[prev in list] [next in list] [prev in thread] [next in thread] 

List:       e-lang
Subject:    [E-Lang] Syntax Experimentation?
From:       "Mark S. Miller" <markm () caplet ! com>
Date:       2001-10-27 16:11:23
[Download RAW message or body]

In private correspondence, Zooko expressed frustration at our reluctance to 
make further non-upwards compatible syntax changes to E.  He pointed to a 
mechanism in recent Pythons for enabling (or disabling?) new syntax features 
of Python on a *per module* basis, effectively supporting both upwards 
compatibility and escape from the past (within limits) at the same time.

While I remain as reluctant as ever, I think this kind of experimentation is 
a good thing.  The existing 'pocket' mechanism in 0.8.10alpha1 was intended 
to support this, as a way of enabling or disabling certain syntactic 
features, but it's global rather than per-module (the eprops.txt file), so 
it's really not practical.

Coming in the next release, 'pocket' features, like "e.enable.dot-props" 
(demonstrated below), which are globally set to "allow" (in addition to the 
existing "true" or "false"), may then be enabled on a per-module basis using 
"pragma". "pragma" was already a reserved keyword, so this change itself is 
upwards compatible.  In the next release, many of the syntax features 
currently set to "false" by default will instead be globally set to "allow" 
by default.

All 'pocket' features may be disabled by pragma on a per-module basis as 
well, irrespective of how they're globally set.

As the following Elmer transcripts demonstrates, the mechanism is already 
working in the development version of E.

    ? interp.props() size()
    # syntax error: The optional e.enable.dot-props feature in eprops.txt is currently off.
    #   interp.props() size()
    #                     ^
    #
    
    ? pragma enable("dot-props")
    ? interp.props() size()
    # value: 79
    
    ? interp.props size
    # syntax error: The optional e.enable.no-paren-call feature in eprops.txt is currently off.
    #   interp.props size
    #                   ^
    #
    
    ? pragma enable("no-paren-call")
    ? interp.props size
    # value: 79
    
    ? pragma disable("dot-props")
    ? interp.props size
    # syntax error: The optional e.enable.dot-props feature in eprops.txt is currently off.
    #   interp.props size
    #                   ^
    #
    
    ? interp getProps size
    # value: 79

This should be adequate to support many syntax experiments, and even for 
such experiments to be bundled with a release, even before there's any 
agreement on making them an official part of E.  This allows us all to play 
with these proposals prior to deciding.  Zooko, thanks for pushing us in 
this direction.  I'm glad we can now support this kind of distributed 
pre-decision experimentation.

Y'all should feel free to perform your experiments with 0.8.10alpha1, even 
though it doesn't support per-module switching.  As long as you make them 
globally switchable with the 'pocket' mechanism (see class EBuilder), it'll 
be easy to then make them locally switchable by pragmas in the next release 
of E.  Go wild.

Of course, it's still a serious decision to incorporate code into the code 
base and we'll treat it as such, even if the feature is off or allow by 
default.  It still has a real maintenance cost.  Also, the scarcity of 
our time and our own estimate of the priority may cause us to seem to be 
dragging our feet on evaluating a submitted change.  Such is life.  In the 
meantime, of course, you are free to create, announce, and distribute your 
experimental variant of E.  If all your changes are switched and default 
"allow", then your variant will be fully compatible with the official 
(erights.org) release of E.

I'm pleased to report that this mechanism only took about an hour to 
implement, which is much less time than has already been spent discussing 
our reluctance to change the syntax.

Note that any pocket features which are not on by default in a given release 
(globally set to "true") are not part of the official E language as of that 
release, and there is no commitment to even support them as optional 
features in future releases.

I will be travelling and out of touch until Wednesday, so don't expect any 
responses from me till then.  But I will read all email in this thread once 
I return.


        Cheers,
        --MarkM

_______________________________________________
e-lang mailing list
e-lang@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/e-lang

[prev in list] [next in list] [prev in thread] [next in thread]