False negative
15 posts
• Page 2 of 2 • 1, 2
Re: False negative
jayfoad wrote:It is tempting to think that all these problems would have been avoided if Dyalog had insisted from day 1 that the LHS of a strand assignment had to be parenthesised:(x y)←... ⍝ strand assignment
x y←... ⍝ would be parsed as x(y←...)
But I'm not sure that's true. There would still be cases like this:x(y z)←... ⍝ ???
Sure, you would know that this is not strand assignment to x(y z); but it could still be modified assignment to x if z was a monadic operator.
I don't think that would remain ambiguous. If x currently has nameclass 2, 8, or 9, then it is modified assignment, and if x currently has nameclass ⎕NC 3, then it is assignment to y and z with the pass-though value being fed to x. Otherwise (nameclass 0, 1, or 4) then it would cause an error.
-
Adam|Dyalog - Posts: 143
- Joined: Thu Jun 25, 2015 1:13 pm
Re: False negative
Thanks for all those clarifying remarks, but ...
that reminds me of reading Stroustrup.
IMO it is getting too complicated in the set of rules you need to know to understand all the possible implications of an assigment mixing with strand notation.
I think we should keep it as simple and "APL-beautiful" as possible.
Kind Regards,
JoHo
that reminds me of reading Stroustrup.
IMO it is getting too complicated in the set of rules you need to know to understand all the possible implications of an assigment mixing with strand notation.
I think we should keep it as simple and "APL-beautiful" as possible.
Kind Regards,
JoHo
-
JoHo - Posts: 37
- Joined: Sat Nov 28, 2009 12:51 pm
- Location: Austria, EU
Re: False negative
I'm admittedly as guilty as anyone in bastardising my dfns with "dewy" code (as opposed to "izzy") (see "How to Write Computer Programs" by John Scholes https://www.dyalog.com/uploads/document ... e_prog.pdf) but strictly speaking modified assignment is foreign to the functional paradigm that dfns profess to espouse.
Its generalisation was presumably modelled largely outside the remit of dfns and in the knowledge that they are, at least to an extent, incompatible.
Its generalisation was presumably modelled largely outside the remit of dfns and in the knowledge that they are, at least to an extent, incompatible.
-
Phil Last - Posts: 628
- Joined: Thu Jun 18, 2009 6:29 pm
- Location: Wessex
Re: False negative
It would be interesting to see how programmers have come to use dfns in real life. As a non-commercial user (thanks for even reading this!), I may not be representative. I often try to do everything via dfns if I can, because it's so easy to create a hierarchy of subfunctions to encapsulate and reuse code; indeed, because of this encapsulation and reuse, dfns are actually easier than tradfns to build and maintain (in our current post-workspace-as-organizing-unit age), especially if very large functions (many 100s to 1000s of lines). (Yes, you can encapsulate via a CLASS or NAMESPACE, but often want a single "function" to provide a complete service).
Where absolutely required, e.g. by syntax or access to special "directives" (like TRIGGERs), I switch over to tradfns; because of that, I would prefer that there be fewer artificial barriers and secondary distinctions between the two types. (Maintain the primary distinctions-- "control structures" generally don't belong in dfns, but differences in core syntax discussed here are really challenging for new learners and for what? Dfns aren't aligned with pure functional programming anyway.).
That is, dfns aren't simply APL's variant of lambda in other languages; they seem wholly amenable to both "do" and "be" styles writ large. Like Python tools, dfns may support functional programming, but they are far too flexible (good!) for us to treat them as functional programming tools in a strict sense. Personally, I'd love to be able to create a tradfn within a dfn without resorting to preprocessor tricks, ⎕FX, or other inefficient fixes (pun intended)-- but not all the time, just when there is something that demands it.
IMHO gone are the days when dfns were the tail-- they are now half the dog! [Sorry for the dog metaphor which "begs" the question: which half? The answer of course is "The right half."].
Where absolutely required, e.g. by syntax or access to special "directives" (like TRIGGERs), I switch over to tradfns; because of that, I would prefer that there be fewer artificial barriers and secondary distinctions between the two types. (Maintain the primary distinctions-- "control structures" generally don't belong in dfns, but differences in core syntax discussed here are really challenging for new learners and for what? Dfns aren't aligned with pure functional programming anyway.).
That is, dfns aren't simply APL's variant of lambda in other languages; they seem wholly amenable to both "do" and "be" styles writ large. Like Python tools, dfns may support functional programming, but they are far too flexible (good!) for us to treat them as functional programming tools in a strict sense. Personally, I'd love to be able to create a tradfn within a dfn without resorting to preprocessor tricks, ⎕FX, or other inefficient fixes (pun intended)-- but not all the time, just when there is something that demands it.
IMHO gone are the days when dfns were the tail-- they are now half the dog! [Sorry for the dog metaphor which "begs" the question: which half? The answer of course is "The right half."].
- petermsiegel
- Posts: 160
- Joined: Thu Nov 11, 2010 11:04 pm
Re: False negative
Hi Peter,
Thanks for the thoughts about dfns! The use of dfns is definitely growing, they are especially popular with newcomers to APL, where I think it is safe to say that the usage is in excess of 50%. The usage is definitely growing amongst commercial users too, but remains a very small percentage, even for newly written commercial code, as far as I can tell.
Quite a few commercial users have started using small anonymous dfns (line fragments). Only a few are writing multi-line functions. Some people are mostly attracted to dfns because you don't need to declare locals, while others actually appreciate the lexical scope and the ability to create multi-function capsules the way you describe.
For people who mostly want dfns in order to avoid localisation, I have actually started thinking that we might want to extend tradfn notation soon to allow you to declare that all locals defined using assignment in the body of a tradfn would be local, with explicit declaration of globals. We are seeing people who use dfns MERELY to achieve this effect get into trouble when they call a dfn which calls a tradfn and that uses another dfn: at this point the combination of dynamic and lexical scopes can be tricky to deal with for someone who is only accustomed to dynamic scope.
The growth of dfns will probably continue. Without wanting to name any body parts, it is clear that we need to revisit aspects of the language and tooling in order to adapt to the growing use of dfns. I think it is difficult to imagine extending the notation to allow dfns to contain in-line tradfns, but perhaps that is just a lack of imagination on my part, we'll see.
Morten
Thanks for the thoughts about dfns! The use of dfns is definitely growing, they are especially popular with newcomers to APL, where I think it is safe to say that the usage is in excess of 50%. The usage is definitely growing amongst commercial users too, but remains a very small percentage, even for newly written commercial code, as far as I can tell.
Quite a few commercial users have started using small anonymous dfns (line fragments). Only a few are writing multi-line functions. Some people are mostly attracted to dfns because you don't need to declare locals, while others actually appreciate the lexical scope and the ability to create multi-function capsules the way you describe.
For people who mostly want dfns in order to avoid localisation, I have actually started thinking that we might want to extend tradfn notation soon to allow you to declare that all locals defined using assignment in the body of a tradfn would be local, with explicit declaration of globals. We are seeing people who use dfns MERELY to achieve this effect get into trouble when they call a dfn which calls a tradfn and that uses another dfn: at this point the combination of dynamic and lexical scopes can be tricky to deal with for someone who is only accustomed to dynamic scope.
The growth of dfns will probably continue. Without wanting to name any body parts, it is clear that we need to revisit aspects of the language and tooling in order to adapt to the growing use of dfns. I think it is difficult to imagine extending the notation to allow dfns to contain in-line tradfns, but perhaps that is just a lack of imagination on my part, we'll see.
Morten
-
Morten|Dyalog - Posts: 462
- Joined: Tue Sep 09, 2008 3:52 pm
15 posts
• Page 2 of 2 • 1, 2
Return to Functional Programming
Who is online
Users browsing this forum: No registered users and 0 guests
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group