headers
Andy Dwelly | 3 Jan 2005 15:37

Beginner's questions

Hello:

My name is Andy Dwelly and I've recently reached one of those happy 
points in life when the opportunity to do a bit of experimenting with 
some new ideas has arisen. I'm trying find an elegant way to put 
together a GUI framework (in someways like swing, swt, etc) . I'm 
looking for a way of doing this that is functional (in the lambda 
calculus sense), secure, and shows improvements in coping with 
concurrency. I personally have a hard time reasoning about threads. E 
looks like its got most of the answers so I'm trying to learn it.

I've worked my way through the Walnut and other start up documents but 
inevitably some questions have arisen, and the only way to get them 
answered is to ask here. So please bear with me if these seem naive.....

First of all, is there a way to search the mail list archive ? I'd hate 
to bother people with stuff that's been asked before , but the archives 
themselves are really too big to trawl through on the offchance my 
questions might have been addressed previously.

Secondly, suppose I have a program....

obj.do_this()
obj.do_that()
promise1 := recvr  <- do_something_elsewhere()
when (promise1) -> done(result) {
   result.do_something_else()
} catch prob {}
obj.do_the_other()
(Continue reading)

Permalink | Reply | 1 comment |
headers
Kevin Reid | 3 Jan 2005 18:37

Re: Beginner's questions

On Jan 3, 2005, at 9:37, Andy Dwelly wrote:
>
> First of all, is there a way to search the mail list archive ? I'd  
> hate to bother people with stuff that's been asked before , but the  
> archives themselves are really too big to trawl through on the  
> offchance my questions might have been addressed previously.

Use Google with the search term:

   inurl:www.eros-os.org/pipermail/e-lang/

>
> Secondly, suppose I have a program....
>
> obj.do_this()
> obj.do_that()
> promise1 := recvr  <- do_something_elsewhere()
> when (promise1) -> done(result) {
>   result.do_something_else()
> } catch prob {}
> obj.do_the_other()
>
> Do the semantics guarantee that obj.do_the_other() is executed prior  
> to result.do_something_else() (even if result.do_something_else()  
> returned really fast) ? In other words, is it true that all 'ordinary  
> code' must be finished prior to any when clauses going off ?

Yes. The body of the 'when' executes in a later turn, just like <-  
sends (which it is built out of non-primitively).
(Continue reading)

Permalink | Reply | 0 comments |
headers
marcs | 3 Jan 2005 19:26

RE: Beginner's questions


> Secondly, suppose I have a program....
>
> obj.do_this()
> obj.do_that()
> promise1 := recvr  <- do_something_elsewhere()
> when (promise1) -> done(result) {
>    result.do_something_else()
> } catch prob {}
> obj.do_the_other()
>
> Do the semantics guarantee that obj.do_the_other() is
> executed prior to
> result.do_something_else() (even if
> result.do_something_else() returned
> really fast) ? In other words, is it true that all 'ordinary
> code' must
> be finished prior to any when clauses going off ?

when you created promise1 above, you created it with an eventual send.
Conceptually, the message to recvr doesn't even get sent until
obj.do_the_other() has completed. So promise1 certainly cannot be resolved
before obj.do_the_other() finishes. I should make this clearer in Walnut.

A subtler question is, suppose the assignment for promise1 is immediate:

promise1 := 3
when (promise1)...

Would the when clause run immediately? You can test these questions using
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Miller | 4 Jan 2005 05:34

Re: On kernel-E, operators, and properties

At http://www.eros-os.org/pipermail/e-lang/2004-March/009661.html
Miller, Mark wrote:
>If anyone believes that names like "operator+" or "+" have some significant
>advantage over names like "op__add", now would be a good time to make those
>arguments.

At http://www.eros-os.org/pipermail/e-lang/2004-March/009662.html
John Williams wrote:
> I don't like names like op__add because they're not obvious or 
> memorable, so you just have to memorize them or look them up whevever 
> you need them. It's easy to guess that op_add maps to "+", but it's no 
> so obvious that "+" should map to op__add and not op__plus. Most of E's 
> operators either have at least two plausible names based on common 
> English usage, or they're so obscure they don't have any names that 
> would be immediately recognizable.
> 
> If you're going to go with "operator+" I'd suggest treating this name as 
> a single token, so there can't be any whitespace between "operator" and 
> "+"; this would simplify grepping source code. For just "+" I think the 
> quotation marks should be mandatory for the same reason.

