#102 Limited multi-line support.

[samurai437]

It would be nice if FreeBASIC would allow things like function parameters or variable initializer data (things with opening and closing tags) to extend over multiple lines without the need for "_"'s.

[Matthew]

Logged In: YES
user_id=723706
Originator: NO

I agree with this, it could make some code look a lot nicer.
Perhaps if it let lines continue whenever there are open brackets. I don't know how hard that would be to sort out though.
Accidental brace mismatches may cause problems, but they would probably be caught, as there would have to be another brace mismatch the other way for the code to fully compile, and I would think the compiler would likely trip up when trying to include subsequent lines in the brackets.

[Abdullah A. Hassan]

Logged In: YES
user_id=1123818
Originator: NO

That's be a nice feature if implemented..

[Yeti Foot]

Logged In: YES
user_id=1223492
Originator: NO

I think I managed to find a way for variable initializers, around

parser-decl-symb-init.bas approx line 136, I changed it to:

'' '{'?
isarray = FALSE
if( lexGetToken( ) = CHAR_LBRACE ) then
    lexSkipToken( )

            'yeti
            hMatch( FB_TK_EOL )

    ctx.dimcnt += 1

then at around line 222, I changed it to this:

    elm_cnt += 1
    if( elm_cnt >= elements ) then
        exit do
    end if

            'yeti
            hMatch( FB_TK_EOL )
        '' ','
            If hMatch( CHAR_COMMA ) = 0 Then Exit Do
            hMatch( FB_TK_EOL )
loop

'' pad
elements -= elm_cnt

That seems to work OK, I had a go with function parameters, and nearly had it working, but it seemed to cause some side-effects, that I haven't been able to solve.

[Albeva]

Logged In: YES
user_id=1175427
Originator: NO

how about defining a "multiline" block? smth like this:

function foo
...,
...,
...

? This would make things clear when is multiline and when not. It doesn't have to be [].

[dkl]

Note: In #2015590 a "block ... end block" compound was suggested for this purpose.

The only way to do this would be to add something like / ... / or similar, something that can be handled in the lexer and that doesn't depend on EOLs itself.

But still I don't like the idea. _ is just what's used to "escape" EOLs. EOL just is a statement separator in FB. I like seeing the 's where they're necessary to wrap long lines. There is little difference between using 's or a compound version of it, because if you have lots of long lines then the line continuation will be scattered all over the place no matter what.

[Otter]

yeah-yeah i also affirm it about "sometimes not even demand for _"

But then, compound is very heavy. Better to do, if the line ends, and there MUST be an expression on its end, don't put an error, but TRY to read this expression from the next line. Treat A = B as an expression, not assignment.
Just start to look for expression on the next line, if an error no-expression would otherwise occur.

[dkl]

Perhaps we could resurrect the idea of accepting EOLs in various places in the parsers, e.g. initializers (as suggested by yetifoot above) and parameter lists?

Only in between the parentheses tokens, comma tokens and expressions (not in the middle of individual expressions). That way there shouldn't be ambiguity at all, and (I think) no problems with token look-ahead either. Afterall, I don't think fbc uses look-ahead when parsing the commas/parentheses, so it'd be easy to "silently" allow EOLs there.

I think that this could be quite useful (perhaps even make the underscore line continuation almost completely unnecessary).