The story of E, part 2 (fwd)

[Ka-Ping Yee]

More forwarded correspondence...


Ping                                            Talk back to the Web!
<ping@lfw.org>                                       http://crit.org/

---------- Forwarded message ----------
Date: Thu, 8 Oct 1998 04:25:39 -0700 (PDT)
From: Ka-Ping Yee <ping@lfw.org>
To: "Mark S. Miller" <markm@caplet.com>
Subject: Re: The story of E, part 2 (fwd)

Hi Mark!

Thanks for your comments.

On Wed, 7 Oct 1998, Mark S. Miller wrote:
>
> Hey how about Part 1?  Looks good, nits below.

Part 1 was the piece before the ellipsis, with some other
background on what EC was originally trying to do with
"Original E".

> Have you seen http://www.erights.org ?  It would be useful there almost
> immediately.

No, i hadn't seen the site since you had put everything up.
You've got a lot of good material there!

If you don't mind the nitpicking... see
http://crit.org/http://www.erights.org/ for my comments.

> Yup, but do you think the same text might also be accessible to someone
> coming from Python with no C++?  Or someone coming from Java to Python?

Maybe.  I didn't go over it -- i just wrote it once through
and sent it immediately.

> >*only* if either (a) you created it or (b) someone passed it
> >to you.  Once you make *everything* work that way, it becomes
> >very easy to predict who cannot possibly do what.
> 
> Actually, there is a third case,

True.  I understand.

> >And that's all.  Apply that to classic security problems,
> >build a distributed object system that transfers objects
> >over encrypted channels, and you have the core of what EC
> >built.  
> 
> Transfers object references.  Objects are usually stationary.

Right.  The objects are conceptually made available across
the encrypted channels -- i didn't choose my words carefully.

> Historically correct, but this describes what we now call "Original E" or
> "The E Extensions to Java"

Yes.  It was part of my background explanation.  Perhaps i
should just leave out talking about Original E altogether 
from now on.  (It's just that EC Habitats was so *neat*...)

> >... It took me a while to really
> >get it all, but they're very cool ideas.
> 
> Thanks!  Do you remember which ideas you had trouble with?

Well, i was very used to declaring data members explicitly
and didn't have a feel for Scheme-like lexical scoping,
so perhaps i belaboured the point more than you would feel
necessary with the VectorMaker vs. AnotherVectorMaker example.
Related to that is how an object's internals are safe from
the outside.

I have yet to grasp how to use "send" properly.  I'll need
to try it out some.


> >    ? 3 + 5
> >    # result: 8
> 
> That's "# value: 8"

Oh.  (I was working from memory.)

> Somewhere else, this example could also be rev'ed to show quasi-literals:
> 
>              to toString { `<Vector $x, $y>` }

Good point.

> It is possible but silly to make "sqrt" a standalone function in scope.
> Instead, E floating point numbers already respond to a "sqrt" message, so
> the following works:
> 
> 	(x*x + y*y) doubleValue sqrt

Kind of yucky.  How about toFloat?  (like toString)
...and toFoo for casting methods in general?

> Equivalent but prettier:
> 
>     ? v getX
>     # result: 1.5

I forgot you could do that.
 
> >... Well, you can still do this in E if you want:
> >
> >    define AnotherVectorMaker(initx, inity) {
> >        define vector {
> >            define x := initx
> >            define y := inity
[...]
> 
> No you can't, because you can only define behavior, not state, between the
> curlies following "define vector".

Oops.  I need clarification on where scopes start.  Is it
all curly braces except right after "define ..." in the kernel
language?

> >the outside world.  The local scope ensures that the contents
> >cannot be accessible from anywhere else -- you can be confident
> >that any secrets you want to keep inside the object are safe.
> 
> Nice explanation.

Thanks!

> >    ? n := {"a" => 440, "b" => 493, "c" => 523 }
> >    # result: {"a" => 440, "b" => 493, "c" => 523 }
> 
> Actually, in light of our previous conversation, I've decided to withdraw
> the "hide" keyword from the language, use bare curlies for the hide
> construct, and not have direct syntactic support for mappings (what you
> call dictionaries).  Instead, syntactic support for mappings will be
> provided by the quasiparser "map":
> 
>      ? n := map`{${"a"} => ${440}, ${"b"} => ${493}, ${"c"} => ${523}}`
> 
> Well, this change isn't yet implemented, and the above example demonstrates
> that it might suck.  Back to the drawing board.

Hmm.  I definitely think removing "hide" was the right thing to
do ("var := hide { ... }" just doesn't read right), but i'd have to
say that syntactic support for mappings would be very good to have.

Well, i'm going to repeat my earlier proposal because i haven't
thought of anything better yet:

    <1, 2, 3> for arrays
    ["a" => 440, "b" => 493, "c" => 523] for mappings

I know that

    < 1, 2, 3 > - 4

may look strange to a parser -- but you can simply declare the
precedence so that the > matches with the < first, can't you?

If you really wanted to put ((3) > (-4)) as an array item
(which must be very rare!), then you can still say:

    < 1, 2, (3 > -4), ...

That handles the closing >.  The opening < should also not be
a problem, because it starts an array only when an operand,
not an operator, is expected:

    a := < 1          # start of array
    a := 2 < 1        # less-than
    b := <<1          # start of nested array
    b := 2<<1         # left-shift
    b := 2-<<1        # start of nested array

You could then also do, for instance:

    @<1, 2, 3> for mutable arrays
    @["a" => 440, "b" => 493, "c" => 523] for mutable mappings

or something like that.

Hmmm... and about those method names...

    ? yourarray := @<1, 2, 3>
    # value: @<1, 2, 3>

    ? myarray := yourarray snapshot
    # value: <1, 2, 3>

    ? temparray := myarray scribble
    # value: @<1, 2, 3>

Does "@" bear any resemblance to a scribble to you?  Does
"scribble" at all connote "taking a copy to scribble on" to you?

I forget, do you use "@" in quasipatterns to denote a place
to write things into?

I think i could get used to it.

Perhaps a little farfetched.  But i couldn't think of any other
word at the moment that means "to make a copy for private editing"...

If you don't like "scribble", other short possibilities might
be "mutable" or "mutate" or "edit" or "editcopy".

Note (!) that without direct syntactic support for mappings --
or for mutable arrays and mappings -- you don't have a concise
way to print them out.  I think that may necessitate it.

Clearly "<...>" is not the perfect choice for a bracketing
construct.  But since "{}" and "()" are clearly taken and we
have two kinds of containers to talk about, we may be stuck
with "[]" and "<>".

By the way, does E do slices?  What do you think of the following:

    ? list := <1,5,3,6,7>
    # value: <1, 5, 3, 6, 7>

    ? list[1:3]
    # value: <5, 3>

    ? list[:2]
    # value: <1, 5>

    ? list[-1]                   # negative indices count from end
    # value: 7

    ? list[-3:]                  # get last three elements
    # value: <3, 6, 7>

    ? list := @<1,2,3,4,5>
    # value: @<1, 2, 3, 4, 5>

    ? list[1:4] := <8>           # slice assignment accepts <> or @<>
    # value: <8>

    ? list
    # value: @<1, 8, 5>

It would be great if E supported all these expressions.
Slices are extremely convenient to have in Python.

> Btw, your reference-state transition diagram is now at
> http://erights.org/doc/elib/elibmanual.pdf in the section "Reference
> Mechanics".

Neat.  Wow, you have been busy -- there's a lot in those PDF
documents.

Oh, one last thing -- what is your distinction between 'string'
and "string", if any -- and how do you interpret backslash-escapes?



Ping