Comments on: Should we axe ALIAS?

Does anyone use the alias function? If not, I propose that we drop it for 3.0.0.

For those who are not familiar with the alias function, it is used to define symbolic equivalence.

Ok, so what does that mean?

It is actually quite simple, but because no other language (that I know of) supports it, most programmers don't understand it. Symbolic equivalence is the concept that some symbol 'xyz is equivalent to some other symbol 'zyx. Which would allow this test to yield true:

>> 'xyz = 'zyx
== true

Why is this concept even in REBOL? There are two main reasons:

1. To make uppercase and lowercase refer to the same word. 'XYZ = 'xyz, 'Xyz = 'xyz, and all other combinations.
2. To allow word "synonyms" within a symbolic namespace.

Huh? What's a symbolic namespace?

It's a context (an object, module, etc.) -- where "symbols" are mapped to "variables" that reference "values"... which in REBOL is done dynamically, at any desired time, not just at load-time, compile-time, link-time, etc. Such contexts are at the core of REBOL's implementation.

So, in fact, you can write:

>> alias 'print "imprimez"
>> imprimez "hello world"
hello world

and this should not be misunderstood as being the same as:

>> imprimez: :print

which is value-equivalence, not symbol-equivalence. Here you are actually defining a new variable called imprimez and setting it to the function value of print. That's quite different.

Ok, so you ask again, why is it useful? Well, let's take the case where you've defined an object that has a print function within it:

>> obj: make object! [
     value: 123
     print: does [system/contexts/exports/print value]
]
>> obj/print
123

But, now, let's say you travel to Paris to visit François at Sorbonne, and you want to be more friendly about your words, so you might write:

>> obj/imprimez
123

And you can see it works quite well! That result comes from the alias for print that was defined earlier. Keep in mind that what follows the obj/ is symbolically mapped -- its association happens very late in the evaluation process.

As you can see, it's kind of a nice concept, but it certainly isn't perfect. You can only define aliases when their words have not already been used. For instance, if you already defined or used a word imprimez before the alias, then it would not be allowed, because the word imprimez already has unique reference within a symbolic namespace.

Well, I must say that I'm not familiar with any programmers actually using the alias feature (not that anyone tells me much of anything unless it's a bug report), so perhaps it's just best to remove it from R3. Right now, during the massive effort to get 3.0 released, it's better to do less for now, but get the rest done sooner.

Perhaps you've seen a change in my attitude... considering how long it's taking to get R3 out the door!

36 Comments

Comments:

