r6rs incompatibilities

r6rs incompatibilities

[Andy Wingo]

Hi,

While I'm thinking about it, I thought I'd mention a couple of
incompatibilities between Guile and R6RS:

 * In r6rs, internal definitions expand to letrec*, not letrec. Guile
   does not support letrec*, though that would be nice.

 * The R6RS specifies many situations in which a conforming
   implementation must signal a specific error. Guile doesn't really
   care about that too much -- if a correct R6RS program would not hit
   that error, we don't bother checking for it.

 * Multiple `library' forms in one file are not yet supported. This is
   because the expansion of `library' sets the current module, but does
   not restore it. This is a bug I think.

 * I'm sure there are other points -- please test and reply :)

Andy
-- 
http://wingolog.org/

Re: r6rs incompatibilities

[Julian Graham]

Hey Andy,


>  * The R6RS specifies many situations in which a conforming
>   implementation must signal a specific error. Guile doesn't really
>   care about that too much -- if a correct R6RS program would not hit
>   that error, we don't bother checking for it.

In a lot of these cases, that's because our libraries simply re-export
bindings from Guile's core library or an SRFI.  Instead of changing
the error-signaling of the original procedures, we could wrap them a
bit more in the relevant libraries to add argument validation, say, or
to re-throw Guile's core errors as R6RS exceptions.


Regards,
Julian

Re: r6rs incompatibilities

[Andy Wingo]

Hi,

On Fri 21 May 2010 14:47, Julian Graham <joolean@gmail.com> writes:

>>  * The R6RS specifies many situations in which a conforming
>>   implementation must signal a specific error. Guile doesn't really
>>   care about that too much -- if a correct R6RS program would not hit
>>   that error, we don't bother checking for it.
>
> In a lot of these cases, that's because our libraries simply re-export
> bindings from Guile's core library or an SRFI.  Instead of changing
> the error-signaling of the original procedures, we could wrap them a
> bit more in the relevant libraries to add argument validation, say, or
> to re-throw Guile's core errors as R6RS exceptions.

Sure; we'll probably take them case-by-case, accomodating where it makes
sense and documenting the incompatibility where it doesn't. It's not
like Guile's exception protocol is particularly well-thought-out :P

Andy
-- 
http://wingolog.org/

Re: r6rs incompatibilities

[Julian Graham]

