> 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.
If you call a function FOO with &key parameters you're expecting it to be a PS function, and if function FOO calls other functions they don't care. You can make the same argument for calling a function BAR expecting multiple values. Except as you point out the multiple-values array will now be passed on to any functions whose value BAR returns, which might or might not lead to subtle bugs. So I am really opposed to this approach. Vladimir > 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 <[email protected]> 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 >> [email protected] >> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel > > > > _______________________________________________ > parenscript-devel mailing list > [email protected] > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel > _______________________________________________ parenscript-devel mailing list [email protected] http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
