Re: Proposal: package.(c)path as tables

[Russell Haley <russ.haley@...>]

On Thu, Sep 7, 2017 at 9:10 AM, Roberto Ierusalimschy
<roberto@inf.puc-rio.br> wrote:
>> 2017-09-07 10:29 GMT+02:00 Martin <eden_martin_fuhrspam@gmx.de>:
>> > I see two arguments in this thread versus proposal:
>> >
>> > * "operating systems do it that way"
>> > * string parsing is easy
>>
>> You miss a most compelling third: it is a breaking change. It will
>> affect all programs that currently modify/change package.path.
>
> Another argument is that it is simpler, both to explain and to
> implement. The concept and the handling (and the documentation) of
> string pathes are unavoidable, because that is how they exist outside
> Lua (e.g., in environment variables).  With the change, we get two
> concepts (and two representations to be manipulated and documented) for
> the same thing.
>
> -- Roberto

I would think that changes to the language should be more than "I
don't like having to implement this myself". I haven't heard a single
compelling use case for why the language needs this, especially given
the simplicity of doing it ourselves. To use an example that I have
argued for as a foil (and an unabashed plug): Loading the main script
from the command line should examine if the script is specified with a
path. If so, that path is added to the front of the search string.
This is compelling for at least two reasons:

1) It simplifies the language because now it's not a "Windows" feature
but a general Lua feature (simplifies code, simplifies cross
platform). I disagree it somehow breaks Unix/Unix like systems (an
argument for a different time) as it would never be noticed by those
that don't use the feature (i.e. don't call with a path).
2) I can provide a definitive use case for it's advantage and "proof"
that having to implement the feature myself breaks things. This path
feature is very useful if you have a library installed on the
computer, but wish to use a different copy with a different set of
libraries (i.e. from a USB thumb drive). This would have been
advantageous when I was messing with a source copy of LuaRocks and
didn't want to break my installed copy. It would also be useful in IT
environments where an admin has a portable set of scripts that can be
run to diagnose a computer or a misbehaving Lua application.
Implementing this myself breaks things because I would have to change
my environment variables (thereby breaking my local installation or
accidentally leaving behind debug settings). The other alternative is
to code the application for paths and handle exceptions internally
which is messy and error prone.

> Another argument is that it is simpler, both to explain and to
> implement. [the string based solution]

And the alternative to the proposal is less than ten lines of pretty
basic code (even for someone that hates parsing). I'm not opposed, but
what is the use case?

Russ