Re: The story of E, part 2 (fwd) Mark S. Miller (
Wed, 14 Oct 1998 00:33:26 -0700

At 02:02 AM 10/13/98 -0700, Ka-Ping Yee wrote:
>But maybe you should really ask a girl. They always seem to
>know this stuff better.

For the historical record, I hereby deny that the above text ever appeared on this list.

>... I think Type objects will at least
>require a string name and an ordered "containment"/"isa" kind of


>They may not require an equality comparison... in
>fact, it might even be a good idea to explicitly omit equality
>comparison, so that subtypes can always stand in for their base

I sympathize with your goal, but no. Equality is pervasive (though yet to be resolved), and in any case, given containment, could be tested by "A <= B && B <= A".

>I note a potentially troublemaking discontinuity here: it looks
>like objects will not inherit from their Type objects, which
>means that two (or possibly three) kinds of "isa" are needed:
> 1. an object "isa(n)" instance created by its Maker and
> inheriting from things created by parent Makers

There should not be any general protocol, as this is an implementation detail that's none of the client's business.

> 2. an object "isa" thing associated with its Type object


> 3. a Type object "isa" subtype of its base types

Yup, but wrong name. While we might say "Joe is a Person" or "Joe is a Mammal", we would not say "Person is a Mammal". I have no syntax for translating "a Person is a Mammal" (but see the "Omega" logic system associated Actors), so instead I say "Person <= Mammal". Types are best considered sets (of the instances which are of that type). "<=" among sets similarly means "non-strict subset".

>Also note possible terminology quagmire around inheritance.
>We can say "behaviour" instead of "class", but we need good
>words to label all the relationships in the smalltalk-style
>inheritance diagram.

Indeed. I'm look forward to help and criticism from all of you. Thanks in advance.

>Is it a requirement of all Types that they be able to create
>objects without being given any constructor arguments? Does
>this lead to the possibility of objects being in some invalid
>state until initialized?

Your second question explains perfectly why the answer to the first question must be no. Smalltalk & JavaBeans got this wrong. Actors, Java & E got this right.

>> A SlotMaker is an object that responds to a one-arg
>> "makeSlot" message by returning an object presumed to act as a Slot.
>Given an assignable Slot, how do you make an object out of it? (i.e.
>a thing for which object := value will translate to slot setValue(value)).

I'm not sure I understand your question. A Slot already is an object. Are you asking "How do you make a variable out of it?" If you've already got a Slot object "foo", and you want to create a variable named "bar" whose value will be held by "foo", you say

define &bar := foo

which expand to

define bar : defineSlot := foo

where "defineSlot" is a SlotMaker defined in the primordial environment as

define defineSlot makeSlot(specimen) {specimen}

>Hey, i wonder, what did you have in mind when you decided to
>make the output look like a comment? Anything actually
>functional as opposed to just aesthetic?


>Was there any intention of being able to copy and paste
>multi-line blocks of interactive sessions? It sure would be
>neat if E knew enough to strip the leading prompt from each
>line. (It is fairly annoying to have to cut and paste each
>line individually in Python when i make a mistake, and of
>course this is exacerbated by Python's indent sensitivity
>which doesn't occur here.)

Thank you, I now have my first satisfying answer for why I avoid indentation-significance.

>> Good suggestions. I don't yet have a stance on this, except that I don't
>> like int("4") or string('a').
>Why not? I am actually much more attached to these two
>particular examples than the rest of the ones above.
>How would you expect to convert from string input to integer?
>This seems vital for a scripting language, for quick and
>interactive use, etc. and it ought to be easy to do.
>I really don't see what you have against 'a' -> "a" ... i
>mean, surely string('a') is clearer and more consistent with
>the rest of the type coercers than "" + 'a'... please
>enlighten me on your thinking.

On int("4"), introspectively, I only find a surprisingly inarticulate "that's not coercion, that's parsing!". I may just be confused, I'll stew further. On

'a' -> "a"

how would you feel about

3 -> [3]

>Do strings concatenate when you juxtapose them?

No, use "+".

>I'm thinking
>of long multi-line messages here, and also wondering whether a
>special quoting mechanism might ever be handy. (Python uses
>'''triple quotes''' for strings that can span many lines.

I decided to break with Java conventions and allow both literal strings and quasi-strings to span multiple lines. I liked this in Tcl.

>Makes for easy editing of help messages and self-documentation
>inside code.

I understand about help. How does it aid self-documentation?

>Btw, any self-documentation conventions?)

Not yet, but I intend to shamelessly imitate javadoc.

>I'm going to risk offense by repeating myself, and more strongly
>emphasize that Vector ought to mean vector in the linear algebra
>sense. If you take that word away, what name are the scientists
>going to use for a vector when they implement math/geometry

I didn't take the word away, java.util.Vector did. I wish it weren't so.

>> >What are the "standard tuple" and "standard mapping" interfaces?
>Looks pretty good, except for the following things...
> containsKey: as in the other message, how about "maps"?

Are you suggesting "maps" in addition to the Java-standard "containsKey" or instead of it?

> each: okay, but i like a verb better: how about "iterate"?


> elements: if we're calling them keys and values, why not values()?
> also note elements() is confusing if sets are maps:
> "set elements()" will get you [null, null, null, ...]
> (I know, set keys() doesn't read that clearly either, but
> at least it might prevent one common misunderstanding.)

In this case, the potential confusion you point out is sufficiently likely that I'm willing to go with "values" *instead of* the Java-standard "elements".

> ? items: Python dictionaries have an "items" method which can
> be very handy -- they produce the list of (key, value)
> pairs. Although Python doesn't do it, it may be useful
> to turn a list into (index, value) pairs too. Not sure
> if "items" is the best name for this, but it's not awful.
> Maybe "itemize".

Actually, I don't think I've ever used "keys" or "elements"/"values" from E, since "each"/"iterate"/"pairs" is so convenient (and the for-loop sugar makes it even more convenient). Since "keys" is 1) sufficient, 2) non-confusing, 3) named as a Javoid would expect, how about we just keep "keys" and drop both "elements" and "items"?

