headers
Mark S. Miller | 1 Feb 2004 02:07

Re: Easy-return

At 02:28 PM 1/31/2004  Saturday, Dean Tribble wrote:
>This is how Smalltalk shows return, so it feels comfortable to me, but I 
>have an objection that in principle, [...], and 
>using the return keyword is more "familiar". 

At 02:35 PM 1/31/2004  Saturday, Ka-Ping Yee wrote:
>Get rid of "^"!  Every other commonly used scripting language uses the
>"return" keyword.  Using "return" allows new programmers to learn by
>example.  Using "^" will bewilder them.

At 03:59 PM 1/31/2004  Saturday, Chip Morningstar wrote:
>E follows the lexical tradition of C, C++ and Java, not Smalltalk.  The
>C-tradition languages all use "return".  That's a sufficiently compelling
>justification to me.  C-tradition programmers will immediately understand
>"return" but be confused by "^" 

(And I remember Zooko chiming in along similar lines.)

Yes, everything everyone says above makes sense in theory. But because 
E uses lambda evaluation for object creation, rather than classes or 
prototypes, the verbose "return would appear way too often and 
inappropriately for my eyeballs. In the proposed easy-return style without 
unary prefix "^":

    def makePoint(x, y) {
        return def point {
            to getX() { return x }
            to getY() { return y }
        }
    }
(Continue reading)

Permalink | Reply | 25 comments |
headers
Zooko O'Whielacronx | 1 Feb 2004 03:28
Gravatar

Re: Easy-return


 MarkM wrote:
>
> At 03:59 PM 1/31/2004  Saturday, Chip Morningstar wrote:
> >E follows the lexical tradition of C, C++ and Java, not Smalltalk.  The
> >C-tradition languages all use "return".  That's a sufficiently compelling
> >justification to me.  C-tradition programmers will immediately understand
> >"return" but be confused by "^" 
> 
> (And I remember Zooko chiming in along similar lines.)

Indeed, I do agree with Ping and Chip on this point.

>     def makePoint(x, y) {
>         return def point {
>             to getX() { return x }
>             to getY() { return y }
>         }
>     }
...
> However, I find the "return" in front of the "return def point" 
> intolerable.

That's a good, err, point.  On reflection, I think I would have actually 
preferred the verbose "return def point" when I was learning E, as it would have 
eased my recurring confusion about the meaning of the various syntactic parts of 
object declaration.  But I agree with you that as an E programmer who no longer 
gets confused by that issue, I would find the extra "return" there to be 
irritating.  I'm undecided on this, but lean toward the "use familiar syntax" 
side of the argument.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chip Morningstar | 1 Feb 2004 03:35

Re: Easy-return

MarkM writes:
>Yes, everything everyone says above makes sense in theory. But because 
>E uses lambda evaluation for object creation, rather than classes or 
>prototypes, the verbose "return would appear way too often and 
>inappropriately for my eyeballs. In the proposed easy-return style without 
>unary prefix "^":
>
>    def makePoint(x, y) {
>        return def point {
>            to getX() { return x }
>            to getY() { return y }
>        }
>    }
>
>The "return x" is familiar enough, and "to getX() { return x }" isn't really 
>more verbose than the old "to getX() :any { x }". (two more characters, one 
>less token.) However, I find the "return" in front of the "return def point" 
>intolerable. It causes the "point" to get lost for the sake of a syntactic 
>phrase no one will find familiar. When Dean first raised the easy-return 
>suggestion, I considered this sufficient grounds for rejecting it. Only with 
>the introduction of Smalltalk's unary prefix "^" am I willing to consider 
>the easy-return proposal. In its absence, I strictly prefer the current E 
>syntax, and would stick with it.

I think "return x" looks exactly right, and I agree that "return def point ..."
looks strange.  However, I would contend that what causes the latter to look
strange is the fact that "def" results in a value, which is exceedingly weird
to a C-tradition programmer.  A more "with the grain" reformulation of
makePoint might be:
(Continue reading)

Permalink | Reply | 12 comments |
headers
Zooko O'Whielacronx | 1 Feb 2004 03:42
Gravatar

Re: Easy-return


 MarkM wrote:
