Proposal: package.(c)path as tables

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

steve donovan
On Thu, Sep 7, 2017 at 1:16 PM, Oliver Kroth <[hidden email]> wrote:
> And going further; it is possible to implement this in pure Lua using
> metatables...

Exactly, which is why I think the original proposal does not describe
a needed language feature.

Reply | Threaded
Open this post in threaded view
|

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

Roberto Ierusalimschy
In reply to this post by Dirk Laurie-2
> 2017-09-07 10:29 GMT+02:00 Martin <[hidden email]>:
> > 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

Reply | Threaded
Open this post in threaded view
|

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

szbnwer@gmail.com
hi there all :)

personally i like this proposal, and mostly what i wanted to say about
it has been already said, but here is all of it:

so my idea to chance is to bump version, so who will make
compatibility for their stuffs, that will be straightforward. the
remaining old and unmaintained(?) packages can still have a simple
compatibility module, that can be like a metatable for set/get both
the string and table version, and synch them. this way we can use a
'wrapper' or whatever for old stuffs, so there's no need to mess with
the contents. in the meantime we can move forward to something that is
in bigger harmony with lua, as it's kinda all around about tables; and
there's no need to a next modification, but only a cleanup for
official support for string path, while there can be a simple
workaround for keep compatibility in pure lua.

the synch and workaround wouldn't be a performance issue, for the most
of the existing packages, because it's not a heavily used stuff, but
it's more likely a lilbit of additional warmup time only.

the _t suffix is bad, because future dirt, the 'paths' can be good,
but an another guess is lookup and lookup_c or whatever, there can be
always a new name, that is not like A -> A and A+suffix -> A+suffix -
and now a 4th version to remove the unnecessary suffix, and get an
another compatibility issue for those who relied on the suffix
version...

a deprecated note is enough for the time of coexists, so a 6.1 can get
rid of all the mess.

duplications won't make harm, so that can be left for the devs, and
they will have dreamless nights if they will dare to make mess around,
but things will work...

i think it can be a good improvement and the switch can be smooth,
just think out well the rest of the fate of the contents of package to
make something that can have a long life as is...

so +1, and i think it wouldn't be a big pain from any side

Reply | Threaded
Open this post in threaded view
|

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

Dirk Laurie-2
2017-09-07 20:50 GMT+02:00 [hidden email] <[hidden email]>:

> the _t suffix is bad, because future dirt, the 'paths' can be good,
> but an another guess is lookup and lookup_c or whatever, there can be
> always a new name, that is not like A -> A and A+suffix -> A+suffix -
> and now a 4th version to remove the unnecessary suffix, and get an
> another compatibility issue for those who relied on the suffix
> version...

Since we are now revamping package.path altogether, why stop
at a table? It could be a userdata. All sorts of system functions
hidden opaquely under the hood. Maybe even integrate it with
a really sophisticated package searcher like kpathsea.

Reply | Threaded
Open this post in threaded view
|

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

Russell Haley
In reply to this post by Roberto Ierusalimschy
On Thu, Sep 7, 2017 at 9:10 AM, Roberto Ierusalimschy
<[hidden email]> wrote:

>> 2017-09-07 10:29 GMT+02:00 Martin <[hidden email]>:
>> > 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

Reply | Threaded
Open this post in threaded view
|

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

Lorenzo Donati-3
In reply to this post by Martin
On 06/09/2017 20:03, Martin wrote:
[snip]

> --[[
> Also there is weird stuff in <package.config>. (String which must
> contain five lines with special meaning.) I'd like to change it too.
> ]]
>

I already proposed that thing long ago. The reply from lua team was,
IRRC, that it was a waste of memory for little gain. I haven't got the
time to search for that thread right now.


> -- Martin
>
>

-- Lorenzo

Reply | Threaded
Open this post in threaded view
|

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

Martin
On 09/10/2017 09:43 AM, Lorenzo Donati wrote:

> On 06/09/2017 20:03, Martin wrote:
>> Also there is weird stuff in <package.config>. (String which must
>> contain five lines with special meaning.) I'd like to change it too.
>
> I already proposed that thing long ago. The reply from lua team was, IRRC, that
> it was a waste of memory for little gain. I haven't got the time to search for
> that thread right now.
>
> -- Lorenzo
>

I've done quick search in maillist for "package.config" and discovered similar
topic in 2010, just seven years ago:
http://lua-users.org/lists/lua-l/2010-06/msg00214.html

Looks like some implementation details are very constant.

-- Martin

Reply | Threaded
Open this post in threaded view
|

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

Martin
In reply to this post by Roberto Ierusalimschy
On 09/07/2017 05:10 PM, Roberto Ierusalimschy wrote:
> 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).

I don't think that "sequence of paths" is harder to explain to Lua programmer
than "string with delimited paths".


On 09/07/2017 05:10 PM, Roberto Ierusalimschy wrote:
> With the change, we get two
> concepts (and two representations to be manipulated and documented) for
> the same thing.
>
> -- Roberto

Yes, here is real problem. At the time when "path" and "paths" will coexist,
changes to one of them must be mirrored to other. I don't see elegant and
lightweight solution for this.

But this facilities can be made independent: module is searched in
"package.paths" (TY Oliver for name), then, if not found, "package.path"
string is processed.

This manner documentation for sequence "package.paths" be independent
from "package.path" (except text describing order in which these entities
are processed).

-- Martin

12