readable-discuss — Discuss methods to improve readability of s-expressions for code

Re: [Readable-discuss] New Release?

[Alan M. G. <alm...@gm...>]

On 2/13/14, "Jörg F. Wittenberger" <Joe...@so...> wrote:
>
> Am 13.02.2014 09:50, schrieb Alan Manuel Gloria:
>> I'm kinda sorta vaguely planning on a Scheme implementation which has
>> STM at its core (basically, all non-transactional mutations are
>> implicitly considered to be inside tiny transactions containing only
>> that mutation).
>
> Have you seen http://ball.askemos.org ?

Err..... not really, and it's a bit more large-scale than what I had in mind.

>
> Your idea reminds me so much to our reasoning.  Just because our
> transactional memory was known to be horribly slow, we decided to have
> two complementary Scheme-alike languages: one without any side effects
> (no effects to be handled in STM, zero overhead) and one sub-language
> having only the effects.  ((Though to distinguish them we chose to
> express the latter in "long-wielded-s-expressions" a.k.a. "XML".))
>
> I'm pretty interested in your plans and progess.  Please keep me posted.

It strikes me that the separation of purity and impurity here is
almost precisely what Haskell does with the separation of the "actual"
language and the IO data type.  Truly pure functions return an IO
object, which can be combined in specific ways with other IO objects
(and with pure functions that return an IO object - for example, a
"read character" IO object can be combined with a pure function that
accepts a character and returns another IO object, forming a larger IO
object that reads a character and then does some other IO action in
response to that character).

Which is a rather big digression from readable lisps, haha.

In any case, my (vague) plan is a relatively simple R7RS compiler,
with everything as a transaction (both mutations and reads), and the
possibility to combine multiple transactions into a larger
transaction.  I/O is a bit mind-bending, so I'll go with "not a
transaction, and will throw an error if you put in a transaction,"
which is the default handling in pretty much every STM implementation
I've seen.

Sincerely,
AmkG

>
> /Jörg
>
>>    If ever, it will of course have SRFI-105 by default
>> and SRFI-110 on #!sweet.
>>
>
>
> ------------------------------------------------------------------------------
> Android apps run on BlackBerry 10
> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> Get your Android app in front of a whole new audience.  Start now.
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
> _______________________________________________
> Readable-discuss mailing list
> Rea...@li...
> https://lists.sourceforge.net/lists/listinfo/readable-discuss
>

Re: [Readable-discuss] New Release?

[Jörg F. W. <Joe...@so...>]

Am 13.02.2014 14:18, schrieb Alan Manuel Gloria:
> On 2/13/14, "Jörg F. Wittenberger" <Joe...@so...> wrote:
>> Am 13.02.2014 09:50, schrieb Alan Manuel Gloria:
>>> I'm kinda sorta vaguely planning on a Scheme implementation which has
>>> STM at its core (basically, all non-transactional mutations are
>>> implicitly considered to be inside tiny transactions containing only
>>> that mutation).
>> Have you seen http://ball.askemos.org ?
> Err..... not really, and it's a bit more large-scale than what I had in mind.

Yes, it certainly is.  Nevertheless the idea is, that the 
fault-tolerant, replicated state is some kind of STM.

>
>> Your idea reminds me so much to our reasoning.  Just because our
>> transactional memory was known to be horribly slow, we decided to have
>> two complementary Scheme-alike languages: one without any side effects
>> (no effects to be handled in STM, zero overhead) and one sub-language
>> having only the effects.  ((Though to distinguish them we chose to
>> express the latter in "long-wielded-s-expressions" a.k.a. "XML".))
>>
>> I'm pretty interested in your plans and progess.  Please keep me posted.
> It strikes me that the separation of purity and impurity here is
> almost precisely what Haskell does with the separation of the "actual"
> language and the IO data type.

In a way yes.

> In any case, my (vague) plan is a relatively simple R7RS compiler,
> with everything as a transaction (both mutations and reads), and the
> possibility to combine multiple transactions into a larger
> transaction.  I/O is a bit mind-bending, so I'll go with "not a
> transaction, and will throw an error if you put in a transaction,"
> which is the default handling in pretty much every STM implementation
> I've seen.

Again: please keep me postet.  Sounds interesting.

/Jörg

Re: [Readable-discuss] New Release?

[Alan M. G. <alm...@gm...>]

On 2/13/14, "Jörg F. Wittenberger" <Joe...@so...> wrote:
>
> Am 13.02.2014 09:50, schrieb Alan Manuel Gloria:
>> I'm kinda sorta vaguely planning on a Scheme implementation which has
>> STM at its core (basically, all non-transactional mutations are
>> implicitly considered to be inside tiny transactions containing only
>> that mutation).
>
> Have you seen http://ball.askemos.org ?

Err..... not really, and it's a bit more large-scale than what I had in mind.

