headers
Kevin Reid | 4 Dec 2005 01:58

Type system edge cases: underenthusiastic deflection or individual bugs?

? def map := [5 => 10]; null

Both of the following seem to me to be bugs of a similar form:  
suitable arguments are rejected because the argument and the  
recipient are both ordinary Java objects which must implement each  
interface, whereas E objects get the Deflection mechanism.

In each example, the first part is the nonworking code and the second  
is a workaround.

1.

   ? for i in 0..10 { println(map.fetch(i, __continue)) }
   # problem: <ClassCastException: Ejector doesn't coerce to a Thunk>

   ? for i in 0..10 { println(map.fetch(i, thunk { __continue() })) }
   # stdout: 10
   #

2.

   ? int.coerce("1", throw)
   # problem: <ClassCastException: Thrower doesn't coerce to an  
OneArgFunc>

   ? int.coerce("1", def _ extends throw {})
   # problem: <ClassCastException: String doesn't coerce to an int>

I see two possible fixes:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kevin Reid | 7 Dec 2005 18:04

Explanation of TraversalKey, and a change proposal (was Re: Labeled promises?)

On Nov 30, 2005, at 10:34, Mark Miller wrote:

>> Would it break anything in the E model to attach labels to promises?
>
> The only issue I see is how it might effect the sameness semantics of
> TraversalKeys. If there's no issue there, then I think this is a  
> good idea.
> It may be a good idea anyway, but it'd take more examination.

I believe this shouldn't be a problem, since under all circumstances  
in which the visible label might change, the TraversalKey-identity  
will also have changed. Is there some other problem you're thinking of?

> A placeholder for an explanation of TraversalKeys is at
> http://www.erights.org/javadoc/org/erights/e/elib/tables/ 
> TraversalKey.html .
> Kevin, could you post an explanation? Thanks.

Um. I don't actually understand TraversalKey that well. What I know I  
probably found from some existing documentation and reading the E-on- 
Java implementation, which I copied for E-on-CL.

Intent:

A TraversalKey is always Settled. Therefore, it can be used as an  
'identity of' some value which has not yet become settled, so that  
cyclic, unsettled data structures may be traversed with a map or set  
used to track what portions have been seen before.

(This is used in TextWriter and serialization, for example.)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Miller | 10 Dec 2005 03:58
Picon
Gravatar

Re: Type system edge cases: underenthusiastic deflection or individual bugs?

> ? def map := [5 => 10]; null
>
> Both of the following seem to me to be bugs of a similar form:
> suitable arguments are rejected because the argument and the
> recipient are both ordinary Java objects which must implement each
> interface, whereas E objects get the Deflection mechanism.
> [...]
>    ? for i in 0..10 { println(map.fetch(i, __continue)) }
>    # problem: <ClassCastException: Ejector doesn't coerce to a Thunk>
> [...]
>    ? int.coerce("1", throw)
>    # problem: <ClassCastException: Thrower doesn't coerce to an
> OneArgFunc>
>
>
> I see two possible fixes:
>
> 1. Have Thrower implement OneArgFunc and Ejector implement Thunk.
> This would fix these particular cases but not the general problem.
>
> 2. Any object passed to a Java method is subject to deflection,
> whether or not it is an E object. This would eliminate all problems
> like this but hide "real" interface mismatches.

Your diagnosis of the bug is correct. #2 is the right fix. All Java
interfaces except Marker interfaces (explained below) are considered
to only be part of Java's static type system, which E should ignore.

Those Java interfaces which directly implement org.erights.e.elib.serial.Marker
http://www.erights.org/javadoc/org/erights/e/elib/serial/Marker.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Miller | 10 Dec 2005 04:04
Picon
Gravatar

Re: Explanation of TraversalKey, and a change proposal

> I believe this shouldn't be a problem, since under all circumstances
> in which the visible label might change, the TraversalKey-identity
> will also have changed. Is there some other problem you're thinking of?

I think this answers my concern. Let's do this.

> MarkM: What would you think of having makeTraversalKey be a method of
> Equalizer, instead of a separate import? TraversalKey's semantics are
> fundamentally connected to the Equalizer, so this seems to me to fit
> well.
>
> Advantages:
>    * Fewer independent paths via which sameness definitions are
> provided to the E environment; this might help with refraction.
>    * More discoverable; it can be found from help(__equalizer).
>    * In E-on-CL, this would eliminate one importable-primitive
> declaration.
>    * If Equalizer and TraversalKey were implemented in E, it would
> make sense to define them together since they share 'private' unsafe
> operations.

All of these are good reasons. I agree. Please just go ahead with both
of these changes in E-on-CL. I'll follow along with E-on-Java when I
have the time. Thanks!

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

    Cheers,
    --MarkM
(Continue reading)

Permalink | Reply | 501 comments |
headers
Kevin Reid | 10 Dec 2005 15:22

Re: Re: Explanation of TraversalKey, and a change proposal

