HLL in Scheme

Francois-Rene Rideau rideau@ens.fr
Wed, 31 Jan 1996 20:40:52 +0000 (GMT)


Dear Patrick,
   here are some comments on your fine work at translating m4 macros
into Scheme code:

[Source organization]
   I know that documenting is a hassle,
but it would be nice if you wrote some README in the manner of what I did,
to explain roughly what is where.
   In particular, it would be nice if you tried
to have a clear way to look in the new sources
for code whose location in former sources we know.
   If you're not satisfied with the former organization,
do not hesitate to move things around,
but please document,
and split into subdirectories as necessary (or just prefix the filename).


[Reflection]
   What m4 lacked most
was the possibility to easily define new defining words.
This is why I had to always used the m4 define macro.
But with Scheme's powerful reflection,
it becomes possible (through macros, or if we interpret the HLL)
to define defining words that would match better the HLL object system.
   There would be such statements as
define-type, annotate-object!, define-annotated-object, etc.
Define-type would itself define
defining words (constructors) and access words (destructors)
for objects of the given type,
that would type-check arguments, and raise exceptions when invalid.
   Type-checking and all this meta-defining would be done
in a parametrized reflective way,
each type having a type that tells how to define, etc,
until we reach some founding meta-type in the system,
which has hardcoded behavior in Scheme.


[Implementing Annotations]
   Of course, there will be annotations directly reflected into scheme
objects by the Scheme representation of the HLL-.
   A trivial implementation for generic HLL- annotations could be based
on a per-object alist of (attribute . value) association
(which would allow GC of objects, though not GC of attribute).
Every attribute thus defined would have a "default behavior"
when no hashed value is found
(itself most probably being looking for a default value to give,
or else escaping to what would eventually be the user-interface).
Attributes might also have a hook to call whenever
a value has been computed, with the object, attribute, value, and
previous alist element as parameters.
This way, logging, profiling, scheduling, debugging, maintaining
cross-attribute consistency, etc, could be done easily.
   An optimization for such attributes would be to have some attributes
stored as fixed "members" of objects, in a class-dependent order (the class
itself being taken from the context, the former alist, or a fixed place in
the object).

   The problem with the former implementations is for the identity
of annotated object. Say you want (my-cons 1 2) to return always identical
objects as of some annotation. Either you find a way for my-cons to hash
all its former results so it would not return a new object, or you
must have rather a annotation-based association table.
More generally, when annotations are results of computations,
there is a need for an common association table
for all possible computed values.



[Types, classes, etc]
   The default type system could be of trivial nature:
just test for a "tag", not type-checking components (that's what you do).
   Now, the tag needs not be a constant symbol, but should rather be
the scheme representation for the HLL type of the object.
   More elaborate checking would rather be unification of types
(when applying a typed lambda-term), so type-checking should be
a reflectively parametrized method of type destructors, that would
be defined by ("inherited from") the meta-class of the class.


[Examples]

In the i386 assembler, the following definitions could be used:

  (definition i386-register-set
     (has-attribute			; handy macro to define an attribute
       set-name				; name of the attribute
       (known-type (hll-set hll-name))	; type: a set of identifiers
       (to-be-continued))		; set-name will be continued
     (known-type		 ; technically, register set is an annotation
       (annotation		 ; associates
         (('category . set-name) ; to a element of set-name called category
          ('size . hll-integer)) ; and an integer called size
          ((enumerated-type)) )) ; an enumerated type
     (known-attribute known-values
	      (auto-type-cast	 ; will transform
	      			 ; symbols into elements of set-name
				 ; (which will be augmented)
				 ; and Scheme lists into HLL enumerated types
				 ; like C enum's that allow
				 ; to extract register number from its name
				 ; when actually assembling
      '(((genreg   8)  (al  cl  dl  bl  ah  ch  dh  bh))
        ((genreg  16)  (ax  cx  dx  bx  sp  bp  si  di))
        ((segreg  16)  (es  cs  ss  ds  fs  gs))
        ((exereg  16)  (ip  flags))
        ((genreg  32)  (eax ecx edx ebx esp ebp esi edi))
        ((exereg  32)  (eip eflags))
        ((ctrlreg 32)  (cr0 cr1 cr2 cr3))
        ((trapreg 32)  (tr0 tr1 tr2 tr3 tr4 tr5 tr6 tr7))
        ((dbugreg 32)  (dr0 dr1 dr2 dr3 dr4 dr5 dr6 dr7))))))

Once the definition is closed, its contents are resolved,
set-name is closed, too, etc.
Now, whenever the i386-register-set is opened,
ax will refer to the given register.
The assembler and disassembler could use the index of registers
in the enumerated set to encode and decode binary instructions.



[Summary]
   The HLL- should most probably be implemented as an "open-implemented"
interpreter, where most objects' implementation would reflect into
HLL- -defined meta-objects, until some special tag is found that the
interpreter reflects into Scheme code.
   The target of the compiler could reflect objects into the LLL model
at different places that the interpret does, so the LLL needn't implement
Scheme (but still may).

--    ,        	                                ,           _ 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/"