Continuation lines

[Davin Church]

I think the idea of having a continuation line is a good one, but I'd like to question your choice of symbols. The "&" is already used in other ways in Dyalog (and also in Linux commands) and might be easily confused. It would also prevent APL64 from adopting any of these other conventions in the future, should it want to.

I recommend using a different symbol for continuation lines.

[Eric.Lescasse]

What about _ as the line continuation symbol (more exactly: space followed by _ )

[Davin Church]

Not bad, but don't some APL's allow "_" as a leading character on variable names?

[Ajay Askoolum]

As the editor is being revamped, it ought to have a facility to switch word wrap on or off.

As functions have line numbers, with word wrap being on, it would be possible to see/write/edit whole lines without horizontal scrolling. And, it would be self-managing.

Continuation lines managed by a reserved symbol is an unnecessary overhead when dealing with code or data.

If you must have hard continuation lines, CTRL + Enter which will force a line break and can be easily deleted with one key stroke might be the one to use- might even be more straightforward for the interpreter to ignore at runtime than composite characters.

[Davin Church]

Ya know, I rather like both those ideas.

[Eric.Lescasse]

The thing I like most concerning C# continuation lines is that I can break the line wherever I want to, in order to align things nicely in my code and make it much more readable.
This happens all the time in C# and I have been using this feature extensively over the years.
I would really like to be able to do the same with my APL64 code.

So, personally, I am not in favor of automatic Word Wrap, which would not allow me to cut my lines where I want to.

[Ajay Askoolum]

1. C# does not use any continuation symbol(s) to indicate that the line continues on the following line(s). (VB.NET does).
2. If you've switched on line numbers, the continuation lines have a different line number.

APL code/statements are line based with the facility to jump to arbitrary location by line number. If you want to break your statements anywhere you like, the fragments cannot have their own line numbers; CTRL + Enter is a non-visible character that can break the statements. The interpreter will need to learn to ignore the breaks but the editor will have to remember to abide by them.

Personally, I find statements over several lines a distraction - Excel recorded macros use line breaks by default, not so much in the interest of readability but as a means of wrapping the statements to fit the available window - and would be happy to switch word wrap on or off to see a whole line.This would be a simple editor feature - no implications for the interpreter, the editor, []cr, []vr. []def, []fx etc. etc.

With C#, you'd add continuation lines anywhere where a space is acceptable i.e you would not break a keyword. With APL, you cannot break within ∘.+ but you can break after the plus in a+B - the editor needs to be quite smart when you press Ctrl + E, the interpreter has to be smarter still to be able to fugure out these nuances.

[Davin Church]

So, personally, I am not in favor of automatic Word Wrap, which would not allow me to cut my lines where I want to.

I don't think we're talking about word wrapping actually changing the lines - just changing the way it's displayed on-screen so I can see a long line (that doesn't have hard line breaks in it) on my screen without scrolling.

[Davin Church]

APL code/statements are line based with the facility to jump to arbitrary location by line number. If you want to break your statements anywhere you like, the fragments cannot have their own line numbers; CTRL + Enter is a non-visible character that can break the statements.

I think this is a very good point! In their example of continuation lines, they've given the extra lines actual line numbers. What would happen if I tried to branch to one of those lines (after the first)? I think it'd be a lot better to not number the continuation lines at all and actually treat them as a single line except for visibility purposes.

If you think about diamonding code into a single line of code, the diamonded lines don't get their own line numbers either, so couldn't that be used as a precendent for continuation lines?

[]VR and []CR would have to have special ways of returning continuation lines, such as imbedding []TCNL (or perhaps []TCLF) somewhere in the text, such as the point at which you pressed Ctrl-Enter. Formatted indentation should be preserved as well, if the lines weren't actually returned as single long lines (in []CR).

[Davin Church]

If Ctrl-Enter is not preferred as a continuation symbol (perhaps because of its invisibility), then how about picking a new Unicode symbol to have that functionality, such as one of these:

Code: Select all

⍚   (diamond underbar)
⌺   (quad-diamond)
⍭   (stile-tilde)
…   (ellipsis; single character)
►   (black-right-pointer)
◈   (diamond-diamond)
❖   (diamond-X) (potentially has other non-APL uses)
↵   (corner-arrow) (perhaps shown on screen if Ctrl-Enter is used?)
↩   (hook-arrow) (perhaps shown on screen if Ctrl-Enter is used?)
⏎   (return symbol) (perhaps shown on screen if Ctrl-Enter is used?)
⎆   (enter symbol)
﹏   (wavy low line)
⤑   (dotted arrow)
⇒   (double-arrow)

[Ajay Askoolum]

I simply do not like the idea of a physical symbol to designate that the statement continues on the next line.

1. My reason is that such a symbol is NOT included by any kind of automated code generation-like Excel macro recording. Therefore, its use is going to be highly subjective and will vary from user to user in any team. Anyone using the continuation symbol for compactness will use it differently from someone using it for readability or simply using it at will.

Code: Select all

      a←1&
        3⍴ &
        1, &
        2, &
        3
      ⍝ Will the result have 3 or 13 elements?
      ⍝ On balance, what was the developer's intention, bearing in mind that 1+2  and 1+ 2 and 1 + 2  and 1 +2 are valid (synonymous) expressions?


2. I have used continuation symbols in Visual Basic, seen it in Excel VBA, and is available in Visual Basic.NET: from my point of view, it simply adds clutter and represents yet another source of syntax error. These environments have continuation symbols because they do not have line terminators.

But, if you must have a continuation symbol, my first preference will be to have a facility for word wrap in the editor. [][CR, []VR already word wrap in the interactive window. Incidentally, when you use either of these to list a function, copy and paste the output into a Word document and then find that you need to remove the line breaks, it becomes an absolute pain.

If you must have a continuation symbol, I think it must be a symbol that does not add clutter: I have suggested Ctrl+Enter (which will also pose the same dilemma as I have illustrated in the code block above).

C# treats all lines as continuation lines unless the line has a terminating semi-colon. After all these years, having a line terminator as mandatory for APL code will be heresy.

C# does not have continuation lines: it has line terminators. Its debugging facilities (F10, F11) treat lines as consecutive characters <after> one semi-colon up to and including the next semi-colon ... (but it is not as simple as just this, since double braces and <using> statements have other rules).

PS:
1. What would be the rules for comments with multi-line statements?
2. Would a space (or any other series of characters) after the continuation symbol generate a syntax error?