NewsForumsCodeLogsGallerySpecsSearch

line continuation

Community Forums/Monkey2 Talk/line continuation

dmaz(Posted 2015) [#1]
so has anything been decided with this? I do remember Mark saying that it won't have monkey1's freedom.

I know someone suggested operators as line continuators and that would be cool... hopefully including commas.

But I really like having commas at the start of the line for statements that continue... so I hope we don't have to use continue characters at all when inside parens or any other kind of bracket.


Danilo(Posted 2015) [#2]
In my experience (with PureBasic) line continuation is especially useful with + - | and comma ','. Other operators can be used, too.
Additionally, long 'If' lines can be splitted at keywords like 'And', 'Or', 'Xor'. It's very nice, useful, clean, and read-able.
Macro DoSomething()
EndMacro

If abc = 1 And def = 2 And
   ghi = 3 And jkl = 4
    DoSomething()
EndIf

title$ = "my "   +
         "long " +
         "Window Title"

CreateWindowEx_(dwExStyle,
                className$,
                title$,
                dwStyle,
                x,
                y,
                width,
                height,
                parentWindow,
                hMenu,
                hInstance,
                lpParam)

OpenWindow(0,0,0,800,600,title$, #PB_Window_SystemMenu     |
                                 #PB_Window_ScreenCentered |
                                 #PB_Window_MinimizeGadget |
                                 #PB_Window_MaximizeGadget )

Repeat : Until WaitWindowEvent() = #PB_Event_CloseWindow




Samah(Posted 2015) [#3]
Monkey already supports operators as line continuation, including periods.


PixelPaladin(Posted 2015) [#4]
That is right, something like this is possible:
Foo(
    arg_1,
    arg_2,
     ...
    arg_n )

... but not this:
Foo(
    arg_1,
    arg_2,
     ...
    arg_n
   )

I think this should also be possible. It would look better when passing arrays and function calls as arguments:
Foo( bar,
     [ hello,
       world( 1 ) ] )

vs.

Foo(
     bar,
     [
       hello,
       world( 1 )   ' <-- Monkey1 would complain here
     ]
   )

The second one should be easier to read.
The compiler should at least look for a closing parenthesis in the next line instead of throwing a syntax error.


dmaz(Posted 2015) [#5]
actually, what I'm really looking for is comma first style. once you start using it, it's hard to go back. ie:
Function Mat4Ortho:Float[]( left:Float
                            ,right:Float
                            ,bottom:Float
                            ,top:Float
                            ,znear:Float
                            ,zfar:Float
                           )
but in any case if I remember right, Mark did say that Monkey2 will not have the same freedom that monkey1 did.


Danilo(Posted 2015) [#6]
Problem is, if you make it too loose, the compiler can't detect errors anymore.
Languages that simply ignore all newlines, usually have a end-of-statement marker, like ';' in the family of C-languages.


Samah(Posted 2015) [#7]
Depending on how loose you make the parser, you could do cool stuff like this:

(Compiles with BlitzMax)


Danilo(Posted 2015) [#8]
:D

I think it could work if you select the allowed line continuation operators and separators very carefully.
Case CRLF, CR, LF
    lineNum++
    If lastToken was ',' | '.' | '+' | '-' | '*' | '/' | '~' | '&' | '|' | '(' | '[' | '{' | 'And' | 'Or' | '='
        return GetNextToken()
    ElseIf lookAhead(1) is in ( ',' | '.' | '+' | '-' | '*' | '/' | '~' | '&' | '|' | ')' | ']' | '}' | 'And' | 'Or' | '=' )
        return GetNextToken()
    EndIf
    return new Token(lineNum-1, tkEndOfStatement)

With multiple meanings of '>' and '<' it needs to be tested if this can fit as well.


Samah(Posted 2015) [#9]
Even better,
Case ';'
    ' end of statement


Edit:
To be honest, if your syntax is designed in such a way that newlines and indentation are completely optional, there's zero ambiguity in your code.

In Lua, these are equivalent:
if blah then a = 2 b = 3 for k,v in pairs(tbl) do print(a, b) end end

if blah then
  a = 2
  b = 3
  for k,v in pairs (tbl) do
    print(a, b)
  end
end

Obviously the first example is ugly as hell, but to the compiler, they're the same. I see no reason why Monkey 2 couldn't do this.
You could still do single-line if statements as long as you put "End" as the last token.


Danilo(Posted 2015) [#10]
While taking a shower, I was thinking if ';' should be added to the line-continuation as well. :)
Could be confusing for programmers coming from C-languages, though. And the BASIC-guys don't
want an explicite end-of-statement character like ';'. They probably want end-of-line, with some
exceptions as shown above.
A simple <Space> as statement separator like BMX is too loose, IMHO.


Samah(Posted 2015) [#11]
@Danilo: A simple <Space> as statement separator like BMX is too loose, IMHO.

It's only too loose if there are special cases like single-line if statements. If newline has no effect on program execution, there's no problem.

Edit:
If newlines were completely ignored, these should be equivalent:
Class Foo Extends Bar Abstract Field hello:String = "world" Method Blah() Print("hi") End End

Class Foo Extends Bar Abstract
	Field hello:String = "world"
	Method Blah()
		Print("hi") 
	End
End



therevills(Posted 2015) [#12]
+1 to "newline has no effect on program execution"


dmaz(Posted 2015) [#13]
ok sure, but I was mainly just hoping they wouldn't be needed inside of any kind of "enclosing" characters like parentheses or quotes.. :)


Nobuyuki(Posted 2015) [#14]
I rather enjoy the way Monkey does it now. MX2 being a bit more strict is fine, as long as I can still separate lines on operators and concat lines using a semicolon.


Samah(Posted 2015) [#15]
@Nobuyuki: ...as long as I can still separate lines on operators and concat lines using a semicolon.

My point is that you shouldn't need to worry about newlines or semicolons at all.