www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - dst = src rather than src dst

reply "Janice Caron" <caron serenityfirefly.com> writes:
Please could D allow the following syntaxes

alias dst = src;
typedef dst = src;

Instead of (or as well as)

alias src dst;
typedef src dst;

I just prefer the destination on the left. Moreover, it would make for greater 
consistency throughout D. It would match up with assignment operators, module 
import renaming, and alias template specializations.
Sep 05 2007
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Janice Caron wrote:
 Please could D allow the following syntaxes
 
 alias dst = src;
 typedef dst = src;
 
 Instead of (or as well as)
 
 alias src dst;
 typedef src dst;
 
 I just prefer the destination on the left. Moreover, it would make for 
 greater consistency throughout D. It would match up with assignment 
 operators, module import renaming, and alias template specializations.

This has been suggested before. I'm all for it. Since types are just a kind of value in the realm of compile time evaluation, it makes sense to just have them use the same syntax. It also puts the part you care about (the symbol you're going to be using) right up front where it's easy to find. Actually that's the part I really care about. I wouldn't mind if the syntax used ':=' or something instead of '=', I'd just like to see the order reversed. --bb
Sep 05 2007
parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Bill Baxter wrote:
 Janice Caron wrote:
 Please could D allow the following syntaxes

 alias dst = src;
 typedef dst = src;

 Instead of (or as well as)

 alias src dst;
 typedef src dst;

 I just prefer the destination on the left. Moreover, it would make for 
 greater consistency throughout D. It would match up with assignment 
 operators, module import renaming, and alias template specializations.

This has been suggested before. I'm all for it. Since types are just a kind of value in the realm of compile time evaluation, it makes sense to just have them use the same syntax. It also puts the part you care about (the symbol you're going to be using) right up front where it's easy to find. Actually that's the part I really care about. I wouldn't mind if the syntax used ':=' or something instead of '=', I'd just like to see the order reversed. --bb

I wouldn't be against it, at least as an alternative. That said, though, I've always seen alias'es and typedef's as being declerations, only directly of a symbol. In that case, they're fully consistant with other declerations taking the form 'TYPE SYMBOL'. All about perspective, I guess. -- Chris Nicholson-Sauls
Sep 05 2007
prev sibling next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Janice Caron" <caron serenityfirefly.com> wrote in message 
news:mailman.91.1188982444.16939.digitalmars-d puremagic.com...
 Please could D allow the following syntaxes

 alias dst = src;
 typedef dst = src;

 Instead of (or as well as)

 alias src dst;
 typedef src dst;

I doubt this will ever change, so to help you get used to the current syntax, here's how I think of it: int x; void function(int) fp; float[] f; These are some variable declarations, right? Now just add alias or typedef in front. alias int x; alias void function(int) fp; alias float[] f; Now they're legal aliases. Think of them like a variable declaration, except instead of making a variable, you're making a type.
Sep 05 2007
prev sibling next sibling parent Alexander Panek <alexander.panek brainsware.org> writes:
Janice Caron wrote:
 Please could D allow the following syntaxes
 
 alias dst = src;
 typedef dst = src;
 
 Instead of (or as well as)
 
 alias src dst;
 typedef src dst;
 
 I just prefer the destination on the left. Moreover, it would make for 
 greater consistency throughout D. It would match up with assignment 
 operators, module import renaming, and alias template specializations.
 
 

alias src [as] dst; typedef src [as] dst; Yay.
Sep 05 2007
prev sibling next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Janice Caron Wrote:

 Please could D allow the following syntaxes
 
 alias dst = src;
 typedef dst = src;
 
 Instead of (or as well as)
 
 alias src dst;
 typedef src dst;
 
 I just prefer the destination on the left. Moreover, it would make for greater 
 consistency throughout D. It would match up with assignment operators, module 
 import renaming, and alias template specializations.
 

I think it was done this way to maintain consistency with C's typedefs. Personally, I like the existing syntax, but I see no reason the other shouldn't be added as an alternative.
Sep 05 2007
parent James Dennett <jdennett acm.org> writes:
Robert Fraser wrote:
 Janice Caron Wrote:
 
 Please could D allow the following syntaxes

 alias dst = src;
 typedef dst = src;

 Instead of (or as well as)

 alias src dst;
 typedef src dst;

 I just prefer the destination on the left. Moreover, it would make for greater 
 consistency throughout D. It would match up with assignment operators, module 
 import renaming, and alias template specializations.