>
> However, there remains Ping's point:
> 
> At 02:35 PM 1/31/2004  Saturday, Ka-Ping Yee wrote:
> >Much better to have one consistent way of doing things than two ways,
> 
> Should we get rid of the "return" keyword?

I would advocate only one keyword for returning, and between "^" and "return" 
I think I still prefer "return".  But I definitely prefer "^"-only to 
"^"-or-"return".

> Likewise, should we get rid of 
> "//" comments, since we support "#" comments, which do the same thing?

Yes.  Err, except that I think we should get rid of "#" in favor of "//" and 
"/* ... */" on the principle of C-programmer-familiarity, even though I prefer 
"#" myself.  

> My feeling is that both of these are best left in so that early E programmers can 
> start by writing in the way they are familiar, [...]

This kind of thing didn't help me learn E, and doesn't help me learn languages 
in general.

I first experience a new language by reading others' code and editing it, not by 
writing fresh code myself.  So for me having multiple alternate syntaces can 
make it harder rather than easier to learn a language, as it can make the code
(Continue reading)

Permalink | Reply | 22 comments |
headers
Ka-Ping Yee | 1 Feb 2004 03:46
Picon

Re: Easy-return

On Sat, 31 Jan 2004, Chip Morningstar wrote:
> A more "with the grain" reformulation of makePoint might be:
>
>     def makePoint(x, y) {
>         def point {
>             to getX() { return x }
>             to getY() { return y }
>         }
>         return point
>     }

In anticipation of MarkM's likely response that having to add the line
"return point" is too much of a hassle, we might consider a compromise:
in general, use the "return" keyword for returning values or nothing;
then say "def" is special and in the absence of a "return", the last
defined value is yielded as the value of the enclosing block.  You could
think of "def" as shorthand for "define and return".

This is one way to satisfy the two opposing desires:
    (a) to avoid leaking values just because they happen to be last
    (b) to avoid any extra work to write in the lambda object style

-- ?!ng
Permalink | Reply | 0 comments |
headers
Mark S. Miller | 1 Feb 2004 03:47

Re: An interesting snippet of code in E 0.8.25k

MarkM wrote:
>>         # Using cryptohash is overkill to get random replacement.
>>         # Thanks to Alan Karp for the random replacement idea.
>>         def index := key.getBareCryptoHash() %% size

At 06:41 AM 1/20/2004  Tuesday, Zooko O'Whielacronx wrote:
>By the way, it is also insufficient to prevent the provider of the new keys from 
>choosing which old keys to eject from the cache.  If you want that property, you 
>ought to use a "universal hash".

