[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Chicken-janitors] Re: #505: permit user-defined read-syntax to restart

From: Chicken Trac
Subject: [Chicken-janitors] Re: #505: permit user-defined read-syntax to restart the reader
Date: Tue, 22 Feb 2011 15:53:48 -0000

#505: permit user-defined read-syntax to restart the reader
  Reporter:  zbigniew        |       Owner:  zbigniew             
      Type:  enhancement     |      Status:  new                  
  Priority:  minor           |   Milestone:  4.7.0                
 Component:  core libraries  |     Version:  4.6.x                
Resolution:                  |    Keywords:  don't fear the reader

Comment(by zbigniew):

 Replying to [comment:3 felix]:
 > Actually I think the 0-values variant is simpler and doesn't need yet
 another library procedure. I understand that it is painful to use a CL
 idiom, a dark spot on the shining architectural awesomeness of CHICKEN.

 More inefficient than ugly, IMO.
 I think you might look at it like this: if you had from the start designed
 reader macros to be capable of restarting the reader, how would you have
 done it?  Would you have passed a continuation argument, like I did in the
 second version?  If so, you could consider the new library procedures to
 be correcting an API defect, and deprecate the old ones.  Or, given that
 only six eggs use user-defined read-syntax, we could change the existing
 API and use a compile-time feature test in them to determine when the
 extra argument should be expected.  (Or change everything to expect an
 #!optional restart argument and defer the test until runtime.)

 If the values solution appeals to you more, then by all means use it.  But
 I will need some way of testing the restart feature availability either
 way: returning (values) from a reader macro on existing Chicken will
 produce illegal code (atomic #<unspecified> value, as when returning

Ticket URL: <>
Chicken Scheme <>
Chicken Scheme is a compiler for the Scheme programming language.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]