On Dec 9, 2005, at 22:04, Mark Miller wrote:
>> MarkM: What would you think of having makeTraversalKey be a method of
>> Equalizer, instead of a separate import? TraversalKey's semantics are
>> fundamentally connected to the Equalizer, so this seems to me to fit
>> well.
>
> All of these are good reasons. I agree. Please just go ahead with both
> of these changes in E-on-CL. I'll follow along with E-on-Java when I
> have the time. Thanks!

I started to implement this, and realized that replacing the maker  
with a method eliminates the usual way of getting a TraversalKey guard.

Options:

   1. Have no TraversalKey guard. This is probably good enough; I  
can't think of a reason to check "someone else's" TraversalKey.
   2. Instead of #makeTraversalKey/1, have #getMakeTraversalKey/1,  
which returns the same maker that is currently importable, with its  
#asType/0 method.
   2. Same as #2, but keep #makeTraversalKey/1.
   3. Add #getTraversalKeyGuard/0 to the Equalizer.
   4. Have it as a separate import, while making TraversalKeys is  
done via the Equalizer. This feels wrong, as it makes the  
TraversalKey guard into a separate primitive.

--

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>
Permalink | Reply | 501 comments |
headers
Kevin Reid | 13 Dec 2005 02:07

Arity-limited verb currying

Since E generally considers messages to be distinct depending on  
their arity, it would be appropriate for the verb-curry feature to  
support specifying the arity. It just occurred to me that this could  
be implemented conveniently without additional syntax:

   ? 1.add/1
   # expansion: __makeVerbFacet.curryCall(1, "add").approxDivide(1)

   # value: <calling "msg"/1 facet>

I'd like your opinions on whether doing this is too much of an abuse  
of /, or too unlikely to be useful to bother with at all.

--

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>
Permalink | Reply | 1 comment |
headers
Kevin Reid | 13 Dec 2005 02:16

Bug: Non-composability of __getPropertySlot

? pragma.enable("dot-props")
? var x := 0
# value: 0

? def o {
 >   to __getPropertySlot(n) :any {
 >     return if (n == "x") { &x } else { null.__getPropertySlot 
(n) } } }
# value: <o>

? def p extends o {}
# value: <p>

? o::&x
# value: <var 0>

? p::&x
# value: ::&x

? o::x := 1
# value: 1

? p::x
# problem: <NoSuchMethodException: <an o>.getX/0>

The problem, as I see it, is that __getPropertySlot, in a sense, is  
another layer of method dispatch, which not all objects participate in.

Fixes that I've thought of so far:
(Continue reading)

Permalink | Reply | 14 comments |
headers
Mark Miller | 15 Dec 2005 06:38
Picon
Gravatar

Re: Re: Explanation of TraversalKey, and a change proposal

On 12/10/05, Kevin Reid <kpreid@...> wrote:
> >> [...] having makeTraversalKey be a method of
> >> Equalizer [...]?
> > [...]
> I started to implement this, and realized that replacing the maker
> with a method eliminates the usual way of getting a TraversalKey guard.
>
> Options:
>
>    1. Have no TraversalKey guard. This is probably good enough; I
> can't think of a reason to check "someone else's" TraversalKey.
>    2. Instead of #makeTraversalKey/1, have #getMakeTraversalKey/1,
> which returns the same maker that is currently importable, with its
> #asType/0 method.
>    2. Same as #2, but keep #makeTraversalKey/1.
>    3. Add #getTraversalKeyGuard/0 to the Equalizer.
>    4. Have it as a separate import, while making TraversalKeys is
> done via the Equalizer. This feels wrong, as it makes the
> TraversalKey guard into a separate primitive.

I think we should do #1, but keep in mind #3 as something we might want to add
later if we find there's a need.

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

    Cheers,
    --MarkM
Permalink | Reply | 0 comments |
headers
Mark Miller | 15 Dec 2005 06:43
Picon
Gravatar

Re: Arity-limited verb currying

On 12/12/05, Kevin Reid <kpreid@...> wrote:
> Since E generally considers messages to be distinct depending on
> their arity, it would be appropriate for the verb-curry feature to
> support specifying the arity. It just occurred to me that this could
> be implemented conveniently without additional syntax:
>
>    ? 1.add/1
>    # expansion: __makeVerbFacet.curryCall(1, "add").approxDivide(1)
>
>    # value: <calling "msg"/1 facet>
>
> I'd like your opinions on whether doing this is too much of an abuse
> of /, or too unlikely to be useful to bother with at all.

My inclination is not to bother for now, but again to keep it in mind
as something
we could add if we find there's a need.

Btw, so long as the operators expand to verb-names, such as
"approxDivide", this
feels too messy. Were the operators to expand into verb-strings
spelled the same as
the operator, i.e.,

   were    x/y   to expand into    x."/"(y)

then this suggestion would seem less messy.

--
Text by me above is hereby placed in the public domain
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kevin Reid | 17 Dec 2005 15:15

File#get(Platform)Path

What is the intended difference between File#getPath and  
File#getPlatformPath?

--

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>
Permalink | Reply | 1 comment |

Gmane