Re: io:lines() and \0

[Tim Hill <drtimhill@...>]

On Feb 21, 2014, at 11:49 PM, Dirk Laurie <dirk.laurie@gmail.com> wrote:

> 
> Oh yes, my father had all those books. I read them all when still at school.
> That one helped me to decide to go into academia rather than business.
> I like forthright, even offensive, people as long as they can recognize
> when an argument has run its course and if necessary agree to differ —
> so that we can move on to the next no-holds-barred argument. Such
> people are generally found in tertiary education.
> 

But this isn’t an academic exercise; this is someone trying to use Lua in a real-world application and seeking help to either fix or work-around what they see as a problem with the Lua libraries. It’s simply not an option to “agree to disagree” and then move on to the next cosy fireside chat; a real-world application has to be made to work.

So what is the real outcome of this thread?

— io:lines() can only work reliably on well-formed text files.
— io:lines() gives no indication when it encounters a malformed text file.

In practical terms, this means that if you do not have control over the input dataset (almost always the case) and you wish to have a robust, well-behaved application (which, i hope, is common), io:lines() cannot be used and you must supply your own text file handling logic.

Being slightly facetious for a moment, perhaps the Lua library docs should say “if you need robust text file handling do not use the Lua text file API”. I’m not sure I see this as a particularly good advertisement for Lua as an application platform.

And this really isn’t academic: Some of the places we use Lua are truly mission-critical — if something fails people really can die. Before using Lua we rigorously evaluated it, and after throwing everything nasty we could at it we concluded that (a) the language, compiler and VM were extremely solid and (b) significant parts of the libraries were weak. Our solution was to replace those weak parts with more robust in-house code, a significant exercise made worth-while by the “golden nugget” of the solid language and VM (compactness was also a factor). But it’s unfortunate that we had to do this, and perhaps others have evaluated Lua and looked elsewhere after finding the libraries wanting. This would be a shame, as I still regard Lua as one of the most elegant and productive languages I’ve seen in [redacted!] years of programming.

—Tim