Reflectivity and extensibility of the HLL

[Francois-Rene Rideau]

> are we talking about the same thing? when i talk about s-expr i am
> refering to their use to describe language constructs like let, if, 
> function calls, etc.  NOT to describe how objects in general should be 
> stored in memory, etc.  Obviously, objects in memory should be stored in 
> some abstract and black box method and i would never suggest that lists 
> are the best representation for that, much less one proscribed by any 
> language definition.
   Well, ok, then. I admit you can use s-exps this way. People used to it
may like it, as well as implementers for a simple layered parser (though
I'm convinced it is not such a great win as presented to be). But I see
many good reasons why people should dislike it, too.


> i see no restriction to s-expr... however it certainly, as i mentioned above,
> is a great deal easier for the programmer to extend to language in complex
> ways.  i would like to know of another language that would allow me to
> write programs that can extend the language interactively with the
> compiler, within the same environment, and not use s-expr.  in lisp, i can
> add to the compiler itself to dynamically alter and add to the language 
> using the full power of the language to do so.  sorry for the 
> evangilizing but i just don't see how that could be done using an 
> arbitrary syntax (perhaps i don't need to know)
   Extensible grammars are being done in Coq, though Coq isn't reflective
and doesn't have first-order grammars :(. Just to say that LISP may be the
most reflective language known to date [I've heard that BETA could beat it],
but that doesn't mean no other language provide a cleaner reflectivity.
   I propose that at the language semantics, something I call "dynamical
active annotations" be defined, by which one can extend the semantics of
objects in a way that it doesn't affect the current semantics [for obvious
eficiency, privacy, etc, reasons, such one must be able to disable such
active annotations on what I call "closed" objects]. Use of such semantical
extension is just impossible or useless if a fixed low-level encoding is used;
   I intend to build the higher-level parts of the HLL like garbage
collection, etc, using just such annotations on top of a very low-level
language; I intend to use the same extension trick to implement efficiently
high-level construct in terms of lower-level objects.


> i agree that a good structural editor would be damn spiffy.  however the
> errors i had in mind could not really be caught by such a editor.  i
> misnamed them when i said syntax errors, because these errors can be
> perfectly legal - i'm thinking about errors due to precedence such as * vs
> + and other operators where the programmer has to remember what happens
> first..  these kind of syntacically correct errors are the thing that
> cause me the most grief.
   Well good structured editor could very well go down to the structure
of operators, too. You could ask it to put the parentheses everywhere,
or just for operators you mismanage usually. You could ask it to put
programs in prefix, infix, or postfix notation, or any combination of
that, etc.


> again, agree about the implementation thing but thats not what i had in 
> mind. i was suggesting that the parser could be part of the language.
> this would allow individuals to create their own syntaxes. as long as 
> the grammer were around to reflect on the syntax, that language would be 
> fully portable and integratable with eveyone elses syntax. that way, you 
> can program with your syntax and i'll use s-expr :)
   Yes. That's what I've been thinking about. So firstly, we must allow
semantics-based higher-order use of constructors *and* deconstructors;
and then we must have grammars as first-class objects. To me, grammars
are just translators/functors/morphism mapping some structure to another.
They are meant to essentially conserve the structure, but you choose to
translate in what direction because it goes toward the direction of
evaluation you want.

--    ,        	                                ,           _ v    ~  ^  --
-- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban --
--                                      '                   / .          --
Join the TUNES project for a computing system based on computing freedom !
		   TUNES is a Useful, Not Expedient System
WWW page at URL: "http://www.eleves.ens.fr:8080/home/rideau/Tunes/"