>
> Your idea reminds me so much to our reasoning.  Just because our
> transactional memory was known to be horribly slow, we decided to have
> two complementary Scheme-alike languages: one without any side effects
> (no effects to be handled in STM, zero overhead) and one sub-language
> having only the effects.  ((Though to distinguish them we chose to
> express the latter in "long-wielded-s-expressions" a.k.a. "XML".))
>
> I'm pretty interested in your plans and progess.  Please keep me posted.

It strikes me that the separation of purity and impurity here is
almost precisely what Haskell does with the separation of the "actual"
language and the IO data type.  Truly pure functions return an IO
object, which can be combined in specific ways with other IO objects
(and with pure functions that return an IO object - for example, a
"read character" IO object can be combined with a pure function that
accepts a character and returns another IO object, forming a larger IO
object that reads a character and then does some other IO action in
response to that character).

Which is a rather big digression from readable lisps, haha.

In any case, my (vague) plan is a relatively simple R7RS compiler,
with everything as a transaction (both mutations and reads), and the
possibility to combine multiple transactions into a larger
transaction.  I/O is a bit mind-bending, so I'll go with "not a
transaction, and will throw an error if you put in a transaction,"
which is the default handling in pretty much every STM implementation
I've seen.

Sincerely,
AmkG

>
> /Jörg
>
>>    If ever, it will of course have SRFI-105 by default
>> and SRFI-110 on #!sweet.
>>
>
>
> ------------------------------------------------------------------------------
> Android apps run on BlackBerry 10
> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> Get your Android app in front of a whole new audience.  Start now.
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
> _______________________________________________
> Readable-discuss mailing list
> Rea...@li...
> https://lists.sourceforge.net/lists/listinfo/readable-discuss
>

Re: [Readable-discuss] New Release?

[Jörg F. W. <Joe...@so...>]

Am 13.02.2014 09:50, schrieb Alan Manuel Gloria:
> I'm kinda sorta vaguely planning on a Scheme implementation which has
> STM at its core (basically, all non-transactional mutations are
> implicitly considered to be inside tiny transactions containing only
> that mutation).

Have you seen http://ball.askemos.org ?

Your idea reminds me so much to our reasoning.  Just because our 
transactional memory was known to be horribly slow, we decided to have 
two complementary Scheme-alike languages: one without any side effects 
(no effects to be handled in STM, zero overhead) and one sub-language 
having only the effects.  ((Though to distinguish them we chose to 
express the latter in "long-wielded-s-expressions" a.k.a. "XML".))

I'm pretty interested in your plans and progess.  Please keep me posted.

/Jörg

>    If ever, it will of course have SRFI-105 by default
> and SRFI-110 on #!sweet.
>

[Readable-discuss] New Release?

[Alan M. G. <alm...@gm...>]

So... Sourceforge just now sent me an e-mail about Readable Lisp
having a new release... that was released last year October.

Is this just Sourceforge being weird or what?

So, anything new?

I'm kinda sorta vaguely planning on a Scheme implementation which has
STM at its core (basically, all non-transactional mutations are
implicitly considered to be inside tiny transactions containing only
that mutation).  If ever, it will of course have SRFI-105 by default
and SRFI-110 on #!sweet.

Re: [Readable-discuss] My first attempt: a process manager

[David A. W. <dwh...@dw...>]

> On Sat, Jan 4, 2014 at 12:07 AM, Mike Gran <sp...@ya...> wrote:
> > Hi.  I thought I'd take a stab at using your readable project
> >
> > Result is attached.  It is a process manager: a structure holds
> > a list of functions and data and call the functions as a unit.
> > Functions that return #f are removed from the manager, and
> > functions that return #t are kept.
> >
> >
> > My impressions are pretty favorable.  I didn't love the
> > let block syntax, so I used defines instead.

I'm really glad they were overall favorable.


On Fri, 10 Jan 2014 21:08:06 +0800, Alan Manuel Gloria <alm...@gm...> wrote:
> Yes, let syntax is a big drawback with the "indentation implies
> parentheses" strategy.

Nothing is perfect, but I think it's very reasonable
We have a general solution using leading "\\"
that easily handles all cases, and <*...*> is a useful shorthand for handling
let statements with short variable-definition blocks.

> As a complete aside, in Haskell, there's a special "fallback" rule
> where an error due to indentation matching will cause the parser to
> attempt to close a group.  This rule usually triggers in Haskell's
> let...in syntax (basically, the "in" keyword is generally a syntax
> error except after a let group, so the parser usually errors here when
> indentation is used), which seems to imply to me that even Haskell has
> some trouble with let syntax, which was simply "fixed" with this
> hackish solution.
> 
> xref http://www.haskell.org/onlinereport/syntax-iso.html#sect9.3 ,
> particularly Note 5.