I think it was done this way to maintain consistency with C's typedefs.

Interestingly, C++ is introducing something like using newname = oldname; which, as a simple case, can replace the existing typedef notation typedef oldname newname; -- James
Sep 06 2007
prev sibling parent reply Russell Lewis <webmaster villagersonline.com> writes:
Let's take this one step further.  Let's say that this is a typedef:
     typedef dst = src.dup;
while this is an alias:
     typedef dst = src;
Sep 05 2007
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Russell Lewis Wrote:

 Let's take this one step further.  Let's say that this is a typedef:
      typedef dst = src.dup;
 while this is an alias:
      typedef dst = src;

Please no!
Sep 05 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Robert Fraser wrote:
 Russell Lewis Wrote:
 
 Let's take this one step further.  Let's say that this is a typedef:
      typedef dst = src.dup;
 while this is an alias:
      typedef dst = src;

Please no!

On second thought, let's take a step back again. And forward and back... and then we're cha-cha-ing! --bb [with apologies to Real Genius]
Sep 05 2007
parent reply Russell Lewis <webmaster villagersonline.com> writes:
Bill Baxter wrote:
 Robert Fraser wrote:
 Russell Lewis Wrote:

 Let's take this one step further.  Let's say that this is a typedef:
      typedef dst = src.dup;
 while this is an alias:
      typedef dst = src;

Please no!

On second thought, let's take a step back again. And forward and back... and then we're cha-cha-ing!

Yeah, I felt the same way when the syntax first occurred to me: "EEK! RUN!" But it's growing on me. There is a certain elegance to the idea that a type is a compile-time variable, and that an alias is copying the (reference to) the type, while a typedef is creating a new type with the same contents (that is, the same semantics) as the old. But I still shudder when I see it. :)
Sep 05 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Russell Lewis wrote:
 Bill Baxter wrote:
 Robert Fraser wrote:
 Russell Lewis Wrote:

 Let's take this one step further.  Let's say that this is a typedef:
      typedef dst = src.dup;
 while this is an alias:
      typedef dst = src;

Please no!

On second thought, let's take a step back again. And forward and back... and then we're cha-cha-ing!

Yeah, I felt the same way when the syntax first occurred to me: "EEK! RUN!" But it's growing on me. There is a certain elegance to the idea that a type is a compile-time variable, and that an alias is copying the (reference to) the type, while a typedef is creating a new type with the same contents (that is, the same semantics) as the old. But I still shudder when I see it. :)

Well, I didn't think it was a horrible idea, just not really necessary. D already has a decent way to distinguish aliases vs definition new types, and as far as I know it doesn't cause any consternation in daily coding (basically you just never use the latter). For a new language without any established conventions it might be a nice idea to treat types more like values across the board, and I believe there are languages that do exactly this (like lisp and python) but I think it's too late for D to try to make such a big change. Just reversing the order of arguments to alias and typedef and sticking an '=' between them seems like a good value proposition to me. Decent gain in readability and consistency, minimal pain in terms of old code breakage (assuming old-style aliases remain allowed for a while.) --bb
Sep 05 2007
parent reply Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Bill Baxter wrote:
 Russell Lewis wrote:
 
 Bill Baxter wrote:

 Robert Fraser wrote:

 Russell Lewis Wrote:

 Let's take this one step further.  Let's say that this is a typedef:
      typedef dst = src.dup;
 while this is an alias:
      typedef dst = src;

Please no!

On second thought, let's take a step back again. And forward and back... and then we're cha-cha-ing!

Yeah, I felt the same way when the syntax first occurred to me: "EEK! RUN!" But it's growing on me. There is a certain elegance to the idea that a type is a compile-time variable, and that an alias is copying the (reference to) the type, while a typedef is creating a new type with the same contents (that is, the same semantics) as the old. But I still shudder when I see it. :)

