so, been working hard on #moxie compiler for the last couple of weeks, and the current issue i'm dealing with is memory management.
as up to now, it's been one foot in GC world and one foot in ownership semantics.
currently i am working on some changes in the underlying semantics of dynamic array (slice) handling. Go's model uses the idea of "grow at append" automatically. this is doubly complicated, firstly, shared handles to subslices, and then, compound that with *concurrent* shared handles to subslices (aliasing).
i'm eradicating aliasing. instead, the default posture is copy semantics. when you subslice in moxie, it's implicitly a copy.
if you want to mutate a buffer, you use a cursor-based iterator like io.Reader/io.Writer
if your operation will not expand or more likely reduce (eg, unescaping text) you can do this with two iterators on the same buffer where the writer is before the reader.
if your operation requires expanding the buffer (eg, decompression, escaping) you have to write the copy into a new buffer.
none of this is especially cutting edge ideas but some language projects have taken one direction, while others take others. the functional drones tend to love copy semantics, and the object/imperative drones tend to like references.
i reject both as being sole solutions. sometimes copy is right. sometimes reference is right. being wedded to one or the other is retardation.
as up to now, it's been one foot in GC world and one foot in ownership semantics.
currently i am working on some changes in the underlying semantics of dynamic array (slice) handling. Go's model uses the idea of "grow at append" automatically. this is doubly complicated, firstly, shared handles to subslices, and then, compound that with *concurrent* shared handles to subslices (aliasing).
i'm eradicating aliasing. instead, the default posture is copy semantics. when you subslice in moxie, it's implicitly a copy.
if you want to mutate a buffer, you use a cursor-based iterator like io.Reader/io.Writer
if your operation will not expand or more likely reduce (eg, unescaping text) you can do this with two iterators on the same buffer where the writer is before the reader.
if your operation requires expanding the buffer (eg, decompression, escaping) you have to write the copy into a new buffer.
none of this is especially cutting edge ideas but some language projects have taken one direction, while others take others. the functional drones tend to love copy semantics, and the object/imperative drones tend to like references.
i reject both as being sole solutions. sometimes copy is right. sometimes reference is right. being wedded to one or the other is retardation.
1