[-- Attachment #1: Type: text/plain, Size: 483 bytes --]

Hello again!


>  * I'm sure there are other points -- please test and reply :)

Indeed!

One thing I noticed while look at Andreas' `wak' project is that the
use of `#!r6rs' seems to be pretty common, which conflicts with
Guile's support for SCSH-style block comments.  Find attached a
(somewhat inelegant) patch that adds support for the `#!r6rs' lexeme
in the default reader.  (What do people think about this?  Is there a
better way to do it?)


Regards,
Julian

[-- Attachment #2: 0001-Support-for-the-r6rs-lexeme.patch --]
[-- Type: text/x-diff, Size: 2729 bytes --]

From f1af40142b47232e726cbe9f7bdc35d5fbf45602 Mon Sep 17 00:00:00 2001
From: Julian Graham <julian.graham@aya.yale.edu>
Date: Sun, 23 May 2010 11:24:59 -0400
Subject: [PATCH] Support for the #!r6rs lexeme.

* libguile/read.c (scm_read_shebang): New function;
  (scm_read_sharp): Call scm_read_shebang on '!', which delegates to
  scm_read_scsh_block_comment as necessary.
---
 libguile/read.c |   39 +++++++++++++++++++++++++++++++++++++--
 1 files changed, 37 insertions(+), 2 deletions(-)

diff --git a/libguile/read.c b/libguile/read.c
index c54fbb6..d169167 100644
--- a/libguile/read.c
+++ b/libguile/read.c
@@ -189,6 +189,7 @@ static SCM *scm_read_hash_procedures;
 static inline SCM scm_read_scsh_block_comment (scm_t_wchar, SCM);
 static SCM scm_read_r6rs_block_comment (scm_t_wchar, SCM);
 static SCM scm_read_commented_expression (scm_t_wchar, SCM);
+static SCM scm_read_shebang (scm_t_wchar, SCM);
 static SCM scm_get_hash_procedure (int);
 
 /* Read from PORT until a delimiter (e.g., a whitespace) is read.  Put the
@@ -309,7 +310,7 @@ flush_ws (SCM port, const char *eoferr)
 	    eoferr = "read_sharp";
 	    goto goteof;
 	  case '!':
-	    scm_read_scsh_block_comment (c, port);
+	    scm_read_shebang (c, port);
 	    break;
 	  case ';':
 	    scm_read_commented_expression (c, port);
@@ -1109,6 +1110,40 @@ scm_read_scsh_block_comment (scm_t_wchar chr, SCM port)
   return SCM_UNSPECIFIED;
 }
 
+static inline SCM
+scm_read_shebang (scm_t_wchar chr, SCM port)
+{
+  int c = 0;
+  if ((c = scm_get_byte_or_eof (port)) != 'r')
+    {
+      scm_ungetc (c, port);
+      return scm_read_scsh_block_comment (chr, port);
+    }
+  if ((c = scm_get_byte_or_eof (port)) != '6')
+    {
+      scm_ungetc (c, port);
+      scm_ungetc ('r', port);
+      return scm_read_scsh_block_comment (chr, port);
+    }
+  if ((c = scm_get_byte_or_eof (port)) != 'r')
+    {
+      scm_ungetc (c, port);
+      scm_ungetc ('6', port);
+      scm_ungetc ('r', port);
+      return scm_read_scsh_block_comment (chr, port);
+    }
+  if ((c = scm_get_byte_or_eof (port)) != 's')
+    {
+      scm_ungetc (c, port);
+      scm_ungetc ('r', port);
+      scm_ungetc ('6', port);
+      scm_ungetc ('r', port);
+      return scm_read_scsh_block_comment (chr, port);
+    }
+  
+  return SCM_UNSPECIFIED;
+}
+
 static SCM
 scm_read_r6rs_block_comment (scm_t_wchar chr, SCM port)
 {
@@ -1323,7 +1358,7 @@ scm_read_sharp (scm_t_wchar chr, SCM port)
     case '{':
       return (scm_read_extended_symbol (chr, port));
     case '!':
-      return (scm_read_scsh_block_comment (chr, port));
+      return (scm_read_shebang (chr, port));
     case ';':
       return (scm_read_commented_expression (chr, port));
     case '`':
-- 
1.7.0.4

Re: r6rs incompatibilities

[Mike Gran]

> From: Julian Graham joolean@gmail.com

> One thing I noticed while look at Andreas' `wak' project is that the
> use of `#!r6rs' seems to be pretty common, which conflicts with
> Guile's support for SCSH-style block comments.  Find attached a
> (somewhat inelegant) patch that adds support for the `#!r6rs' lexeme
> in the default reader.  (What do people think about this?  Is there a
> better way to do it?)

What happens with this patch if the file only contains the four
characters "#!r6" followed by EOF?  Does it behave appropriately
after calling scm_ungetc on EOF?  (I guess that would make it an 
unterminated hash bang comment.)

Thanks,
Mike

Re: r6rs incompatibilities

[Julian Graham]

Hi Mike,


> What happens with this patch if the file only contains the four
> characters "#!r6" followed by EOF?  Does it behave appropriately
> after calling scm_ungetc on EOF?  (I guess that would make it an
> unterminated hash bang comment.)

If the fifth character is EOF instead of 'r', control is handed to
scm_read_scsh_block_comment (after ungetting EOF), which raises the
appropriate unterminated comment error.


Regards,
Julian

Re: r6rs incompatibilities

[Andy Wingo]

Hi Julian,

On Sun 23 May 2010 19:24, Julian Graham <joolean@gmail.com> writes:

>> What happens with this patch if the file only contains the four
>> characters "#!r6" followed by EOF?  Does it behave appropriately
>> after calling scm_ungetc on EOF?  (I guess that would make it an
>> unterminated hash bang comment.)
>
> If the fifth character is EOF instead of 'r', control is handed to
> scm_read_scsh_block_comment (after ungetting EOF), which raises the
> appropriate unterminated comment error.

If you add a test case I'm fine with this solution; though I would
prefer it to be read as #:r6rs.

We could make this more general, as the r7 committees are wont to do: if
#! is followed by whitespace or /, then read as a block comment;
otherwise read one token. In our case, we would read #!foo as #:foo. I
don't think this change would affect anyone. What do you think?

Andy
-- 
http://wingolog.org/

Re: r6rs incompatibilities

[Andy Wingo]

On Sun 23 May 2010 22:52, Andy Wingo <wingo@pobox.com> writes:

> We could make this more general, as the r7 committees are wont to do: if
> #! is followed by whitespace or /, then read as a block comment;
> otherwise read one token. In our case, we would read #!foo as #:foo. I
> don't think this change would affect anyone. What do you think?

Note that there are a couple of other #! constructs being considered for
scheme 7, for example to control case folding. It seems more or less
sensible. Perhaps we should read these as directives, and not as datums
at all.

There is also the possibility of introducing a reader option for this
behavior.

Andy
-- 
http://wingolog.org/

Re: r6rs incompatibilities

[Julian Graham]

Hey Andy,

>> We could make this more general, as the r7 committees are wont to do: if
>> #! is followed by whitespace or /, then read as a block comment;
>> otherwise read one token. In our case, we would read #!foo as #:foo. I
>> don't think this change would affect anyone. What do you think?
>
> Note that there are a couple of other #! constructs being considered for
> scheme 7, for example to control case folding. It seems more or less
> sensible. Perhaps we should read these as directives, and not as datums
> at all.
>
> There is also the possibility of introducing a reader option for this
> behavior.


Any chance we could go with my (admittedly sloppy) approach (or
something equally as quick) in the short term, and then, as they say
in the 'biz, "iterate?"  The above sounds sweet, but it seems like
it'd make more sense to tackle those things post-2.0.


Regards,
Julian

Re: r6rs incompatibilities

[Andy Wingo]

On Wed 26 May 2010 15:02, Julian Graham <joolean@gmail.com> writes:

>>> We could make this more general, as the r7 committees are wont to do: if
>>> #! is followed by whitespace or /, then read as a block comment;
>>> otherwise read one token. In our case, we would read #!foo as #:foo. I
>>> don't think this change would affect anyone. What do you think?
>>
>> Note that there are a couple of other #! constructs being considered for
>> scheme 7, for example to control case folding. It seems more or less
>> sensible. Perhaps we should read these as directives, and not as datums
>> at all.
>>
>> There is also the possibility of introducing a reader option for this
>> behavior.
>
> Any chance we could go with my (admittedly sloppy) approach (or
> something equally as quick) in the short term, and then, as they say
> in the 'biz, "iterate?"  The above sounds sweet, but it seems like
> it'd make more sense to tackle those things post-2.0.

Heh, sure. But don't make it return SCM_UNSPECIFIED, please; make it
treat #!r6rs as a comment. See
http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-7.html#node_sec_4.2.3.

Andy
-- 
http://wingolog.org/

Re: r6rs incompatibilities

[Ludovic Courtès]

Hi,

Andy Wingo <wingo@pobox.com> writes:

> On Wed 26 May 2010 15:02, Julian Graham <joolean@gmail.com> writes:
>
>>>> We could make this more general, as the r7 committees are wont to do: if
>>>> #! is followed by whitespace or /, then read as a block comment;
>>>> otherwise read one token. In our case, we would read #!foo as #:foo. I
>>>> don't think this change would affect anyone. What do you think?
>>>
>>> Note that there are a couple of other #! constructs being considered for
>>> scheme 7, for example to control case folding. It seems more or less
>>> sensible. Perhaps we should read these as directives, and not as datums
>>> at all.
>>>
>>> There is also the possibility of introducing a reader option for this
>>> behavior.
>>
>> Any chance we could go with my (admittedly sloppy) approach (or
>> something equally as quick) in the short term, and then, as they say
>> in the 'biz, "iterate?"  The above sounds sweet, but it seems like
>> it'd make more sense to tackle those things post-2.0.
>
> Heh, sure. But don't make it return SCM_UNSPECIFIED, please; make it
> treat #!r6rs as a comment. See
> http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-7.html#node_sec_4.2.3.

Functions that read comments all return ‘SCM_UNSPECIFIED’, which allows
them to be distinguished by the main loop.

Thanks,
Ludo’.

Re: r6rs incompatibilities

[Andy Wingo]

Hi :)

On Wed 26 May 2010 18:43, ludo@gnu.org (Ludovic Courtès) writes:

>> Heh, sure. But don't make it return SCM_UNSPECIFIED, please; make it
>> treat #!r6rs as a comment. See
>> http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-7.html#node_sec_4.2.3.
>
> Functions that read comments all return ‘SCM_UNSPECIFIED’, which allows
> them to be distinguished by the main loop.

Ah good catch; apologies for not reading the code thoroughly enough.

Andy
-- 
http://wingolog.org/