Interesting, but for present purposes, I don't think I need to care about 
that issue. The interesting thing about the example as a whole is that 
makeStringCache can provide the benefits of caching, which internally 
requires mutable state, while appearing to be immutable (given that the 
provided function is Functional, which it isn't here). Clients of such a 
cache can benefit from work done on behalf of other clients, even though the 
cache provides these clients no ability to overtly effect each other. (Of 
course, it does provide them with an additional covert channel which they 
can read if they can time things. Wrt E's threat models and claims, this 
does not increase vulnerabilities.)

>Alternately, implementing an LRU is nice and simple -- have the values of 
>`values' contain both the actual value and the pointers for a doubly-linked list 
>of keys which is sorted in order of how-recently-used.  Each update to this 
>linked list is O(1) plus the cost of one additional hash table access.
>
>Who knows if this would actually be slower or faster than 
>"getBareCryptoHash() %% size" in E/Java.  :-)

>*Do* you care if the generator of new keys has that ability to manipulate the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Zooko O'Whielacronx | 1 Feb 2004 04:06
Gravatar

Re: Easy-return


 Chip Morningstar wrote:
>
> >    def makePoint(x, y) {
> >        return def point {
> >            to getX() { return x }
> >            to getY() { return y }
> >        }
> >    }
...
> I think "return x" looks exactly right, and I agree that "return def point ..."
> looks strange.  However, I would contend that what causes the latter to look
> strange is the fact that "def" results in a value, which is exceedingly weird
> to a C-tradition programmer.  A more "with the grain" reformulation of
> makePoint might be:
> 
>     def makePoint(x, y) {
>         def point {
>             to getX() { return x }
>             to getY() { return y }
>         }
>         return point
>     }

That's exactly right.  If I had seen the version that Chip provides above, with 
a "return" keyword and with "def" not returning a value, it would have helped me 
a great deal in learning E for the first time.  I could have just *read* that 
code, without even studying the documentation, and understand what the code was 
doing, and thus learned E by reading E code.  That is my favorite way to learn 
a new programming language.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Mark S. Miller | 1 Feb 2004 04:47

Re: E Project Ideas?

At 09:59 PM 1/21/2004  Wednesday, Don Schwarz wrote:
>After months of trying to dream up a programing language with seamlessly
>distributed execution and web-of-trust-based permissioning, I've finally
>decided to take a close look at E.  I'm hooked!

Cool, and thanks!

>I am fishing around for a medium-sized project to work on over the next
>few weeks, and I would like to do something beneficial to the E
>community.  I've come up with a few preliminary ideas:
>
>1. I keep coming across references to a soon-to-be-developed E -> Java
>bytecode compiler.  Did work on this project ever begin?  If not, has
>there been a prototype or proof-of-concept, at least?  Although a
>full-blown compiler is bound to be an extremely complex project,
>implementing a subset of the language with hooks into the interpreter
>for unimplemented features should be relatively trivial.  Am I missing
>something?

I don't think so.

At 08:45 PM 1/29/2004  Thursday, marcs wrote:
>One of my most strongly desired dreams is for someone to compile E
>through GCJ. There are a couple of features missing from GCJ to achieve
>full E compilation (I believe the problem is proxies), but the couple of
>attempts to compile through GCJ failed before ever getting to the point
>where something should have been broken. It has been a long enough time
>since the last attempt that it might well be worth trying again. 

MarcS here means something quite different than you're asking about:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark S. Miller | 1 Feb 2004 05:01

Kernel-E to be Specified and Frozen

This seems like a good time to announce my next intended major milestone: In 
E 0.9, also to be known as E's "alpha release", I intend to commit to a 
final definition of Kernel-E. After that point, I intend that Kernel-E 
evolve only in strictly upward compatible ways, unless there's an overriding 
problem that forces our hand. (The security bug Kevin found is an example of 
an adequate problem.) Now that we're about to have several implementations 
of Kernel-E that need to kept in synch (E-on-Java, E-on-Squeak, perhaps a 
revived smallcaps, perhaps a smallcaps-to-JVM-bytecodes, hopefully perhaps 
someday an enative), we can only maintain compatibility among them by 
reference to a stable spec. 

Accordingly, I also expect to start writing such a spec, and debating on 
e-lang all remaining Kernel-E issues that need to be settled. (Like 
thrown-problem encapsulation, which I'll be getting back to.)

Besides the Kernel-E special forms, E 0.9 will also represent a commitment 
to a certain set of core library APIs to be enumerated. This will include 
primitives adequate for rebuilding the current awful .emaker module system 
in E, without requiring any unreasonable privileges. (The hope is, if one 
can rebuild the current awful module system in E, then one should be able to 
build better module systems, and these should be able to co-exist, so that 
we can evolve our way away from the current module system later without 
breaking anything. We hope to thereby survive postponing the design of a 
decent module system.)

The primitive I have in mind is essentially the two argument 
"eval" which Paradigm Regained
http://www.erights.org/talks/asian03/index.html calls the "loader". This 
eval will take a term-tree representing the E expression and a ConstMap 
representing the environment. In the process, we'll also be closing out the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark S. Miller | 1 Feb 2004 05:20

Re: Easy-return

At 06:35 PM 1/31/2004  Saturday, Chip Morningstar wrote:
>I remain highly unpersuaded of the virtue of the expression-language convention
>that every executable construct yields a value.

At some point, we have to say, this is the experiment we're trying. It's not 
necessarily the best experiment to be trying, but it is what it is. While an 
E-like non-expression language may well be a wonderful thing, perhaps better 
than E, the time is long past for considering such a proposal as possible 
improvements to E. Such a proposal creates a new language and a new 
experiment. I would wish it all the best.

----------------------------------------
Text by me above is hereby placed in the public domain

        Cheers,
        --MarkM
Permalink | Reply | 0 comments |

Gmane