[e-lang] StaticScope's hasMetaStateExpr definition

[Kevin Reid]

On Jul 23, 2006, at 0:12, Mark S. Miller wrote:
> Kevin Reid wrote:
>> Um. I seem to remember having discussed this already (not on the
>> mailing list) after I asked the above question.
>>
>> My own proposal was that e`...` should return *unexpanded* (full E)
>> node trees, thus allowing composition to happen before any expansion.
>>
>> If we do this, then only E and Kernel-E need exist.
>
> Yes, that is reasonable and would work. There are two things that  
> make me
> uncomfortable with this:
>
> 1) Even trivially different syntactic forms of the "same"  
> expression, such as
> "x + y" vs "x.add(y)", would become distinct cases. OTOH, given a  
> library of
> source-to-source transformers, one could always first apply the  
> transformer
> that did the desired case folding. Since the programmer would then  
> have full
> flexibility in choosing which foldings they wish, maximum  
> flexibility does
> indeed argue for your suggestion.

Yes. The most common case would be e`x + y`.asKernelE().

> 2) If done in the style of the current ENode trees, it requires an  
> explicitly
> different kind of object per syntactic form.

E-on-CL already does this. I offer it as an example.

> How many is it?

E-on-CL introduces 65 additional ENode subclasses. The list is  
included below.

> Does this use justify introducing all those kinds of objects?

- E-on-CL also introduces them in order to separate the execution  
structure of the parser and expander.

- There are likely uses for working with unexpanded code, especially  
if we can add more SourceSpan-like information to preserve comments  
and formatting.

- Why not? What are the costs?

- It seems cleaner to me that nonkernel structures have a data  
representation as well as an E-syntax representation.

> Perhaps a more S-expression-ish representation, such as a term- 
> tree, would be more  appropriate for this use?

To me, there is not really any difference, except in the style of the  
interface. E-on-CL uses macros to define CL classes, but it could  
just as well be done with a single class with a 'node type' slot;  
that is only an implementation choice.


Nonkernel node types in E-on-CL:

AccumExpr
AccumPlaceholderExpr
BinaryExpr
CdrPattern
CoerceExpr
CompareExpr
ConditionalExpr
CurryExpr
DefrecExpr
ExitExpr
ForExpr
ForwardExpr
FunctionExpr
FunCallExpr
FunSendExpr
GetExpr
If1Expr
InterfaceExpr
ListExpr
MapExpr
MatchBindExpr
MessageDescExpr
MismatchExpr
ModPowExpr
NKAssignExpr
NKObjectExpr
NullExpr
ObjectHeadExpr
ParamDescExpr
PrefixExpr
PropertyExpr
PropertySlotExpr
QuasiExpr
RangeExpr
SameExpr
SendExpr
SwitchExpr
ThunkExpr
UpdateExpr
URIExpr
URISchemeExpr
WhenExpr
WhenFnExpr
WhileExpr
BindPattern
CallPattern
FunCallPattern
MapPattern
QuasiParserExpr
QuasiPattern
SamePattern
SuchThatPattern
TailPattern
FunctionObject
MethodObject
PlumbingObject
ETo
MapPatternAssoc
MapPatternImport
MapPatternRequired
MapPatternOptional
QuasiText
QuasiExprHole
QuasiPatternHole
QuasiEscape

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>