variable xref

[Mark Waddingham]

On 2018-03-28 15:45, Mike Kerner via use-livecode wrote:
> Heck no.  I spend way too much time in environments that were written 
> to
> make the complier-writer's job easier and have 50-100 lines of headers.
> It's annoying to the extreme.

Heh - I'm not sure that the necessity to predeclare things in many 
languages can just be put down to 'making the compiler writer's job 
easier' - even if you go back 'just' 15 years, computers were nowhere 
near as powerful as they are today and most of the languages which exist 
today have a history which goes back waaaay further.

If things are not pre-declared then you need at *least* two passes to 
compile a program. Each pass requires a linear traversal of the input to 
the pass. If you require the programmer to pre-declare then you can 
compile in a single pass in many cases (a technique called 
syntax-directed translation). If you don't pre-declare then the first 
phase has to parse all the syntax into structures without knowing how 
they fit together, and then you have to iterate over those structures 
defining the 'names' in appropriate scopes and *then* you have to 
iterate over those structures again to link up the uses of the names to 
the definitions.

(You can merge the declaration and parsing phases - but not the 
declaration, parsing and definition phases - hence why you have a 
minimum of two passes in a language which does not require 
pre-declaration).

Of course, in a dynamic environment like LiveCode where code is split up 
and insulated into multiple distinct much smaller texts, and you can 
defer action until use, pre-declaration is not really required (and 
indeed it is not) - you can amortize the cost of the notional passes 
over the time the program is running rather than having to do it all 
ahead of time.

> Nothing makes code less readable than re-using i, j, k, l, and m 
> because
> you don't feel like using a readable loop counter because you'll have 
> to
> fix the declaration.

I must confess I still use i, j, k etc. type variable naming - but only 
when I want the index and element in numeric arrays or if I'm writing 
code which is doing maths where the equations use such index notation:

   repeat with i = 1 to the number of elements in tVar
     -- now I can mutate the elements of tVar as it loops
   end repeat

I'm not sure why I've got into that habit though - its not really a good 
one! Although I don't think it does much harm if the loops are only two 
or three lines long.

Of course, if you happen to have an non-optimizing lower-level compiler, 
then re-using variables can make a huge difference to code performance 
as you can be more sure a register will be used (assuming the data type 
is appropriate) - that being said 32-bit intel architectures have never 
really had that issue as they have virtually no registers anyway! 
(Fortunately something which the 64-bit variant has fixed!).

> I want the best of both worlds, and mostly I want the machine to do the
> work, not me.  I'm busy.

Indeed, the work has to be done at some point, by somebody/thing - the 
balance is whether you want to pay the cost:
   1) waiting for things to compile (a full recompile of the engine on 
Mac OS X used to take 15-20mins when I first got it; although the record 
was apparantly 8 hrs on the AIX box MetaCard used to have - and C/C++ 
*requires* predeclaration for most things).
   2) over the lifetime of the execution of the program (or at the start 
if you use a lot of code at startup)
   3) by the programmer whilst writing the code

That all being said, variable analysis could be done better in all 
languages I think - although it isn't the easiest of problems or things 
to get right. Python I think might be *slightly* better than LiveCode's 
(its somewhere between explicitVars = true and explicitVars = false - 
and doesn't require declaration). On the other hand, Python doesn't have 
a mode where you can have bare literals (which require significant 
context analysis to work out whether they are variables are not unless 
you do all the work whilst executing the code - which is essentially 
what LiveCode does when explicitVars are false - so you pay for that 
with a performance cost and not knowing whether you've made an error 
before you run).

I think it would be generally true to say that most programming 
languages are designed to keep any context-sensitive information 
required compile/execute them to the bare minimum - and any which is 
required can be collected in very fast and efficient ways. For humans 
this is very unintuitive though - if nothing else, humans are generally 
quite good at very quickly guessing at the correct context of things 
when there is a paucity of information - computers may have caught up a 
bit speed wise to allow greater contextual awareness (just because they 
are faster with more storage/memory) but programming languages perhaps 
have not...

My general feeling that there is a better balance lurking - somewhere 
between Python and LiveCode's non-explicit-variables mode:

   1) Python does not require pre-declaration of variables, and is pretty 
good at determining when you mis-spelt a variable - however all literals 
must be quoted.

   2) LiveCode does not require pre-declaration (in expliciVars = false 
mode), and allows you to unquote literals as long as they are not also 
variables in the same context - but it cannot tell you if you've 
mis-spelt a variable.

The problem here is finding that balance.

Warmest Regards,

Mark.

P.S. We are also, of course, blessed with the fact these days that you 
can have readable variable names at all - I think the VMS C compiler 
still had an 8 char limit on identifiers until some hideously recent 
time.

P.P.S. Even with the machines we do have today, I'm not sure what not 
having to predeclare things in C would do the speed of compilation of C 
- so in some cases we just have to live with the slight inconvenience :)

-- 
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps