LAZY link propagation - comments/discussion please

Hi,

I am posting this language proposal for comment.

Currently LaZY links are treated by the language at compile-time as a
link value - not as a link to be resolved. Thus a link to a LAZY link
will result in the LAZY link being returned as part of the link
resolution. This has the advantage that references may be treated as
values in the same way integers and strings - can be copied, etc. The
disadvantage is that this breaks abstraction:

Consider:

    foo extends {
        y 20;
        x 10;
    }

    bar extends {
         myFoo extends foo {
             x y;
         }
         y 30;
         z myFoo:x;
     }

In this case bar:z resolves to 20.

Now consider

     bar extends {
         myFoo extends foo {
             x LAZY y;
         }
         y 30;
         z myFoo:x;
     }

At runtime, a lookup of bar:z would return 30, which would seem
inconsistent. To make sure that we return the same original value of 20
- just lazily resolved - we need to tag the bar:z attribute as LAZY.

     bar extends {
         myFoo extends foo {
             x LAZY y;
         }
         y 30;
         z LAZY myFoo:x;
     }


This is clearly breaking abstraction - that the decision to change an
attribute to be lazily bound has repercussions beyond the immediate
context of the attribute definition.

An alternative semantics, and one I have previously implemented
internally as an experiment, is to make LAZY propagate - thus a link to
a LAZY link is itself implicitly tagged as LAZY without users having to
do it explicitly as in the last example. This would of course propagate
back through any chain of links as required. In effect the two LAZY
examples above would be identical in their semantics.

So what is the disadvantage wrt to the existing scheme (apart from not
being backward compatible)? The main issue is that references can no
longer be values, because any reference to them will be tagged as lazy
rather than having the link copied.

Fundamentally, this is because a (in hindsight mistaken) simplifying
design choice was to conflate the idea of LAZY with being a value. We
should have had separate tags for the two concepts. Thus we could use a
DATA tag to indicate that this is a reference value, never to be
resolved lazily or otherwise, to be returned as the result of a
resolution at all times and not just at compile time but also run-time.
(Note, in the same way as it makes no sense to have a LAZY integer, it
makes no sense to have a LAZY DATA link. However a DATA LAZY link???)

The semantics of the split mechanisms is far cleaner, but not fully
backwards compatible... however I suspect(!) that most descriptions
would not fall foul of this. I have rarley seen a specification where a
reference is strictly DATA rather than LAZY.

Comments? Should we leave it as is? Change it? Do something different?
When? Etc etc

Patrick






-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0709&bid&3057&dat1642