Well, I didn't think it was a horrible idea, just not really necessary. D already has a decent way to distinguish aliases vs definition new types, and as far as I know it doesn't cause any consternation in daily coding (basically you just never use the latter). For a new language without any established conventions it might be a nice idea to treat types more like values across the board, and I believe there are languages that do exactly this (like lisp and python) but I think it's too late for D to try to make such a big change.

In Python, types /are/ values. That is, classes are objects; you can even define classes whose instances are classes. These are called metaclasses. Python's object model is so thoroughly different from D's that this comparison is not a useful one.
 Just reversing the order of arguments to alias and typedef and sticking 
 an '=' between them seems like a good value proposition to me.  Decent 
 gain in readability and consistency, minimal pain in terms of old code 
 breakage (assuming old-style aliases remain allowed for a while.)
 

As to the actual proposal, I am basically indifferent. The /lack/ of the equals sign makes it clear that it reads left-to-right, in my mind. Although you might make it syntactically consistent with assignment: int i = 10; alias F = Foo; It will still be different from assignment in very fundamental ways: i = 20; // okay F = Bar; // Huh? alias F = Baz; // Ack! The fact that the syntax looks nothing like assignment underscores the fact that /it is not an assignment/. I would classify the proposal as a foolish consistency, but I wouldn't really care if it were added. (Except that adding redundant syntaxes for the same operation is rarely a good idea.) -- Kirk McDonald http://kirkmcdonald.blogspot.com Pyd: Connecting D and Python http://pyd.dsource.org
Sep 05 2007
next sibling parent reply Nathan Reed <nathaniel.reed gmail.com> writes:
Kirk McDonald wrote:
 The fact that the syntax looks nothing like assignment underscores the 
 fact that /it is not an assignment/. I would classify the proposal as a 
 foolish consistency, but I wouldn't really care if it were added. 
 (Except that adding redundant syntaxes for the same operation is rarely 
 a good idea.)
 

I second the proposal someone already made of allowing alias Foo as Bar; This doesn't look like an assignment, but makes the declaration more readable and allows one to easily remember which identifier is the alias being created (at least, if one is a native English speaker...) at the slight cost of adding the keyword 'as'. The 'as' could be optional so as not to break existing code. Thanks, Nathan Reed
Sep 05 2007
next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Nathan Reed wrote:
 Kirk McDonald wrote:
 The fact that the syntax looks nothing like assignment underscores the 
 fact that /it is not an assignment/. I would classify the proposal as 
 a foolish consistency, but I wouldn't really care if it were added. 
 (Except that adding redundant syntaxes for the same operation is 
 rarely a good idea.)

I second the proposal someone already made of allowing alias Foo as Bar; This doesn't look like an assignment, but makes the declaration more readable and allows one to easily remember which identifier is the alias being created (at least, if one is a native English speaker...) at the slight cost of adding the keyword 'as'. The 'as' could be optional so as not to break existing code.

I wouldn't say it's totally unambiguous. When I first read it just now I thought "foo as bar ... we're going to refer to foo as bar. Wait, that sounds just like the current alias?!" Whereas I can't think of any way someone could misinterpret which is the new and which is the old in "alias Foo = Bar;" --bb
Sep 05 2007
prev sibling next sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
Nathan Reed wrote:
 Kirk McDonald wrote:
 The fact that the syntax looks nothing like assignment underscores the 
 fact that /it is not an assignment/. I would classify the proposal as 
 a foolish consistency, but I wouldn't really care if it were added. 
 (Except that adding redundant syntaxes for the same operation is 
 rarely a good idea.)

I second the proposal someone already made of allowing alias Foo as Bar;

Is that: class Bar; alias Foo as Bar; // treat identifier Foo the same as Bar or: class Foo; alias Foo as Bar; // refer to Foo as Bar And I'm a native English speaker. On the other hand, the equals sign is quite unambiguous because it's a close analogy to existing assignments.
Sep 05 2007
parent Alexander Panek <alexander.panek brainsware.org> writes:
Christopher Wright wrote:
 Is that:
 class Bar;
 alias Foo as Bar; // treat identifier Foo the same as Bar
 
 or:
 class Foo;
 alias Foo as Bar; // refer to Foo as Bar
 
 And I'm a native English speaker.
 
 On the other hand, the equals sign is quite unambiguous because it's a 
 close analogy to existing assignments.

