lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

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

which can then be called:

  unpackage(require "math")

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

  unpackage "math"


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 <> 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 <> (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.