07-06-2014, 05:05 PM
From the Wiki:
"SAVE "xxx" DATA <varname>( )
This behaves like the original Sinclair BASIC, but here you can save/load/verify not only arrays, but single variables. Parenthesis can be omitted (in Sinclair BASIC they were mandatory). You can also use LOAD/VERIFY with this.
SAVE "xxx" DATA
With no varname saves ALL the entire user variable variable área plus the HEAP memory zone. That is, it saves all the program state. You can also use LOAD/VERIFY with this."
So I used SAVE "Content" DATA ArrayOfContent (). I did not omit the parenthesis and use ArrayOfContent nor did I use ArrayOfContent (0) were 0 stands for the first element in the array. I only wanted the array data or the contents of the array saved but it did not work contrary to what the wiki says and what the original language was capable of.
Boriel wrote:
"Save data with strings is complicated because they're dynamic."
I know, all of those pointers pointing to various places in memory and if one element chances size and becomes bigger then it has to be relocated and the pointer changed leading to fragmentation of the linier data causing it not to become linier or if it becomes smaller, well, basically same effect in the end. This is not trivial to get around I know. But in my instance all I needed was the contents of one particular string array and not all the other stuff that was on the heap and data area as it would have seriously gotten in my way leading to a lot of extra work and problems, a very dirty and unclean approach. So I was FORCED to write my own routines and cycle through the array and poke it's contents to a memory area that was above the boundaries of the compiled program and to get it back I had to read from that memory location through peek and a temporary string variable and then assign that temporary variable to the array again. If only that worked because of the ArrayName(Index)=TempVar bug, so it was time for yet another workaround. But there is a problem with this approach, I have to write my own routines and they take memory and if I am working with large string arrays then this approach doubles the memory they take contents wise.
But I have been thinking, would not a functionality similar to REDIM solve this and that functionality is then to be deployed automaticly when the program encounters
SAVE DATA ArrayName, string or numeric. That should get the contents arranged in a linier fashion so it can be saved out in a proper fashion.
Like I said, it is the little things like REDIM, ERASE and SELECT CASE, DIM ArrayName(1) AS STRING => {"Hello","I am a string array"} [Index base 0] in the absence of
DATA lines and ByRef, ByVal including arrays and optional parameters and a warning disabling scheme that make or break a language and/or a compiler. Along with
proper FOR/NEXT loops instead of the C style loops that are now used and if the compiler sees in can get away with using C style loops then it should be smart enough to use it without any user intervention in the form of switches.
To me this is bare minimum. Note I did not go into asking for support for TYPEs, a standard fare with QBASIC; or UNIONS, or OOP or a switch from 40bit floats to 32bit
floats and that should lessen ZX ROM dependency making the compiler even more retargetable to other machines than it is right now. Nor am I asking for that all commands to use the heap like both of the SAVE and LOAD commands as that lessens even more the dependency of platform specific configurations and not to mention it makes the compiler more consistent. And I did not ask for more input/output choices like the ability to deal with 128K disks and RAM disks or even the disk systems that are available for the 48K machine. Put all of that together then you have a real usable compiler, well, maybe apart from OOP and UNIONS, that reaches beyond the bare minimum. After that UNIONS and OOP and 128K memory management and the support for the PLAY command can be considered to make an outstanding compiler.
But as it is, despite of the excellent refactoring effort, the compiler does not reach the bare minimum that can then be built upon.
My thoughts.
"SAVE "xxx" DATA <varname>( )
This behaves like the original Sinclair BASIC, but here you can save/load/verify not only arrays, but single variables. Parenthesis can be omitted (in Sinclair BASIC they were mandatory). You can also use LOAD/VERIFY with this.
SAVE "xxx" DATA
With no varname saves ALL the entire user variable variable área plus the HEAP memory zone. That is, it saves all the program state. You can also use LOAD/VERIFY with this."
So I used SAVE "Content" DATA ArrayOfContent (). I did not omit the parenthesis and use ArrayOfContent nor did I use ArrayOfContent (0) were 0 stands for the first element in the array. I only wanted the array data or the contents of the array saved but it did not work contrary to what the wiki says and what the original language was capable of.
Boriel wrote:
"Save data with strings is complicated because they're dynamic."
I know, all of those pointers pointing to various places in memory and if one element chances size and becomes bigger then it has to be relocated and the pointer changed leading to fragmentation of the linier data causing it not to become linier or if it becomes smaller, well, basically same effect in the end. This is not trivial to get around I know. But in my instance all I needed was the contents of one particular string array and not all the other stuff that was on the heap and data area as it would have seriously gotten in my way leading to a lot of extra work and problems, a very dirty and unclean approach. So I was FORCED to write my own routines and cycle through the array and poke it's contents to a memory area that was above the boundaries of the compiled program and to get it back I had to read from that memory location through peek and a temporary string variable and then assign that temporary variable to the array again. If only that worked because of the ArrayName(Index)=TempVar bug, so it was time for yet another workaround. But there is a problem with this approach, I have to write my own routines and they take memory and if I am working with large string arrays then this approach doubles the memory they take contents wise.
But I have been thinking, would not a functionality similar to REDIM solve this and that functionality is then to be deployed automaticly when the program encounters
SAVE DATA ArrayName, string or numeric. That should get the contents arranged in a linier fashion so it can be saved out in a proper fashion.
Like I said, it is the little things like REDIM, ERASE and SELECT CASE, DIM ArrayName(1) AS STRING => {"Hello","I am a string array"} [Index base 0] in the absence of
DATA lines and ByRef, ByVal including arrays and optional parameters and a warning disabling scheme that make or break a language and/or a compiler. Along with
proper FOR/NEXT loops instead of the C style loops that are now used and if the compiler sees in can get away with using C style loops then it should be smart enough to use it without any user intervention in the form of switches.
To me this is bare minimum. Note I did not go into asking for support for TYPEs, a standard fare with QBASIC; or UNIONS, or OOP or a switch from 40bit floats to 32bit
floats and that should lessen ZX ROM dependency making the compiler even more retargetable to other machines than it is right now. Nor am I asking for that all commands to use the heap like both of the SAVE and LOAD commands as that lessens even more the dependency of platform specific configurations and not to mention it makes the compiler more consistent. And I did not ask for more input/output choices like the ability to deal with 128K disks and RAM disks or even the disk systems that are available for the 48K machine. Put all of that together then you have a real usable compiler, well, maybe apart from OOP and UNIONS, that reaches beyond the bare minimum. After that UNIONS and OOP and 128K memory management and the support for the PLAY command can be considered to make an outstanding compiler.
But as it is, despite of the excellent refactoring effort, the compiler does not reach the bare minimum that can then be built upon.
My thoughts.