Actually that "[as]" wasn't a proposition to /change/ the syntax, but rather a hint for people who might find the order unintuitive. Personally I don't have a problem with it, as it's simple and straight forwards alias one thing as another. (That's like with x86 assembly: Intel syntax is mov DST, SRC; AT&T syntax is mov SRC, DST -- if AT&T wasn't so unreadable in all other aspects, I'd go for it just because of the order of operands.) I'm all against the equal sign, because it's used in completely different terms. Assigning one type to the other just doesn't look right. Kind regards, Alex
Sep 06 2007
prev sibling parent Russell Lewis <webmaster villagersonline.com> writes:
Nathan Reed wrote:
 Kirk McDonald wrote:
 The fact that the syntax looks nothing like assignment underscores the 
 fact that /it is not an assignment/. I would classify the proposal as 
 a foolish consistency, but I wouldn't really care if it were added. 
 (Except that adding redundant syntaxes for the same operation is 
 rarely a good idea.)

I second the proposal someone already made of allowing alias Foo as Bar; This doesn't look like an assignment, but makes the declaration more readable and allows one to easily remember which identifier is the alias being created (at least, if one is a native English speaker...) at the slight cost of adding the keyword 'as'. The 'as' could be optional so as not to break existing code.

I don't think that this will add a lot of clarity. I don't know about other people, but when I read that syntax above, I still ask the question, "Is Foo being declared to be 'the same as' Bar, or is Bar being declared 'as a new alias of' Foo." Perhaps it is instantly clear to other folks, I don't know. But I know that at least one programmer finds the "as" syntax just as unclear as the original.
Sep 06 2007
prev sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Kirk McDonald wrote:
 Bill Baxter wrote:

 Just reversing the order of arguments to alias and typedef and 
 sticking an '=' between them seems like a good value proposition to 
 me.  Decent gain in readability and consistency, minimal pain in terms 
 of old code breakage (assuming old-style aliases remain allowed for a 
 while.)

As to the actual proposal, I am basically indifferent. The /lack/ of the equals sign makes it clear that it reads left-to-right, in my mind.

I don't think it's a matter of being difficult to remember where src and dest are supposed to go (though I do admit I type it backwards sometimes) It's just harder to read. It's like putting the name of a function at the end of the function body. Or the name of a class at the end. Names and titles of things go at the beginning, not the end. Unless you're Paul Harvey telling "the rest of the story". The reader of code runs across a symbol like "value_type" and needs to find out what that is. I say it's harder to find it here: alias init_base!(init_with_call_policies!(CallPoliciesT, InitT)) base; alias InitT.n_arguments n_arguments; alias InitT.n_defaults n_defaults; alias InitT.signature signature; alias pointee!(Ptr).type value_type; alias objects.pointer_holder!(Ptr,value_type) holder; alias objects.instance!(holder) instance_t; than here: alias base = init_base!(init_with_call_policies!(CallPoliciesT, InitT)); alias n_arguments = InitT.n_arguments; alias n_defaults = InitT.n_defaults; alias signature = InitT.signature ; alias value_type = pointee!(Ptr).type; alias holder = objects.pointer_holder!(Ptr,value_type); alias instance_t = objects.instance!(holder); The fact that it's more consistent with value assignments and with renamed import syntax is a nice added bonus.
 Although you might make it syntactically consistent with assignment:
 
 int i = 10;
 alias F = Foo;
 
 It will still be different from assignment in very fundamental ways:
 
 i = 20; // okay
 F = Bar; // Huh?
 alias F = Baz; // Ack!

I don't get your point with that example. All types are inherently 'final' since they are always compile time constants. So it's just like saying: final int i = 10; i = 20; // huh? Yeh, that's just wrong. You can't do it. Nothing strange about it.
 The fact that the syntax looks nothing like assignment underscores the 
 fact that /it is not an assignment/. 