>Aren't we missing del(key) here? Need this...

Sorry. See move

>How do you deal with iterating over mutable things? Or do you
>just outlaw that? (Seems like a decent answer, i suppose.)

I hadn't thought of that. Currently all iteration operations implicitly iterate over a snapshot of the collection, and the implementation of mappings and tables knows not to actually make a copy unless needed (copy-on-write). If I moved the iteration messages into the immutable collection abstractions, the same patterns would happen, but the meaning would be more explicit -- you'd have to say

for k => v in muTable snapshot {

instead of the currently allowed

for k => v in muTable {

>> Sequences (I do like that word) in addition have both slice(start) and
>> slice(bound), and (for Java folk) define "length" as a synonym for "size".

Oops, that should be "slice(start, bound)". Closed-open interval, of course.

>Hmm. Regarding "len" vs. "length" vs. "size" ... can we just pick
>one and go with it everywhere? Less guessing is probably better.
>I'm fine with any of them -- if you want to go with "length" to
>appease Java folk, that's great.

"size". I will banish "length". (I agree with Dean that "count" would be better in the absence of Java conventions.)

>If you're still interested in having a repr-type protocol on all

I am.

>one possible way to make it go down easier is a Miranda
>method that made asRepr call toString if you didn't supply your
>own definition.

Instead, the miranda method should be like

to asRepr { `<${self toString}>` }

except that the angle brackets should be replaced by something that'll give a guaranteed immediate parsing error (assuming that the asRepr output up to this point was well formed). Otherwise, your cut-and-paste use could accidentally seem to work.

>> ? define PointMaker(x, y) {
>> > define point {
>> > to getX {x}
>> > to getY {y}
>> > }
>> > }
>> # value: <PointMaker>
>> ? define pt := PointMaker(3, 5)
>> # <point>
>I quite like this. I think this would lead to the convention
>that the defining occurrence of a behaviour would capitalize
>the behaviour name, in this case "point".

I'd like to reserve "Point" to name a type-object that describes the protocol spoken by objects like pt.

>... You may need to create a different
>quasiparser for repr substitution if we proceed this way.

I'm glad you found this early. You're right about the implied need, but I'm not willing to pay this cost. "asRepr" therefore goes on a long list of good ideas that need to be more fully worked out before they can be adopted.

>> [discussion of truncDivide and % vs _/ and %%]

>All very beautiful.
>It really makes you wonder if anyone ever thought about this
>issue when making up other languages.

Like most good things, I got this from Norm.

>... (Wait a second, though... aren't underscores part of
>identifiers? Oh, no, they can't be, because of pattern ignore.
>But are underscores permitted within identifiers?)

They are used in identifiers, in the ignore pattern, and in "_/". What's the problem?

>> I don't get it. What's the alternative?
>object <- minus(arg).
>... i am trying to avoid having too many different ways
>to say the same thing. We'll get people who prefer to write
> to get(index)
>and people who prefer to write
> to [](

(actually, it's

to [index]

>and they will get confused reading each other's code, have
>religious wars on the topic, etc.
>In my ideal world:
> object + argument # operators are too common to avoid
> object add(argument) # the second of only two ways to call add
> object <- add(argument) # the one & only way to send add
> define object {
> to add(argument) { # the one & only way to define such a method
> ...
> }
> }

Ok, I get it, and I think I like it. The goal E currently satisfies, which this violates, is that a programmer familiar with the operator spelling of one of these can do everything they want without needing to learn the identifier spelling. I think I'll take the simpler grammar in exchange. Thanks!

>I remember vaguely that there was a macro syntax but i don't
>think it was ever explained to me. Do we need one?; is it
>well defined yet?; and where can i read the definition?

Well, it's in the download's src/jsrc/org/erights/e/elang/syntax/e.y

>... But i do wonder whether
>a language already as powerful as E really needs a macro language.
>Have you run into cases yet where you have felt a need for one?

Yes. Besides, given macros, several constructs, such as "while" and "class", could be removed from the grammar.

	More, asynchronously, later,