[parenscript-devel] Implicit returns

Red Daly reddaly at gmail.com
Sat Oct 10 16:29:43 UTC 2009


On Sat, Oct 10, 2009 at 9:25 AM, Daniel Gackle <danielgackle at gmail.com>wrote:

> It sounds like other people want this too. Perhaps its time has come!
>

Hear, hear.

-Red


> Failing to add return is a bug that bites us often, and sometimes takes a
> while to track down, since the problem can show up in a different part of
> the program as "foo is undefined" (where foo was supposed to be the return
> value of some function).
>
> We have many thousands of lines of generated JS with lots of returns in it,
> which makes for a good regression test for whether a major change like this
> has worked or not. The JS shouldn't change much, if at all. If other people
> would also do before-and-after diffs on their codebases, that would be a
> good way to verify whether implicit return is actually working.
>
> < Though maybe there should be a policy for these incompatible changes >
>
> Yes, there probably should. Personally I'd be fine with a special variable
> to turn something like this on or off. A compromise might be to support both
> modes for a couple of major releases and then phase out the old way. I'm
> just thinking out loud here.
>
>
>
>
> On Sat, Oct 10, 2009 at 5:39 AM, John Fremlin <not at just.any.name> wrote:
>
>> Daniel Gackle <danielgackle at gmail.com> writes:
>> [...]
>> > Vladimir, have you ever thought of or tried to get RETURN out of PS?
>> What are
>> > the main challenges?
>>
>> The lack of implicit return is something that always trips me up writing
>> parenscript. I think it would be a good idea. (Though maybe there should
>> be a policy for these incompatible changes :-)
>>
>> It is a bit of effort to implement completely (i.e. marking the last
>> form in a defun or lambda to be a returning form, and transforming it to
>> use return if it doesn't already), because you would have to figure out
>> how to push a return through each special form (e.g. if).
>>
>> But it sounds feasible . . .
>>
>> Related to the impedance mismatch between Lisp's view of expressions and
>> statements as the same thing and JavaScript's balkanisation of the
>> concepts.
>>
>> [...]
>>
>>
>
> _______________________________________________
> parenscript-devel mailing list
> parenscript-devel at common-lisp.net
> http://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/20091010/2ae7cd3c/attachment.html>


More information about the parenscript-devel mailing list