Slicing, not as modern as you thought

[Patrick Schluter]

On Monday, 8 July 2019 at 04:39:10 UTC, Era Scarecrow wrote:
> On Sunday, 7 July 2019 at 14:12:05 UTC, Patrick Schluter wrote:
>> the lowly Sinclair ZX81 already implemented slicing in its 
>> Basic string handling.
>
>  So present in BASIC which Microsoft did.

No, Microsoft BASIC did not have slicing. String handling in it 
was dynamic and garbage collected. Very few string functions 
would work inplace and it was easy to get GC pauses because any 
string operation would allocate new strings all the time: LEFT$, 
RIGHT$, MID$, STR$, RTRIM$, LTRIM$ all would allocate a new 
string.
Most other Basics followed scheme and believe me, there were a 
lot of BASIC dialects in the 8 bit era (TI-Basic, 
TI-Extended-Basic, Sharp Pocket Computer Basic, BBC-Basic, 
HP-Basic, all quite different in syntax and features but all more 
of less following the string handling of MS-Basic). That's why I 
was quite surprised when understanding Sinclair's Basic slice 
syntax. That explains also why, I never was able as a kit, to 
adapt listings in magazines of Sinclair games to my TI-99/4A or 
to my Apple II. A thing that was much easier with other micros of 
that time.


>
>  Keep in mind all 6502's had super limited memory, an 8bit 
> chip, 8bit address space & registers with *SOME* 16 bit 
> addressing options (including using the 0-page, or addresses 
> hard coded).

Sinclair were Z80 but granted, it was not that much better than 
6502.

>
>  So with super limited space and no real memory management (you 
> can sorta allocate space but never free it); That and strings 
> 99% of the time were being replaced (or printed) and not 
> modified in place, it's easy enough to reason they'd rather 
> point to the same address (and not slow it down with 
> duplicating data or have to deal with running out of precious 
> 20k of ram). Arrays in BASIC were as you said, have an offset 
> an a size. But there's no real dup option or the like, or 
> splitting appending or doing interesting and fun things with 
> the GC.

No, string handling in the Basics of the 8 bit micros were all 
fully GC.

>
>  Interesting to bring up. Honestly tinkering with Burrow 
> Wheeling Transformation, i did something similar, doing a 
> single short array to slice and make a huge number of arrays, 
> but keeping allocation to a minimum (more for performance 
> reasons and not for minimal memory usage).
>
>  Also, you could have easily done the same thing in C anyways, 
> as it's all just pointers and ints anyways, nothing would be 
> stopping you from pointing to the middle of a string and then 
> just saying it's N length (unless you absolutely required the 
> \0 terminating byte).

The game changing detail in D is that [] is a fat pointer 
supported by the language. So no heroic efforts to bind the 
pointer with the length as is require in C.