The goal on one hand is semantic modeling (and also data abstraction?).
On the other hand, there should be a certain transparancy and control over representation and layout.
The second point is similar in spirit to Lil (the high-level assembler project at bell labs). The history of this project suggests that while a transparent model is good for ease of understanding, abstraction wins. It’s better for portability and a net win for having the higher-level ideas as direct concepts.
Type allow expressing concepts. The control over representation of the models / concepts should be left to compiler directives. If specific representations are needed for performance (e.g. memory alignment, reducing number of copies etc) then they can be hand coded and used as intrinsics just like built-in types (see #6 #11 #16)
The goal on one hand is semantic modeling (and also data abstraction?).
On the other hand, there should be a certain transparancy and control over representation and layout.
The second point is similar in spirit to Lil (the high-level assembler project at bell labs). The history of this project suggests that while a transparent model is good for ease of understanding, abstraction wins. It’s better for portability and a net win for having the higher-level ideas as direct concepts.
Type allow expressing concepts. The control over representation of the models / concepts should be left to compiler directives. If specific representations are needed for performance (e.g. memory alignment, reducing number of copies etc) then they can be hand coded and used as intrinsics just like built-in types (see #6 #11 #16)
https://en.m.wikipedia.org/wiki/Little_Implementation_Language