Re: Free format strings?

[Björn De Meyer <bjorn.demeyer@...>]

Peter Hill wrote:
> 
> Peter Hill wrote:
> > However there doesn't seem to be a way to wrap long strings *without*
> > inserting a newline. Tradionally, "\" by itself has been used as a
> > free-format wrap character for strings. So:
> >     "abc\
> >     def"
> > was the same as
> >     "abcdef"
> >
> > Does Lua have such a feature? If not it should.
> 
> Björn De Meyer:
> > The way you do it in Lua is simply to say
> >
> >    "abc"
> > .. "def"
> >
> 
> That's certainly clear looking (and standard). Thanks. It might do to add an
> example like that to the manual, though, for the benefit of unobservant
> people like myself :-).
> 
> I actually have to type it as:
>     a = "abc"..
>     "def"
> rather than
>     a = "abc"
>     .."def"
> as that gives the error
>     stdin:1: unexpected symbol near `..'
> 
> Yet another case of the (apparent) general free-format / line-break
> principle... that if a syntactic sequence seems finished, and a line-break
> is encountered, then it is deemed to *be* finished. Is that principle stated
> in general terms in the manual somewhere? I've only encountered the one
> specific example in the function call section but it seems to be a general,
> simple & sensible rule.

/snip

I'm sorry, but what's going on here is more of a 
quirk of the Lua interpreter than a problem in the language. 
When you use the lua interpreter as an interactive tool, 
every line is compiled separately as a chunk, unless the interpreter
detects that the line is not finished (such as in function definitions,
loops, etc)

In essence this causes a difference between the behaviour of the lua 
interpreter when run interactively and when run on a file. 
Just take this example: 

local try = "Hello"
print(try)

If you run this example interactively, it will print 'nil',
because the local variable try is defined in another chunk,
and goes out of scope the moment the print() function is called.
If you store this example in a file, however, and then run it,
then it will print 'Hello' as expevcted, because now, the whole 
file is one chunk. 

Perhaps this problem indicates that some solution is needed 
to make the interactive lua interpreter work more accurately.
However, I fear that this will be difficult. In Lua, 
when it is not run interactively, the only newline/freeform 
conflict that exists is the one documentend, namely 
for function calls. 

Oh, and by the way, these limitations of freeform, and of the 
return statement exist in Lua exist because of difficult problems 
with the parser and the parsing of ambiguous statements. If you 
or someone else could solve these problems without altering the 
language, then that would be nice...



-- 
"No one knows true heroes, for they speak not of their greatness." -- 
Daniel Remar.
Björn De Meyer 
bjorn.demeyer@pandora.be