Re: [ANN] Penlight 1.3 Request for Comment

[steve donovan <steve.j.donovan@...>]

On Sat, Sep 14, 2013 at 3:34 PM, Andrew Starks <andrew.starks@trms.com> wrote:
> It would be wonderful if there were a clock library which allowed me to make
> a date/time object with an arbitrary TICKS and EPOCH value, where epoch was
> some date/time value in the native clock's terms.

Dates:

Yep, current code is very much about Unix epoch + seconds. However,
they are objects (and really all I require of classes is that they
support that basic fact) and so we can sneak in fractional seconds as
an extra field.

> On ISO 8601: so long as you are providing a "day of week" function, this is
> the ONLY format that I would ever want and the only one that I would ever
> need you to parse.

Great, because it's not difficult - doesn't need lpeg for that. There
are a few places in PL where having lpeg would make some things
easier/faster (such as the lexical scanner), but it would be an extra
dependency.

Date.Format actually supports parsing a ridiculous amount of time/date
formats, when it hasn't been given a 'DD-MM-YY' or some such.  Jay
recently writing about the perils of 'small mini-languages in strings'
made me want to rethink this, since being very permissive means that
error messages are vague and misunderstandings can happen.

Classes:

Nothing too clever about current implementation, and I certainly don't
support classes for religious reasons ;)  They're just a tactic in the
game of handling complexity, not a prime directive.  pl.class is more
flexible these days; if the constructor ('_init') returns a value,
then that's the object.  However, taking a particular approach makes
some kinds of extension awkward.  I think they shouldn't be such
closed boxes, and perhaps providing some additional machinery so
people can compose the solutions they want?  Without including the
whole of LOOP, of course.

Types:

I really like the type library you recently released, and I think it
meets a need.  pl.types has become the place for querying types for
'capabilities', like is_callable, etc.  Would be cool if we could
integrate features into that?

The lpeg-like syntax is highly suggestive and cute - describing the
structure of actual real Lua types _is_ non-trivial.  (Someone should
do a paper on that, I think)  But it's possible to over-obsess about
type checking and the notation will probably give most of this list a
serious headache ;)

I'm considering including some variant of 'strict structs':

http://lua-users.org/wiki/StrictStructs
http://steved-imaginaryreal.blogspot.com/2011/09/strict-tables-in-lua.html

The rationale is that often Lua data is not sufficiently
strongly-typed.  We have a tendency to pass and return ad-hoc tables;
they are a bitch to document and reason about.

steve d.