Fair enough.  Again, nothing's perfect.

> >  Also, I used
> > 'cond' in lieu of 'if' because I liked the look of having
> > an 'else'.
> 
> Yes, the "old" syntaxes like that tend to be very pretty in indentation syntax.

I think "if" looks great:
if {x < y}
! x
! y

Obviously if you want a *keyword* to mark the else clause, that doesn't do it,
but in that case "cond" is the better choice anyway.

--- David A. Wheeler

Re: [Readable-discuss] My first attempt: a process manager

[Alan M. G. <alm...@gm...>]

On Sat, Jan 4, 2014 at 12:07 AM, Mike Gran <sp...@ya...> wrote:
> Hi.  I thought I'd take a stab at using your readable project
>
> Result is attached.  It is a process manager: a structure holds
> a list of functions and data and call the functions as a unit.
> Functions that return #f are removed from the manager, and
> functions that return #t are kept.
>
>
> My impressions are pretty favorable.  I didn't love the
>
> let block syntax, so I used defines instead.

Yes, let syntax is a big drawback with the "indentation implies
parentheses" strategy.

As a complete aside, in Haskell, there's a special "fallback" rule
where an error due to indentation matching will cause the parser to
attempt to close a group.  This rule usually triggers in Haskell's
let...in syntax (basically, the "in" keyword is generally a syntax
error except after a let group, so the parser usually errors here when
indentation is used), which seems to imply to me that even Haskell has
some trouble with let syntax, which was simply "fixed" with this
hackish solution.

xref http://www.haskell.org/onlinereport/syntax-iso.html#sect9.3 ,
particularly Note 5.

>  Also, I used
> 'cond' in lieu of 'if' because I liked the look of having
> an 'else'.

Yes, the "old" syntaxes like that tend to be very pretty in indentation syntax.

>
> It works for me with Guile 2.0.9 and Readable 1.0.
> Thanks,
>
> Mike Gran
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> Readable-discuss mailing list
> Rea...@li...
> https://lists.sourceforge.net/lists/listinfo/readable-discuss
>

Re: [Readable-discuss] My first attempt: a process manager

[David A. W. <dwh...@dw...>]

That is awesome!  Thanks for letting us know!

Mike Gran <sp...@ya...> wrote:
>Hi.  I thought I'd take a stab at using your readable project
>
>Result is attached.  It is a process manager: a structure holds
>a list of functions and data and call the functions as a unit.
>Functions that return #f are removed from the manager, and
>functions that return #t are kept.
>
>
>My impressions are pretty favorable.  I didn't love the 
>
>let block syntax, so I used defines instead.  Also, I used
>'cond' in lieu of 'if' because I liked the look of having
>an 'else'.
>
>It works for me with Guile 2.0.9 and Readable 1.0.
>Thanks,
>
>Mike Gran
>
>
>------------------------------------------------------------------------
>
>------------------------------------------------------------------------------
>Rapidly troubleshoot problems before they affect your business. Most IT
>
>organizations don't have a clear picture of how application performance
>
>affects their revenue. With AppDynamics, you get 100% visibility into
>your 
>Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
>AppDynamics Pro!
>http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Readable-discuss mailing list
>Rea...@li...
>https://lists.sourceforge.net/lists/listinfo/readable-discuss

--- David A.Wheeler

[Readable-discuss] My first attempt: a process manager

[Mike G. <sp...@ya...>]

Hi.  I thought I'd take a stab at using your readable project

Result is attached.  It is a process manager: a structure holds
a list of functions and data and call the functions as a unit.
Functions that return #f are removed from the manager, and
functions that return #t are kept.


My impressions are pretty favorable.  I didn't love the 

let block syntax, so I used defines instead.  Also, I used
'cond' in lieu of 'if' because I liked the look of having
an 'else'.

It works for me with Guile 2.0.9 and Readable 1.0.
Thanks,

Mike Gran

Re: [Readable-discuss] treatment of quote symbol

[David A. W. <dwh...@dw...>]

I said:
> > To be honest, I think we should treat x'x as an error in the sample
> > implementation (though guile treats x'x as a single symbol).  You can
> > always use |x'x| if you mean that, and if you mean (x 'x), we already
> > have several much clearer ways to express that:
> 

On Fri, 6 Dec 2013 10:58:25 -0500, John Cowan <co...@me...> wrote:
> +1

Okay, I've pushed that change, and it now reports more specifically what the problem is.
That means that x'y is no longer legal... and it will *immediately* identify that as an error
(and report the failing character, ' in this case).

This was never specified in SRFI-110 (or Scheme), so it's not a spec change...
it's just a way to more strict in a standards-compliant way.

--- David A. Wheeler

Re: [Readable-discuss] treatment of quote symbol

[John C. <co...@me...>]

David A. Wheeler scripsit:

> To be honest, I think we should treat x'x as an error in the sample
> implementation (though guile treats x'x as a single symbol).  You can
> always use |x'x| if you mean that, and if you mean (x 'x), we already
> have several much clearer ways to express that:

+1

-- 
Henry S. Thompson said, / "Syntactic, structural,               John Cowan
Value constraints we / Express on the fly."                 co...@cc...
Simon St. Laurent: "Your / Incomprehensible     http://www.ccil.org/~cowan
Abracadabralike / schemas must die!"

Re: [Readable-discuss] Reorganize to reduce namespace pollution and maximally create library

[Alan M. G. <alm...@gm...>]

> Hmm.  Generating code is reasonable of course.
> One problem with the "shar" approach is that common code will be
> copied into different separate files, and eventually not consistently
> maintained.
> I'd like to say "one thing once" as much as possible (for maintenance).
>
> A variation would be to create ONE shell script that can generate (to
> stdout)
> Scheme code for the variant identified in a parameter;
> it could "cat" the main code at the right time.
> Something like:
> =====
> #!/bin/env sh
> # $1 is the type to generate.
> case "$1" in
> GUILE)
>   echo "..." ;;
> *) echo "..." ;;
> esac
> cat kernel.scm
> =====
>
> A completely different approach is a cpp-like tool.
> I've cobbled together an awk implementation of cpp-like syntax so
> you can do this:
> #ifdef GUILE
> ...
> #elseifdef RSCHEME
> ...
> #else
> ...
> #endif
>
> Either one would mean that we only need to say something ONCE
> if it can be used in multiple circumstances.

I *think* awk can be more portable.

The nice thing with the separate-processors approach is that we can
solicit just the bits we need to concatenate from the various Scheme
islands.  If we have one file that makes everything, it will
eventually become a single large monster that no one likes to touch
(assuming widespread usage of this particular implementation of
SRFI-110, at least).

Separate generators for each implementation-version we claim to
support strikes as more maintainable in the long run.  I don't expect
a lot of code duplication, if we could have a "good enough" set of
"things I assume the compatibility layer can do".

Oh, and source annotation is a ****er.  The style used assumes Guile
idioms.  In Racket a reader is supposed to return "syntax objects",
which wrap a datum and the source location and top-level lexical
environment.  Syntax objects are either a datum+source loc, or a
syntax-cons on syntax objects (or a syntax-vector or a
syntax-whatever).

It's theoretically possible to use a eq?-key hash table for
attach-source-info (key is the datum, value is the source info), wrap
sweet-read, and when sweet-read returns a datum, to convert the datum
and its sub-datums to syntax objects, attaching the source info to
each datum.  Instead of exporting sweet-read directly, we just wrap it
into an extra layer of (let () ..) that returns sweet-read and
friends, then wraps the returned sweet-read into an actual sweet-read
that makes the hash table and does the whatever whatever needed to
turn them into syntax objects.  The hash table does not need to be
weak-keyed, since it lives only within the sweet-read invocation.

Sincerely,
AmkG

Re: [Readable-discuss] treatment of quote symbol

[Jörg F. W. <Joe...@so...>]

Am 06.12.2013 07:01, schrieb David A. Wheeler:
> I'm guessing Joerg Wittenberger wants something else, though :-).
> So let's talk about that.
I just wanted to know whether the current behavior was an accident or 
intentional.

John's reply
http://trac.sacrideo.us/wg/wiki/QuoteDelimiter
made me aware that I overlooked a compatibility issue within Scheme itself.

So I'll eat the food (and insert spaces into my code where they are 
missing now).

/Jörg

Re: [Readable-discuss] Reorganize to reduce namespace pollution and maximally create library

[David A. W. <dwh...@dw...>]

John Cowan dropped the following bad news:
> >> Dude, you have a hold of the Tar Baby here. R6RS and R7RS libraries
> >> can't be the result of a macro, neither as a whole nor in part. All
> >> you've done is trade off one set of portability breakers for another.
> >

I said:
> > Ugh.  In that case, maybe we should just drop the "readable-kernel-module-contents"
> > macro altogether, and just write straight code with weird names to
> > reduce possible namespace problems.
> > We can include cond-expand guile magic so that it works as-is as a guile module.
> >
> > Alan: Any objections?

