Namelist as left argument
7 posts
• Page 1 of 1
Namelist as left argument
I wander what was the reason of not allowing Namelist as function left argument?
Valid function:
Non valid:
Valid function:
- Code: Select all
(a b)←g foo(d e f)
Non valid:
- Code: Select all
(a b)←(g h)foo(d e f)
- alexbalako
- Posts: 16
- Joined: Mon Nov 30, 2009 8:58 pm
Re: Namelist as left argument
There is an (admittedly weak) argument that there are two styles of functions: "infix" functions which take an argument on either side and behave like an APL primitive, and "method-like" functions which might take a long list of arguments and do something more "application-like". In this case, it seems like a better idea to put all the arguments on the right side in the style adopted by most other programming languages. Naming elements of the left argument allows you to "mix metaphors".
The real reason is that it doesn't seem suficiently important to warrant the effort required to implement it (it is not as "trivial" as it might seem) - there are so many other projects which are "more worthy".
The new APL# language *is* likely to support naming the elements of both arguments.
The real reason is that it doesn't seem suficiently important to warrant the effort required to implement it (it is not as "trivial" as it might seem) - there are so many other projects which are "more worthy".
The new APL# language *is* likely to support naming the elements of both arguments.
-
Morten|Dyalog - Posts: 451
- Joined: Tue Sep 09, 2008 3:52 pm
Re: Namelist as left argument
A counter that I'd like to throw in is that there is a long-standing convention for mixed functions that "control" arguments go on the left with "data" on the right; I can envisage needing more control sub-arguments than data - as in "use this, that and the other to mutate this data array". But I haven't checked my actual usage and know that only this week I did a "mutate this array using this, that and the other" because the readability of the code worked out better that way.
I certainly feel uncomfortable with "like most other programming languages".
If I keep this up, please can I be banned?
I certainly feel uncomfortable with "like most other programming languages".
If I keep this up, please can I be banned?
Visit http://apl.dickbowman.com to read more from Dick Bowman
-
Dick Bowman - Posts: 235
- Joined: Thu Jun 18, 2009 4:55 pm
Re: Namelist as left argument
Dick Bowman wrote:I certainly feel uncomfortable with "like most other programming languages".
Then stay with "classic" APL and don't name parts of either argument - this is a sneaking similarity with other programming languages :-).
It certainly goes against the age-old APL tradition of having "optional" elements of either argument (especially common for "control" arguments on the left).
-
Morten|Dyalog - Posts: 451
- Joined: Tue Sep 09, 2008 3:52 pm
Re: Namelist as left argument
Lots of my old STSC APL*PLUS mainframe code is (I am still supporting it) of the form
R <- LA function RA;L1;L2;L3;R1;R2
L1 L2 L3 <- LA
R1 R2 <- RA
....
which is crying out for a namelist for both left and right arguments.
When recoding this in Dyalog, there are often good reasons not change it to
R <- function (L1 L2 L3 R1 R2)
......
Using the "Modified Assignment Operator" ( "A + <- 1" )
where the function being called has a namelist as its results
really "need" a namelist as it's left argument.
(Admititly, Comute might help here.)
So please add "Namelist as left argument" into Dyalog.
Ray
(PS Sorry about the non-use of an APL font, but I do not yet have Dyalog installed on my new PC.)
R <- LA function RA;L1;L2;L3;R1;R2
L1 L2 L3 <- LA
R1 R2 <- RA
....
which is crying out for a namelist for both left and right arguments.
When recoding this in Dyalog, there are often good reasons not change it to
R <- function (L1 L2 L3 R1 R2)
......
Using the "Modified Assignment Operator" ( "A + <- 1" )
where the function being called has a namelist as its results
really "need" a namelist as it's left argument.
(Admititly, Comute might help here.)
So please add "Namelist as left argument" into Dyalog.
Ray
(PS Sorry about the non-use of an APL font, but I do not yet have Dyalog installed on my new PC.)
Ray Cannon
Please excuse any smelling pisstakes.
Please excuse any smelling pisstakes.
-
ray - Posts: 219
- Joined: Wed Feb 24, 2010 12:24 am
- Location: Blackwater, Camberley. UK
Re: Namelist as left argument
Noted and registered as a "Request For Enhancement". However, being able to rewrite:
as
Isn't really a "giant leap" for mankind, compared to the effort required to implement and document it, and compared to other things that people have asked for... so at the moment this "RFE" is not anywhere near the top of the "To Do" list.
- Code: Select all
R ← LA function RA;L1;L2;L3;R1;R2
L1 L2 L3 ← LA
R1 R2 ← RA
as
- Code: Select all
R ← (L1 L2 L3) function (R1 R2)
Isn't really a "giant leap" for mankind, compared to the effort required to implement and document it, and compared to other things that people have asked for... so at the moment this "RFE" is not anywhere near the top of the "To Do" list.
-
Morten|Dyalog - Posts: 451
- Joined: Tue Sep 09, 2008 3:52 pm
Re: Namelist as left argument
Actually, I'm becoming quite fond of the old mainframe idea of single arguments - because each one can (should?) now be a collection object, either GUI form or normal namespace.
True, instead of var1 var2 var3 {gets} RA, you would now have to change the entries to RA.var1
But think of the power you now have - not just boring old variables, but now tools can be passed as well - perhaps a localised collection of spiffing new dfns (created long after this ex-mainframe fn was born) to operate on var1, var2 etc? And of course this could go a long way to removing both global refs and even []PATH?
I'm well known as a fully paid-up fan of the LUV data structure (2-element nested array, namelist in 1st element keys position of actual data in 2nd); but the overheads of reading/writing are sometimes too much for small operations, and of course it only 'transports' data.
Which perhaps is the long way of saying, 'don't bother with this change [do something new/exciting]'
True, instead of var1 var2 var3 {gets} RA, you would now have to change the entries to RA.var1
But think of the power you now have - not just boring old variables, but now tools can be passed as well - perhaps a localised collection of spiffing new dfns (created long after this ex-mainframe fn was born) to operate on var1, var2 etc? And of course this could go a long way to removing both global refs and even []PATH?
I'm well known as a fully paid-up fan of the LUV data structure (2-element nested array, namelist in 1st element keys position of actual data in 2nd); but the overheads of reading/writing are sometimes too much for small operations, and of course it only 'transports' data.
Which perhaps is the long way of saying, 'don't bother with this change [do something new/exciting]'
- Peter Merritt
- Posts: 3
- Joined: Sun Feb 28, 2010 12:21 pm
7 posts
• Page 1 of 1
Who is online
Users browsing this forum: No registered users and 1 guest
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group