On Fri, 2004-02-06 at 07:20, Michael Borek wrote:
>
> Please note that I wasn't suggesting that call-by-parameter-name be
> included now! I just wish to point out that using '=' or ':=' would
> require a syntax change should call-by-parameter-name ever be implemented.
Why? They are different beasts both lexically and semantically. There
would be no need to change the syntax of default value definition were
call-by-parameter-name ever be added.
> In addition, '=' is used for numeric equality and I don't believe should be
> overloaded for assignment. With respect to ':='; formally, no assignment
> is being done in the procedure declaration as there are no bindings in
> existence until the procedure is called.
That's true, but can't the same be said for the *entire* procedure
definition? I guess I don't see much difference between:
procedure foo(x:=1)
and
procedure foo(x)
/x := 1
(especially since they are symantically identical - so sharing a common
syntax seems pretty reasonable).
> I think that '=>' helps to
> reinforce the notion, in the declaration, that the assignment is deferred
> to the call.
But that breaks the syntactic and semantic 'link' with the above, and
would, to me at least, confuse things even more *if* Unicon ever added
call-by-parameter-name, since they are semantically different
operations. (I'm not advocating call-by-parameter-name incidently -
I think Clint is right. In fact, I've never been a fan of it [though
it *is* fun to think about!] - that's forcing extra lanes on the
namespace bridge between the calls and the definition of a procedure.)
> An important point is: not that '=>' be used, but that the symbol should be
> distinguishable so that no ambiguities could occur. (I simply picked
> this one as Ada already uses it for the same purpose.) Other possibilities
> are: ':-', ':>', '->', or '|-', for example (although I don't like using
> ':' twice for aesthetic reasons).
I happen to like the idea of "=>" for call-by-parameter-name, even
if I'm not particularly enthused about the basic idea itself!
Certainly, if CBPN were implemented in a language, I'd want a syntax
that is distinct from existing operations in that language, as the
operation bridges name spaces, which is a unique characteristic, e.g:
x := f(i => i +:= 1)
> + (As a side note, Ada also allows one to create a procedure which is
> + the same as another with some of the parameters filled in:
>
> + f(x, z) = g(x, y => 5, z) (NB: not the true Ada notation!)
Is this what is typically called a 'closure' in older languages? It's
an intriguing idea, but what are the advantages over (in Unicon):
procedure f(x,z)
suspend g(x,5,z)
end
(other than saving a some typing)? A small performance gain,
I suppose, but I keep hoping that a runtime-optimizer (aka 'hot-spot')
gets written for Unicon [Clint can repeat his point about
"unless someone pays for it..."]
Anyway, I've seen several proposals for type+default value declarations
that I'd be happy with. Maybe we should let Clint's group pick one and
put it in so the current oddities about trying to specify structured
types for parameters can be fixed - which is what I'm personally
concerned about.
Incidently a few tests of the resulting semantics are the following
procedure heads (using my personal favorite [heh,heh] syntax):
procedure f(x:list)
procedure f(x:=list())
procedure f(x:=list)
procedure f(x:list=list())
procedure g(x:list=list)
[Note, these do *different* things, deliberately - but
each makes sense from a type+initialization standpoint.]
--
Steve Wampler -- [EMAIL PROTECTED]
The gods that smiled on your birth are now laughing out loud.
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Unicon-group mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/unicon-group
