The Tunes HLL Syntax

Language syntax is a matter of conventions. No one expressed any preference yet, and existing languages of interest are many, each with its own completely different syntax. See the Semantics page.
I guess we'll have to define the HLL as multiple extensions to existing languages, then refine it to obtain cleaner things. All this is pure draft.
So which some existing syntax to start with: BETA ? SELF ? CECIL ? Dylan ? LISP ? Haskell ? CAML ? SML ? C ? Perl ? Python ? Icon ? Oberon ? FORTH ? Esperanto ? Latin ? French ? English ?


HLL-

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.



Standard Basic constructors



Standard Library of language extensions

That's worth a whole subproject...


Syntactic Difficulties

What was previously in HLL.doc:
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 ?


To Do on this page

  • Make first proposals.
  • Allow meaningful indentation on any syntax
  • Think about how to embed syntaxes in each other
  • Settle full HLL syntax.
  • Be faithful to the semantics.
  • Wait for feedback, as usual.


  • See the Tunes HLL Semantics.
  • Back to the Tunes HLL Subproject.


    Page Maintainer:
    Faré -- rideau@clipper.ens.fr