Closed zot closed 12 years ago
Maybe have optional type assertions (x :? person) for type checking, as opposed to dispatching. On an error, it could inspect the stack for violated assertions on items that have already been evaluated. Maybe there's a more transparent implementation of memoization, or a better way to tie it into the context stack?
for
f a b::tx c d::ty = code
:
generate a definition for
f a b
that returns
b.f(a, b)->(c)->(d)->dispatcher code
Dispatch code works like a dispatch method in Xtend and dispatches based on d's type. The final method called can be named using the types in the secondary constraints, like f_ty().
Example:
The Leisure code classify p::person s::shoe = concat[ 'Person: ' p ', shoe: ' s]
can (roughly) generate this _classify() method in the Leisure_person class:
Leisure_person._classify = (_p, _s)->
if _s() instanceof Leisure_shoe then @_classify$Z_shoe(_p, _s)
else if Leisure_Object._classify? then Leisure_Object._classify.apply(this, arguments)
else throw new Error("No 'classify' function can handle a 2nd argument with type #{getType s}")
Leisure_person._classify$Z_shoe = (_p, _s)-> _concat()(->_cons()(->'Person')(_cons()(_p)(->_cons()(', shoe')(->_cons()(_s)(_nil)))))
The actual function body goes into Leisure_person._classify$Z_shoe. Further polymorphic definitions would generate other methods and rewrite the dispatch method, Leisure_person._classify(_p, _s)
Change setType and getType to use JS prototypes, with Function as the root -- metadata can be stored in prototype