[e-lang] Announcing E 0.8.26g: Many small breaks with the past

[Kevin Reid]

Miller, Mark <erights@hp.com> wrote:

> Kevin Reid wrote:
> > Mark S. Miller <markm@caplet.com> wrote:
> > ...
> > > Non-Upwards Compatible Changes
> > ...
> > >     Retiring Previously Deprecated Features
> > >       *       e.enable.dot-props property has been retired. Rather than
> > > the old "bob foo(carol)", one must now write "bob.foo(carol)".
> > 
> > I think you mean e.enable.no-paren-call.
> 
> Oops. Good catch, but I meant neither. I mean instead the
> e.enable.no-dot-call. I've fixed the highlights page.

Oops! Of course.

> > (Den currently uses get/2 heavily. If running Den is a problem for you
> > due to this, I'll install 0.8.26 and work on getting Den updated to
> > match.)
> 
> Yes thanks, I'd appreciate that.

I'll post when I have done so.

> > For a while I've been thinking of a generalization of this - a
> > PassByCopy struct maker, something like:
> > 
> > def makeStruct(data :Map[[String, List], any]) :any {
> >   def struct implements PassByCopy {
> >     match msg {
> >       data[msg]
> >     }
> >   }
> > }
> > 
> > For example:
> > 
> > def makeValueThunk(value) :any {
> >   makeStruct([["get", []] => value])
> > }
> 
> Weird and interesting. Hmmm... I need to stew on this.

It's essentially a variety of non-Turing-complete mobile code.

Only somewhat related question: is it currently possible for
E-implemented objects to control how they are passed over a CapTP
connection?

> > > First Draft Causeway Code Included
> > 
> > Wild speculation: Causality tracking for eventual sends?
> 
> Yes! See http://www.eros-os.org/pipermail/e-lang/2002-November/007811.html.

General thought:

There must be a finite limit on how much history is kept. Much
computation across turns happens in the form of what would be
essentially tail-calls in synchronous execution (for example, the
EverReporter/Reactor interface).

-- 
Kevin Reid