[Gambas-user] variable declaration everywhere ???

[Tobias Boege]

On Fri, 14 Dec 2018, Christof Thalhofer wrote:
> Hi Rolf,
> 
> Am 14.12.18 um 11:49 schrieb Rolf-Werner Eilert:
> 
> >> Basic seems to be an easy language for beginners, but – as always –
> >> allows a lot of very ugly code constructions.
> > 
> > That's true - but it's in the programmer's hands.
> 
> Not really – if the programmer is a beginner.
> 

So maybe it's time to introduce compiler pragmas to Gambas, to be
able to switch between the default "beginner mode" and "expert mode"
(caution: voids warranty) where you can declare variables anywhere,
even inside method invocations, and where we can finally have self-
modifying code.

Just kidding.

What I actually want to do is ping back to Bug #1361 which proposes
what is being discussed here but didn't get any discussion itself.
[ Maybe I should have RFC'd it to the mailing list, but this one time
I thought it would be more appropriate to submit it as a real feature
request to the real bugtracker. ]

I don't know if Benoît is working on that bug specifically (it was
Accepted) or was inspired otherwise to implement that now. In case
I'm the one indirectly responsible for the discussion (the exact
performance of which seems to be a staple among programmers), let me
say this: I for one prefer a language which gives me "enough rope to
hang myself", but I totally support the best practices advice given
in this thread. It's just that sometimes when you work on something
inherently ugly in Gambas, like parsing text efficiently, you genuinely
want to hang yourself. And it gets worse if the language doesn't let you.

If your function is longer and complex, some variables tend to live
shortly, are more temporary, than others. The original drive behind
Bug #1361 was to be able to declare those variables closer to where
they become relevant, instead of making new functions for the tasks
these temporaries belong to, and then having to pass all the state
shared by these functions as ByRef's (yuck!).

[ Yes, I will admit that parsing can often be done in a cleaner way
which the JSON module demonstrates: if you turn the parser into a
separate module, you get to keep the parser state in class-global
variables and the parser rules can be relatively small self-contained
functions, each driving the global read head further. But even that
module has its fair share of GoSub, for example. ]

If you ask me now, I like the compromise that David Sanromá and
Benoît earlier today somewhat suggested:

  1. Loop variables can be declared directly in the loop opening syntax.
     And they have a function scope.

This is a nicely controlled and useful special case of "let's declare
variables anywhere". About the function scope: is that just because
real nested lexical scopes aren't implemented yet and are not coming?
And I guess you occasionally need to refer to a loop variable right
after the loop to see how far you got, so you'd get that with the
function scope. The pollution of the outer scope is nicely caught by

  2. Loop variables can be redeclared as soon as it keeps its type.

so I have actually nothing against the function scope. I just felt that
the decision wasn't justified loudly enough. I don't think you can make
much spaghetti out of these two rules.

In addition, concerning Bug #1361:

  3. Declaration of local variables can happen at the beginning of
     every lexical scope.

This means that you can't declare variables just anywhere, but only
at the beginning of blocks which should usually have a distinct
indentation. Example:

  ' Not OK
  Dim i As Integer
  Print i
  Dim j As Integer = i ^ 2
  Print j

  ' OK
  Dim i As Integer
  For j As Integer = 0 To Rand()
    Dim k As Integer = i ^ 2 + j
    Print k
  Next

If you have any shame, this might increase the amount you feel of it
even more when you do that because "hey, this loop body looks just like
a new function of its own!". In my opinion, this forces the code to
still look Gambas-y organized while serving the need of declaring
variables in multiple places.

But to be honest, I won't be sad if this controversial feature is cancelled.
Whatever made me write something as demanding as "I want the ability to
Dim local variables anywhere in a function" in that bug, I don't remember
it anymore. There are plenty other languages to make a merry mess with.
À propos, I think the If and Select Case statements feel left out by all
the discussion of *loop* variables. Now, how often did you want to do

  If (Dim i As Integer = InStr(sStr, sNeedle)) <> 0 Then
    Mid$(sStr, i, 1)...
  Endif

I do that all the time in other languages, which support it, and my
neck is alright still :-)

Regards,
Tobi

PS(A): I missed a good deal of this thread because google decided it
was spam, along with some other mails I've been receiving, and liking
to receive, for years. If you use gmail, maybe check in and look at
what you are missing.

-- 
"There's an old saying: Don't change anything... ever!" -- Mr. Monk