LinkSemantics |
Edit this page |
Forget everything you ever learned about pointers...
Abandon all hope, ye who enter here...
Wheat does not have pointers. Instead, it has links. Links are similar to URLs in a web page, or symbolic links in a Unix style file system. Every object has a name, and so a link is a name than can be followed. Of course, the object at that name can change, and hence, what the link points to can change. This is why it is unlike a pointer or a reference.
Links are not transparent: You must know than an object is a link, and you have to explicitly follow it. In this regard, a link is more like a pointer than like a symbolic link.
However, there are places, such as LibraryBinding?, where the binding is expected to be a link, and so, there the follow operation is implicit.
The advantages of links over pointers are several:
Links, like URLs come in several flavors. URLs have several forms: relative, absolute & full-path (relative to the protocol, server & port, but absolute in path). Similarly, links will need several flavors, and these need to be worked out. Some clear options are:
Does a single link have to correspond to a single object? Hehe, how about one link to several objects, so you can simultaneously LISP-style invoke operations on several at a time (but you cant access member values nor expect results from more than one object). Actually that parenthetical expression gives pretty severe restrictions.
Since we have no notion that a link has to always point to the same object, how about being able to have a more generic kind of link, like one specified with an XPath expression, so that the appropriate object can be identified at runtime.
--SummerMisherghi 2003-03-10
Wow - this brings up a lot of good ideas and points... let me take them one at a time...
--MarkLentczner 2003-03-11, feel free to intersperce comments in what follows
1) On the one hand I am quesy about having operations that a programmer thought were scalar suddenly being vector. Especially because, as one gets more compilcated structures than an array, somethimes there are choices about how to apply an operation to a structure (infix? postfix? dot? moving window?). On the other hand, I've always felt it was as deficiency that GlyphicScript didn't support multi-valued returns in the language. Furthermore, if Wheat's message send is isomorphic to HTTP request, then what is isomorphic to the HTTP response being a multi-part MIME∞? Once we know how handle that, then we should have handle on what to do here.
2) As you can tell from the top of this page, I had modeled links on relative URLs (since so much of Wheat is inspired by turning HTTP into a programming language!). Of course, relative URLs were, in turn, obviously modeled on file system symbolic links. These systems provided just a few forms of link (absolute, relative, and in the case of URLs, there are several types of relative), and yet turn out surprisingly versatile. Based on those successes, I'm inclined to keep links simpler until we see a need for something more.
3) On the other hand, we architect to the link mechanism to allow for such expansion: I'm not sure if a link is a magic kind of value, or a magic kind of object, or a magic kind of property. If it is the later, then clearly the link itself is just an object, and we could create other families of objects that sit in those magic properties.
4) Seems clear to me that we should investigate XPATH as a possible basis for links. I'll have to go read the W3C recommendation. A brief look at the table of contents makes it clear that it could involve lots of computation. We'd have to make sure that simple links (abs. or rel.) could be stored and followed very efficiently. Remember: Wheat has no pointers, so it is going to have lots of links.
5) I hadn't written up this idea, that I had quite a while ago: A link is really just a kind of method! My intention for Wheat is to use the method/property dualism from GlyphicScript. So fetching the value of a property of an object might really be running a no-argument method. In Wheat we add the possibility that it is fetching an object via a link. (To the caller these are all transparent and look the same.) Well - why not encode the link as a method? Or rather, compile the link. If we are doing that, then, well, why can't we compile XPATH links?
References:
Abandon all hope, ye who enter here...
Wheat does not have pointers. Instead, it has links. Links are similar to URLs in a web page, or symbolic links in a Unix style file system. Every object has a name, and so a link is a name than can be followed. Of course, the object at that name can change, and hence, what the link points to can change. This is why it is unlike a pointer or a reference.
Links are not transparent: You must know than an object is a link, and you have to explicitly follow it. In this regard, a link is more like a pointer than like a symbolic link.
However, there are places, such as LibraryBinding?, where the binding is expected to be a link, and so, there the follow operation is implicit.
The advantages of links over pointers are several:
- It allows the notion of referring to something else be exactly the same no matter where it is: on the same machine or across the internet. A traditional pointer or reference is generally limited to the same process, and most extensions to allow them to point 'off-world' generally introduce semantic differences.
- Since no link is 'hard', objects can be deleted without worry. Of course, this is a double edged sword. Since we no longer have a notion who is using an object, the decision to delete must be managed by the programmer again (though Wheat should make this much easier). So, when a link is used, there is the implicit possibility that the target of the link might be gone. This is natural: that cool web page may no longer be there.
Links, like URLs come in several flavors. URLs have several forms: relative, absolute & full-path (relative to the protocol, server & port, but absolute in path). Similarly, links will need several flavors, and these need to be worked out. Some clear options are:
- relative to the object containing the link
- absolute
- library relative
- process relative - I suppose this is a global!
Discussion
Subject: XPath∞Does a single link have to correspond to a single object? Hehe, how about one link to several objects, so you can simultaneously LISP-style invoke operations on several at a time (but you cant access member values nor expect results from more than one object). Actually that parenthetical expression gives pretty severe restrictions.
Since we have no notion that a link has to always point to the same object, how about being able to have a more generic kind of link, like one specified with an XPath expression, so that the appropriate object can be identified at runtime.
--SummerMisherghi 2003-03-10
Wow - this brings up a lot of good ideas and points... let me take them one at a time...
--MarkLentczner 2003-03-11, feel free to intersperce comments in what follows
1) On the one hand I am quesy about having operations that a programmer thought were scalar suddenly being vector. Especially because, as one gets more compilcated structures than an array, somethimes there are choices about how to apply an operation to a structure (infix? postfix? dot? moving window?). On the other hand, I've always felt it was as deficiency that GlyphicScript didn't support multi-valued returns in the language. Furthermore, if Wheat's message send is isomorphic to HTTP request, then what is isomorphic to the HTTP response being a multi-part MIME∞? Once we know how handle that, then we should have handle on what to do here.
2) As you can tell from the top of this page, I had modeled links on relative URLs (since so much of Wheat is inspired by turning HTTP into a programming language!). Of course, relative URLs were, in turn, obviously modeled on file system symbolic links. These systems provided just a few forms of link (absolute, relative, and in the case of URLs, there are several types of relative), and yet turn out surprisingly versatile. Based on those successes, I'm inclined to keep links simpler until we see a need for something more.
3) On the other hand, we architect to the link mechanism to allow for such expansion: I'm not sure if a link is a magic kind of value, or a magic kind of object, or a magic kind of property. If it is the later, then clearly the link itself is just an object, and we could create other families of objects that sit in those magic properties.
4) Seems clear to me that we should investigate XPATH as a possible basis for links. I'll have to go read the W3C recommendation. A brief look at the table of contents makes it clear that it could involve lots of computation. We'd have to make sure that simple links (abs. or rel.) could be stored and followed very efficiently. Remember: Wheat has no pointers, so it is going to have lots of links.
5) I hadn't written up this idea, that I had quite a while ago: A link is really just a kind of method! My intention for Wheat is to use the method/property dualism from GlyphicScript. So fetching the value of a property of an object might really be running a no-argument method. In Wheat we add the possibility that it is fetching an object via a link. (To the caller these are all transparent and look the same.) Well - why not encode the link as a method? Or rather, compile the link. If we are doing that, then, well, why can't we compile XPATH links?
References:
There is no comment on this page.
[Display comments/form]
