[e-lang] Bug (0.8.26h): deSrcKit does not handle non-identifier verbs

Dean Tribble tribble at deantribble.com
Fri Apr 30 01:02:47 EDT 2004


> >Options:
> >
> >  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 mailing list