I would say that the fact that the syntax looks nothing like assignment belies the fact that /it is an assignment/. Think of 'alias' as meaning 'metatype', the type of types. metatype F = Baz; F is a new type variable (metatype) and now it equals the same thing as type variable Baz.
 I would classify the proposal as a 
 foolish consistency, but I wouldn't really care if it were added. 
 (Except that adding redundant syntaxes for the same operation is rarely 
 a good idea.)

Well redundancy, there is that, yes. I suppose we could propose to leave D1.0 as is and change 2.0 completely. But I think it's probably better to leave both in and just think of it as a backwards compatibility nod to C/C++ -- just like foo x[3]; vs foo[3] x; --bb
Sep 05 2007
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Bill Baxter wrote:
 Kirk McDonald wrote:
 [snip]
 
 Although you might make it syntactically consistent with assignment:

 int i = 10;
 alias F = Foo;

 It will still be different from assignment in very fundamental ways:

 i = 20; // okay
 F = Bar; // Huh?
 alias F = Baz; // Ack!

I don't get your point with that example. All types are inherently 'final' since they are always compile time constants. So it's just like saying: final int i = 10; i = 20; // huh? Yeh, that's just wrong. You can't do it. Nothing strange about it.

import module1; import module2; alias toString = module1.toString; alias toString = module2.toString; If you're going to maintain consistency with assignment, overloading a symbol should be gotten rid of as well.
 The fact that the syntax looks nothing like assignment underscores the
 fact that /it is not an assignment/. 

I would say that the fact that the syntax looks nothing like assignment belies the fact that /it is an assignment/. Think of 'alias' as meaning 'metatype', the type of types. metatype F = Baz; F is a new type variable (metatype) and now it equals the same thing as type variable Baz.

But it's *not* assignment. Variables have a single location in memory. A symbol can refer to many things. Come D 2.0, it'll even be able to refer to many things of different types (regular functions overloaded on templates).
 I would classify the proposal as a foolish consistency, but I wouldn't
 really care if it were added. (Except that adding redundant syntaxes
 for the same operation is rarely a good idea.)

Well redundancy, there is that, yes. I suppose we could propose to leave D1.0 as is and change 2.0 completely. But I think it's probably better to leave both in and just think of it as a backwards compatibility nod to C/C++ -- just like foo x[3]; vs foo[3] x;

I'm not a big fan of the proposal because you're getting into murky semantic waters using '='. I see this as a case of "if it ain't broke, don't fix it". :) -- Daniel
Sep 05 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Daniel Keep wrote:
 
 Bill Baxter wrote:
 Kirk McDonald wrote:
 [snip]

 Although you might make it syntactically consistent with assignment:

 int i = 10;
 alias F = Foo;

 It will still be different from assignment in very fundamental ways:

 i = 20; // okay
 F = Bar; // Huh?
 alias F = Baz; // Ack!

'final' since they are always compile time constants. So it's just like saying: final int i = 10; i = 20; // huh? Yeh, that's just wrong. You can't do it. Nothing strange about it.

import module1; import module2; alias toString = module1.toString; alias toString = module2.toString;