I'll be answering this old message before replying to Dean, because

1) I'm now inclined to do approximately what John suggests above.

2) I'd like to examine Dean's guard-syntax proposals under the assumption that
we will be doing so.

3) I'd like to use this issue as context to a set of related suggestions in
another email I'll be sending shortly.
(Continue reading)

Permalink | Reply | 12 comments |
headers
Mark Miller | 4 Jan 2005 07:12

Announcing Release 0.8.33o: Smaller & Faster

At <http://www.erights.org/download/0-8-33/index.html>.

This is not a release candidate. It is the new official release of E.

At various times, Kevin Reid and Dean Tribble have each urged me to memoize
the ASTs that result from parsing and transforming expressions. With this
change, multiple loadings of the same module share these ASTs, rather
than duplicating them. The results are quite pleasing. For example, the
Causeway example shown at <http://www.erights.org/elang/tools/causeway/> went
from using around 50MB of heap down to around 40MB. On multi-vat examples, the
results are more dramatic. At
<https://bugs.sieve.net/bugs/?func=detailbug&bug_id=125653&group_id=16380>
MarcS reported being out of memory after creating 3 sliver servers. Testing 
this release (thanks!), he was able to create 10 with no problems.

Please try it on your own code and let us know if you see a significant
performance difference -- either way! After all, memoizing has some costs too,
and it would be good to know if anyone sees a slowdown.

This release also fixes the infamous "donor is gone" bug that had resisted
diagnosis for so long
<http://bugs.sieve.net/bugs/?func=detailbug&bug_id=125665&group_id=16380>.
To fix this bug, I had to make an incompatible change to the CapTP protocol,
so E vats prior to 0.8.33o will not interoperate with E vats running 0.8.33o
or later. (At some point we will no longer be able to simply drop support for
an old protocol when making such a change, but that day hasn't arrived yet.)

For other changes, please see the Highlights page at
<http://www.erights.org/download/0-8-33/highlights.html>, or stay tuned to e-lang.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Miller | 4 Jan 2005 07:20

Simplifying abstract syntaxes (was: On kernel-E, operators, and properties)

Mark Miller wrote:
> By way of context, the E abstract syntax allows any arbitrary string as a
> message selector. When the message selector is an E identifier, the E 
> concrete
> syntax allows the selector to be written without the quotes. However, an E
> language processor that starts with ASTs would not need to know or care 
> about,
> for example, the Unicode tables saying what is an identifier character.

At http://www.eros-os.org/pipermail/e-lang/2004-April/009821.html
Dean Tribble wrote:
> I'm learning C# and noticed that it has a similar but more
> general mechanism:  <at> "blah blah" is the identifier <blah blah> and can be
> used anywhere an identifier can be used. This provides the ability to
> access libraries from other languages, etc.

The particular choice above doesn't work for us, because of our conflicting
use of ' <at> '. But yes, I'd like to remove such distinction from the E abstract
syntax everywhere, and from the Term tree syntax as well. Proposal: Instead of
saying that an E variable-name may only be an identifier, define it as

     <variable-name> ::= <ident>
     |                   '::' <ident>
     |                   '::' <literal-string>
     ;

As of 0.8.33p, these productions can be enabled by
pragma.enable("noun-string")'. The reason for using '::' is that the
experimental property access syntax already uses '::<property-name>', where
<property-name> can be an identifier or a literal string, for property access.
(Continue reading)

Permalink | Reply | 7 comments |
headers
Mark Miller | 4 Jan 2005 08:03

Re: Count of complex guards

Dean Tribble wrote:
> In thinking about the user-defined construct syntax, I theorized that 
> complex guards are not particularly common, and so bending anything else 
> about the syntax in order to better support guards should probably be 
> avoided.

I find this plausible. There is also the question of maintaining practical
upwards compatibility, for which this kind of empirical investigation is
exactly what's needed. Thanks!

> To support this theory, I instrumented my E-to-eslang 
> translator and ran it over all of the E source code included in the 
> distribution (version 0.8.32a).  The attached file (assuming it doesn't 
> make me cross some size limit) has the translator output.Below is some 
> summary information, analysis, and then come conclusions.  MarkM did a 
> quick sanity check, and had some comments, which I would like him to 
> post in reply :-)

