Re: Project lead nominations for standard libraries?

["David J. Slate" <dslate@...>]

For what they're worth, I thought I would add my impressions to all
the other posts about the '#' operator:

My particular point of view is that of a relative Lua newbie, since
I've only used Lua extensively for the last 18 months or so.  On the
other hand, I'm not a computer newbie; having programmed computers for
more than 48 years, I've seen and used a lot of different hardware and
OS platforms, and several programming languages, of which I would
judge Lua to be the nicest I've encountered so far.

When I first saw how the '#' operator applied to tables, it seemed a
bit of an anomaly.  In a language as elegant as Lua, I expected a
single-character core operator like '#' to have a simple, general, and
intuitively predictable meaning when applied to the data types for
which it's relevant.  As applied to strings it does, returning
unambiguously the length of the string.  But applied to tables, it
produces a sensible result only for arrays or lists with integer
indices beginning with 1 and without "holes".  Intuitively, I would
have expected a "length operator" as applied to an associative table
to produce a count of its keys, regardless of what kind of table it
was.  There could of course be an appropriately-named function that
worked like '#' actually does.

Note that this is just my aesthetic sense reacting, and perhaps
someday varieties in taste regarding programming languages will be
explained by genetic differences (I wonder what strange combination of
genes could lead to an appetite for Perl!).

-- Dave Slate


On Sat, 1 Jan 2011 17:10:34 +0100 Axel Kittenberger <axkibe@gmail.com>
wrote:

> > 2) The length operator returns the last index before a nil in an array
> 
> Just before someone reads it wrong again. No it doesn't.
> And I think the notion is correct, _we_ know what # means, but Lua at
> least in its root has not been targeted at the expert that reads the
> manual very closely, but aimed to be a simple as hazard free language
> as possible. For _us_ # is perfect, for the Lua-newbie it can easily
> become a hazard.
> 
> My suggestion is: remove any default core implementation of # on
> tables. # just calls __len on the metatable and thats it, nothing
> else.
> 
> Then provide in the core library a "List" function [1] returning a List table.
> a = List{a, b, c}.
> 
> This one has the metatable __len set to define #. Any other table hasn't.
> List can either maintain the length itself, or rely on some #-like
> core functionality provided by any other means to the userspace. A
> list can throw an error if any operation would make it a non-list or
> if you want to do it else lose its list ability and thus its metatable
> (throwing an error when # is later called upon). table.insert -- or
> list.insert ? -- can also rely on the #-like core functionallity thats
> not called # anymore.
> 
> This way I hardly see perfomance loss.
> 
> [1] I'd call it "List" since this is the more generic term for a
> linear organisation. Array has a specific meaning in informatics, and
> the list implementation not necessary has to be an arrray. Also to
> hinder confusion with the cores "array" and "hash" part.


On Sat, 01 Jan 2011 16:03:30 +0100 Henning Diedrich <hd2010@eonblast.com> wrote:

> Hi Steve,
> 
> a happy new year. Apologies for the word count. The drama is fake, 
> that's clear, yes?
> 
> On 1/1/11 3:10 PM, steve donovan wrote:
> > On Fri, Dec 31, 2010 at 11:58 PM, Henning Diedrich<hd2010@eonblast.com>  wrote:
> >> So I plead with you, Roberto, for the soul of Lua, as Chris called out, fix
> >> # !
> > But it ain't broken, so why fix it? It works precisely as specified.
> 
> In my view, for Lua's audience, the spec is broken. First class nil is 
> not an answer,
> not for Lua, to my mind. That's perfect as is.
> 
> "# is reverse magic. Dark magic, seen from the higher level. It requires 
> understanding
> of implementation to 'become' intuitive. But without even the benefits 
> of the usual
> over-eager white magic. Lua, for its purity, should shun both, of course."
> 
> I put that in quotes.
> 
> > It's a problem when people pretend that a raw Lua table is the
> > particular data structure they have in mind
> 
> Lua gets pretty close to pretend one structure, the table, is all
> you ever need, but then without a warning backs out of it with #,
> isn't it?
> 
> >   - "a pure array with
> > bounds checking", "a pure associative map where nil can be a key",
> > etc. Unfortunately it is not possible for human programming languages
> > to guess what kind of data structure is actually intended ;)
> 
> If speed was no factor, all would be entirely transparent and really only
> 'a list'. But it is, which brings the implementation level in play. So
> only for performance, not for the logic of it, is knowledge about
> implementation necessary. And that should be, and is, beyond the concerns
> of a segment of Lua programmers. Who not co-incidently may also be less
> active in a discussion like this.
> 
> So that makes me a champion of imaginary silently nodding masses, of
> course. But truth be told, I might take a less noble stand had I not now 
> and
> then to answer for mistakes others make in one way or an other. That's what
> informs my take on this. Not that I ever in my life would forget the spec of
> # again after this thread ... or fight for nil becoming a first class 
> citizen, or
> Lua what it is otherwise not. It's in my view "for Lua staying true to 
> itself."
> 
> The spec of # as is does not do Lua a favor. I think you could say, it's 
> broken.
> 
> Henning
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://vlists.pepperfish.net/cgi-bin/mailman/private/lua-l-lists.lua.org/attachments/20110101/851b5889/attachment.htm