-pekr- 30-Aug-2009 16:04:38	I just wonder how removal of 'alias might get R3 released process shorter? :-) Doesn't its implementation exist in R2 already? Or would it mean more work, if it would be supposed to work in R3? I never used alias, I was using print1: :print aproach from time to time, but never an 'alias ...
Henrik 30-Aug-2009 16:10:42	The way you are writing this blog post is exactly how I would want to read the manual, but unfortunately, the official doc reads like this unenthusiastic blurp: http://rebol.com/docs/words/walias.html Would you want to use it after reading that? It doesn't show the tricks you can do with ALIAS, which you are showing in this post and why it's different from value-equivalence. For me, the writing difference between that link and your post one reason that I may not use a function. Also I didn't find it in the R2 Core Manual.
Endo 30-Aug-2009 18:41:08	A few days ago on mailing list someone asked about pointing to same object, alias was the "accepted answer".
Jerry Tsai 30-Aug-2009 20:26:20	Since Unicode was supported in R3 alpha, I had been trying to alias Chinese terms with frequently-used REBOL words, so we could programming in REBOL in Chinese. But it turned out to be a bad idea. Guess what? Because of typing, REBOL programming in Chinese is (way too) slower than doing it in English. Mixing Chinese and English in REBOL code makes it look unclear and amateur. Some Chinese kids or elementary schools might like this idea though.
Goldevil 31-Aug-2009 2:45:01	I simply never used it
danakil 31-Aug-2009 3:46:50	We find REBOL to be very well suited for the creation of DSL's (Domain Specific Languages). The Alias function, when coupled with suitable mechanism for #include'ing text files, is invaluable in this context. By all means, keep it as part of the core. Our company (www.vectornova.com) develops a high performance analytical DBMS(VectorStar, a "columnar rdbms" which provides a vectorized SQL based on first class functions) using the J array programming language (www.jsoftware.com). A few years ago we were a paying R2 customer and used REBOL to build a (IOO, rather nice) prototype for our user interface.
Ladislav 31-Aug-2009 6:05:20	I tend to agree with Jerry. Carl and other English native speakers know, how hard it is to establish a REBOL term even in your native language. Therefore, once being familiar with a REBOL term in English, I avoid translating it to my native language.
Carl Read 31-Aug-2009 6:10:47	As mentioned above, ALIAS cropped up on the mailing list last week... http://www.rebol.org/ml-display-message.r?m=rmlYBNC I've never personally found a use for it, but some might (and have, it seems), and if leaving it in won't slow R3's release schedule, it seems leaving it in would be best.
Ladislav 31-Aug-2009 14:50:06	Re: "ALIAS cropped up on the mailing list last week" - yes, it cropped up, but with no real application
Brian Hawley 31-Aug-2009 14:51:30	Please, make ALIAS go away. Keep the internal function that implements case-preserving words, but rid us of the problematic external function. The only use I've seen for it since its inception is to generate bug tickets. If even Jerry doesn't use it, it's more trouble than it's worth.
Maxim Olivier-Adlhoch 31-Aug-2009 16:10:35	ALIAS makes REBOL *special*, but the real question is... does is make it *better*. Although I find the Concept of 'ALIAS very interesting, in a decade of REBOLing, I've never had a need for it. It seems value equivalence has been enough for me so far. BUT the symbol equivalence for path notation is something I never realized ALIAS allowed, and I actually would have used it this way in the past... had I known. ALIAS is kind of a feature that has fallen between the cracks and few of us, even Gurus, use it. Probably because REBOL's reduced syntax is so pliable to start with. I'll second Henrik's post that the explanation, in Carl's post REALLY makes a better case FOR it than any I have read before. Maybe something that can be removed and re-introduced later with better docs & more obvious usage examples and real-world scenarios where this makes REBOL better.
Ratio 31-Aug-2009 16:39:44	Example above doesn't work. It's recursive. We get a stack overflow: >> obj: make object! [ value: 123 print: does [print value] ] >> obj/print ** Internal Error: Stack overflow ** Where: print ** Near: print value This would work: >> obj: make object! [ value: 123 Xprint: does [print value] ] >> obj/Xprint 123 >> alias 'Xprint "imprimez" >> obj/imprimez 123 Ratio
Ratio 31-Aug-2009 16:43:16	If I understand Carls description correctly (was hard), alias 'print "imprimez" internally works as follows: word 'imprimez points to the word 'print word 'print points to the function print So alias installs an indirect function call (via the word 'print). With "symbols" Carl obviously means words, with "context" their meaning, with "namespace" the internal table of words, right? Then wouldn't it be a good idea to stick to a clearly defined language instead of changing the explanation syntax somehow voluntarily? In alias we are still using different words for the same thing. Those words are called synonyms. There is no "symbol-"/word-equivalence in the described sense. This is impossible, unthinkable. Yes, we may never forget, that in human and computer languages it's always the same: Everywhere we have just ONE but fundamental distinction: Words and there meanings (values, functions, cats and dogs). In semantics (see Carnap) the meaning of words is known as "extension" the word itself and its definition as "intension". So the word "horse" obviously is not a real horse. It just points to it. Exactly the same - not more and not less - applies to all human and computer languages. If we write imprimez: :print the word 'imprimez points (just as 'print) to function print directly. This already is a great! Superior to other IT languages. Alias implements an indirect function call, so it might be a bit slower. Obviously mainly designed to change existing source code at runtime it might be hard to get it working perfectly. I cannot see that this feature is really needed. There are other things I'm missing or not understanding: Generic keyboard handling especially in GUIs, dialogs between applications written in different languages, console for R3, improved documentation etc. Might be "small" issues, but important for REBOL beginners. Why not improve the more important, fundamental things first? Too trivial for Gurus? ;-) Ratio
danakil 31-Aug-2009 19:09:16	I'm a bit rusty on my REBOL so I'll quote from a different prog lang: This (array-oriented) language provides a function 'first that retrieves the first element from a collection. When that collection is used to represent an stack, it is convenient (at least stylistically) to refer to the 'first function as 'pop. An aliasing facility (which I assume analogous to REBOL's) provides the functionality to make it possible *without* having to define another function that ends up just calling the first one. This is, admittedly, a somewhat trivial example, but it should be enough to make the key issues stand out: the main benefit of an aliasing feature is domain-specific naming with *zero* performance burden.
Sunanda 1-Sep-2009 8:43:15	I am one of the people who have only used ALIAS enough to produce bug reports.... In R2 it is potentially a useful feature under some condition - not that I have ever used it for real. In R3, designing for ALIAS is problematic. Issues include: multiple contexts: is an alias universal (as, in effect in R2) ot just for system/contexts/whatever ? modules: if module A sets an alias, should module B be able to set the same word as an alias? If yes, one set of problems; if no, then independently written modules cannot be properly isolated from each other protect: protect and protect/hide and perhaps some other security code needs to be carefully designed so that aliases do not subvert the protection I think ALIAS could be useful in R3, but it does nor warrant any delays and extra design at this stage to make it play well with the rest of R3. Two suggestions: as per the blog: dump it inspired by one of Brian's Curecode tickets -- keep it, but require SECURE to enable it; be clear in the documentation that it is alpha only and not guaranteed to fully work. Then work on it again way after R3.0 is safely released.
Edoc 1-Sep-2009 9:11:57	I've used ALIAS before, to build simple command dialects. I liked the ability to support synonym words. I'm not overly attached to it, but I thought it was useful.
Brian Hawley 2-Sep-2009 13:23:56	Danakil, a: :b adds no overhead to function calls. This is a value alias, assigning a value to another word. Functions are values in REBOL. The ALIAS function performs symbol aliasing, making two different spellings of the same word. A value alias can be limited to a single context - a symbol alias can not, it affects every context.
danakil 2-Sep-2009 17:05:25	Brian, Thank you for your very clear explanation. I had overlooked the fact that functions are values in REBOL. This clearly avoids the performance issue. Nevertheless, the aliasing feature that I was talking about does behave like the `imprimez in Carl's example, with the further advantage that is also limited to a specific context (each namespace has its own alias dictionary). In J (the prog lang I was referring to) aliases are useful because they support renaming of functions without loosing the ability to take advantage of what is called "special code" (http://www.jsoftware.com/help/dictionary/special.htm). "Special code" turns out to be a far more important concept than the simple optimization that it seems at first sight: in short, is the recognition of patterns of function calls, and the automatic replacement (by the interpreter) of those patterns with a more efficient alternative. In fact, this is one of Backus' main points in his Turing Award lecture (http://www.thocp.net/biographies/papers/backus_turingaward_lecture.pdf) -- J, by the way, is a modern descendant/hybrid of Iverson's APL and Backus' FP/FL. Alas, at least in J, the function pattern recognition algorithm fails when the component functions have different names from the originals in the pattern specification. Aliasing solves that for J.
Ashley 2-Sep-2009 21:22:34	REBOL is already expressively rich enough to let you accomplish simple things in multiple ways ... do we really need to confuse newcomers even more by allowing the 'syntax' to be dynamically changed!
Gerard Cote 2-Sep-2009 21:46:03	I want REBOL be keeping its ALIAS alive and well running sinc this is one of the features I looked for since my first interest towards this language. I see it as an efficient and easy way to adapt the english words to french ones for teaching persons that are not proficient with english. Yes I saw it from the begining (back in 1999 but then I became very sick for ten years long and now I am just coming back to life and my REBOL interest revives) as a french REBOL language version of the language - then thought that simply replacing keywords by new ones would be sufficient. Not sure now this could be true - but nevertheless I would keep it - Finally I agree with Sunanda's advice above. Maybe later if this is to slow the R3 release. First things first!
Gerard Cote 2-Sep-2009 21:59:23	Please provide a mean to UNALIAS properly as it is now impossible to UNDO any previous ALIAS - even after entering a bad string ALIAS in the first time. Not very practical, except if automatically done using a validated script first.
-pekr- 2-Sep-2009 23:55:34	After reading all comments, I think there is no reason of why to remove an alias :-)
Ladislav 3-Sep-2009 8:48:30	The comments of the Alias proponents: Pekr: "...I never used alias..." Gerard: "...it is now impossible to UNDO any previous ALIAS..." Edoc: "...I've used ALIAS before..." I may be trying too hard to read between the lines, but cannot help to understand it as: "...do not use..." Carl Read: "...I've never personally found a use for it..." Danakil: "...Our company (...) using the J array programming language..." - again, can translate to "...not using it..." in my opinion I do not think more is needed to axe Alias.
Ben 3-Sep-2009 15:38:08	Slight concern with arbitrary release dates. Its not necessary to impose an arbitrary release date for a product. The product being developed is event driven - not date driven. I refer back to the old adage 'If it takes nine months for a women to make a baby, can it take one month for nine women?' No. Don't rush just to rush. There's plenty of that type of software out already. R2 is a great product. With the appropriate time being spent on R3, it will blow away anything on the market. -b
danakil 4-Sep-2009 12:55:48	(at)Ladislav: We were a *paying* corporate customer of R2, we still love REBOL and would *love* to use it again (commercially). R2 might still be a "great product", as Ben says, but we don't think it is wise to embark in a commercial project based on a technology that has been practically deprecated for several years now. R3 has arguably taken a bit too long to complete and it better be as powerful as possible when it comes out, thence our concern for alias and similar capabilities. Nevertheless, our most significant concern is the current GUI which strikes most people as quite amateurish in style (see www.extjs.com for an example of current state of the art) and functionality (multicolumn grids?) and the lack of a clear plan / concrete implementation of a browser plugin.
Giuseppe Chillemi 4-Sep-2009 14:46:24	I like the alias concept and I have never read about it until I posted a question on the mailing list. I don't ever now when it has been introduced as I have not found it in the official manual. I do not know which is the cost of maintaining it but the concept is quite good.
Ladislav 5-Sep-2009 9:52:27	Danakil: no offense intended, but I do not think you would need Alias for the purposes you mentioned. Your goals are achievable using more standard approaches, e.g. the context dependency may be crucial, but it is not actually supported by Alias, which makes symbols equal in all contexts. It is quite hard for me to convince you about that, since you actually did not try to compare Alias with other means.
Ladislav 5-Sep-2009 10:26:56	"...technology that has been practically deprecated for several years now..." - with all respect to your thoughts I cannot disagree more
Ladislav 5-Sep-2009 11:11	A terminological/explaining note. The Alias function does not create what is defined as "alias" in the dictionary. E.g. the expression: one: 1 can be interpreted as "giving a name" to the given number. If we use that terminology, then the expression: a-specific-number: :one gives another name to the number, so it can be considered an "alias" in that sense. As opposed to that, the expression: alias 'one "the-smallest-positive-integer" actually does not make the word 'the-smallest-positive-integer an alias of the word 'one in the above sense. Instead it causes the words 'one and 'the-smallest-positive-integer to be treated as *synonyms* regardless of any values they may refer to. Hope this clarifies the things at least a bit.
danakil 5-Sep-2009 17:02:58	Ladislav: no offense taken, on the contrary, I appreciate your detailed explanation of the aliasing functionality. Before, I was just pointing out that we were indeed likely candidates for commercial R3 licenses. AFAIK, in this industry, "deprecated" is used to refer to functionality that, though still available, has already been marked for deletion in an upcoming release, to be replaced by an improved mechanism. Although R2 has obviously never been officially marked as "deprecated", it is well known in the industry that approaches such as the one followed by Rebol Technologies in its handling of the R2-to-R3 transition usually result in a significant loss of momentum, if not a downright loss of sales. Even more so because of the gross underestimation of the time that it would take to release R3. The market is not standing still at all: Ruby, PHP, Javascript, and Python have all made great strides since R3 was announced; ExtJS, Capuccino/Objective-J, Adobe AIR, MS Silverlight, and Sun JavaFx have since appeared (although still struggling with birth pains); and Perl seems to be going the way of the dodo. Commercially, REBOL is stagnant. You may have misunderstood my reference to "dictionary of aliases" but the way you describe the alias functionality is *exactly* the way it behaves in our current environment. The aliased names are syntactically replaced ("translated") at a very late stage. Anyway, I'm not sure it is worth arguing more about this point since, as I said above, we have other--more important--concerns about R3.
Ladislav 5-Sep-2009 18:00:17	Sorry, not needing to argue with Danakil, but need to clarify, that the terminology I use is not compatible. Reasons: "deprecation" according to Wikipedia: "In computer software standards and documentation, the term deprecation is applied to software features that are superseded and should be avoided." - this is clearly not the case of R2; no recommendation was made that the usage of R2 "should be avoided", and if danakil makes such a statement, I simply disagree alias functionality - I read in danakil's contribution above: "each namespace has its own alias dictionary" Thus, it is not true, that the Alias functionality in REBOL behaves *exactly* this way, to the contrary, REBOL aliases are maintained "across namespace boundaries"
danakil 5-Sep-2009 18:37:35	(at)Ladislav: by "exactly this way" I clearly referred to the way you described the said functionality in your last comment (where you make no reference at all to context or namespace -- in fact, in one of my previous comments I explicitly stated that J's aliasing functionality differed from REBOL's in precisely the way you point out in this last comment of yours). I'm truly sorry to say so, but IMO it is very likely that if you were to recommend using R2 now for a large/important project in a corporate setting...you would risk getting fired, or at least laughed at. I have high hopes that R3 will change that.
Andreas Bolka 6-Sep-2009 6:58:51	Axe it.
Gerard Cote 6-Sep-2009 10:04:07	Another final comment. Since the use I see means translate in French and use every part of the language, it seems that we can't only alias the words but also all the body parts when the word is a function and everything else inside, Not a simple task in my opinion. For Mezzanines it's relatively easy, but for natives, it will be harder to cope with... Not sure it's a so good idea after all to go this way! For simple symbolic replacements it's a wish to be preserved, however.
Henrik 9-Sep-2009 3:50:43	Danakil: Nevertheless, our most significant concern is the current GUI which strikes most people as quite amateurish in style (see www.extjs.com for an example of current state of the art) and functionality (multicolumn grids?) and the lack of a clear plan / concrete implementation of a browser plugin. If that's state of the art, then we shouldn't have much trouble. :-)
Carl Sassenrath 9-Sep-2009 14:00:11	Ok, thank you for your inputs. I did not expect quite this much debate on it. I'll read it again very carefully, and make a decision. Also, I'll create some new blog threads for some of the other issues.

Post a Comment:

You can post a comment here. Keep it on-topic.