The HLL- will be the initial implementation for the HLL, written as s-exps interpreted by a program written in Scheme.
The HLL- will basically have all Scheme constructs, with ones like car and cdr being deprecated, and support for the number type tower being postponed, while some extensions will be added: annotations, first-class environments, a reflective interpreter, a CPS macro system, a pattern matching system, a module system.
Features of the full HLL it won't have are
arbitrary syntax (arbitrary s-exp syntax only),
weak pointers (R4RS Scheme doesn't support them) with finalizers,
modules to define LLL types, etc.
But the compiler ought to eventually support them.
HLL words needed: [Plurals generally accept a list of argument over which it maps the singular keyword] Module (Module) defines a module which is an object to close with various bindings (static, quasi-static, dynamic, whatever). Copyright-Notice (Copyright-Notice ) standard attribute for modules Version (Copyright-Notice ) standard attribute for modules Local (Locals ) define unexported object Variable (Variable [ ]) defines a typed variable Syntactical scopes: ; ; is a list of recursive definitions, each of the form ; 1 ::= 1 and ... and n ::= n ; ; ; is a left-hand side of definition, of the form ; for an identifier ; or ( ) for a functional definition with parameters ; ; ; is a list of parameters, each of the form ; for an identifier ; or ( ) for a typed identifier ; or ( ) for a type without identifier ; Basic abstractions: * annotations * environments as interned symbol->value annotations * patterns as interned object->environment->new-environment S Basic concretizers: * hash tables * The MOCK paradigm for object semantics: we have meta(n) constructors and destructors. I'd like for instance, to say that object K is to be observed with a set of observable O, and that its semantics is that the set of possible modifications is M. Then, I don't care how it is implemented, but I wish it be as efficient as possible as for cost function C. The semantical relations between M,O,C,K should be specifiable in a language as expressible as possible: it shall include higher-order logic as well as notions of time, space and communication cost, and to allow implementation and interfacing of low-level objects, it should also include as complete low-level machine descriptions as possible. The specification could make the semantical relations explicit, and let the computer find implementations. Or it could propose an implementation, and let the computer find the abstract semantics it understands. Or (ideally) it would give enough of both so that program execution as well as program manipulation are easy. In any case, given these M,O,C,K semantics, everything is allowed to the system, and the way to express them is the calling convention. If better ways to express them are found, the calling convention will be changed, and hopefully, some translator is expressible in both calling conventions, so that the whole system may be translated on the fly. Pretty high-level isn't it ?
Page Maintainer: