Re: [Chicken-users] Strange problems with args egg
Thank you for the help! This is definitely a very interesting language
to learn.
On 08/03/2013 09:06 AM, John Cowan wrote:
Jonathan Chan scripsit:
Here is the smallest amount of args-using Chicken that will cause the
problem:
(define-syntax test
(syntax-rules ()
((test)
(begin
(define opts (list (args:make-option (h help) #:none "display
this text" (print "foo"
(write (args:parse (command-line-arguments) opts))
[...]
The strange thing is that h and help seem to have turned into ("h390"
"help391"), causing problems.
This is not a Chicken-specific problem, but a general problem
with non-hygienic macros. You are using the non-hygienic macro
"args:make-option" within a hygienic macro. The syntax-rules transformer
doesn't know that "h" and "help" are being used literally here (because
it cannot tell what args:make-option does), so it systematically renames
them to avoid collisions.
Is there something I need to change to fix the problem? Sorry for many
misunderstandings.
You can rewrite test as a non-hygienic (explicit renaming or implicit
renaming) macro.
--
Jonathan Chan
j...@fastmail.fm
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Strange problems with args egg
Did you try my patch? You don't have to rewrite anything, it's a bug in the
args egg.
On Aug 4, 2013, at 2:13 AM, Jonathan Chan wrote:
> Thank you for the help! This is definitely a very interesting language to
> learn.
>
> On 08/03/2013 09:06 AM, John Cowan wrote:
>> Jonathan Chan scripsit:
>>
>>> Here is the smallest amount of args-using Chicken that will cause the
>>> problem:
>>>
>>> (define-syntax test
>>> (syntax-rules ()
>>> ((test)
>>> (begin
>>>(define opts (list (args:make-option (h help) #:none "display
>>>this text" (print "foo"
>>>(write (args:parse (command-line-arguments) opts))
>>>
>> [...]
>>
>>> The strange thing is that h and help seem to have turned into ("h390"
>>> "help391"), causing problems.
>> This is not a Chicken-specific problem, but a general problem
>> with non-hygienic macros. You are using the non-hygienic macro
>> "args:make-option" within a hygienic macro. The syntax-rules transformer
>> doesn't know that "h" and "help" are being used literally here (because
>> it cannot tell what args:make-option does), so it systematically renames
>> them to avoid collisions.
>>
>>> Is there something I need to change to fix the problem? Sorry for many
>>> misunderstandings.
>> You can rewrite test as a non-hygienic (explicit renaming or implicit
>> renaming) macro.
>>
>
> --
> Jonathan Chan
> j...@fastmail.fm
>
>
> ___
> Chicken-users mailing list
> Chicken-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/chicken-users
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] scrutinizer warning in dotted argument notation when using units
Hi! I noticed this warning using the latest version from master: ;test.scm (use data-structures) (flatten '(1 2 3) '(4 5 6) '(7)) [hugo@io test]$ csc test.scm Warning: at toplevel: (test.scm:3) in procedure call to `flatten', expected 1 argument, but was given 3 arguments Is also easily reproducible with any file included as unit, declaring a procedure using dotted argument notation. This is not happening if the procedure is defined in the same file. I'm not sure why. I take a look at scrutinizer.scm just to learn how it works, and I'm sending a patch, but I'm not sure if its correct. (Also, if someone is in teaching mood: 1) debugging the scrutinizer I found sometimes procedures or vars are replaced with '*, what does it means? 2) if someone figures out.. why is this not happening on procedures in the same file? ) Regards, Hugo scrutinizer.patch Description: Binary data ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] scrutinizer warning in dotted argument notation when using units
On Sun, Aug 04, 2013 at 01:50:06PM -0300, Hugo Arregui wrote:
> Hi!
Hi!
> I noticed this warning using the latest version from master:
>
> ;test.scm
> (use data-structures)
> (flatten '(1 2 3) '(4 5 6) '(7))
>
> [hugo@io test]$ csc test.scm
>
> Warning: at toplevel:
> (test.scm:3) in procedure call to `flatten', expected 1 argument,
> but was given 3 arguments
>
> Is also easily reproducible with any file included as unit, declaring
> a procedure using dotted argument notation. This is not happening if
> the procedure is defined in the same file. I'm not sure why.
I don't understand what you mean by the above. Can you produce a simple
test situation?
> I take a look at scrutinizer.scm just to learn how it works, and I'm
> sending a patch, but I'm not sure if its correct.
I'm not 100% sure but it looks like your patch causes it to simply stop
processing argument type declarations altogether as soon as it encounters
a pair.
For example, if you have a procedure of (boolean fixnum pair flonum vector),
it would see it as if it were declared as (boolean fixnum).
> (Also, if someone is in teaching mood:
> 1) debugging the scrutinizer I found sometimes procedures or vars are
> replaced with '*, what does it means?
* is the "any" or "unknown" type. Anything will match it. It's basically
used when you don't know the type of a value.
> 2) if someone figures out.. why is this not happening on procedures in
> the same file? )
A test would be useful.
I've just pushed the attached patch to master: the problem was actually
simply in the type definition for flatten; it accepts any number of
arguments which may be of any type, but it was declared as accepting only
one argument, which had to be a pair.
Cheers,
Peter
--
http://www.more-magic.net
>From a647d9ed65f44df527e513464093447f56e24ead Mon Sep 17 00:00:00 2001
From: felix
Date: Thu, 1 Aug 2013 11:52:57 +0200
Subject: [PATCH] Adds "letrec*" and minimal tests. "letrec*" ist not used
explicitly and only in internal expansions to avoid bootstrapping issues.
Internal defines expand into uses of "letrec*".
Signed-off-by: Peter Bex
---
NEWS | 2 ++
chicken-syntax.scm | 11 ++-
compiler.scm | 21 -
eval.scm | 19 ++-
expand.scm | 11 ++-
extras.scm | 2 +-
manual/Non-standard macros and special forms | 7 +++
tests/syntax-tests.scm | 16
8 files changed, 80 insertions(+), 9 deletions(-)
diff --git a/NEWS b/NEWS
index 2d9ab2b..4d96844 100644
--- a/NEWS
+++ b/NEWS
@@ -25,6 +25,8 @@
- For R7RS compatibility, named character literals #\escape and #\null are
supported as aliases for #\esc and #\nul. WRITE will output R7RS names.
- The CASE form accepts => proc syntax, like COND (as specified by R7RS).
+ - letrec* was added for R7RS compatibility. Plain letrec no longer behaves
+like letrec*.
- Compiler
- the "inline" declaration does not force inlining anymore as recursive
diff --git a/chicken-syntax.scm b/chicken-syntax.scm
index ce1bdf6..29ed89d 100644
--- a/chicken-syntax.scm
+++ b/chicken-syntax.scm
@@ -422,6 +422,7 @@
`(,%let-values (,(car vbindings))
,(fold (cdr vbindings))) ) )
+;;XXX do we need letrec*-values ?
(##sys#extend-macro-environment
'letrec-values '()
(##sys#er-transformer
@@ -1056,11 +1057,11 @@
(##sys#check-syntax 'rec form '(_ _ . _))
(let ((head (cadr form)))
(if (pair? head)
- `(##core#letrec ((,(car head)
- (##core#lambda ,(cdr head)
- ,@(cddr form
- ,(car head))
- `(##core#letrec ((,head ,@(cddr form))) ,head))
+ `(##core#letrec* ((,(car head)
+(##core#lambda ,(cdr head)
+ ,@(cddr form
+ ,(car head))
+ `(##core#letrec* ((,head ,@(cddr form))) ,head))
;;; Definitions available at macroexpansion-time:
diff --git a/compiler.scm b/compiler.scm
index 3cadc6b..0398eef 100644
--- a/compiler.scm
+++ b/compiler.scm
@@ -105,6 +105,7 @@
; (##core#let ({( )}) )
; (##core#let ({( )}) )
; (##core#letrec ({( )}) )
+; (##core#letrec* ({( )}) )
; (##core#let-location [] )
; (##core#lambda )
; (##core#lambda ({}+ [. ]) )
@@ -616,7 +617,7 @@
(append aliases e)
se2 dest ldest h ln) ) ) )
- ((##core#letrec)
+ ((##core#letrec*)
(let ((bindings (cadr x))
(body (cddr x)) )
(walk
@@ -630,6 +631,24 @@
