> I just started taking a closer look at Enchilada, because I was
> wondering about the feasibility of implementing a version in Cat. Now
> that I have looked at it closer I find it to be a very clever
> language!
>
I'm keeping a close eye on Cat too. Currently I'm implementing
Enchilada in Factor, mostly because Factor is the most mature
concatenative language to date (besided Forth of course but that
language is lacking a strong runtime with a garbage collector).
It will be interesting to see how well Enchilada can ride on top of a
typed language such as Cat. When Cat is finished I'm going to
implement Enchilada on top of Cat, just to see how it will compare to
the Factor version.
>
> Have you considered implementing Enchilada in Haskell? It seems like
> it may be a very nice match given Haskell's lazy nature, and you might
> get some nice type-checking for free.
>
I've done some small subsets of Enchilada in Haskell, OCaml and
Concurrent Clean.
But it seems that Enchilada is better build on top of dynamically
typed languages such as Scheme, Lisp, Smalltalk and .... Factor.
For instance, efficient and seemingless fixnum -> bignum support is
one of the advantages of such languages.
>
> The following are some nitpicky comments about the documentation
Please do nitpick: I'm always trying to improve the documentation.
> - I'd prefer to see the more common terms "unary" and "binary" to the
> lesser well-known terms monadic and dyadic in the documentation.
I got this terminology from APL'ish languages where this idiom is
more common.
Let me check on usage... probably unary and binary is more common.
> - I'd call out the point that there are two data types "expressions"
> and "lists". At first it sounds like there is only one, though on
> closer read I realize that you do not make this claim. Nonetheless it
> is a bit confusing.
I admit that I'm a little bit vague there. However most languages
don't consider operators and expressions as a seperate type (until
Joy came into existence) so I think it's fair that I claim there is
only one. But I guess it's more concise to say - only one *data* type.
> - A table of contents for the manual would be very helpful.
Check... I'll do that.
> - The invariants for division are not correct, since the GCD is not
> always defined. Also you use "gdc" instead of "gcd". It is just a
> minor technical point, your intent is clear enough.
The gcd is not defined for zeros. However, I escape this with the
following statement:
If A or B is 0 then C == A and D == B. So:
0 6 / -> 0 6
6 0 / -> 6 0
0 0 / -> 0 0
2 6 / -> 1 3
6 2 / -> 3 1
... an alternative interpretation is that the / 'sticks' to the
original values when one or two of the operators is zero.
> - ". This feature makes Enchilada one of the few languages that is
> both strong and single typed.". I think this claim is incorrect.
> Virtually every dynamically checked language has a strong type system
> if we reduce all types to a single all-encompassing type (e.g.
> variant, object, etc.)
>
But not every operator of a dynamically typed language can work on
the all-encompassing type.
For instance, you cannot add (+) lists and numbers in Smalltalk,
although both are members of the all-encompassing type object. In
contrast, addition is strongly typed in Enchilada for all data
objects. And because there is only one object type in Enchilada on
which operators operate, this reduces it to a strong and single typed
language.
> - "divide(a,b) a b % {v w=a w - + b / * &} " is quite confusing. Maybe
> this can be alleviated syntactically?
Sure, I can always add some extra symbols to alleviate.
>
> Anyway, great job!
Thanks. To be fair it has been mostly research. This is in sharp
contrast with your work that is targetting for real world usage.
Still, I am trying to prove that Enchilada (or similar concepts) can
serve a niche, that is, SOX compliant programs in a distributed setup :)
Robbert.