Queries

["Peter Hill" <corwin@...>]

- QUERIES -

(1) CRLF / CR / LF
I can't find any documentation of how Lua handles the CR / LF / CRLF issue
of various platforms.

For example, the definition of "[[" says it ignores a following new line.
But is that a CR, LF, CRLF? Or does it depend on the platform's definition
of "newline".

Is CR or LF treated as pure whitespace? Or discarded completely?


(2) LUAC SCRIPTING
When "luac" produces a bytecode file, does the first line still keep its
"#!" shell script line?


(3) BOOLEAN

What was the catalyst for the new "true" and "false" values?

In strongly typed languages I consider boolean types to be an essential
requirement (they're missing from C which was bad).

In a language like Lisp or Lua, where "or" and "and" work on general values
rather than booleans, they seem out of place.

Perhaps it comes from wondering what one gets from "not nil". I'd personally
say it returns the constant "notnil" (rather than "true").

Or maybe it comes from the desire to use the results of a boolean comparison
as an index, eg:
    t = {[false]="Bad", [true]="Good"}
    print(t[a~=b])
which would not work without booleans since "nil" is an invalid index.

But then one could always have something like:
    t = {false="Bad", true="Good"}
    print(t[a~=b and "false" or "true"])

I think (for Lua) I prefer not having booleans as a core type. I would also
like to add the immediate-if function of C (or some equivalent):
    a ? b : c
which is equivalent to
    (function() if a then return b else return c end)()
It is clearer than "a and b or c" and works 'correctly' when "b" is "nil".

Note that "b" and "c" should be able to return multiple values... they
should NOT be truncated down to a single return value.


(4) EFFICIENCY & IMPLEMENTATION of UPVALUES-vs-LEXICAL SCOPE

I haven't seen anything about the implementation of the old upvalues (for
Lua functions, not C ones) and the new lexical scope.

(a) Implementation

- Upvalues -
With the old upvalues I always assumed that the upvalue "constants" would be
bound into the function's byte code by replacing references with actual
constant bytecodes. Ie, it would be the same as if the constants were there
from the start.

Of course that may not have been the way it was done. Instead, the compiler
might have simply created a runtime wrapper function, which is somewhat less
efficient for repeated calls. :-(

- Local Variables -
I always presumed that these live on the stack, and are thus very efficient.

- New Lexical Scope Locals -
Since these go on existing whether or not a block is running I presume they
can't be stack based but instead either live on a general static-variable
heap, or perhaps are attached & stored as a part of various closure blocks.
Presumably these static variables remain until they are garbage collected.

Is that how it is?

Can normal stack-based local variables exist in this environment?
Presumably, depending on the compiler's ability to detect enduring usage.
But that seems a bit of an ask for the poor thing... and the clarity to the
user is not high.

What was thought of the option of using a different explicit definition for
such persisting variables? Eg:
    do
      local x
      static y
      f = function()
        -- y is visible, and enduring.
        -- x is not visible
      end
    end


(b) Standard Functions

In the old days of upvalues one could use them when calling a standard
function, eg:
    function f(a)
      %print("A="..a)
    end

This gained in two ways:
(i) "print" was compiled as a constant rather than a global lookup, which is
much more efficient for repeated use.
(ii) "print"'s current value was set in stone, so that subsequent tinkering
& redefining of the "print" global symbol did not cause "f" to change its
behaviour.

On the other hand it was also ugly, so I don't know how many programmers
used it! :-(


If one doesn't have upvalues then it makes sense to redefine functions as
locals to the main chunk, gaining some efficiency of access (I presume) as
well as some protection against redefintion (assuming that later code uses
"local print = f" to override rather than "print = f").


*cheers*
Peter Hill.