Re: [Chicken-hackers] Fix

2017-04-14 Thread Peter Bex
On Fri, Apr 14, 2017 at 04:40:36PM +0200, Moritz Heidkamp wrote:
> Hi everyone,
> 
> char-ready? on string input ports would return #f when they've reached
> the end of their underlying string. However, char-ready? is supposed to
> return #t in this case. The attached patch fixes this and adds a
> corresponding regression test. It applies to both master and chicken-5.

Nice find, thanks!  I've pushed it to both branches and added a NEWS
entry, because this is a pretty important fix.

We should keep an eye on Salmonella to see if any eggs inadvertently rely
on this broken behaviour.

Cheers,
Peter


signature.asc
Description: Digital signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers


Re: [Chicken-hackers] Fix

2017-04-14 Thread John Cowan
On Fri, Apr 14, 2017 at 10:40 AM, Moritz Heidkamp <
moritz.heidk...@bevuta.com> wrote:

char-ready? on string input ports would return #f when they've reached
> the end of their underlying string. However, char-ready? is supposed to
> return #t in this case.
>

Yes.  The semantics of char-ready? is that it returns #f if there are no
characters available now, but there might be some available in future.  In
particular, at EOF there is always an EOF object available.

-- 
John Cowan  http://vrici.lojban.org/~cowanco...@ccil.org
Schlingt dreifach einen Kreis vom dies!
Schliesst euer Aug vor heiliger Schau,
Denn er genoss vom Honig-Tau,
Und trank die Milch vom Paradies.
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers


[Chicken-hackers] [PATCH] Fix #1362 and simplify macro-renaming a bit

2017-04-14 Thread Peter Bex
Hi all,

This ticket was reported a few days ago, and it's a reasonably easy fix.
When looking up an identifier, we look it up in the current syntactic
environment (SE) and if that fails, we check its '##core#macro-alias
property, if any, and return it.

This behaviour is fine when looking up identifiers: it may have been
renamed, so we need to look up its actual value.  But when renaming,
this is not fine, because that effectively _undoes_ the rename (if
it was renamed before).  So instead of using "lookup", rename now
performs just the alist lookup itself.

This bug affects master as well, so I think it's a good idea to fix
it there too (see attached patches, there was a small conflict so
I added patches for both versions).

Cheers,
Peter
From 05df2f8fdb852ee3ce6f20857ee41a4f57ceef9d Mon Sep 17 00:00:00 2001
From: Peter Bex 
Date: Fri, 14 Apr 2017 16:49:54 +0200
Subject: [PATCH 1/2] Do not undo macro renaming when renaming twice.

The "lookup" procedure will try to look up the renamed identifier in
the syntax env and if that fails, it checks whether the looked-up
identifier is an alias of another identifier, in which case it
returns the original identifier.

This fallback behaviour causes problems when we rename an identifier
twice.  In normal use, that doesn't tend to happen (but it could).
When using IR macros, this happens all the time, because the input
form is completely renamed first, and then the output form is
reverse-renamed (renaming any "plain" identifiers in the process).
This behaviour will "collapse" any plain identifiers, so that, on the
reverse rename, they are mapped to the same identifier as those from
the input form.

This fixes ticket #1362, as found by Megane.
---
 NEWS   |  4 
 expand.scm | 10 +-
 tests/syntax-tests.scm | 30 ++
 3 files changed, 39 insertions(+), 5 deletions(-)

diff --git a/NEWS b/NEWS
index df1af55..e06bd79 100644
--- a/NEWS
+++ b/NEWS
@@ -9,6 +9,10 @@
   - Unit "posix": If file-lock, file-lock/blocking or file-unlock are
 interrupted by a signal, we now retry (thanks to Joerg Wittenberger).
 
+- Syntax expander
+  - Renaming an identifier twice no longer results in an undo of the
+rename (fixes #1362, thanks to "megane").
+
 - Build system
   - Fixed broken compilation on NetBSD, due to missing _NETBSD_SOURCE.
 
diff --git a/expand.scm b/expand.scm
index 8020be3..55e3107 100644
--- a/expand.scm
+++ b/expand.scm
@@ -243,7 +243,7 @@
 	"syntax transformer for `" (symbol->string name)
 	"' returns original form, which would result in endless expansion")
 	   exp))
-	(dx `(,name --> ,exp2))
+	(dx `(,name ~~> ,exp2))
 	exp2)))
   (define (expand head exp mdef)
 (dd `(EXPAND: 
@@ -813,7 +813,7 @@
 		(lambda (a) 
 		  (dd `(RENAME/RENV: ,sym --> ,(cdr a)))
 		  (cdr a)))
