Re: Cross-platform newlines in multiline strings

["Aaron Brown" <aaron-lua@...>]

RLake wrote:

> [...] but in principle you can put random binary strings
> into a Lua script by surrounding them with [[ ]], as long
> as they don't contain unbalanced [ and ] characters. 

Is arbitrary binary data really what long strings are for,
though?

> And it would break files created on Mac OS <=9 or in
> "classic" mode on Mac OS X, which use a bare carriage
> return as a line ending character. (Moving Mac OS 9
> scripts to another OS is pretty well broken anyway,
> though.) 

Well, the Lua interpreter is already smart enough to
understand scripts in Mac format if they don't contain long
strings.  Although maybe there isn't that much going on
there, since Lua in general doesn't care much how things are
broken up into lines.

> It's even worse with regular strings: moving this program: 
> 
>    print "foo\ 
> bar" 
> 
> from DOS to Unix produces a syntax error, since \<cr> is
> not recognised as a continuation, so an incomplete quote
> is reported when the <nl> is read. 

Interesting.

> do 
>   local meta = {} 
>   function meta:__call(str)
>     table.insert(self, str); return self
>   end 
>   function meta:__unm()
>     return table.concat(self, "\n")
>   end 
>   function L(...)
>     return setmetatable(arg, meta)
>   end 
> end 
> 
> foo = -L 
>   "line 1" 
>   "line 2" 
>   "line 3" 

This is highly cool.  It took me a bit of thinking to
understand it, and I'm still not sure I totally grok it, so
I'd like to explain it:  Starting from "foo = -L" the first
thing that happens is that L gets executed with "line 1" as
an argument.  That returns a magical table { "line 1" }
which has a __call metamethod which then gets called with
the argument "line 2" and the implicit argument self.  That
returns the same callable table after inserting "line 2"
into it.  The table stops getting called when there are no
more arguments, then the unary minus turns the table into a
string.  Is this accurate?  The fact that the callable table
returned by L gets immediately called doesn't make sense to
me.  For instance, in the following code

  f = function() return function(s) print(s) end end
  print f() "foo"

f gets turned into a function, but it doesn't immediately
get called with the argument "foo".  Instead there's a parse
error.  So obviously there's something I'm missing.

Luiz Henrique de Figueiredo wrote:

> Lua 5.1 (work0) already tries to be smart about
> end-of-lines: it handles \r\n for DOS, \n for UNIX and \r
> for Mac.
>
> But it does mean that an explicit CR in a long string will
> be converted to NL.

Excellent.  In my opinion that's the right thing to do.
Have Lua completely not care what EOL format is used (rather
than not caring except with long strings).  If the
programmer wants real carriage returns or other arbitrary
binary data, he can use backslash escapes (which admittedly
don't work in long strings) or an external file.

Let me make sure I understand you, though -- a CR and a NL
next to each other (in DOS order) would get converted into
just one NL and not two, right?

-- 
Aaron