Sorry it took so long.

> ------------
> 395 complex guards out of 18,124 possible guards in all the e-files
> under esrc.  Note that this is from kernel E versions
> of everything, of course, which may introduce more guard opportunities.
> 
> Of the 395 complex guards, the major categories are:

I'm editing your enumerations below to show the cases in E syntax rather than 
in terms of their expansion to Kernel-E.
(Continue reading)

Permalink | Reply | 16 comments |
headers
Dean Tribble | 4 Jan 2005 09:08

Re: Count of complex guards

Mark Miller wrote:

>> In thinking about the user-defined construct syntax, I theorized that 
>> complex guards are not particularly common, and so bending anything 
>> else about the syntax in order to better support guards should 
>> probably be avoided.
>
> I find this plausible. There is also the question of maintaining 
> practical
> upwards compatibility, for which this kind of empirical investigation is
> exactly what's needed. Thanks!

You are welconme.

>> - guards don't deserve the full power of expressions if that 
>> interferes with normal programming.
>
> Agreed, given that one can still use an arbitrary expression by 
> enclosing it in parens.

Yup (that was easier than I expected :-)

>> - Supporting {} extensions for expressions but not for guards seems 
>> very plausible.  Though it would make for a theoretical syntax 
>> discontinuity, I don't think any programmer would be surprised or 
>> disturbed by this restriction.
>
> If we're not going to support an unparenthesized
>
>     foo (a,b) sepWord { ... }
(Continue reading)

Permalink | Reply | 13 comments |
headers
Mark Miller | 4 Jan 2005 12:14

Re: Count of complex guards

 >>Dean Tribble wrote:
 >>> - Supporting {} extensions for expressions but not for guards seems
 >>> very plausible.  Though it would make for a theoretical syntax
 >>> discontinuity, I don't think any programmer would be surprised or
 >>> disturbed by this restriction.

 > Mark Miller wrote:
 >> If we're not going to support an unparenthesized
 >>
 >>     foo (a,b) sepWord { ... }
 >>
 >> as a guard, then I think we also shouldn't support an unparenthesized
 >>
 >>     foo(a,b)

Dean Tribble wrote:
 > I couldn't figure out from your example what syntac you are refering
 > to.  If it's going away, then that's OK :-)

I'm saying, if we're not going to accept the proposed new lambda-args syntax 
as an unparenthesized guard, then we shouldn't accept the normal

     <call> ::= <call> '(' argList ')'

as an unparenthesized guard either, since to accept one without the other 
would be confusing. Whether this is going away is precisely what we're discussing.

> nullOK[foo] doesn't work

What do you mean, "doesn't work"? It doesn't work computationally? Or it
(Continue reading)

Permalink | Reply | 12 comments |
headers
Mark Miller | 4 Jan 2005 13:23

[Fwd: [agents] LCMAS <at> IJCAI05]


-------- Original Message --------
Subject: [agents] LCMAS  <at>  IJCAI05
Date: Tue, 4 Jan 2005 10:23:35 +0000 (GMT)
From: Wiebe van der Hoek <WiebevanderHoek@...>
To: Wiebe van der Hoek <wiebe@...>

-----------------------------------------------------------------

     CALL FOR PAPERS

     LCMAS 2005
     3rd International Workshop on
     Logic and Communication in MultiAgent Systems
     satellite workshop of IJCAI 2005

     http://www.win.tue.nl/%7Eevink/lcmas05.html

-----------------------------------------------------------------

The third edition of the LCMAS workshop series aims at bringing
together researchers interested in topics related to the use of formal
tools when applied to modelling, specifying, verifying, and reasoning
about multi-agent systems in which communication and updating play a
crucial role. Specifically, the workshop aims at providing a forum for
discussing technical issues arising in the use of formalisms
(epistemic, temporal, dynamic and authentication logics, and related
techniques) inspired by the needs of modelling information exchanges
in multi-agent systems. The workshop will be held as a satellite
workshop of IJCAI05, the 19-th edition of the biannual international
(Continue reading)

Permalink | Reply | 0 comments |

Gmane