Re: [ANN] typecheck 1.1 released

["Gary V. Vaughan" <gary@...>]

Hi Soni,

On 07/07/2017 09:23 PM, Soni L. wrote:
> On 2017-07-08 12:45 AM, Gary V. Vaughan wrote:
> > I am happy to announce release 1.1 of typecheck.
> >
> > Typecheck's home page is at http://gvvaughan.github.io/typecheck
> > [[snip]]
>
> Why not pow decorators?
>
> x + argscheck "my_function (int, int) => int" .. f --> runtime error
> x + argscheck '...' ^ f --> ok
>
> In any case, both operators are right-associative, which gives proper 
> decorator semantics.
>
> (Also please tell me you felt inspired by my own libs? ^-^ [1][2])

I did see the announcements, but the decorator syntax was a contributed
patch.  Until that point I was using decorator functions:

  x + argscheck('my_function (int, int) => int', f)

However, even now I'm not convinced of the utility of inline argscheck
calls.  Adding the decorators to a module export table seems much more
manageable to me:

   return {
      fname = argscheck 'fname (int, int) => int' .. fname,
   }

> >   - New `check` method for ensuring that a single value matches a 
> > given type specifier.
> >
> >   - New "functor" type specifier for matching objects with a `__call` 
> > metamethod - note, most `std.object` derived types will match 
> > successfully against the "functor" specifier.
> >
> >   - New "callable" type specifier for matching both objects with a 
> > `__call` metamethod, and objects for which Lua `type` returns 
> > "function" - note, this is exactly what the "function" specifier used 
> > to do.
>
> Does this work in sandboxes?

Sure.  Why wouldn't it?  As long as the __call metamethod is accessible
to the decorator function at call time, it can be used to check the
arguments.

Cheers,
Gary