forGL Information in GitHub

Showcase
, , , , ,
9

Summary:
I think you are really asking about what is the recommended forGL syntax ?
forGL does Not recommend a single syntax.
There is No forGL Way.
That is both an advantage and an obligation of forGL.
Advantage as it allows our forGL Users to express their ideas as they wish.
Obligation to be sure that more syntax combinations are supported correctly / logically / fairly.

Minimal change would be
replace trace with show
replace i++ with i = i + 1 (have reserved notation for ++ increment but not implemented yet)
replace ; with . (period) perhaps.
The given example just uses 1 statement per block.
forGL inference allows not having to add punctuation to end a statement if only 1.

We could keep the same 1 statement per line style as you give

while ( i < 10 ) {
    if ( i % 2 == 0 ) {
        "even" show 
    } else { 
        "odd" show 
    } 
    i + 1 into i    // OR  i + 1 =: i  OR  i from i + 1  OR  i := i + 1
}

or
perhaps all on 1 line :

while ( i < 10 ) { if ( i % 2 == 0 ) { "even" show } else { "odd" show } i + 1 into i }

Or perhaps a style that uses fewer lines than we start with but more than 1.

Because forGL does not limit how many statements per line, the formatting is really up to the User.
The 1 statement per line is more a continuation of the “punch card days” and now it is a limit more due to how Debuggers work than a real problem with most compilers or interpreters.

forGL is not intended to impose any single way of expression of Problems or Solutions but rather provide an application and environment where anyone can experiment with various ways of thinking about programming and then test their ideas. And then the really Cool part is to transpile to Haxe and then transpile to a dozen other programming languages.

So one way of thinking about the forGL environment is that it allows a way to express programming ideas that looks more like a pseudo programming language syntax than most others. But I think it is effective because it gives immediate feedback as part of the very flexible syntax.

“how would that look in an NL neutral programming language?”
Perhaps in one way I fail to give you a good answer. As of now I am not confident that we should look for a singular solution.

Perhaps the best I may say is: Use whatever style you like.
One thing I have learned after working on forGL is that code style is not very important.
Ease of Reading and Understanding are very important.

Because the forGL roadmap will be adding more programming paradigms this year, the intention is not to go to wildly different syntax but to try to follow syntax and semantic conventions related to the various paradigms. Concatenative was perhaps a poor choice to start with but the forGL Interpreter is already Stack based and I can’t think of any general purpose CPU architecture / instruction set that does Not have some kind of Stack segment & Stack related Registers.

So I thought a gentle introduction to new programmers about the Stack concept and making the Data, Operator and Noun Stacks be a visible part of forGL would help. The view of the Stacks can also be limited to just the Data stack or none at all. There is also a simple feature that waits a short period of Time between Automated steps. Which gives the appearance of a kind of Stack Animation.

Thanks Ian for the thoughtful question.

1 Like