Re: Packaging and importing

[Rici Lake <lua@...>]

On 17-Aug-05, at 1:20 PM, Chris Marrin wrote:

> I see it most often for "standard" things like Math.

Indeed. I think math (not Math :) ) might be an exception here, since 
you're probably not going to find sin, atan2 and PI [1] in other 
packages (barring a multi-precision mathematics package, of course.)

One of the changes between Lua 4 and Lua 5 was the move of a huge 
number of standard library functions from the global namespace into 
package tables. On the whole, it's probably an improvement, since it 
avoids name collision (the common alternative, often found in C 
programs, is namespacing with prefixes: math_sin, bignum_sin, 
mortal_sin, etc.; which can hardly be said to be an improvement on 
math.sin, etc.)

But for casual users, particularly mathematical ones, it's annoying. So 
one option is to dump the relevant package directly into the global 
namespace, pretty much as you suggest. But I don't think the proposed 
'import' compile-time macro should be overloaded to do this; that's 
just confusing. (I'm really putting the cart before the horse here, 
since import is just a nebulous proposal based on an interesting but 
not yet adopted parsing modification.)

Assuming that require returns a table, you can easily achieve this 
effect:

function unpackage(pkg)
  local env = getfenv(2) -- yuk
  for k, v in pairs(pkg) do
    env[k] = v
  end
end

which can then be called:

  unpackage(require "math")

Alternatively (and possibly better), the putative macro processor could 
convert:

  unpackage "math"

into

  do local env = getfenv(); for k,v in pairs(require "math") do env[k] 
= v end end

which might not be too difficult for it.

However, I would be nervous about using this sort of technique aside 
from a small number of standard packages.

For what it's worth, I still think min and max should be primitives 
rather than part of the math package. They are perfectly well defined 
for anything for which < or <= is a total-ordering, or something close 
to a total ordering. [2]

----------------

[1] I ran into this in the Allegro faq 
<http://alleg.sourceforge.net/faq.html> this morning, and it charmed me 
enough that I reproduce it here:

Q: Why is it considered good coding practice to define PI as a 
constant, rather than just using the value 3.141592 in my code?

A: It simplifies the maintenance of your program, in case the value of 
PI ever needs to be changed. Also it will make your program more 
portable to other compilers that use different values of PI.


[2] IEEE-754r seems to still be in the process of deciding what min and 
max should mean if one argument is a NaN; the current draft seems to be 
heading in the usual direction of adding almost every possible 
semantics with a different name, so we may end up with all of the 
following: minnum, minnummag, minnan, minnanmag, maxnum, maxnummag, 
maxnan, maxnanmag, where num indicates that a number is preferred to a 
NaN; nan indicates that a NaN is preferred to a number; and mag 
indicates that the comparison is by absolute value ("The *mag functions 
are guaranteed to violate somebody's expectations.") See 
<http://www.validlab.com/754R/drafts/754r.pdf> (also available in .sxw, 
.html, .txt and .ps, choose your poison), section 5.10, page 120 and 
following.

This seems consistent with the 20 (down from 26) comparison predicates, 
to which section 5.10 adds two more: totalorder and totalordermag.