Tunes HLL TODO list
TODO,v 1.2 1998/12/03 17:32:09 fare Exp

* As the HLL-Scheme is expressive enough,
 encode calling conventions with routines,
 so that they can be used automatically,
 abstracted,
 etc.

E.g.:
	(declare-procedure Print-Char
		(Params		; aka explicit params
		   (name: c
		    in: al
		    type: char
		    english: "character to print"
		    francais: "caractre  imprimer"))
		(Assumes	; aka implicit params
		   (standard-LLL-segment-setup))
		(USE		; Unwanted Side Effect
		   (spoils bx)
		   (uses-up-to-n-stack-levels 3))
		(Does
		   ((mov ebx ...)
		    ...
		   )))

* Instead of writing a monolithic asm program,
 we'll define chunks of code, that call each other.
 When the compiler optimizes,
 it will automatically detect programs that have only
 one escape so that it will place code chunks in sequence that
 minimize the number of jumps.


* Partial evaluation:
 we must define how operators like "/" can be computed,
 at several stages of the assembly.
 It could done by "div" operations (at init or runtime or anytime)
 or by the assembler as86,
 or by the HLL-


* When importing parameter contexts from other modules
 that are exported afterwards,
 actual modules imported may or may not define extra symbols
 from those required

* type of an object includes all constructors this object depends on.
 evaluating consists in reducing this set of constructors,
 until some irreducible state is reached.

* by redefining basic operators,
 it should be almost gratuituously        to modify the whole system,
 with constructed values being deduced again from 

* in the HLL-, typing, module interface/implementation are discussed.
interface/implementation is just the problem of defining explicit & implicit
parameters.

* X86 asm/disasm is done by pattern matching. What should the
 syntax be ?


* pattern matching: using quotes and quasiquotes. These do not prevent
 evaluation below, but just unification.
 for instance, the pattern 'a matches anything whose value is the
 same as a, while pattern ''a matches only symbol a.
 This means that patterns of patterns will quote a lot...
 
* Higher-order patterns: there are patterns that match functions
For instance, if f matches F
(lambda(x) (f y))

* The symbol --> attribute
  and attribute --> (object->value)
  mappings is similar to the extent mechanism in the paper from PP.
  That values be locations as well as constant values is an
  orthogonal issue.

* The quasi-static bindings is lambda-calculus with call-by-symbol instead
 of call-by-position. Combined with extents, it would solve some
 alpha-conversion problems.
 Implicit resolving of quasi-static bindings is exactly what I called
 the "escape mechanism" for the HLL.

* The side-effect detection optimization *should* make a difference
 between wanted side-effects and unwanted side-effects.
 For instance, using the heap and possibly causing memory overflow
 is a side-effect, but not a wanted one, so if it could be optimized
 away, let's do it. Waiting in an idle loop is also often useless.
 On the contrary, some side-effects, even though we can prove their effect
 will eventually  get overwritten, are necessary: for instance, logging
 the current heap state consistently into persistent memory
 involves writing to disk information that needn't ever be read back,
 unless a crash occurs, in which case it'll prove of foremost importance.
 Even memory&time consumption from program whose result is known may
 be important at some point (i.e. benchmarks), while idle loops may be
 necessary to synchronize with I/O devices.

* It should be possible to give default values to stuff, yet
 allow other values to be used, and prevent the compiler from
 inlining those values.
