Menu
▾
▴
lua-users-stdlib — Discussion of non-core standard libraries for Lua
You can subscribe to this list here.
| 2004 |
Jan
(8) |
Feb
(29) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
(7) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Reuben T. <rr...@sc...> - 2013-03-25 13:10:40
|
On 25 March 2013 08:12, Gary V. Vaughan <ga...@va...> wrote: > Hi Reuben, > > On 25 Mar 2013, at 08:48, Reuben Thomas <rr...@sc...> wrote: > > On 25 March 2013 01:44, Gary V. Vaughan <ga...@gn...> wrote: > > > That would be nice, provided my recent patch to getopt goes in. In > fact, preferably everything up to 47d51c718ce. Is that possible without > messing with history? > > > > No it's not. And github (rightly) don't allow rewinding on master, so I > just committed a revert for the premature branch merge. master builds and > meets specs using both Lua 5.1 and 5.2 for me. Feel free to release, or > ping me if you like me to do it. > > > > > > I'm unclear why you couldn't just tag before the bit you reverted? But > fine, making a release now is good. > > So that the commits you made to master after the premature merge > (particularly changes to the release rule) are available while making the > release. > Ah, the reason I was puzzled is that the changes I mentioned I need in the release were all before the mistaken branch merge. |
|
From: Gary V. V. <ga...@va...> - 2013-03-25 08:12:53
|
Hi Reuben, On 25 Mar 2013, at 08:48, Reuben Thomas <rr...@sc...> wrote: > On 25 March 2013 01:44, Gary V. Vaughan <ga...@gn...> wrote: > > That would be nice, provided my recent patch to getopt goes in. In fact, preferably everything up to 47d51c718ce. Is that possible without messing with history? > > No it's not. And github (rightly) don't allow rewinding on master, so I just committed a revert for the premature branch merge. master builds and meets specs using both Lua 5.1 and 5.2 for me. Feel free to release, or ping me if you like me to do it. > > > I'm unclear why you couldn't just tag before the bit you reverted? But fine, making a release now is good. So that the commits you made to master after the premature merge (particularly changes to the release rule) are available while making the release. > Note that I changed the release source check-in scheme to work the same as that for luaposix, i.e. it expects to find a checkout of master next to a checkout of the release branch, the latter named stdlib-release. This avoids nuking files in the master checkout (in my case I found I was nuking all my release-notes-* files, which is not a disaster, but is a bit annoying). Ack. No worries... I'll make another clone of the git repo, and fire off the release later this afternoon. Cheers, -- Gary V. Vaughan (gary AT vaughan DOT pe) |
|
From: Reuben T. <rr...@sc...> - 2013-03-25 01:49:05
|
On 25 March 2013 01:44, Gary V. Vaughan <ga...@gn...> wrote: > > > > > That would be nice, provided my recent patch to getopt goes in. In fact, > preferably everything up to 47d51c718ce. Is that possible without messing > with history? > > No it's not. And github (rightly) don't allow rewinding on master, so I > just committed a revert for the premature branch merge. master builds and > meets specs using both Lua 5.1 and 5.2 for me. Feel free to release, or > ping me if you like me to do it. > > I'm unclear why you couldn't just tag before the bit you reverted? But fine, making a release now is good. Note that I changed the release source check-in scheme to work the same as that for luaposix, i.e. it expects to find a checkout of master next to a checkout of the release branch, the latter named stdlib-release. This avoids nuking files in the master checkout (in my case I found I was nuking all my release-notes-* files, which is not a disaster, but is a bit annoying). -- http://rrt.sc3d.org |
|
From: Gary V. V. <ga...@gn...> - 2013-03-25 01:44:42
|
Hi Reuben, On 25 Mar 2013, at 03:34, Reuben Thomas <rr...@sc...> wrote: > On 24 March 2013 11:37, Gary V. Vaughan <ga...@gn...> wrote: > Done, although it took me a minute to find the listserv. Might be worth advertising the list in README? > > A thought before I do that: maybe it would be better just to encourage the use of the github issue tracker? Otherwise we're basically saying "you need a github account AND a sourceforge account if you want to play with us" which seems mean. Well, you don't need a sourceforge account to sign up to the mailing list. However, I for one don't think much of sourceforge... it's littered with advertising, and slow as hell. I'd be very happy indeed to pretend they do not exist. If the github issue tracker is sufficient to your needs, then I see no reason to keep a sourceforce mailing list around too... > > Some of the package tests are currently failing. Please can we have those fixed so we can release v34, which I need for another project? > > How about I tag the revision just before I introduced those failures, and release that as v34? > > That would be nice, provided my recent patch to getopt goes in. In fact, preferably everything up to 47d51c718ce. Is that possible without messing with history? No it's not. And github (rightly) don't allow rewinding on master, so I just committed a revert for the premature branch merge. master builds and meets specs using both Lua 5.1 and 5.2 for me. Feel free to release, or ping me if you like me to do it. Cheers, -- Gary V. Vaughan (gary AT gnu DOT org) |
|
From: Reuben T. <rr...@sc...> - 2013-03-24 20:34:52
|
On 24 March 2013 11:37, Gary V. Vaughan <ga...@gn...> wrote: > Done, although it took me a minute to find the listserv. Might be worth > advertising the list in README? > A thought before I do that: maybe it would be better just to encourage the use of the github issue tracker? Otherwise we're basically saying "you need a github account AND a sourceforge account if you want to play with us" which seems mean. > > Some of the package tests are currently failing. Please can we have > those fixed so we can release v34, which I need for another project? > > How about I tag the revision just before I introduced those failures, and > release that as v34? > That would be nice, provided my recent patch to getopt goes in. In fact, preferably everything up to 47d51c718ce. Is that possible without messing with history? -- http://rrt.sc3d.org |
|
From: Gary V. V. <ga...@gn...> - 2013-03-24 11:56:38
|
Hi Reuben, On 23 Mar 2013, at 20:38, Reuben Thomas <rr...@sc...> wrote: > [Gary: you're not yet subscribed. In the interests of long-term sanity, please do!] Done, although it took me a minute to find the listserv. Might be worth advertising the list in README? > Some of the package tests are currently failing. Please can we have those fixed so we can release v34, which I need for another project? How about I tag the revision just before I introduced those failures, and release that as v34? I have about a dozen pending patches, all under revision, and requiring specs to be written to make sure they continue to work. I don't want to rush them and make a half baked release of these changes, so I'd rather take the time to finish and verify that everything was done correctly even if that means they don't get in until v35. > Feel free to push the changes to make modules other than package not perturb the global environment if they're ready; it'd be nice (but hardly essential) to get all the modules sorted in the same release. They're not, and I'm not confident enough that the changes I have completed already are optimal just yet, sorry :( Cheers, -- Gary V. Vaughan (gary AT gnu DOT org) |
|
From: Reuben T. <rr...@sc...> - 2013-03-23 13:38:55
|
[Gary: you're not yet subscribed. In the interests of long-term sanity, please do!] Some of the package tests are currently failing. Please can we have those fixed so we can release v34, which I need for another project? Feel free to push the changes to make modules other than package not perturb the global environment if they're ready; it'd be nice (but hardly essential) to get all the modules sorted in the same release. -- http://rrt.sc3d.org |
|
From: Reuben T. <rr...@sc...> - 2006-03-29 00:38:24
|
On Tue, 28 Mar 2006, Identity Guarded wrote: > I downloaded both the latest Compat-5.1 and the latest stdlib, installed them > in the correct path (/usr/local/share/lua50), and tried to execute the > following script (nothing crazy -- just seeing if it compiles): > > #!/usr/bin/lua > require "compat-5.1" > require "io.getopt" > > I get: > > $ ./test_script > /usr/bin/lua: /usr/local/share/lua50/rex-ext.lua:7: bad argument #1 to > `setmetatable' (table expected, got nil) > stack traceback: > [C]: in function `setmetatable' > /usr/local/share/lua50/rex-ext.lua:7: in function `init' > /usr/local/share/lua50/compat-5.1.lua:200: in function `require' > /usr/local/share/lua50/string/xml.lua:6: in function `init' > /usr/local/share/lua50/compat-5.1.lua:200: in function `require' > /usr/local/share/lua50/string-ext.lua:8: in function `init' > /usr/local/share/lua50/compat-5.1.lua:200: in function `require' > /usr/local/share/lua50/io/getopt.lua:7: in function `init' > /usr/local/share/lua50/compat-5.1.lua:200: in function `require' > ./make_init.d_script:4: in main chunk > [C]: ? This is fixed now, I think. -- http://rrt.sc3d.org/ | Slow Pedestrian Crossing (Anon) |
|
From: Identity G. <d7r...@sn...> - 2006-03-28 19:29:02
|
Hi,
I wasn't sure if the stdlib project for Lua was still active. Reuben, I've
sent this message to you personally just this once in the event that the
mailing list isn't active; just let me know if you do read the mailing list
still.
I downloaded both the latest Compat-5.1 and the latest stdlib, installed them
in the correct path (/usr/local/share/lua50), and tried to execute the
following script (nothing crazy -- just seeing if it compiles):
#!/usr/bin/lua
require "compat-5.1"
require "io.getopt"
I get:
$ ./test_script
/usr/bin/lua: /usr/local/share/lua50/rex-ext.lua:7: bad argument #1 to
`setmetatable' (table expected, got nil)
stack traceback:
[C]: in function `setmetatable'
/usr/local/share/lua50/rex-ext.lua:7: in function `init'
/usr/local/share/lua50/compat-5.1.lua:200: in function `require'
/usr/local/share/lua50/string/xml.lua:6: in function `init'
/usr/local/share/lua50/compat-5.1.lua:200: in function `require'
/usr/local/share/lua50/string-ext.lua:8: in function `init'
/usr/local/share/lua50/compat-5.1.lua:200: in function `require'
/usr/local/share/lua50/io/getopt.lua:7: in function `init'
/usr/local/share/lua50/compat-5.1.lua:200: in function `require'
./make_init.d_script:4: in main chunk
[C]: ?
I haven't yet dug into the stdlib code. Actually, before digging in, I was
interested to see first what the status was on the project. Is scripting in
Lua still a sensible direction to push towards? Or has there been too much
resistance from the Lua community in general?
If stdlib is current, then do you perhaps know what the problem might be?
According to "lua -v" I'm on version 5.0.2, which came from the Debian
testing repository (Debian versions 5.0.2-5.1).
Thanks for you help,
Sukant Hajra
|
|
From: Reuben T. <rr...@sc...> - 2004-02-14 14:14:41
|
> At present, you could gave the module an alias, but if you deleted the > original name it would break the internal references. That probably ought to > be changed. Good point. I hadn't thought of that. -- http://www.mupsych.org/~rrt/ | What you don't know controls you |
|
From: Reuben T. <rr...@sc...> - 2004-02-14 14:13:45
|
> It doesn't really matter that much. I can always rename any "vector" > module to "list" and be done. I'm just lazy, find it easier to type > "list", and think its natural-language overtones mesh better with the > word "table". I strongly agree with this. List is a reasonably vague word, and it's obvious and nice to type. > Actually, this reminds me. What are the times on Lua tables? I know > that integer indices are special, but do they get true O(1) access? > Presumably, other keys are O(log n), as usual. Integer indices that end up in the array part of the table get O(1) access (effectively they have space reserved for them). However, which keys are actually in the array part is a little harder to determine. Basically, it's all the keys up to N such there are at least half of all possible keys in the range 1-N, i.e. occupancy of the array is at least 50%. But if you add bigger keys (>N) then even when occupancy of some larger N becomes >50%, those keys will be kept in the hash table part until it overflows and the table is resized. When this happens depends on the table. If you never put anything but integer keys in a table, then almost all your keys will almost always have O(1) access time. > Nah, ASCII representations are for the weak. You need the funny arrows > and things. :-) Funny thing, I've been reading the docs on K recently, and I'm impressed (I've been meaning to do it for years...). -- http://www.mupsych.org/~rrt/ | art, n. romanticized mundanity |
|
From: Reuben T. <rr...@sc...> - 2004-02-14 13:29:13
|
> On Saturday 07 February 2004 23:15, Jamie Webb wrote: > > Well, Reuben already has zip = unzip = transpose. Maybe there's an argument > > for having foldl = reduce, map = foreach, etc. > > Actually, map = transform is probably better, following C++. I'd rather reduce the number of names if possible. I had zip = unzip = transpose because I thought that it was unlikely that programmers used to zip and unzip would realise that they were both transpose in Lua. OTOH, that's a fairly small community I'm catering too, and discussion among users of the libraries might be hampered by having all these names... OTOOH, those names are much more obvious when you're reading code and you're trying to work out what it's doing... I think the answer is probably (as usual) to strike a balance. My view of that balance would be to provide those names that make code easier to read, and not provide extra names just to give people the names they're used to. zip, unzip and transpose are different ideas (they have different types in strongly-typed languages, after all!). map and transform aren't. In the end, the only way to keep this thing small and simple (as it should be) is to have a "one true way". This should really be as close as possible to *the* One True Way, and I'm quite happy to argue over it lots, but in the end, I think we have to make a decision. -- http://www.mupsych.org/~rrt/ | wit, n. educated insolence (Aristotle) |
|
From: Jamie W. <j...@jm...> - 2004-02-09 01:44:29
|
On Sunday 08 February 2004 23:48, Johann Hibschman wrote: > It doesn't really matter that much. I can always rename any "vector" > module to "list" and be done. I'm just lazy, find it easier to type > "list", and think its natural-language overtones mesh better with the > word "table". At present, you could gave the module an alias, but if you deleted the original name it would break the internal references. That probably ought to be changed. > Actually, this reminds me. What are the times on Lua tables? I know > that integer indices are special, but do they get true O(1) access? > Presumably, other keys are O(log n), as usual. They are hash tables, so in practice can usually be treated as O(1). Integer indices are implemented as an array, so are guaranteed O(1). There is a 'sparsity' heuristic which determines the size of the array. Any indices falling outside the array are hashed as usual. > In any case, I don't see much of a point in continuing to discuss this, > since I can always rename packages to whatever I prefer. If you would > really rather call it a vector package, we can just go with that. TBH I don't much like vector either. I just also don't like misnaming things, not least because it leaves no name for the real thing. In terms of wasted keystrokes and display width, perhaps vec would be better than vector. |
|
From: Johann H. <jhi...@ya...> - 2004-02-08 23:48:14
|
On Feb 7, 2004, at 6:15 PM, Jamie Webb wrote: > On Friday 06 February 2004 03:42, Johann Hibschman wrote: >> Well, "list" is a natural language word, so it's broad and doesn't >> promise much. A "vector" is a rather specialized technical word, more >> specialized than even "array", so it promises a lot. > > That's just it though: all three are rather specialised technical > words. The > exact way in which they are specialised depends on the field you work > in. Well, there is still a difference. "list" is common language, that's been co-opted by many programming languages to mean linked lists, but it's certainly not omni-present. For example, I do a lot of Python, and Python lists are vector-like lists, not linked lists. However, it's certainly true that the list/vector difference is maintained in Scheme, Common Lisp, Java, OCaml, and probably many other languages. It doesn't really matter that much. I can always rename any "vector" module to "list" and be done. I'm just lazy, find it easier to type "list", and think its natural-language overtones mesh better with the word "table". > Since Lua is a mixed imperative/functional language, we should take > our > definitions from those worlds: Arrays are fixed-size, n-dimensional > mutable > structures with O(1) random access, O(n) inserts, etc., Vectors are > single-dimensional, mutable and resizable in imperative languages, > with O(1) > random access, O(n) inserts, etc. Lists are mutable and resizable in > imperative languages, and have O(n) random access and O(1) inserts. > Data > Structures books may qualify such lists as linked lists, but > programming > languages such as C++, ML, and LISP don't. Actually, this reminds me. What are the times on Lua tables? I know that integer indices are special, but do they get true O(1) access? Presumably, other keys are O(log n), as usual. > Also, the implications of a misunderstanding differ: If a user were to > assume > he was dealing with a mathematical vector when in fact he wasn't, that > could > only be as a consequence of a more direct misunderstanding of the > operations > he is performing, and the interpreter is likely to complain very > quickly. > OTOH, if a programmer were to assume he was dealing with a linked > list, he > could quite happily produce a working program, only to discover once > he tries > it on production-scale data that it runs N times slower than expected. That's certainly true, but I think it's very unlikely. >> At work, I'm converting over some old APL programs, so I'll probably >> have some extremely screwy ideas in a few weeks, if I can ever get the >> blasted font to work. Now _there_'s a concise language. > > Mmm... I thought those people who still dealt with APL tended to use > ASCII > representations these days? Nah, ASCII representations are for the weak. You need the funny arrows and things. :-) In any case, I don't see much of a point in continuing to discuss this, since I can always rename packages to whatever I prefer. If you would really rather call it a vector package, we can just go with that. Cheers, Johann |
|
From: Jamie W. <j...@jm...> - 2004-02-07 23:23:56
|
On Saturday 07 February 2004 23:15, Jamie Webb wrote: > Well, Reuben already has zip = unzip = transpose. Maybe there's an argument > for having foldl = reduce, map = foreach, etc. Actually, map = transform is probably better, following C++. |
|
From: Jamie W. <j...@jm...> - 2004-02-07 23:15:54
|
On Friday 06 February 2004 03:42, Johann Hibschman wrote: > On Feb 5, 2004, at 6:48 AM, Jamie Webb wrote: > > On Thursday 05 February 2004 03:22, Johann Hibschman wrote: > >> Hm. From an aesthetic point of view, I'd still rather have functions > >> such as map, filter, and their friends in a "list" package, rather > >> than > >> in a "vector" package. "list" is a human word, more accurate than > >> "vector" for what amounts to a linear sequence. > > > > In what sense do you mean more accurate? > > Well, "list" is a natural language word, so it's broad and doesn't > promise much. A "vector" is a rather specialized technical word, more > specialized than even "array", so it promises a lot. That's just it though: all three are rather specialised technical words. The exact way in which they are specialised depends on the field you work in. Since Lua is a mixed imperative/functional language, we should take our definitions from those worlds: Arrays are fixed-size, n-dimensional mutable structures with O(1) random access, O(n) inserts, etc., Vectors are single-dimensional, mutable and resizable in imperative languages, with O(1) random access, O(n) inserts, etc. Lists are mutable and resizable in imperative languages, and have O(n) random access and O(1) inserts. Data Structures books may qualify such lists as linked lists, but programming languages such as C++, ML, and LISP don't. > It seems equally likely that someone will see "vector" and think > "element of a vector space" as someone will see "list" and think > "linked list". I think a vanishingly small number of people are going > to be confused by using the word "list" for something with O(1) access, > just like a vanishingly small number of people will expect a vector to > have a fixed dimension and pre-defined mathematical operations. Difference: A [Lua table with integer keys] may well be a member of a vector space (well, as good as; I don't think double quite qualifies as a field), but it would never be a linked list. Also, the implications of a misunderstanding differ: If a user were to assume he was dealing with a mathematical vector when in fact he wasn't, that could only be as a consequence of a more direct misunderstanding of the operations he is performing, and the interpreter is likely to complain very quickly. OTOH, if a programmer were to assume he was dealing with a linked list, he could quite happily produce a working program, only to discover once he tries it on production-scale data that it runs N times slower than expected. > I think you missed my point; these definitions work for linked lists > just as well as for 1D arrays, so they don't really show the > "vector"-ness of vectors. They show that vectors, arrays, and lists all satisfy your 'element of a vector space' criterion. Therefore, in mathematical terms, we could call any one of them a vector (assuming the elements are numbers). In programming terms, as explained above, a [Lua table with integer keys] has the properties of a vector, and not those of an array or list. > Hm. In lisp, they're typically multiple-dispatch "multimethods", so, > yes, this is OOP, just not in foo.bar(baz) form. In Lua, I guess all > you could do would be to have the same functions work for both strings > and tables, so it's probably not worth the effort. Indeed. > Well, there are cuddly names and there are cuddly names. "reduce" is a > better word than "foldl", for one, but "foldl" allows you to also > define "foldr", which is good. I think I'd personally rather have > "reduce" with an optional from_end argument than foldl/foldr, but > clearly tastes differ. Well, Reuben already has zip = unzip = transpose. Maybe there's an argument for having foldl = reduce, map = foreach, etc. > At work, I'm converting over some old APL programs, so I'll probably > have some extremely screwy ideas in a few weeks, if I can ever get the > blasted font to work. Now _there_'s a concise language. Mmm... I thought those people who still dealt with APL tended to use ASCII representations these days? -- Jamie Webb |
|
From: Johann H. <jhi...@ya...> - 2004-02-06 03:42:33
|
On Feb 5, 2004, at 6:48 AM, Jamie Webb wrote:
> On Thursday 05 February 2004 03:22, Johann Hibschman wrote:
>> Hm. From an aesthetic point of view, I'd still rather have functions
>> such as map, filter, and their friends in a "list" package, rather
>> than
>> in a "vector" package. "list" is a human word, more accurate than
>> "vector" for what amounts to a linear sequence.
>
> In what sense do you mean more accurate?
Well, "list" is a natural language word, so it's broad and doesn't
promise much. A "vector" is a rather specialized technical word, more
specialized than even "array", so it promises a lot.
It seems equally likely that someone will see "vector" and think
"element of a vector space" as someone will see "list" and think
"linked list". I think a vanishingly small number of people are going
to be confused by using the word "list" for something with O(1) access,
just like a vanishingly small number of people will expect a vector to
have a fixed dimension and pre-defined mathematical operations.
If that's the case, why not go for the word that's common, has two
fewer characters, and is easier to touch-type?
> Scaling: map(bind(op["*"], x), v)
> (identity being x == 1)
>
> Addition: map(op["+"], v1, v2)
> Or with Reuben's version: zipWith(op["+"], {v1, v2})
> Additive identity: generate(id, 0, table.getn(v))
> (closed as usual, and a vector space if you configure Lua to do its
> arithmetic
> with integers IIRC)
I think you missed my point; these definitions work for linked lists
just as well as for 1D arrays, so they don't really show the
"vector"-ness of vectors.
>> I suppose that's just taste. However, to steal an idea from Common
>> Lisp, would it be a good idea to have a set of "sequence" functions,
>> in
>> their own package, that are designed to be smart enough to try to
>> decide what kind of type they're dealing with and Do The Right Thing?
>
> Ideally. The modern take on that is either OOP or generic programming,
> where
> table, vector, etc. all implement/model sequence. I'd like to see that
> sort
> of thing, but it doesn't appear to be practical in Lua presently,
> because
> both require a stronger notion of type. Trying to do it just by
> analysing
> tables seems very unpleasant.
Hm. In lisp, they're typically multiple-dispatch "multimethods", so,
yes, this is OOP, just not in foo.bar(baz) form. In Lua, I guess all
you could do would be to have the same functions work for both strings
and tables, so it's probably not worth the effort.
> As Reuben says, the library has functional stuff for those who want
> it, and
> more general stuff as well. Functional programming is always going to
> require
> imperative programmers to adjust their mindset somewhat, and I don't
> think
> that providing fewer primitives (making it less helpful), or trying to
> give
> the functions more cuddly names (so they don't match up with the
> literature)
> is going to change that.
Well, there are cuddly names and there are cuddly names. "reduce" is a
better word than "foldl", for one, but "foldl" allows you to also
define "foldr", which is good. I think I'd personally rather have
"reduce" with an optional from_end argument than foldl/foldr, but
clearly tastes differ.
At work, I'm converting over some old APL programs, so I'll probably
have some extremely screwy ideas in a few weeks, if I can ever get the
blasted font to work. Now _there_'s a concise language.
-Johann
|
|
From: Jamie W. <j...@jm...> - 2004-02-05 11:48:25
|
On Thursday 05 February 2004 03:22, Johann Hibschman wrote:
> Hm. From an aesthetic point of view, I'd still rather have functions
> such as map, filter, and their friends in a "list" package, rather than
> in a "vector" package. "list" is a human word, more accurate than
> "vector" for what amounts to a linear sequence.
In what sense do you mean more accurate?
> I know many people look at "list" and think "linked list", but "vector"
> is just bad. Well, at least it seems like poor terminology unless you
> can point me at the scaling operators and the identity, and demonstrate
> that they're closed under addition.
Scaling: map(bind(op["*"], x), v)
(identity being x == 1)
Addition: map(op["+"], v1, v2)
Or with Reuben's version: zipWith(op["+"], {v1, v2})
Additive identity: generate(id, 0, table.getn(v))
(closed as usual, and a vector space if you configure Lua to do its arithmetic
with integers IIRC)
> I suppose that's just taste. However, to steal an idea from Common
> Lisp, would it be a good idea to have a set of "sequence" functions, in
> their own package, that are designed to be smart enough to try to
> decide what kind of type they're dealing with and Do The Right Thing?
Ideally. The modern take on that is either OOP or generic programming, where
table, vector, etc. all implement/model sequence. I'd like to see that sort
of thing, but it doesn't appear to be practical in Lua presently, because
both require a stronger notion of type. Trying to do it just by analysing
tables seems very unpleasant.
> I'm still working on my package of lispy routines. Obvious things that
> I use all the time are "find", "find_if", "position", "position_if",
> and "member." The other functions, like "substitute", are also handy,
> just not as often. These can be applied over tables and strings at
> least, and perhaps over other types that are defined.
Well, I hope you'll contribute them when you're done.
> I'm just afraid that if the library becomes too functional, the Typical
> Programmer would have a hard time figuring out how to apply all the
> elegant tools.
As Reuben says, the library has functional stuff for those who want it, and
more general stuff as well. Functional programming is always going to require
imperative programmers to adjust their mindset somewhat, and I don't think
that providing fewer primitives (making it less helpful), or trying to give
the functions more cuddly names (so they don't match up with the literature)
is going to change that.
|
|
From: Reuben T. <rr...@sc...> - 2004-02-05 09:15:51
|
> I'm just afraid that if the library becomes too functional, the Typical > Programmer would have a hard time figuring out how to apply all the > elegant tools. I don't think there's too much danger of that with the mix we have so far. I think I'll shut up now until I've had a chance actually to finish a first cut with the results of the recent conversation we've had. I'm going to be away for a week starting tomorrow, so it probably won't happen until I get back, but hopefully I'll have some time while away to work on it. -- http://www.mupsych.org/~rrt/ | wet nurse, n. lactating lackey |
|
From: Johann H. <jhi...@ya...> - 2004-02-05 03:38:44
|
On Feb 4, 2004, at 5:58 AM, Reuben Thomas wrote: > I'll end with a concrete proposal of what I think is best from the > above: > we should add "vector" and "function" to the current "string", "table" > &c., and put all our additions into those four tables. One or two are > tricky (are map and filter in function or table?) but they all fit in > one > of the four. Once that's done we can take another look. Hm. From an aesthetic point of view, I'd still rather have functions such as map, filter, and their friends in a "list" package, rather than in a "vector" package. "list" is a human word, more accurate than "vector" for what amounts to a linear sequence. I know many people look at "list" and think "linked list", but "vector" is just bad. Well, at least it seems like poor terminology unless you can point me at the scaling operators and the identity, and demonstrate that they're closed under addition. I suppose that's just taste. However, to steal an idea from Common Lisp, would it be a good idea to have a set of "sequence" functions, in their own package, that are designed to be smart enough to try to decide what kind of type they're dealing with and Do The Right Thing? I'm still working on my package of lispy routines. Obvious things that I use all the time are "find", "find_if", "position", "position_if", and "member." The other functions, like "substitute", are also handy, just not as often. These can be applied over tables and strings at least, and perhaps over other types that are defined. I'm just afraid that if the library becomes too functional, the Typical Programmer would have a hard time figuring out how to apply all the elegant tools. -Johann |
|
From: Reuben T. <rr...@sc...> - 2004-02-04 21:50:59
|
> > Doesn't matter unless the mapped function is assuming something about the > > underlying list. It shouldn't be. > > Lua isn't a pure language. If map doesn't do what users expect, they will just > go back to their for-loops. Fair enough. And there's another rather more compelling reason: if you're building some kind of result, you want it in order. > > Cos it is. Discussed on the list; look at the code if you're not > > convinced. It's necessary because the table can be rehashed while you're > > traversing it. I think Squirrel avoids this. > > The code below definately runs in O(N), meaning next() is O(1): Once again, I'm talking rubbish. next(t) is linear; next(t,e) is constant time. -- http://www.mupsych.org/~rrt/ motive, n. a mental wolf in moral wool (Bierce) |
|
From: Jamie W. <j...@jm...> - 2004-02-04 21:39:40
|
On Wednesday 04 February 2004 18:36, Reuben Thomas wrote:
> n is evil.
Perhaps, but the weird hidden n is a bit evil too. I agree that that is
something that ought to be rationalised one way or the other though.
> > Also, next() doesn't honour numerical order.
>
> Doesn't matter unless the mapped function is assuming something about the
> underlying list. It shouldn't be.
Lua isn't a pure language. If map doesn't do what users expect, they will just
go back to their for-loops.
> Cos it is. Discussed on the list; look at the code if you're not
> convinced. It's necessary because the table can be rehashed while you're
> traversing it. I think Squirrel avoids this.
The code below definately runs in O(N), meaning next() is O(1):
t = {}
for i = 1,N do t[i] = true end
k,v = next(t)
while k do
t[k] = false
k,v = next(t,k)
end
I can believe there are situations in which it is linear (can't be bothered to
look at the source), but for the normal case where the keys are not modified,
it doesn't appear to be.
|
|
From: Reuben T. <rr...@sc...> - 2004-02-04 18:36:37
|
> > So that's part of our re-org of the existing libraries. > > Yeah. Just means that stdlib will break existing code, slowing uptake. Well, we'll have to minimise that. There's no big problem in duplicating to start with. > I suppose. Given that those functions are likely to be used in groups, it > would be nice to have something really short, but I suppose fn is too likely > to get shadowed by people's locals. Sadly. A lot of the time I'm annoyed by the new naming scheme and having to type table. and string. all the time. > > It's a real pity that next() is linear or map over vectors wouldn't have > > to be different from map over tables. > > It would anyway. Map over vectors needs to miss out the n if present. n is evil. > Also, next() doesn't honour numerical order. Doesn't matter unless the mapped function is assuming something about the underlying list. It shouldn't be. > And why do you say next is linear? Cos it is. Discussed on the list; look at the code if you're not convinced. It's necessary because the table can be rehashed while you're traversing it. I think Squirrel avoids this. -- http://www.mupsych.org/~rrt/ | robber, n. a candid man of affairs (Bierce) |
|
From: Jamie W. <j...@jm...> - 2004-02-04 18:25:57
|
On Wednesday 04 February 2004 17:30, Reuben Thomas wrote: > So that's part of our re-org of the existing libraries. Yeah. Just means that stdlib will break existing code, slowing uptake. > Keyword, duh. func? I suppose. Given that those functions are likely to be used in groups, it would be nice to have something really short, but I suppose fn is too likely to get shadowed by people's locals. > It's a real pity that next() is linear or map over vectors wouldn't have > to be different from map over tables. It would anyway. Map over vectors needs to miss out the n if present. Also, next() doesn't honour numerical order. And why do you say next is linear? -- Jamie Webb |
|
From: Reuben T. <rr...@sc...> - 2004-02-04 17:30:17
|
> I'm wondering though if the special-purpose stuff wouldn't be better going
> straight into Cheia rather than stdlib.
Quite possibly. It's really just a question of presentation.
> Perhaps some metrics on level of usage of each function would be more
> appropriate.
Right.
> Mmm... except that most of what is in Lua table ought to be in vector.
So that's part of our re-org of the existing libraries.
> > I'll end with a concrete proposal of what I think is best from the above:
> > we should add "vector" and "function" to the current "string", "table"
> > &c., and put all our additions into those four tables. One or two are
> > tricky (are map and filter in function or table?) but they all fit in one
> > of the four. Once that's done we can take another look.
>
> Well, fn or something rather than function presumably
Keyword, duh. func?
> Given the argument order, the existing convention suggests that map and
> filter ought to be in function. Trouble with that is that then you can't
> have vector.map, list.map, table.map, etc. So, either the argument order
> needs changing (bad, because other languages have it that way round, and
> it makes the most sense for partial applicaton), the convention needs
> abandoning (might be bad, depending on this whole { __index = table }
> business), or map needs to be on vectors only (bad; not very
> forward-thinking).
It's a real pity that next() is linear or map over vectors wouldn't have
to be different from map over tables.
--
http://www.mupsych.org/~rrt/ | maxim, n. wisdom for fools
|
