Re: paving cowpaths with libraries (was Re: Upstream is not the last word (was Re: [ANN] Lua 5.1.5 (rc1) now available))

So first off let me say I'm on the side of "lean is better", which means keeping a really minimal runtime. But if the runtime *IS* to be extended, what should the criteria be for selecting the extensions? Let me throw out a straw-man list, others can critique it (or ignore it!) as they wish...

1. Generality. Library routines should apply to as many problem domains as possible. So no adding home mortgage functions to the math library, for example.

2. Non-Triviality. Routines that can be written in 5-10 lines of Lua code don't seem good candidates to me. The example earlier of a "set()" function to create a set from a table (migrate array values to keys) seems to me to fall into that category. [If you go down this road you end up with developers really just stringing together dozens of calls to runtime functions, with the result that the code no longer looks like Lua and the underlying operation is all but lost in the mess.]

3. Performance. Some things are hard to code efficiently in Lua, and routines that handle heavy lifting in C do make some sense.

4. Abstraction. Some operations are inherently platform-dependent in their implementation, even if they can be exposed through a standard interface. [Lua does pretty well on this, but it does inherit some of the failures in this regard of the underlying C runtime (the format of paths passed to the file open functions comes to mind).]

[As an aside, imho adding lots of library routines can lead to AWFUL code. First off, inexperienced developers can get lost amongst a huge sea of library routines, fail to find the "ideal" routine and end up writing the code themselves anyway (or worse, bending the wrong routine to the task). Second, inexperienced developers often treat library routines as "magic", particularly when it comes to performance, and end up writing slow code and then blaming the runtime library for not being instantaneous. The bloated Java and .Net libraries are examples of this.]

--Tim

On Feb 15, 2012, at 2:28 AM, Dirk Laurie wrote:

Op 14 februari 2012 03:17 schreef Jay Carlson <nop@nop.com> het volgende:

Let me give some examples. Maybe it's the whole list, or even a superset. Feel free to say, "I never use that" or "I never use that and I can't see why anybody would". Or say "using a library function for that would be just as verbose as inlining it." Don't feel free to say,"that's trivial". The more trivial something is, the more likely we agree on how it works. I am so tired of writing/pasting these trivial functions, and looking for what they're called in other people's code.

When looking through your list, I often find that I use something like it — but seldom exactly the same. I've sampled one case below.

You can skip the rest of this post if you like, since I'm not soliciting constructive criticism of my conventions. My point is only that the fact that you do it your way and I do it my way is an argument in favour of not enshrining either in a `standard` library.

Dirk

Shallow-copy a table. I'd use a shallow merge-copy too.

I use this more versatile function. Shallow-copy has `{}` and shallow-merge has
the destination table as third argument.

function util.import(from,items,to)
-- import(from,nil,to) copies everything; can be used as shallow table copy
-- import(from,items,_ENV) copies items to current environment
-- import(from,items) copies items to global environment
-- import(from) copies everything to global environment
-- import(from,foo) replaces foo by a new table if foo is not a table
-- import("name") copies from require "name"
-- if `items` has only one item, it need not be put into a table
-- all versions return the table `to`
to = to or _G or getfenv() -- specified or Lua 5.2 or Lua 5.1
-- FAQ: Why make _G the default, not _ENV?
-- Ans: Otherwise in interactive mode nothing happens past the current line.