On Fri, 6 Dec 2013 12:12:51 +0800, Alan Manuel Gloria <alm...@gm...> wrote:
> None whatsoever.
> 
> I think Jorg's proposal to make a file (the "shar") that makes the
> output based on the detected Scheme implementation is good.  We could
> even run the file multiple times to generate different outputs, one
> for each Scheme supported and detected.
> 
> I propose this system:
> 
> 1.  We write as if we own the namespace.  Select some suitable soup of
> features from R4RS through R7RS, and define it in comments well in the
> core implementation file.  The core implementation file is then just a
> bunch of (define ...) forms, possibly with some hooks on options like
> "CL mode" or "Scheme mode".
>
> 2.  Write a bunch of "shar"s, which take the original file and
> transform it to code that a particular Scheme implementation-version
> accepts.  Basically, it just prepends and appends some additional
> code, probably just plain text, to the core implementation file.  The
> shar can put the entire core implementation file within some sort of
> (define-library... ) form, if needed.
> 
> 3.  If a particular Scheme implementation-version supports parameters,
> then the "CL mode" option can be made into a parameter.  If not, it
> can be a global instead.  We document this in, say, a USAGE.Chicken or
> USAGE.Guile-1.8 or whatever file.
> 
> For example, a "standard R5RS shar" would just wrap the implementation
> file in something like:
> 
> #! /bin/sh
> 
> IN=$1
> OUT=$2
> 
> cat > $OUT <<PREFIX
> (define (readable%is-cl-mode)
>   readable%cl-mode)
> (define readable%cl-mode #f)
> 
> (define readable%whatevers
>   (let ()
> PREFIX
> cat $IN >> $OUT
> cat > $OUT <<SUFFIX
>   (list sweet-read neoteric-read curly-read)
>   ) ;let
> ); define readable%whatevers
> 
> (define sweet-read (car readable%whatevers))
> (define neoteric-read (cadr readable%whatevers))
> (define curly-read (caddr readable%whatevers))
> SUFFIX

Hmm.  Generating code is reasonable of course.
One problem with the "shar" approach is that common code will be
copied into different separate files, and eventually not consistently maintained.
I'd like to say "one thing once" as much as possible (for maintenance).

A variation would be to create ONE shell script that can generate (to stdout)
Scheme code for the variant identified in a parameter;
it could "cat" the main code at the right time.
Something like:
=====
#!/bin/env sh
# $1 is the type to generate.
case "$1" in
GUILE)
  echo "..." ;;
*) echo "..." ;;
esac
cat kernel.scm
=====

A completely different approach is a cpp-like tool.
I've cobbled together an awk implementation of cpp-like syntax so
you can do this:
#ifdef GUILE
...
#elseifdef RSCHEME
...
#else
...
#endif

Either one would mean that we only need to say something ONCE
if it can be used in multiple circumstances.

--- David A. Wheeler

Re: [Readable-discuss] treatment of quote symbol

[David A. W. <dwh...@dw...>]

> David A. Wheeler scripsit:
> > What do you think x'x *should* mean?  That's incredibly ugly!

On Thu, 5 Dec 2013 13:08:53 -0500, John Cowan <co...@me...> wrote:
> Its meaning is specifically left up to the implementation.  Apostrophe
> is neither a <subsequent> (required to be treated as part of the
> identifier) nor a <delimiter> (required to be treated as not part of
> the identifier).  Its general category is Po, which means that in R6RS
> and R7RS implementations are explicitly allowed to treat it as part of
> the identifier.

> <http://trac.sacrideo.us/wg/wiki/QuoteDelimiter> reports what Schemes
> actually do. Only a few of the major implementations actually allow
> x'x as an identifier.

SRFI-110 depends on other specs to define what symbols etc. are,
so formally SRFI-110 gives us a lot of freedom.

To be honest, I think we should treat x'x as an error in the sample implementation
(though guile treats x'x as a single symbol).  You can always use |x'x|
if you mean that, and if you mean (x 'x), we already have several
much clearer ways to express that:
(x 'x)
x('x)
x 'x

I'm guessing Joerg Wittenberger wants something else, though :-).
So let's talk about that.

It would probably be difficult to support x'x as 2 adjacent expressions
in many implementations in one special case: bare initial indents.
Since "read" must return, we depend on the unconsumed space or tab
to let us know that we're reading in the next item with an initial intend.
If we peek an apostrophe and don't consume it, there's no space or tab to inform.

It might be possible to support  x'x as 2 adjacent expressions in other cases,
though it might be awkward. Generally, if we consume an expression
and there's nonwhitespace left over, we complain about it,
as part of the general system to detect errors.
E.G., it-expr-real's complains about "Unexpected text after n-expression"
and we'd have to modify things to permit it.

It seems to me that x'x is almost certainly a mistake, and should cause an immediate
read failure as part of early error detection.  There are so few opportunities
for early error detection!!  Thoughts, anyone?

--- David A. Wheeler

Re: [Readable-discuss] Reorganize to reduce namespace pollution and maximally create library

[Alan M. G. <alm...@gm...>]

On Mon, Nov 25, 2013 at 10:10 PM, David A. Wheeler
<dwh...@dw...> wrote:
> John Cowan:
>> Dude, you have a hold of the Tar Baby here. R6RS and R7RS libraries
>> can't be the result of a macro, neither as a whole nor in part. All
>> you've done is trade off one set of portability breakers for another.
>
> Ugh.  In that case, maybe we should just drop the "readable-kernel-module-contents"
> macro altogether, and just write straight code with weird names to
> reduce possible namespace problems.
> We can include cond-expand guile magic so that it works as-is as a guile module.
>
> Alan: Any objections?

None whatsoever.

I think Jorg's proposal to make a file (the "shar") that makes the
output based on the detected Scheme implementation is good.  We could
even run the file multiple times to generate different outputs, one
for each Scheme supported and detected.

I propose this system:

1.  We write as if we own the namespace.  Select some suitable soup of
features from R4RS through R7RS, and define it in comments well in the
core implementation file.  The core implementation file is then just a
bunch of (define ...) forms, possibly with some hooks on options like
"CL mode" or "Scheme mode".

2.  Write a bunch of "shar"s, which take the original file and
transform it to code that a particular Scheme implementation-version
accepts.  Basically, it just prepends and appends some additional
code, probably just plain text, to the core implementation file.  The
shar can put the entire core implementation file within some sort of
(define-library... ) form, if needed.

3.  If a particular Scheme implementation-version supports parameters,
then the "CL mode" option can be made into a parameter.  If not, it
can be a global instead.  We document this in, say, a USAGE.Chicken or
USAGE.Guile-1.8 or whatever file.

For example, a "standard R5RS shar" would just wrap the implementation
file in something like:

#! /bin/sh

IN=$1
OUT=$2

cat > $OUT <<PREFIX
(define (readable%is-cl-mode)
  readable%cl-mode)
(define readable%cl-mode #f)

(define readable%whatevers
  (let ()
PREFIX
cat $IN >> $OUT
cat > $OUT <<SUFFIX
  (list sweet-read neoteric-read curly-read)
  ) ;let
); define readable%whatevers

(define sweet-read (car readable%whatevers))
(define neoteric-read (cadr readable%whatevers))
(define curly-read (caddr readable%whatevers))
SUFFIX

Re: [Readable-discuss] Portability tweaks to kernel.scm (our Scheme implementation)

[Alan M. G. <alm...@gm...>]

On Sun, Nov 17, 2013 at 10:02 AM, David A. Wheeler
<dwh...@dw...> wrote:
> Alan: This redefines raise/guard for all guiles, even if it's already available.
> It should probably only do that for guile < 1.8, and should otherwise yank in
> the real R6RS handler.  Do you agree?  If so, could you add that magic, to
> minimize futzing low-level functionality... or any other cleaning up you see?
> Also... does it work on your guile 1.6?

Hello, sorry, been doing stuff unrelated to Scheme lately, so I
haven't been checking my e-mails, haha.

I'll see this soon if possible.

Sincerely,
AmkG

Re: [Readable-discuss] treatment of quote symbol

[John C. <co...@me...>]

David A. Wheeler scripsit:

> What do you think x'x *should* mean?  That's incredibly ugly!

Its meaning is specifically left up to the implementation.  Apostrophe
is neither a <subsequent> (required to be treated as part of the
identifier) nor a <delimiter> (required to be treated as not part of
the identifier).  Its general category is Po, which means that in R6RS
and R7RS implementations are explicitly allowed to treat it as part of
the identifier.

<http://trac.sacrideo.us/wg/wiki/QuoteDelimiter> reports what Schemes
actually do.  Only a few of the major implementations actually allow
x'x as an identifier.

-- 
Only do what only you can do.               John Cowan <co...@cc...>
  --Edsger W. Dijkstra's advice
    to a student in search of a thesis

Re: [Readable-discuss] treatment of quote symbol

[David A. W. <dwh...@dw...>]

On Thu, 05 Dec 2013 13:14:34 +0100, "Jörg F. Wittenberger"	<Joe...@so...> wrote:
> Hi all,
> 
> it's beginning to annoy me: normal Scheme readers treat quote and 
> quasiquote symbols as terminating charachters when reading symbols.
> 
> With the "readable reader" they suddenly become part of a symbol. That's 
> all rather confusing and causes so much incompatibility.
> 
> Its this really intended or just an oversight?

What do you think x'x *should* mean?  That's incredibly ugly!

--- David A. Wheeler

[Readable-discuss] treatment of quote symbol

[Jörg F. W. <Joe...@so...>]

Hi all,

it's beginning to annoy me: normal Scheme readers treat quote and 
quasiquote symbols as terminating charachters when reading symbols.

With the "readable reader" they suddenly become part of a symbol. That's 
all rather confusing and causes so much incompatibility.

Its this really intended or just an oversight?

/Jörg

Re: [Readable-discuss] Reorganize to reduce namespace pollution and maximally create library

[Jörg F. W. <Joe...@so...>]

Am 27.11.2013 02:28, schrieb David A. Wheeler:
> I said:
>>> At the least, I could put things in different files, and then use "cat"
>>> to create files usable to different systems.
> On Tue, 26 Nov 2013 14:47:36 +0100, "Jörg F. Wittenberger":
>> Not too bad and idea.  While it might not scale to whole programs, it's
>> certainly a valid way to get things done for something the size of a
>> srfi's implementation.
> Right.  This thing is small.
>
> I don't see anything good for trivial preprocessing:
> * "scmxlate" appears too complex to get going.

Probably.  A few bullet point about my take on this.

1)  Whatever we do here, it's not necessarily going to be used "for 
real" but merely to show how things would have to be processed in users 
build.
2) From (1) I conclude: the least amount of commonly available tools is 
the best.
3) When pre-processing LISP code, the best language for the job is 
actually LISP, since it has easily access to the structure of the code 
to be rewritten.  Other languages are forced to go through axillary 
properties of the code.
cpp, as you said, is a disaster for LISP and m4 is a disaster in itself.
4) Point (3) is mostly incompatible with (2).  The only exception might 
be recent GNUmake.  I did not yet have the time to check it out, but I 
read it would support guile.  Maybe one could trick it into running a 
guile pre-process.
5) Coming back once more to my desire to have a Scheme reader which 
would allow to deliver a modified AST including comment nodes: such a 
beast could be used to write back-and-forth (round-trip-safe) code to 
code transformations.  One could work with any flavor when porting to 
new implementations and easily roll the result back into the "generic" 
form. All this should need would be the generic base and a 
guile-as-in-gnumake specialized version.

Let me add: I'm not entirely sold to (5) but I'd like to see how this 
would work in reality before I judge.

> * "cpp" is a disaster for Lisp (it wants to parse '...' as character constants)
> * "m4" is easy to get wrong, and has too much functionality.
>
> I think I could create a simple "#ifdef ... #elifdef... #else... #endif"
> preprocessor in awk (which is in the POSIX standard)
> that would do the job.

If I dug deep enough into the code I ever wrote, I guess I could come 
back with at least two such things in K&R C.
;-)

I'm not sure it's worth to write a special tool just for this special case.

>    Then the whole thing could be in one file,
> and generate variations for different purposes.  For those Schemes with
> cond-expand, we could put them in one file, so we wouldn't have to
> generate too many files.
>
>

Since the single-file approach would still require some pre-processing, 
let me suggest yet another single file approach: "shar".  A shell 
archive including several files a little sh-script to glue the pieces 
together.  Still one file.  ;-)

Irony aside: any tool will do.  Simplicity for the end user should be 
the trumping argument.

Re: [Readable-discuss] using t-expressions

[Jörg F. W. <Joe...@so...>]

Am 27.11.2013 02:22, schrieb David A. Wheeler:
> On Tue, 26 Nov 2013 15:11:39 +0100, "Jörg F. Wittenberger" wrote:
>> I changed it's signature to match srfi-23 (for know)
>>
>> (: read-error (string &rest * -> *)
> Okay, but you'll need to modify the procedure definition to match.
Sure.  I just did not want to clutter the list with some imature, 
temporary code.

>
>> But I tend to prefer a more restrictive, though compatible, syntax in
>> this case
>>
>> (: read-error (string input-port string &rest * -> *)
> Please don't.  The intent was to be syntactically consistent
> with "error" as defined in srfi-23 and R7RS.
> Someone can always modify the error port to change where it goes.
> Oh, I presume you mean "output-port" not "input-port" there.

No, I meant "input-port" - or rather the "fake input port" we're reading 
from.
Iff the latter supports getting the position or something, the 
read-error could report them too.  For the moment I just used peek-char 
to show the problematic character.

This signature is compatible with srfi-23 error.  It's just a little 
more specific and should probably itself rely on plain "error" in the 
implementation.

>
>> Whereby I'd require all calls to read-error to pass the port and the
>> last successfully read token in an effort to further improve error messages.
> Why not just pass "last successfully read token" as a parameter after the string?

That was the intent behind the "string" after the "(fake) input-port".

>
>>> The ONLY procedure that catches an exception is t-expr-catch:
>>>     (define (t-expr-catch port)
>>>       (init-sweet)
>>>       (guard
>>>         (exception
>>>           ((eq? exception 'readable)
>>>            (read-to-unindented-line port) (t-expr-catch port)))
>>>         (t-expr port)))
>>>
>> Is there actually any scheme implementation which benefits from this
>> catching?  I can't image.
> Our processing program does, because it tries to process as well as it can.
> But we could change the interface.
>
>> I'd feel it might be good to provide a "clean up read" like
>> `read-to-unindented-line` to help the implementor of a repl.  But for
>> the default it just does not feel right to me.
> Okay.  An easy approach would be to raise an exception on error,
> and add an option to permit the current behavior (catch and retry).
> That's an interface change, but the SRFI doesn't define specifics on how
> to handle errors (since Schemes vary in this matter), and it makes sense
> that people will want to get errors.
>
> Guile 1.8 doesn't support srfi-23 or R7RS, so that would need to be
> implemented separately on guile.
>

This one does not look to bad to me:
https://www.gnu.org/software/guile/docs/docs-1.8/guile-ref/Error-Reporting.html#Error-Reporting

/Jörg

Re: [Readable-discuss] Reorganize to reduce namespace pollution and maximally create library

[David A. W. <dwh...@dw...>]

I said:
> > At the least, I could put things in different files, and then use "cat"
> > to create files usable to different systems.

On Tue, 26 Nov 2013 14:47:36 +0100, "Jörg F. Wittenberger":
> Not too bad and idea.  While it might not scale to whole programs, it's 
> certainly a valid way to get things done for something the size of a 
> srfi's implementation.

Right.  This thing is small.

I don't see anything good for trivial preprocessing:
* "scmxlate" appears too complex to get going.
* "cpp" is a disaster for Lisp (it wants to parse '...' as character constants)
* "m4" is easy to get wrong, and has too much functionality.

I think I could create a simple "#ifdef ... #elifdef... #else... #endif"
preprocessor in awk (which is in the POSIX standard)
that would do the job.  Then the whole thing could be in one file,
and generate variations for different purposes.  For those Schemes with
cond-expand, we could put them in one file, so we wouldn't have to
generate too many files.

--- David A. Wheeler

Re: [Readable-discuss] using t-expressions

[David A. W. <dwh...@dw...>]

I said:
> > The ONLY procedure that throws an exception is "read-error":
> >    (define (read-error message)

On Tue, 26 Nov 2013 15:11:39 +0100, "Jörg F. Wittenberger" wrote:
> I changed it's signature to match srfi-23 (for know)
> 
> (: read-error (string &rest * -> *)

Okay, but you'll need to modify the procedure definition to match.

> But I tend to prefer a more restrictive, though compatible, syntax in 
> this case
> 
> (: read-error (string input-port string &rest * -> *)

Please don't.  The intent was to be syntactically consistent
with "error" as defined in srfi-23 and R7RS.
Someone can always modify the error port to change where it goes.
Oh, I presume you mean "output-port" not "input-port" there.

> Whereby I'd require all calls to read-error to pass the port and the 
> last successfully read token in an effort to further improve error messages.

Why not just pass "last successfully read token" as a parameter after the string?


> > The ONLY procedure that catches an exception is t-expr-catch:
> >    (define (t-expr-catch port)
> >      (init-sweet)
> >      (guard
> >        (exception
> >          ((eq? exception 'readable)
> >           (read-to-unindented-line port) (t-expr-catch port)))
> >        (t-expr port)))
> >
> 
> Is there actually any scheme implementation which benefits from this 
> catching?  I can't image.

Our processing program does, because it tries to process as well as it can.
But we could change the interface.

> I'd feel it might be good to provide a "clean up read" like 
> `read-to-unindented-line` to help the implementor of a repl.  But for 
> the default it just does not feel right to me.

Okay.  An easy approach would be to raise an exception on error,
and add an option to permit the current behavior (catch and retry).
That's an interface change, but the SRFI doesn't define specifics on how
to handle errors (since Schemes vary in this matter), and it makes sense
that people will want to get errors.

Guile 1.8 doesn't support srfi-23 or R7RS, so that would need to be
implemented separately on guile.

--- David A. Wheeler

Re: [Readable-discuss] Reorganize to reduce namespace pollution and maximally create library

[David A. W. <dwh...@dw...>]

I said:
> > > I'll note that my Common Lisp implementation "just works",

On Tue, 26 Nov 2013 11:29:49 -0500, John Cowan <co...@me...> wrote:
> Well, yes.  Common Lisp is a pretty thorough standard, and as such
> it has a fairly large number of actively developed implementations,
> as languages go: ABCL, CCL, CLISP, CMUCL, ECL, MKCL, SBCL.  But that's
> nothing compared to Scheme's seventy-seven or so.

It's not the number of implementations, it's the lack of a
widely-implemented standard way to invoke basic capabilities,
such as a module system, exception system, and hash tables.
Heck, not even macros (a Lisp basic) are completely universal.

If there were 77 Schemes that agreed on all those, it'd be fine.

> As a developer, I stick to Chicken and Chibi, and resolutely ignore the
> (mis)behavior of other Schemes.

I have the same basic approach (using "guile" as the list).

Here's hoping that R7RS, especially R7RS-large, will make it
possible to unify the islands.  I think Scheme would be more
compelling if people could actually work together :-).

--- David A. Wheeler