3 ms·

[1] https://en.wikipedia.org/wiki/MUSIC-N https://en.wikipedia.org/wiki/MUSIC-N [2] https://en.wikipedia.org/wiki/Nyquist_(programming_language) https://en.wik

[1] https://en.wikipedia.org/wiki/MUSIC-N https://en.wikipedia.org/wiki/MUSIC-N [2] https://en.wikipedia.org/wiki/Nyquist_(programming_language) https://en.wikipedia.org/wiki/Nyquist_(programming_language) [3] https://en.wikipedia.org/wiki/ANIMAL_(image_processing) https://en.wikipedia.org/wiki/ANIMAL_(image_processing)

deleted 4y ago
[deleted]
deleted 4y ago
[deleted]
sargstuff 4y ago
Was looking for lists of underlying lisp hardware DS / (ebnf) terminal node (aka lisp 'cons' form ) for a given lisp implimentation. ** x = 1 aka s-expression cons on symbolics machine would map to a linear array / stack. ** x < log(1) Are there modern non-stack based follow-ups? aka revised symbolics approach, not necessarily in direction symbolics went, perhaps ranslations to asci / neural net / 'dna' organizational hardware? *** x > log(1) Guess lisp using math to not get in the way of language designer/programer to allow language to conform to subject at hand doesn't make for similar categorical discussion as algol family of languages. Lisp lanuage & reasoning for dialect closest 'broad category/taxonomy of dialects' without getting into specific subject domain / 'what lisp get's compiled to'. aka: ** Lisp generational groupings per ebnf terminal node: 1st generation, use of "point" forms : encoding schemes / Lisp macro -- data 'point' 2nd generation, use of functional forms : scheme -- line segment / group set 3rd generation, use of topological forms : Haskel / ARC -- function
- deleted 4y ago
  [deleted]
- sargstuff 4y ago
  The concept was to reference with other languages where higher-dimensional representation breaks down because of initial implicit hardware issues / assumptions at language design time. examples: lisp -- mapping to popular stack/register hardware. C -- pointers & malloc implications snobol's successor icon -- pre-database '70's design descision on how to handle 'table' type (where today table can be key:pair, graph, document, heirarchy and not just a vector set)

deleted 4y ago

[deleted]

deleted 4y ago

[deleted]

sargstuff 4y ago

Was looking for lists of underlying lisp hardware DS / (ebnf) terminal node (aka lisp 'cons' form ) for a given lisp implimentation. ** x = 1 aka s-expression cons on symbolics machine would map to a linear array / stack. ** x < log(1) Are there modern non-stack based follow-ups? aka revised symbolics approach, not necessarily in direction symbolics went, perhaps ranslations to asci / neural net / 'dna' organizational hardware? *** x > log(1) Guess lisp using math to not get in the way of language designer/programer to allow language to conform to subject at hand doesn't make for similar categorical discussion as algol family of languages. Lisp lanuage & reasoning for dialect closest 'broad category/taxonomy of dialects' without getting into specific subject domain / 'what lisp get's compiled to'. aka: ** Lisp generational groupings per ebnf terminal node: 1st generation, use of "point" forms : encoding schemes / Lisp macro -- data 'point' 2nd generation, use of functional forms : scheme -- line segment / group set 3rd generation, use of topological forms : Haskel / ARC -- function

deleted 4y ago
[deleted]
sargstuff 4y ago
The concept was to reference with other languages where higher-dimensional representation breaks down because of initial implicit hardware issues / assumptions at language design time. examples: lisp -- mapping to popular stack/register hardware. C -- pointers & malloc implications snobol's successor icon -- pre-database '70's design descision on how to handle 'table' type (where today table can be key:pair, graph, document, heirarchy and not just a vector set)