Hmm. Ok that's very interesting. I didn't realize that was possible with symbol aliases (I've been thinking pretty much only about types).
 If you're going to maintain consistency with assignment, overloading a
 symbol should be gotten rid of as well.

Once again, I don't think consistency is the main reason to make the change, but it's a nice bonus. Improved readability of keeping everything on the left side is what I'm after. So I guess my reaction to the above is, yeh, there's an inconsistency now between type aliases and symbol aliases, and after the change there would be an equivalent inconsistency between value assignment and symbol alias assignment. If that inconsistency bothers people more than the current inconsistency for some reason then I'd be happy for there to be a different alias assignment syntax besides '=', as long as the thing being defined goes on the left side.
 The fact that the syntax looks nothing like assignment underscores the
 fact that /it is not an assignment/. 

belies the fact that /it is an assignment/. Think of 'alias' as meaning 'metatype', the type of types. metatype F = Baz; F is a new type variable (metatype) and now it equals the same thing as type variable Baz.

But it's *not* assignment.

I don't mean its an assignment in the "D grammar AssignExpression := ..." sense. Obviously its not that. But it *is* assigning a symbol (F) a meaning (Baz).
 Variables have a single location in memory.
 A symbol can refer to many things.

Yeh, but a _type_ alias cannot refer to many _types_.
 Come D 2.0, it'll even be able to
 refer to many things of different types (regular functions overloaded on
 templates).

But a type alias will still only be one type... I think. Has to be since otherwise the compiler has no way of knowing what you mean when you declare a new one: T foo;
 I'm not a big fan of the proposal because you're getting into murky
 semantic waters using '='.  I see this as a case of "if it ain't broke,
 don't fix it".  :)

Yeh, and that's probably how Walter sees it too. It ain't broke, just sprained a bit. Just like automatic fallthrough in switch statements. It doesn't hurt bad enough to warrant breaking with how C does it. I thought maybe there was a chance this time, because in the previous discussion I don't think anyone mentioned the possibility of maintaining the C-compatible alongside the new syntax. Unlike the switch fallthrough issue the new syntax wouldn't preclude the old. Plus by this time I was hoping there were enough people seriously immersed in generic programming to see the type:value :: metatype:type analogy more clearly. But if Kirk doesn't get it, and Don doesn't chime in with "what a great idea" in the next 5 minutes, well ... it's hopeless. --bb
Sep 05 2007
next sibling parent Daniel Keep <daniel.keep.lists gmail.com> writes:
Bill Baxter wrote:
 Daniel Keep wrote:
 [snip]

 I'm not a big fan of the proposal because you're getting into murky
 semantic waters using '='.  I see this as a case of "if it ain't broke,
 don't fix it".  :)

Yeh, and that's probably how Walter sees it too. It ain't broke, just sprained a bit. Just like automatic fallthrough in switch statements. It doesn't hurt bad enough to warrant breaking with how C does it. I thought maybe there was a chance this time, because in the previous discussion I don't think anyone mentioned the possibility of maintaining the C-compatible alongside the new syntax. Unlike the switch fallthrough issue the new syntax wouldn't preclude the old. Plus by this time I was hoping there were enough people seriously immersed in generic programming to see the type:value :: metatype:type analogy more clearly. But if Kirk doesn't get it, and Don doesn't chime in with "what a great idea" in the next 5 minutes, well ... it's hopeless. --bb

If it's any consolation, I'd be over the moon if it really *was* assignment. Having types as just another value opens up so many interesting possibilities. Sadly, that's not the case in D just as of yet. Oh well :) -- Daniel
Sep 05 2007
prev sibling parent reply Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Bill Baxter wrote:
 But if Kirk doesn't get it, and Don doesn't chime in with "what a great 
 idea" in the next 5 minutes, well ... it's hopeless.
 
 --bb

I do "get it" (an "alias" is the type of a symbol, you initialize the alias to the symbol, &c &c), I just don't particularly like it very much. This is primarily because it's merely a syntax change. If the old syntax is retained, we have redundant syntaxes, which is annoying and not a good thing. Before removing the current syntax, we have to of course consider the existing body of code which would have to be changed. (I do not think I need to belabor this point. Remember when implicit .ptr conversion was removed? This would be much worse. Removing the existing syntax is Not An Option.) Neither option is a winner. Last and least, I do not not think it's much of an improvement. It is not like the existing syntax is ambiguous. It's not even unclear. In fact, my most frequent uses of alias render the "rvalue" and "lvalue" of the alias abundantly clear, since the rvalue frequently has keywords and things in it, or at least is more complicated than just an identifier. (Which is usually why I'm aliasing it in the first place.) -- Kirk McDonald http://kirkmcdonald.blogspot.com Pyd: Connecting D and Python http://pyd.dsource.org
Sep 06 2007
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Kirk McDonald wrote:
 Bill Baxter wrote:
 But if Kirk doesn't get it, and Don doesn't chime in with "what a 
 great idea" in the next 5 minutes, well ... it's hopeless.

 --bb

I do "get it" (an "alias" is the type of a symbol, you initialize the alias to the symbol, &c &c),

Sorry for saying that. I know you understand the concept perfectly. I was think something more like "get that it would be a worthwhile change" but I just cut out too many words. --bb
Sep 06 2007