[<<][staapl][>>][..]
Fri Sep 26 10:45:23 CEST 2008

Type system for Coma functions

Path: Coma identifiers need to be linked to compile time information.
How to implement this?  I'm already using this space for Forth
parsers, so it requires a different ns..  Time to look at how Typed
Scheme does this.

Now, as long as one stays within the primitives + composition model,
this seems rather trivial.  Base types could be derived from primitive
stack code pattern matching rules, and composition is just figuring
out all the branches that are taken depending on Coma run-time..

If there is remaining dynamic dispatch based on the value of
instructions, then this won't work: search space will explode
exponentially.  So the move to real agebraic types might be
necessary..

I.e. something like [qw n] -> (if (n < 0) [qw -1] [qw 0])
Here 'n can't be determined at compile time, but it still generates a
[qw ...] type in any case.  When the two branches do not generate the
same type, this gives a problem, since it requires type unions (to
simplify) or an exhaustive search.

There is also a problem with Scheme -> Coma metaprogramming: how to
introduce typing info there?  This requires a binding form that allows
information to travel at compile time.

  (let ((abc 123))
    (let-macro ((foo (macro: 1 +))
                (bar (macro-value abc)))
       (macro: bar foo)))


Roadmap:

  * Figure out where this kind of dependency is used in an essential
    manner.  Go from there to decide on what kind of restrictions to
    impose.

  * Scheme -> Coma template programming then requires some annotation.
    This could be solved by using a special binding form that
    introduces local Coma words, so is not an essential problem, but
    does reduce the freedom a bit in how to formulate things.


I do wonder if this is the right way to go..  This is a can of worms.
I'm better of starting with a typed language to build a similar system
to see where the problems are..  Most code in Staapl is structured
enough so it can be straightforwardly translated to Ocaml or Haskell
code.


Conclusion: stay with the current implementation, and gradually allow
static checks to be introduced.  Avoid conversion to a full static
type system until the problem is understood (an implementation in a
typed language is working.)

Looks like the road to follow is more towards Typed Scheme instead:
this already is written from the viewpoint of integrating with a
dynamic language.





[Reply][About]
[<<][staapl][>>][..]