Thanks for the comments. My responses to individual points follow after my additional remarks.
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. 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. I think that '=>' helps to reinforce the notion, in the declaration, that the assignment is deferred to the call. 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). Specific points: > Clint: > The discussion of changing the syntax of calls is a request that Unicon be > extended to include a means of overriding the declared parameter order by > explicit names. + I'm not asking for this now. As you state below, it would be expensive. + The point I want to make with respect to this is that, should it ever be + feasible to implement call-by-parameter-name, the notation I propose + would not have to be altered, whereas using either '=' or ":=" would + require a syntax change. > I believe Ada and Common Lisp have this feature, and that + You are correct. Ada has it for all parameters; Lisp only for those + parameters designated as keywords. > it has real value, mainly in procedures with many parameters and many > defaults. + (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!) > On the other hand, parameters to function calls are expressions, > where all of (Icon and) Unicon's rich set of operators are in full force. > The potential for misinterpretation is rich. A call-parameters-by-name > extension would be great, but it is a major design and implementation > project, not a minor revision such as the one that started this thread. So > unless someone wants to implement it, or fund it, it is not going to happen > any time soon ;-) and there is no need to debate specific syntax options for > it. + You are correct on all points. As I wrote above, I'm not actually asking + for this (yet!:^) > Wade: > ... But I thought the notation proposed was for *declaring* functions, > not *calling* them. + You are right. I am not proposing it for calling procedures; that was + an addendum to point out its utility for the future. > I was going to ask why you'd put a default value into the call, but come to > think of it, I can imagine this might be useful. + I wasn't actually thinking of doing this and don't quite understand + what you mean #^) Perhaps you could expand on the topic? > OTOH, a way of calling > parameters by name would be more useful, but different. I'd prefer => being > used to name parameters in that way. So: > procedure form_field(type := INPUT_HIDDEN, name, value := &null, width := > "") > ... could be called: > form_field(name => "edit_id") > ... which would be the same as: > form_field(INPUT_HIDDEN, "edit_id") + I think we are better served by using the same notation for parameter + defaulting and binding. Finally, I'm sorry for the long lines; autowrap sometimes does have its drawbacks! Thank you Michael -- "Death before Dishonour; Beer before Lunch" __________________________________________________________________ New! Unlimited Netscape Internet Service. Only $9.95 a month -- Sign up today at http://isp.netscape.com/register Act now to get a personalized email address! Netscape. Just the Net You Need. ------------------------------------------------------- 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
