Timeline for How did Woz write the Apple 1 BASIC before building the computer?
Current License: CC BY-SA 4.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 18, 2021 at 15:25 | comment | added | supercat | Would that accessing characters 1 to 4 of element (1,5) of array A$? Could such an array reserve different numbers of characters for different elements? | |
| Nov 18, 2021 at 14:02 | comment | added | Maury Markowitz | HP did, they used [ and ] as alternatives that allowed A$(1,5)[1,4]. Not sure why no one copied that. It does lead to some confusion porting from HP as well, but that's not much of an issue these days... | |
| Nov 17, 2021 at 17:34 | comment | added | supercat |
Could any string-slicing-based BASICs accommodate arrays of strings? In MS-BASIC, if one says dim a$(3):a$(0)="supercalifragilisticexpialidocious":a$(1)="wow"+str$(ti):a$(2)="ok", one could then output any of those with print a$(index). Could one do such a thing in string-slicing dialects without having to reserve an object with space for 3x34 characters?
|
|
| Nov 17, 2021 at 12:41 | comment | added | Maury Markowitz | Atari BASIC parses everything at edit time, not runtime. As part of this process, it removes quotes from string constants and places a two-byte length token at the front. So the space is exactly that of the original constants, or in this case, 800 bytes. Perhaps I do not understand what you are asking. | |
| Nov 16, 2021 at 16:01 | comment | added | supercat | How efficiently could string-slicing BASICs hold e.g. a list of 100 strings with an average length of 8 but a maximum length of 32? In MS-BASIC, that would take 1100 bytes, but from what I understand in string-slicing dialects it would take 3200. | |
| Nov 16, 2021 at 15:47 | comment | added | supercat | Slicing requires that one know in advance the lengths of strings one will be using, or waste memory on oversized reservations. MS actually gets by with a very low memory footprint if the time spent on GC isn't a concern, and spending a little more effort and ROM space for the GC code would have made it possible to enormously improve its efficiency, especially if string literals (and other strings) had been stored prefixed by length or one were willing to waste a byte per allocation (if only strings with length of at least one were kept in memory, the length byte would suffice). | |
| Nov 16, 2021 at 14:31 | comment | added | Maury Markowitz | @supercat - slicing does not produce a new string, just a pointer. MS functions create new strings. slicing uses less memory, is much faster, and doesn't eat up RAM. | |
| Nov 15, 2021 at 18:10 | comment | added | supercat |
Aside from the fact that the garbage collector was designed to be compact rather than efficient, what's wrong with the MS approach? It could have been improved perhaps with a function to compute mid$(a$, s, e-s) without having to repeat s, or to compute mid$(a$, s, 1) without having to evaluate the 1, but for many tasks it seems as or more convenient than the slicing approach used by e.g. HP BASIC.
|
|
| Nov 15, 2021 at 15:38 | history | answered | Maury Markowitz | CC BY-SA 4.0 |