Re: [ANN] Penlight 1.3 Request for Comment

[Andrew Starks <andrew.starks@...>]

On Saturday, September 14, 2013, steve donovan  wrote:
> 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.

Good call. Off list is where I'll take it. I'll catch up with you on your repo. Thanks Steve!