I think that is great, Dan. I like the table approach, especially for its use for mass updating internal parameters.
My approach is simpler, and is designed more to reduce line count than to expand it, while still providing the documentation benefit of named parameters. I disagree that its not extremely useful though there are 2 separate features of my implementation. The first is that for either y and/or x args, a line gets inserted into the function that is: 'parm1 parm2... parmn' =. y defaults fixlenx defval1;defval2...;defvaln I've been using such lines manually for a while, and its IMO extremely useful both in documenting, and the inherent usefulness to the caller of having optional parameters that exposes more customizability without imposing the tedium on the caller of caring about anything he doesn't want to. The 2nd feature is just moving that internal line out into the function definition as just the parameters: 'parm1 parm2... parmn';defval1;defval2...;defvaln Its hard to justify this 2nd feature as extremely useful, and it also loses the ability to easily refer to setting some default parameters based on other provided parameters, the purely data driven implementation does open other doors, such as: function signature documentation, integration into complex tacit expressions ( http://www.jsoftware.com/jwiki/PascalJasmin/Multiline%20tacit%20expressions%20with%20macros) the same definition format supports your table calling convention, which you might dismiss as useless fluff, but could be useful as a more public/exploratory API, and as such, a customizable calling convention can be implemented in "middleware" without touching the source definitions. > it would be hard to marry rank and named parameters in any cohesive and useful way The rebuttal is that not every function needs it (rank or parameters), but a parameterized function would make sense applied rank 1 to a table that is consistent in what parameters it ommits. Multiple application to variable parameter lists is easily done through boxing. In the end though, this is about functions determining their own calling conventions within the same language, and is an extremely powerful feature. J's little x and y's turn out to be more powerful than anything else because they can be turned into anything else. ----- Original Message ----- From: Dan Bron <[email protected]> To: [email protected] Cc: Sent: Wednesday, June 11, 2014 11:32:07 PM Subject: Re: [Jprogramming] copula -- function parameters for J Pascal wrote: > I wrote something else cool instead: > > Parsing function parameters outside of the function: > last section at: > http://www.jsoftware.com/jwiki/PascalJasmin/J%20tricks%20with%20assign I haven't read that whole page yet, but if you're interested in silly tricks with assign, maybe you'd like this (and the pages it links to): http://rosettacode.org/wiki/Named_parameters#J Basically, it lets you declare formal parameters for J verbs, conceptually like the "function foo(string name, int age)" of other languages, and then refer to these parameters, reliably and transparently, inside your verb (e.g. 'if. age > 10 do. 'Hello Mr.' , name else. 'Hey ',name',' is your dad around?' end.) . Auxillary names are defined to let you know whether a user specified a given parameter, or it took its default value. All names are completely, authentically local, and so evaporate when the verb exits. An additional script, added later, emulates the calling conventions of other languages (e.g. foo['Bobby',10] or foo[name='Bobby',age=10] etc). And though these things exist and were fun to write, I don't see any serious use for them in J. Our language has its own conventions, offered in pursuit of its own objectives, which are more often than not at odds with the conventions of most mainstream languages. For example, it would be hard to marry rank and named parameters in any cohesive and useful way; since rank is utterly central to J programming, we probably won't see much use of named parameters. -Dan ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