-	   ((lookup sym se) => 
+	   ((assq sym se) =>
 		(lambda (a)
 		  (cond ((symbol? a)
 			 ;; Add an extra level of indirection for already aliased
@@ -822,15 +822,15 @@
 			 (cond ((or (getp a '##core#aliased)
 (getp a '##core#primitive))
 (let ((a2 (macro-alias sym se)))
-  (dd `(RENAME/LOOKUP/ALIASED: ,sym --> ,a ==> ,a2))
+  (dd `(RENAME/SE/ALIASED: ,sym --> ,a ==> ,a2))
   (set! renv (cons (cons sym a2) renv))
   a2))
-			   (else (dd `(RENAME/LOOKUP: ,sym --> ,a))
+			   (else (dd `(RENAME/SE: ,sym --> ,a))
  (set! renv (cons (cons sym a) renv))
  a)))
 			(else
 			 (let ((a2 (macro-alias sym se)))
-			   (dd `(RENAME/LOOKUP/MACRO: ,sym --> ,a2))
+			   (dd `(RENAME/SE/MACRO: ,sym --> ,a2))
 			   (set! renv (cons (cons sym a2) renv))
 			   a2)
 	   (else
diff --git a/tests/syntax-tests.scm b/tests/syntax-tests.scm
index 1004f71..e23f8af 100644
--- a/tests/syntax-tests.scm
+++ b/tests/syntax-tests.scm
@@ -1115,6 +1115,36 @@ take
 (import rename-builtins)
 (assert (eq? '* (strip-syntax-on-*)))
 
+;; #1362: Double rename would cause "renamed" var to be restored to
+;; the original macro aliased name (resulting in a plain symbol)
+(let-syntax ((wrapper/should-do-nothing
+  (er-macro-transformer
+   (lambda (e r c)
+ (let* ((%x (r 'x))
+(%%x (r %x)))
+   `(let ((,%x 1)
+  (,%%x 2))
+  ,(cadr e)))
+  (print (let ((x 1)) (wrapper/should-do-nothing x
+
+;; Same net effect as above, but more complex by the use of IR macros.
+(letrec-syntax ((bind-pair
+ (ir-macro-transformer
+  (lambda (e i c)
+(let* ((b (cadr e))
+   (exp (caddr e))
+   (body (cdddr e)))
+  `(let* ((x ,exp)
+  (,(car b) (car x))
+  (,(cadr b) (cdr x)))
+ ,@body)
+(foo
+ (ir-macro-transformer
+  (lambda (e

[Chicken-hackers] Fix

2017-04-14 Thread Moritz Heidkamp
Hi everyone,

char-ready? on string input ports would return #f when they've reached
the end of their underlying string. However, char-ready? is supposed to
return #t in this case. The attached patch fixes this and adds a
corresponding regression test. It applies to both master and chicken-5.

Cheers
Moritz
>From 0fb9dd6eb4f9380e6ef44cf4ee2030e1f11ef412 Mon Sep 17 00:00:00 2001
From: Moritz Heidkamp 
Date: Fri, 14 Apr 2017 16:22:39 +0200
Subject: [PATCH] Fix char-ready? on EOF for string input ports

char-ready? on string input ports would return #f when they've reached
the end of their underlying string. However, char-ready? is supposed
to return #t in this case.
---
 library.scm  | 3 +--
 tests/port-tests.scm | 2 ++
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/library.scm b/library.scm
index 3caba429..51d6793b 100644
--- a/library.scm
+++ b/library.scm
@@ -4255,8 +4255,7 @@ EOF
 	   (##sys#setislot p 10 (fx+ position len)) ) ) )
  void ; close
  (lambda (p) #f)			; flush-output
- (lambda (p)			; char-ready?
-   (fx< (##sys#slot p 10) (##sys#slot p 11)) )
+ (lambda (p) #t)			; char-ready?
  (lambda (p n dest start)		; read-string!
(let* ((pos (##sys#slot p 10))
 	  (n2 (fx- (##sys#slot p 11) pos) ) )
diff --git a/tests/port-tests.scm b/tests/port-tests.scm
index ec6a323b..463e31e6 100644
--- a/tests/port-tests.scm
+++ b/tests/port-tests.scm
@@ -42,6 +42,8 @@ EOF
   (read-line p)))
 (assert (= 20 (length (read-lines (open-input-string *text*)
 
+(assert (char-ready? (open-input-string "")))
+
 (let ((out (open-output-string)))
   (test-equal "Initially, output string is empty"
   (get-output-string out) "")
-- 
2.12.0

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers