Group Email Manager

login signup
[Scheme-reports] practical matters - CSAN Alex Shinn (23 Aug 2011 02:31 UTC)
Re: practical matters - CSAN Arthur A. Gleckler (23 Aug 2011 02:59 UTC)
Re: [Scheme-reports] practical matters - CSAN John Cowan (23 Aug 2011 04:57 UTC)
Re: [Scheme-reports] practical matters - CSAN Aubrey Jaffer (23 Aug 2011 21:55 UTC)
Re: [Scheme-reports] practical matters - CSAN Alex Shinn (24 Aug 2011 00:09 UTC)
Re: [Scheme-reports] practical matters - CSAN John Cowan (24 Aug 2011 01:17 UTC)
Re: [Scheme-reports] practical matters - CSAN Alex Shinn (24 Aug 2011 01:58 UTC)
Re: [Scheme-reports] practical matters - CSAN Aubrey Jaffer (27 Aug 2011 02:58 UTC)
Re: [Scheme-reports] practical matters - CSAN John Cowan (28 Aug 2011 04:41 UTC)
Re: [Scheme-reports] practical matters - CSAN Aubrey Jaffer (29 Aug 2011 16:19 UTC)
Re: [Scheme-reports] practical matters - CSAN Aaron W. Hsu (29 Aug 2011 16:31 UTC)
Re: [Scheme-reports] practical matters - CSAN Aubrey Jaffer (07 Sep 2011 00:19 UTC)
Re: [Scheme-reports] practical matters - CSAN Aubrey Jaffer 29 Aug 2011 16:16 UTC 
 | Date: Sat, 27 Aug 2011 23:58:19 -0400
 | From: John Cowan <cowan@mercury.ccil.org>
 |
 | Aubrey Jaffer scripsit:
 |
 | > 9 of the 27 use scanf, which should be refactored to be macro-free.
 |
 | It's non-hygienic, so yes.

The procedural part of the SCANF module is SCANF-READ-LIST, which
takes a format-string and input-port or string as arguments and
returns a list of objects read.  Reading proceeds as far as the input
matches the format-string.

This would seem like a good application for multiple-value returns:
SCANF-READ would return the number of format directives matched
followed by the objects read.  But LET-VALUES, LET*-VALUES, and
(srfi-8) RECEIVE expect the number of bindings to match the number of
return values.  They can't be used if the number of return values is
not known in advance.

So SCANF-READ must be used with CALL-WITH-VALUES; which is little help
with destructuring the list of values.  The VALUES constructs have
been disappointing because their use is not simpler or more powerful
than using LIST and APPLY.

CASE-LAMBDA can be used if the desired behavior changes radically with
different numbers of values; but often there is a lot of commonality
in the procedure.  A shared internal definition can't be called
because CASE-LAMBDA is the outer binding of the definition.  So either
code must be replicated in each clause or each clause must call an
external procedure with all the arguments.

What would be helpful is something like:

  (BIND-VALUES
    <expression>
    ((<var1> [ <default-expression1> ])
     (<var2> [ <default-expression2> ])
     ...)
    <body>)

where <var1> gets bound to the first value returned by <expression>,
or to <default-expression1> if <expression> returned no values, or
signals an error if there is no <default-expression1>;
<var2> gets bound to the second value returned by <expression>, or to
<default-expression2> if <expression> returned fewer than 2 values, or
signals an error if there is no <default-expression2>, ...

 | > So 95% of SLIB would survive the transition to being macro-free.
 |
 | Excellent.
 |
 | > SRFI-96 could be amended or superseded.
 |
 | It would be good to know which of its procedures (if any) are no
 | longer needed.

The R7RS port of SLIB would drop the procedures:
  defmacro:eval
  defmacro:load
  macroexpand
  defmacro:expand*
  macro:expand

and would define:
  (define macro:eval slib:eval)
  (define macro:load slib:load)

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports