[parenscript-devel] Skipping null returns at the top level.
Hi folks, I was wondering if there's an idiom for skipping the generation of a form completely at the top-level. This is mildly related to the implicit return feature currently being trialled. Here's an example: suppose I'm trying to skip over this form: (in-package :something-something) by using (defpsmacro in-package (x) nil) An in-package form then compiles to "null;" This spurious output may result in errors (I'm using ps to convert my Lisp code to Actionscript). How about using (values) to indicate explicitly that something doesn't have any return values? Yong.
I've also found that annoying about macros. I'm going to see what can be done. Vladimir 2010/1/26 szergling <senatorzergling@gmail.com>:
Hi folks,
I was wondering if there's an idiom for skipping the generation of a form completely at the top-level. This is mildly related to the implicit return feature currently being trialled. Here's an example: suppose I'm trying to skip over this form:
(in-package :something-something)
by using
(defpsmacro in-package (x) nil)
An in-package form then compiles to "null;"
This spurious output may result in errors (I'm using ps to convert my Lisp code to Actionscript).
How about using (values) to indicate explicitly that something doesn't have any return values?
Yong.
_______________________________________________ parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
On 1/27/10, Vladimir Sedach <vsedach@gmail.com> wrote:
I've also found that annoying about macros. I'm going to see what can be done.
Vladimir
Thank you. Look forward to it. By the way, I think implicit return is a very useful feature. Yong.
2010/1/26 szergling <senatorzergling@gmail.com>:
Hi folks,
I was wondering if there's an idiom for skipping the generation of a form completely at the top-level. This is mildly related to the implicit return feature currently being trialled. Here's an example: suppose I'm trying to skip over this form:
(in-package :something-something)
by using
(defpsmacro in-package (x) nil)
An in-package form then compiles to "null;"
This spurious output may result in errors (I'm using ps to convert my Lisp code to Actionscript).
How about using (values) to indicate explicitly that something doesn't have any return values?
Yong.
<<snip>>
I just pushed a patch that should do the right thing; take a look. Vladimir 2010/1/27 szergling <senatorzergling@gmail.com>:
On 1/27/10, Vladimir Sedach <vsedach@gmail.com> wrote:
I've also found that annoying about macros. I'm going to see what can be done.
Vladimir
Thank you. Look forward to it.
By the way, I think implicit return is a very useful feature.
Yong.
2010/1/26 szergling <senatorzergling@gmail.com>:
Hi folks,
I was wondering if there's an idiom for skipping the generation of a form completely at the top-level. This is mildly related to the implicit return feature currently being trialled. Here's an example: suppose I'm trying to skip over this form:
(in-package :something-something)
by using
(defpsmacro in-package (x) nil)
An in-package form then compiles to "null;"
This spurious output may result in errors (I'm using ps to convert my Lisp code to Actionscript).
How about using (values) to indicate explicitly that something doesn't have any return values?
Yong.
<<snip>>
_______________________________________________ parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
On 2/1/10, Vladimir Sedach <vsedach@gmail.com> wrote:
I just pushed a patch that should do the right thing; take a look.
That works, but the functionality is missing from ps-compile-stream (and therefore ps-compile-file), so I've added this too (see patch for inspiration, or if it's acceptable/modifiable, merge?). I also wonder if (in case I wasn't clear in my original email) this actually makes more "sense" for parenscript? (lambda () nil) => function () {return null;} (lambda () (values)) => function () { } (lambda () (values 1 2 3)) => function () { ok, nevermind??? } Not sure either way. I don't think my changes have broken anything in the meantime :) However, while all the tests passed, there's a warning too: Running other tests: ...........................................................................................................................................; in: LAMBDA NIL ; (PARENSCRIPT::PS-COMPILE PARENSCRIPT-TEST::X) ; ; caught WARNING: ; undefined variable: X ; ; compilation unit finished ; Undefined variable: ; X ; caught 1 WARNING condition ................................................................................. I could not hunt down (quickly) the cause of this warning, so I haven't done anything. Thanks for the good work! Yong
Vladimir
2010/1/27 szergling <senatorzergling@gmail.com>:
On 1/27/10, Vladimir Sedach <vsedach@gmail.com> wrote:
I've also found that annoying about macros. I'm going to see what can be done.
Vladimir
Thank you. Look forward to it.
By the way, I think implicit return is a very useful feature.
Yong.
2010/1/26 szergling <senatorzergling@gmail.com>:
Hi folks,
I was wondering if there's an idiom for skipping the generation of a form completely at the top-level. This is mildly related to the implicit return feature currently being trialled. Here's an example: suppose I'm trying to skip over this form:
(in-package :something-something)
by using
(defpsmacro in-package (x) nil)
An in-package form then compiles to "null;"
This spurious output may result in errors (I'm using ps to convert my Lisp code to Actionscript).
How about using (values) to indicate explicitly that something doesn't have any return values?
Hi Yong, On what forms does ps-compile-stream fail? I'm using this as a test: (with-input-from-string (s "(progn (defmacro macro-null-toplevel () nil) (macro-null-toplevel))") (ps-compile-stream s)) Vladimir 2010/2/3 szergling <senatorzergling@gmail.com>:
On 2/1/10, Vladimir Sedach <vsedach@gmail.com> wrote:
I just pushed a patch that should do the right thing; take a look.
That works, but the functionality is missing from ps-compile-stream (and therefore ps-compile-file), so I've added this too (see patch for inspiration, or if it's acceptable/modifiable, merge?).
I also wonder if (in case I wasn't clear in my original email) this actually makes more "sense" for parenscript?
(lambda () nil) => function () {return null;}
(lambda () (values)) => function () { }
(lambda () (values 1 2 3)) => function () { ok, nevermind??? }
Not sure either way.
I don't think my changes have broken anything in the meantime :) However, while all the tests passed, there's a warning too:
Running other tests: ...........................................................................................................................................; in: LAMBDA NIL ; (PARENSCRIPT::PS-COMPILE PARENSCRIPT-TEST::X) ; ; caught WARNING: ; undefined variable: X ; ; compilation unit finished ; Undefined variable: ; X ; caught 1 WARNING condition .................................................................................
I could not hunt down (quickly) the cause of this warning, so I haven't done anything.
Thanks for the good work!
Yong
Vladimir
2010/1/27 szergling <senatorzergling@gmail.com>:
On 1/27/10, Vladimir Sedach <vsedach@gmail.com> wrote:
I've also found that annoying about macros. I'm going to see what can be done.
Vladimir
Thank you. Look forward to it.
By the way, I think implicit return is a very useful feature.
Yong.
2010/1/26 szergling <senatorzergling@gmail.com>:
Hi folks,
I was wondering if there's an idiom for skipping the generation of a form completely at the top-level. This is mildly related to the implicit return feature currently being trialled. Here's an example: suppose I'm trying to skip over this form:
(in-package :something-something)
by using
(defpsmacro in-package (x) nil)
An in-package form then compiles to "null;"
This spurious output may result in errors (I'm using ps to convert my Lisp code to Actionscript).
How about using (values) to indicate explicitly that something doesn't have any return values?
_______________________________________________ parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
On 2/13/10, Vladimir Sedach <vsedach@gmail.com> wrote:
Hi Yong,
On what forms does ps-compile-stream fail? I'm using this as a test:
(with-input-from-string (s "(progn (defmacro macro-null-toplevel () nil) (macro-null-toplevel))") (ps-compile-stream s))
Vladimir
Hi Vladimir, You are quite right. I am mistaken. Sorry for the noise. I'm guessing that I had been misled by stale fasls. My best guess at the moment is that it is compilation-interface.fasl that depends on special-forms but comes before it in the .asd file. I cannot reproduce this since I've wiped my old directory. Could that have happened? Yong.
2010/2/3 szergling <senatorzergling@gmail.com>:
On 2/1/10, Vladimir Sedach <vsedach@gmail.com> wrote:
I just pushed a patch that should do the right thing; take a look.
That works, but the functionality is missing from ps-compile-stream (and therefore ps-compile-file), so I've added this too (see patch for inspiration, or if it's acceptable/modifiable, merge?).
<<snipped>>
On 2/16/10, szergling <senatorzergling@gmail.com> wrote:
On 2/13/10, Vladimir Sedach <vsedach@gmail.com> wrote:
Hi Yong,
On what forms does ps-compile-stream fail? I'm using this as a test:
(with-input-from-string (s "(progn (defmacro macro-null-toplevel () nil) (macro-null-toplevel))") (ps-compile-stream s))
Vladimir
Hi Vladimir,
You are quite right. I am mistaken. Sorry for the noise.
I'm guessing that I had been misled by stale fasls. My best guess at the moment is that it is compilation-interface.fasl that depends on special-forms but comes before it in the .asd file. I cannot reproduce this since I've wiped my old directory. Could that have happened?
Yong.
I'm quite confused now, so it's probably best to get independent verification. Here's the form I'm interested in. It's actually two forms (as when read in via ps-compile-file): (with-input-from-string (s " (defmacro macro-null-toplevel () nil) (macro-null-toplevel)") (ps-compile-stream s)) ==> "null" I'm hoping to get nothing here, as in Vladimir's original progn form. Compare (with-input-from-string (s "(progn (defmacro macro-null-toplevel () nil) (macro-null-toplevel))") (ps-compile-stream s)) ==> "" So perhaps I did see the null producing behaviour originally, after all :) Yong.
Thanks for pointing that out. PS-COMPILE-STREAM was doing things a little wrong. Just pushed a patch for that. I'm going to package up the next release from that. Vladimir 2010/2/19 szergling <senatorzergling@gmail.com>:
On 2/16/10, szergling <senatorzergling@gmail.com> wrote:
On 2/13/10, Vladimir Sedach <vsedach@gmail.com> wrote:
Hi Yong,
On what forms does ps-compile-stream fail? I'm using this as a test:
(with-input-from-string (s "(progn (defmacro macro-null-toplevel () nil) (macro-null-toplevel))") (ps-compile-stream s))
Vladimir
Hi Vladimir,
You are quite right. I am mistaken. Sorry for the noise.
I'm guessing that I had been misled by stale fasls. My best guess at the moment is that it is compilation-interface.fasl that depends on special-forms but comes before it in the .asd file. I cannot reproduce this since I've wiped my old directory. Could that have happened?
Yong.
I'm quite confused now, so it's probably best to get independent verification. Here's the form I'm interested in. It's actually two forms (as when read in via ps-compile-file):
(with-input-from-string (s " (defmacro macro-null-toplevel () nil) (macro-null-toplevel)") (ps-compile-stream s)) ==> "null"
I'm hoping to get nothing here, as in Vladimir's original progn form.
Compare
(with-input-from-string (s "(progn (defmacro macro-null-toplevel () nil) (macro-null-toplevel))") (ps-compile-stream s)) ==> ""
So perhaps I did see the null producing behaviour originally, after all :)
Yong.
_______________________________________________ parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
participants (2)
-
szergling -
Vladimir Sedach