Proposal to add symbol: "hasInstanceStrict"

[Mike Samuel]

On Tue, Feb 20, 2018 at 1:20 PM, T.J. Crowder <
tj.crowder at farsightsoftware.com> wrote:

> On Tue, Feb 20, 2018 at 6:05 PM, Mike Samuel <mikesamuel at gmail.com> wrote:
> >
> > I'm probably just going to echo themes that T.J. has dealt with better,
> but:
>
> Quite the opposite.
>
> And keying off Mike's excellent summary: I like the idea of providing a
> means of handling preconditions (and postconditions), of which runtime type
> checking is one example but only one. I'd just prefer to see it as a
> general mechanism than type-checking specifically.
>
> I suggest getting deep into the decorators stuff and helping push it
> forward, possibly into areas where it hasn't previously been headed (such
> as your `let x = sum(y, y)` where you want to have runtime type checking on
> what gets assigned to `x` -- as far as I know, that isn't even on their
> radar). Basically that's applying a precondition to the assignment to `x`
> (or a postcondition on the call to `sum`). Which could be interesting. You
> may or may not get agreement on pushing forward that far, but if you feel
> strongly about the functionality you're after, I see that as the direction
> to pursue. (Not that I'm in ANY way any kind of authority on moving things
> through the process here. Not remotely.)
>
> -- T.J. Crowder
>

One way that decorators (I keep saying annotations) for locals might work
is:

@foo
const x = initialValue
f(x)

desugars to

const x = foo(undefined, initialValue)
f(foo(x))

When the decorated local is used as a left-hand side, the use is wrapped in
a call to the decorator.
When the decorated local is used as a right-hand side, the value assigned
is the result of the decorator applied to the previous value and the
candidate value.

I think that would be enough to build guards upon.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180220/d75f78f4/attachment-0001.html>