Re: Flush the term upvalue from 5.1 manual

[ramsdell@... (John D. Ramsdell)]

John Belmonte wrote:

> Roberto, in his talks, freely admits that "upvalue" is not the best
> term.  

So let's give him a term that needs no apologies.

> However, do we want to replace every instance of "upvalue" in the C
> API with "inherited_binding_reference"?

Actually, I wasn't suggesting the C API be changed, I was just
suggesting changing the words in Section 2.4.  In any event, if the C
API were to be changed, I would replace every instance of "upvalue"
with "ibr".  The abbreviation "ibr" does not misdirect people into
thinking it has something to do with a Lua value.

> Please let's not have another naming and meaning debate on this as
> in 2001.

A new manual is coming out, so it's time to get out the warts.  Here
is another issue I came upon.  I was trying to automatically generate
Lua programs that contain string literals made up of binary data.  In
C, the language references make it clear that if I generate a string
that meets the following regular expression, \"([^"\\\n]|\\[n\\"])*\",
I will generate something that will be correctly compiled by a C
compiler.  In other words, all I have to do is quote just three
characters, double quote, backslash, and newline.

Section 2.1 of the manual in version 5.1 beta does not explicitly
say what cannot be in a string.  For example, for a string that starts
with a double quote, the section does not explicitly say that a string
cannot contain an unquoted newline character.  Furthermore, I cannot
tell from the description if I must quote open bracket in a string
started with double quotes, or if C syntax also works for Lua
programs.  Please clarify the description of string literals in the
manual.  (I actually know to generate the strings, my point is that
the manual does not clearly specify how to do it.)

John