headers
Mark S. Miller | 1 Jan 2004 04:27

Announcing E 0.8.24j: Better Diagnostics, working equality.

Available at http://www.erights.org/download/0-8-24/index.html

This release is also to be known as E-2003. Happy New Year's Eve!

This is an official release of E, 
* fixing the backtrace printing bugs reported by Kevin Reid and Chris Hibbert, 
* with causality tracing improvements suggested by Terry Stanley, 
* and in which capEdit is now working again.

Chris Hibbert wrote:
>I took a quick look, and of the problems I mentioned: "mismatched parens, 
>undeclared vars, assign to readonly var, etc." only mismatched parens seems 
>to be improved.  If I should take another look, let me know.  It's late 
>here, and my eyes are drooping.

You were correct. These static errors now report their positions correctly, 
so I have closed out this bug. (Dynamic errors also report their positions 
much more often, but there are still many uncovered dynamic cases.)

These same improvements in backtrace diagnostics have also greatly helped 
provide Terry with the tracing information she needs for Causeway, the 
(currently post mortem) space-time causality inspector.
(See http://www.eros-os.org/pipermail/e-lang/2002-November/007811.html )

Thanks to Kevin, Chris, and Terry for testing feedback on earlier attempts 
at this release. This official one is much better as a result.

Note that the major security hole Kevin reported, 
"safeScope Mutability breaks confinement"
https://bugs.sieve.net/bugs/?func=detailbug&bug_id=125579&group_id=16380
(Continue reading)

Permalink | Reply | 501 comments |
headers
Chris Hibbert | 1 Jan 2004 05:08
Gravatar

Re: Announcing E 0.8.24j: Better Diagnostics, working equality.

The highlights for 8.24
     http://www.erights.org/download/0-8-24/highlights.html
includes the following in the description of the new valueGuards:

 > def x :int := y
 >
 > x is final variable whose permanent value is the result,
 > if any, of coercing the current value of y through the
 > int guard. This definition has the same effect as
 >
 >    (def x := int.coerce(y, null); y)
 >
 > except that the original will be taken by many meta-level
 > tools (like auditors) to declare approximately the "type"
 > of x, whereas the expanded version leaves x "untyped".

Is it really the case that the value of the assignment expression is 
the uncoerced value of y?  That's the way I read the "; y" part of the 
expression.  That would be surprising.

Chris
--

-- 
It's always ourselves we find in the sea.
   -- E. E. Cummings
http://www.ecopsychology.org/gatherings4/

Chris Hibbert
hibbert@...
http://discuss.foresight.org/~hibbert
(Continue reading)

Permalink | Reply | 502 comments |
headers
Mark S. Miller | 1 Jan 2004 06:04

Re: Announcing E 0.8.24j: Better Diagnostics, working equality.

At 08:08 PM 12/31/2003  Wednesday, Chris Hibbert wrote:
>> def x :int := y
>>
>> [...] This definition has the same effect as
>>
>>    (def x := int.coerce(y, null); y)
>
>Is it really the case that the value of the assignment expression is the 
>uncoerced value of y?  That's the way I read the "; y" part of the 
>expression.  

Yes.

>That would be surprising.

Hmmm. It hadn't occurred to me that this would be surprising. Unfortunately, 
no matter which way is less surprising, this is the only workable answer for 
E. The left side of a def-expression is any pattern. It would be bad to 
introduce a special case for the common case -- when the pattern is a simple 
variable definition. Patterns can do many things besides coerce, so I don't 
know what it would mean to try to generalize from "the value is the coerced 
value" to a rule that would work for any pattern.

Btw, a similar issue comes up with assignment. Since assignment, in general, 
just invokes the Slot's setValue/1 method, whatever that is, we can't know 
what the "actual" value is assigned unless we do the corresponding 
getValue/0 right then. Unlike the def-expression, at least this is a 
possible rule, but it's unpleasant.

I current rule is that the value of either a def-expression or an assignment
(Continue reading)

Permalink | Reply | 1 comment |
headers
Chris Hibbert | 1 Jan 2004 06:46
Gravatar

Re: Announcing E 0.8.24j: Better Diagnostics, working equality.

 > [The] current rule is that the value of either a
 > def-expression or an assignment is the value that
 > the right hand side evaluated to. This rule is simple
 > and works in all cases. Is it too surprising?

No, it's not too surprising.  I'll just have to work to make sure my 
mental model clearly shows that the guard is part of the slot/variable 
on the left, and not a property of the assignment statement.  It would 
have to be part of the assignment statement in order to affect the 
value of the assignment statement.

I can live with that.  Especially since using the value of the 
assignment statement would be an unusual pattern for me.

Chris
--

-- 
Computers are telescopes we use to see the infosphere.
Some care about telescopes, most want to see the stars.
  Paraphrased from Gelernter

Chris Hibbert
hibbert@...
http://discuss.foresight.org/~hibbert
Permalink | Reply | 0 comments |
headers
Kevin Reid | 1 Jan 2004 16:14

Re: Three problems with exceptions

Mark S. Miller <markm@...> wrote:

> >Lastly, I'd like to mention something interesting in the way of
> >exception propagation semantics. I'm not sure this is a good idea, but I
> >think it would solve the information leakage problem while allowing
> >distinguishable failure types across vats.
> >
> >In the ColdC language (http://web.cold.org/):
> 
> Sounds intriguing, but I don't get it yet. It seems like it may have some
> relationship to the Keeper direction Dean is suggesting.

I'll give a silly example, because I haven't thought of a good one.

(Could someone provide a more plausible, short, piece of code that needs
information from exceptions hidden?)

I'll use ColdC's syntax for the propagation expression, though I
wouldn't recommend it: (> ... <)

def __makeMap(...) {
  def constMap {
    ...
    to get(key) :any {
      constMap.get(key, thunk {
        # This exception will propagate outside of the method, because 
        # it is explicitly 'throw'n, and thunk{} doesn't affect
        # propagation.
        #
        # throw() will need to be slightly special, because no ordinary
(Continue reading)

Permalink | Reply | 3 comments |
headers
Kevin Reid | 1 Jan 2004 17:44

Syntax: Trailing commas in lists, and line breaks in list-patterns

I would like E to allow trailing commas in comma-separated lists, so I 
can write code like

   [
     one,
     two,
     three,
   ]

without needing to remember to add a comma to the formerly-last item 
when I add another item.

A related issue: The list- (and map-) pattern, unlike the 
list-expression, does not permit a line break after the leading [, 
requiring me to write:

   def [ \
     one,
     two,
     three
   ] := ...

--

-- 
Kevin Reid
Permalink | Reply | 3 comments |
headers
Jonathan S. Shapiro | 1 Jan 2004 17:54
Favicon
Gravatar

Re: Syntax: Trailing commas in lists, and line breaks in list-patterns

On Thu, 2004-01-01 at 11:44, Kevin Reid wrote:
> I would like E to allow trailing commas in comma-separated lists, so I 
> can write code like
> 
>    [
>      one,
>      two,
>      three,
>    ]
> 
> without needing to remember to add a comma to the formerly-last item 
> when I add another item.

If this does not present an impossible difficulty in the language
design, I *strongly* support it.

One of the irritations in machine-generated code is the "separator vs.
terminator" distinction. Requiring that the last element *not* be
followed by a comma means that the code emitter must be complicated to
handle the last element separately.

> A related issue: The list- (and map-) pattern, unlike the 
> list-expression, does not permit a line break after the leading [, 
> requiring me to write:
> 
>    def [ \
>      one,
>      two,
>      three
>    ] := ...
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark S. Miller | 1 Jan 2004 20:47

Re: Syntax: Trailing commas in lists, and line breaks in list-patterns

At 08:44 AM 1/1/2004  Thursday, Kevin Reid wrote:

>I would like E to allow trailing commas in comma-separated lists, so I can 
>write code like
>
>  [
>    one,
>    two,
>    three,
>  ]
>
>without needing to remember to add a comma to the formerly-last item when I 
>add another item.

I agree, but I need some help from someone who's better at debugging yacc 
grammars. For example, the current argList: production is

    argList:
            emptyBr
     |      args
     ;

When I change it to

    argList:
            emptyBr
     |      args
     |      args ','
     ;
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mark S. Miller | 1 Jan 2004 21:12

Re: Syntax: Trailing commas in lists, and line breaks in list-patterns

At 11:47 AM 1/1/2004  Thursday, Mark S. Miller wrote:
>At 08:44 AM 1/1/2004  Thursday, Kevin Reid wrote:
>>I would like E to allow trailing commas in comma-separated lists, [...]
>
>[...] For example, the current argList: production is
>
>    argList:
>            emptyBr
>     |      args
>     ;
>
>When I change it to
>
>    argList:
>            emptyBr
>     |      args
>     |      args ','
>     ;

I just made the corresponding change to the term tree grammar, term.y, which 
yacc accepted happily. So this fix will at least make it into the term tree 
grammar starting with the next release of E. A nice improvement, thanks!

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

        Cheers,
        --MarkM
Permalink | Reply | 0 comments |
headers
Kevin Reid | 2 Jan 2004 00:42

Bug (0.8.24j): integer %% not behaving as documented

? -5 %% 7
# value: -5

? -5.0 %% 7.0
# value: 2.0

--

-- 
Kevin Reid
Permalink | Reply | 1 comment |

Gmane