[e-lang] Bug (0.8.26h): deSrcKit does not handle non-identifier
tribble at deantribble.com
Fri Apr 30 01:02:47 EDT 2004
> > 1. E.call/3
> > 2. e.enable.verb-string
> #2 would require accepting this switch into the language. I'm inclined to do
> so, because it allows Kernel-E's semantics to be more independent of any
> particular choice of surface syntax. In the expression of a Kernel-E program
> as a term-tree AST, in order to interface well with tamed legacy libraries
> (as here) it makes sense to allow any string as a verb. For example, I could
> imagine that the E-on-Squeak effort may find it convenient to be able to
> invoke, for example (in the proposed E surface syntax): 'x."at:put:"(i, v)'.
> Dean, would you indeed find this helpful?
Definitely. I'm learning C# and noticed that it has a similar but more
general mechanism: @"blah blah" is the identifier <blah blah> and can be
used anywhere an identifier can be used. This provides the ability to
access libraries from other languages, etc.
> If we allow this in Kernel-E ASTs, then we would still need a way to
> represent these ASTs in the E surface syntax for Kernel-E. #2 does that. #1
> doesn't, since it represents a distinct Kernel-E expression, even though
> it's an expression with the same meaning.
> So let's experiment with e.enable.verb-string. If we like it in practice,
> then we'll take it from there.
> (I realize one could make the same argument in favor of allowing
> non-identifier variable names, but I won't make that argument ;).)
Ooops I just made that argument.....
More information about the e-lang