[parenscript-devel] A simpler way to do multiple value return? (Was: PS test failures in 7be9b45)

[Daniel Gackle]

< It wouldn't work for calling JavaScript functions that used the
arguments pseudo-array, either for arbitrary arity or for passing
arguments on. There's lots of JS functions around that do things like
foo.apply(null, slice(arguments, x)) or whatever. >

True, but PS already imposes Lisp lambda-list semantics on the
arguments pseudo-array. Functions that manipulate it (other than for
just passing arguments on) will break on things like &key params if
they don't interpret them correctly. So I'm not sure that the price
here isn't one we've already had to pay, and if that's true then it
hasn't turned out to be much of a problem.

I'd be interested to see examples that break on the implicit MV arg
that don't already break on &key. Passing the arguments pseudo-array
on, for example, shouldn't break. It just throws the responsibility
for parsing the MV arg on to somebody else, which in non-MV-aware
cases will typically ignore it and in MV-aware cases will handle it
according to the protocol.

It strikes me that the implicit MV arg is a generalization of the &key
mechanism where the key is not a symbol (string) but a sentinel
object. The big break with current practice is that it's hidden rather
than specified by the user at the source level. Makes me wonder if a
different syntax than MULTIPLE-VALUE-BIND might help - something to
make the underlying mechanism less unexpected...

To be sure, it's a hack and not at all what one would do with proper
access to the internals. But I wonder if it's as good as we're likely
to get by way of a correct implementation.


On Sun, Sep 2, 2012 at 6:28 PM, Vladimir Sedach <vsedach at gmail.com> wrote:

> > We may have crossed a wire here. When you said, "You can do that with
> > a global table instead of setting a property on the function object,"
> > I thought you had in mind a global table keyed by function *name*,
> > which is why I asked about lambdas since they have no names. JS won't
> > let you use a function object as a key so one would have to concoct
> > some naming scheme.
>
> For my first prototype for the new MV mechanism, that's what I thought
> and used gensyms. But then I tried foo[<function object>] and that
> works in both FF and CL-JS. But looking at ECMAScript, property
> identifiers do indeed have to be JavaScript String objects
> (http://ecma-international.org/ecma-262/5.1/#sec-8.10).
>
> > Moreover, if it worked for MV, the sentinel idea could be used to tag
> > anything else we wanted into the call. Seems like that could be pretty
> > powerful.
> >
> > Where does this break?
>
> It wouldn't work for calling JavaScript functions that used the
> arguments pseudo-array, either for arbitrary arity or for passing
> arguments on. There's lots of JS functions around that do things like
> foo.apply(null, slice(arguments, x)) or whatever.
>
> > p.s. There's also a way to communicate exactly how many return values
> > are desired, short-circuiting any computation that might be needed to
> > generate the full VALUES list. (I think this point is independent of
> > the above idea but I'll adapt the same examples.) Suppose we have:
>
> In general you have to evaluate all the expressions given to values
> for their side-effects, so this would only save a few assignments.
>
> Vladimir
>
> _______________________________________________
> parenscript-devel mailing list
> parenscript-devel at common-lisp.net
> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/parenscript-devel/attachments/20120902/5f5dc35a/attachment.html>