In a recent Dyalog email it was noted that:
"We have been asked by several customers to allow comments to appear after the closing "}" in a dfn. Allowing this is a not insignificant piece of work, and has been added to the wish list for a future release of Dyalog APL."
I imagine this is signficant work because the closing brace ends the function, and thus by definition comments after the last brace are outside of the function and cannot simultaneously be inside the function. It would seem that should end the discussion right there. But if you are going to allow them after the last brace, why not before the first brace?
I hope this turns out to be one of the cases where the team says "well, if we do A, we should also do B, but we obviously can't do B, so lets not do A".
Really, this strikes me as a very bad idea, and a source of new problems.
What is the reason that simply adding comment lines within the body of the function, at the end, but before the last brace, won't do?
Comments in Dfns
Re: Comments in Dfns
paulmansour wrote:In a recent Dyalog email it was noted that:
[...]
What is the reason that simply adding comment lines within the body of the function, at the end, but before the last brace, won't do?
Indeed. Maybe it's a misunderstanding: I reported this problem, but I am happy when APL won't crash. It hit me because I accidentally inserted a block of comments after the closing curly. Only when the stuff disappeared after having pressed the "Format" key I pressed the "Undo" key to get it back in order to move the block elsewhere when things ended up in an aplcore. Thats certainly not acceptable.
It could refuse to format/fix the function because the code is invalid. That would be enough.
Kai
Re: Comments in Dfns
Code: Select all
At present, when you exit the editor, anything after the closing brace is discarded:
┌dup─────────────────────┐
│dup←{ │
│ ⍵ ⍵ │
│} all of this will │
│be quietly lost when the│
│edit window closes │
└────────────────────────┘
Are we happy with this behaviour?
Or should we say "can't fix" and refuse to close the edit window?
Re: Comments in Dfns
"Can't Fix" would indeed be entirely appropriate.
At present I can't fix a dfn if the closing brace is missing. What is required is to prevent the fix if the closing brace is not the last non white-space.
At present I can't fix a dfn if the closing brace is missing. What is required is to prevent the fix if the closing brace is not the last non white-space.
Re: Comments in Dfns
Fully agreed. Silently loosing code doesn't seem right.
-
- Posts: 431
- Joined: Fri Oct 03, 2008 4:14 pm
Re: Comments in Dfns
I agreem, seems like a good idea to me.
Re: Comments in Dfns
Now logged as official issue:
[6055] "⎕FX/editor should refuse to fix a D-fn if anything other than white space follows the closing brace."
Thanks for taking the time to get this right.
J.
[6055] "⎕FX/editor should refuse to fix a D-fn if anything other than white space follows the closing brace."
Thanks for taking the time to get this right.
J.