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

[Readable-discuss] All okay for an updated release?

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

The "develop" version includes a fix for the unintended guile 2.0 regression.
I've made a few other changes to make it work on more systems, e.g., old autoconfs.
I've even created a patch that I *think* will make it work on guile 1.6
(it replaces "else" with "#t" in the deployed code, but only if necessary).

If anyone else could test it, that'd be great!  I've tested this on several different systems.
Also, patches to remove the warnings generated by guile 2.0 (listed below) while not interfering
with other Schemes would be great.

--- David A. Wheeler


=== guile 2.0 warnings ===

;;; compiling /home/dwheeler/readable-code/readable-1.0.3/_build/readable/kernel.scm
;;; readable/kernel.scm:2526:16: warning: possibly unbound variable `srfi-69-make-hash-table'
;;; readable/kernel.scm:2531:48: warning: possibly unbound variable `type-printer'
;;; readable/kernel.scm:2533:12: warning: possibly unbound variable `hash-table-update!/default'
;;; readable/kernel.scm:2536:17: warning: possibly unbound variable `hash-table-ref'
;;; readable/kernel.scm:2545:31: warning: possibly unbound variable `type-num-slots'
;;; readable/kernel.scm:2548:31: warning: possibly unbound variable `slot-ref'
;;; readable/kernel.scm:2552:25: warning: possibly unbound variable `hash-table-ref/default'
;;; readable/kernel.scm:2553:16: warning: possibly unbound variable `hash-table-delete!'
;;; readable/kernel.scm:2555:17: warning: possibly unbound variable `srfi-69-make-hash-table'
;;; readable/kernel.scm:2556:8: warning: possibly unbound variable `hash-table-walk'
;;; readable/kernel.scm:2558:35: warning: possibly unbound variable `hash-table-set!'
;;; readable/kernel.scm:2567:50: warning: possibly unbound variable `type-printer'
;;; readable/kernel.scm:2568:25: warning: possibly unbound variable `hash-table-ref/default'
;;; readable/kernel.scm:2573:21: warning: possibly unbound variable `hash-table-ref/default'
;;; readable/kernel.scm:2585:24: warning: possibly unbound variable `hash-table-set!'
;;; readable/kernel.scm:2685:33: warning: possibly unbound variable `type-printer'
;;; compiled /home/dwheeler/.cache/guile/ccache/2.0-LE-8-2.0/home/dwheeler/readable-code/readable-1.0.3/_build/readable/kernel.scm.go
;;; unsweeten:184:16: warning: possibly unbound variable `pretty-print'

Re: [Readable-discuss] Guile meta-commands

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

Alex Rozenshteyn scripsit:

> There seems to be no way to get an input equivalent to ",h -c a" (note
> the lack of parentheses) into the guile repl using guile-sweet.

Yes.  Alas, in Guile the ,commands are special-case hacks in the reader,
rather than (as in Chicken and Gambit) special handling of the "unquote"
form by the REPL loop.  That is, at the Chicken repl it is the same
to type

> ,l foo

and

> (unquote l) foo

-- 
John Cowan          http://www.ccil.org/~cowan        co...@cc...
Time alone is real
  the rest imaginary
like a quaternion       --phma

Re: [Readable-discuss] Guile meta-commands

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

On Tue, 1 Jul 2014 11:58:20 -0400, Alex Rozenshteyn <rpg...@gm...> wrote:
> There seems to be no way to get an input equivalent to ",h -c a" (note
> the lack of parentheses) into the guile repl using guile-sweet.
> 
> This makes it more difficult to use guile-sweet as a replacement for
> the guile repl, since some guile meta-commands are not handled.

The guile repl includes some magic commands and handles them specially.
Unfortunately, it makes assumptions that the sweet reader falsifies.
It'd be nice to find a way to invoke these commands directly... and then perhaps their
ease could be restored.

Here's what I know so far:
Guile's source code can be viewed on savannah's git page, e.g.:
  http://git.savannah.gnu.org/gitweb/?p=guile.git;a=tree;f=module/system/repl;h=c767baf098d5dde0cb396eabcd6c40482608846c;hb=93e838423cba836fd90662f9acd362ddf3aa6fb1
The repl is implemented in "module/system/repl/", especially file "repl.scm".
I suspect that procedure "meta-reader" is a key player.

I haven't spent much time looking to see if there's a way to invoke the meta-commands
more directly, but it *seems* like it should be possible!

> Also, sweeten suggests that the solution would be ",h\n-c\na\n", but
> both unsweeten and guile-sweet output before all three lines have been
> input, and unsweeten does not collapse them onto the same line.
> 
> I'm not sure how one could work around it or even if it's something
> one could solve within the spec, but it just bit me, so I thought I'd
> mention it.

Thanks.  Anyone have suggestions?

--- David A. Wheeler

[Readable-discuss] Guile meta-commands

[Alex R. <rpg...@gm...>]

There seems to be no way to get an input equivalent to ",h -c a" (note
the lack of parentheses) into the guile repl using guile-sweet.

This makes it more difficult to use guile-sweet as a replacement for
the guile repl, since some guile meta-commands are not handled.

Also, sweeten suggests that the solution would be ",h\n-c\na\n", but
both unsweeten and guile-sweet output before all three lines have been
input, and unsweeten does not collapse them onto the same line.

I'm not sure how one could work around it or even if it's something
one could solve within the spec, but it just bit me, so I thought I'd
mention it.

-- 
          Alex R

Re: [Readable-discuss] Build error with guile-2.0

[Alex R. <rpg...@gm...>]

Yes, it works. Thank you.

On Mon, Jun 30, 2014 at 11:34 PM, David A. Wheeler
<dwh...@dw...> wrote:
> On Mon, 30 Jun 2014 22:42:35 -0400, Alex Rozenshteyn <rpg...@gm...> wrote:
>> Huh. I'm surprised that there was actually a problem. Thanks for
>> fixing it! (and sorry for spamming the list a bit)
>
> That's not spam at all.  This list is *exactly* for discussing issues.
> I'm surprised that slipped through, but obviously it did, sorry about that.
>
> If you could confirm that it works on *your* system that'd be great.
> This is a serious problem, and I'd like to release a new version soon, but
> I'd rather make sure that it *stays* fix.
>
> --- David A. Wheeler



-- 
          Alex R

Re: [Readable-discuss] Build error with guile-2.0

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

On Mon, 30 Jun 2014 22:42:35 -0400, Alex Rozenshteyn <rpg...@gm...> wrote:
> Huh. I'm surprised that there was actually a problem. Thanks for
> fixing it! (and sorry for spamming the list a bit)

That's not spam at all.  This list is *exactly* for discussing issues.
I'm surprised that slipped through, but obviously it did, sorry about that.

If you could confirm that it works on *your* system that'd be great.
This is a serious problem, and I'd like to release a new version soon, but
I'd rather make sure that it *stays* fix.

--- David A. Wheeler

Re: [Readable-discuss] Build error with guile-2.0

[Alex R. <rpg...@gm...>]

Huh. I'm surprised that there was actually a problem. Thanks for
fixing it! (and sorry for spamming the list a bit)

On Mon, Jun 30, 2014 at 6:44 PM, David A. Wheeler <dwh...@dw...> wrote:
> On Mon, 30 Jun 2014 14:44:02 -0400, Alex Rozenshteyn <rpg...@gm...> wrote:
>> I'm trying to build the 1.0.2 version on a 64-bit debian testing
>> machine. I have guile-2.0 (and guile-2.0-dev) installed. After running
>> ./configure --without-common-lisp, I try to run make, and I get the
>> attached error.
>>
>> I'm probably doing something wrong, but I'm not really sure what.
>
> Thanks for the report!  The problem appears to be specific to guile 2.0.  Sorry about that.
>
> I think I've fixed it, the update is on the "develop" branch on git.
> If you could test it out, that'd be great.  The instructions here:
>    http://sourceforge.net/p/readable/wiki/Install-howto/
>
> Basically, you need to install git, autoconf, and automake.  Then check out the code this way:
>  git clone git://git.code.sf.net/p/readable/code readable-code
>  cd readable-code
>  git checkout -b develop origin/develop  # Set up and switch to "develop" branch
>  autoreconf -i
>
> Then configure, build, and test as usual:
>  ./configure --prefix=/usr
>  make
>  make check
>
> --- David A. Wheeler



-- 
          Alex R

Re: [Readable-discuss] Build error with guile-2.0

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

On Mon, 30 Jun 2014 14:44:02 -0400, Alex Rozenshteyn <rpg...@gm...> wrote:
> I'm trying to build the 1.0.2 version on a 64-bit debian testing
> machine. I have guile-2.0 (and guile-2.0-dev) installed. After running
> ./configure --without-common-lisp, I try to run make, and I get the
> attached error.
> 
> I'm probably doing something wrong, but I'm not really sure what.

Thanks for the report!  The problem appears to be specific to guile 2.0.  Sorry about that.

I think I've fixed it, the update is on the "develop" branch on git.
If you could test it out, that'd be great.  The instructions here:
   http://sourceforge.net/p/readable/wiki/Install-howto/

Basically, you need to install git, autoconf, and automake.  Then check out the code this way:
 git clone git://git.code.sf.net/p/readable/code readable-code
 cd readable-code
 git checkout -b develop origin/develop  # Set up and switch to "develop" branch
 autoreconf -i

Then configure, build, and test as usual:
 ./configure --prefix=/usr
 make
 make check

--- David A. Wheeler

[Readable-discuss] Build error with guile-2.0

[Alex R. <rpg...@gm...>]

(Third time's the charm; darn HTML formatted message)

(I tried to send this before, but I hadn't subscribed to the list, so
it was held in queue and didn't get through)

I'm trying to build the 1.0.2 version on a 64-bit debian testing
machine. I have guile-2.0 (and guile-2.0-dev) installed. After running
./configure --without-common-lisp, I try to run make, and I get the
attached error.

I'm probably doing something wrong, but I'm not really sure what.

Any help would be appreciated. Thank you.

Error message:
----------------------

% GUILE_WARN_DEPRECATED=detailed make
/bin/mkdir -p readable
cp -p "./src/kernel.scm" readable/kernel.scm
Generating  unsweeten
Generating  bin/sweeten
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;;       or pass the --no-auto-compile argument to disable.
;;; compiling /home/alex/Misc/readable-code/./unsweeten
;;; compiling /home/alex/Misc/readable-code/readable/kernel.scm
`use-syntax' is deprecated. Please contact guile-devel for more info.
Syntax-case macros are now a part of Guile core; importing (ice-9
syncase) is no longer necessary.
;;; WARNING: compilation of
/home/alex/Misc/readable-code/readable/kernel.scm failed:
;;; ERROR: Unbound variable: temp-saved-keywords
;;; WARNING: compilation of /home/alex/Misc/readable-code/./unsweeten failed:
;;; ERROR: Wrong type (expecting symbol): (syntax-rules () ((_ . rest) #f))
Backtrace:
In ice-9/boot-9.scm:
 157: 12 [catch #t #<catch-closure 1749620> ...]
In unknown file:
   ?: 11 [apply-smob/1 #<catch-closure 1749620>]
In ice-9/boot-9.scm:
  63: 10 [call-with-prompt prompt0 ...]
In ice-9/eval.scm:
 432: 9 [eval # #]
In ice-9/boot-9.scm:
2401: 8 [save-module-excursion #<procedure 1766a80 at
ice-9/boot-9.scm:4045:3 ()>]
4052: 7 [#<procedure 1766a80 at ice-9/boot-9.scm:4045:3 ()>]
1724: 6 [%start-stack load-stack ...]
1729: 5 [#<procedure 1855180 ()>]
In unknown file:
   ?: 4 [primitive-load "/home/alex/Misc/readable-code/./unsweeten"]
In ice-9/eval.scm:
 432: 3 [eval # #]
 386: 2 [eval # #]
 393: 1 [eval #<memoized set-read-mode> (#f #f ((())) ...)]
In unknown file:
   ?: 0 [memoize-variable-access! #<memoized set-read-mode>
#<directory # 173dc60>]

ERROR: In procedure memoize-variable-access!:
ERROR: Unbound variable: set-read-mode
Makefile:1146: recipe for target 'bin/sweeten' failed
make: *** [bin/sweeten] Error 1


--
          Alex R

Re: [Readable-discuss] Readable version 1.0.2 released!

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

On Sat, 28 Jun 2014 21:50:53 -0400, John Cowan <co...@me...> wrote:

> Another point is that not supporting `else` is non-conformant all the
> way back to R2RS. Not supporting it makes Guile 1.6 a Not-Quite-Scheme.

Which just shows the need for standards and standards test suites.
To be fair, guile fixed this years ago.

> A third point is that a one-line hack for Guile 1.6 fixes the problem:
> 
> 	(define else #t)
> 
> Just make sure this line isn't present for any real Scheme.

I doubt that'll work.  "else" is also used in (cond-expand ...) and (case ...).
I don't have a guile 1.6 handy, but I do have guile 1.8.  In 1.8, this works:
  (case #\a (else (display "hi")))
yet this fails:
  (define else #t)
  (case #\a (else (display "hi")))
and I suspect the same would be true for guile 1.6.

Thanks for the idea though!!

--- David A. Wheeler

Re: [Readable-discuss] Readable version 1.0.2 released!

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

David A. Wheeler scripsit:

> Perhaps more importantly, GNU Guile 2.0.0 was released on 2011-02-16.

Not so important, because Guile 2.x is not a drop-in replacement for
Guile 1.x, and many distros don't have it even yet, or have both.
So Guile 1.8 support is still important.

Another point is that not supporting `else` is non-conformant all the
way back to R2RS.  Not supporting it makes Guile 1.6 a Not-Quite-Scheme.

A third point is that a one-line hack for Guile 1.6 fixes the problem:

	(define else #t)

Just make sure this line isn't present for any real Scheme.

-- 
John Cowan          http://www.ccil.org/~cowan        co...@cc...
In the sciences, we are now uniquely privileged to sit side by side
with the giants on whose shoulders we stand.  --Gerald Holton

Re: [Readable-discuss] Readable version 1.0.2 released!

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

On Sat, 28 Jun 2014 08:15:15 +0800, Alan Manuel Gloria <alm...@gm...> wrote:
> Since I'm pretty much the only one who wants Guile 1.6 support, and
> I'm pretty satisfied with the perfectly working old version, feel free
> to drop Guile 1.6 support.  I just wanted to make clear the reason for
> why #t was used in the first place ^^.

Okay.  If you (or anyone else) thinks we need to re-add guile 1.6 support,
we could do it using autoconf and text substitution.  That way the source code
would be clean modern code, and then transformed for execution only when needed.
I'd be happy to add it, after all, you're co-author of the spec and your work has been
instrumental in making the readable stuff happen.  But you're satisfied, and I don't
know of anyone else using such an old version of guile.

GNU Guile 1.8.0 was released on 2006-02-12 (https://www.gnu.org/software/guile/old-news.html),
over 8 years ago.  Perhaps more importantly, GNU Guile 2.0.0 was released on 2011-02-16.
That's enough time for most people to have updated beyond 1.6, and over time
I expect that even fewer and fewer people will care about guile version 1.6.

--- David A. Wheeler

Re: [Readable-discuss] Readable version 1.0.2 released!

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

On Thu, Jun 26, 2014 at 10:33 AM, David A. Wheeler
<dwh...@dw...> wrote:
> On Wed, 25 Jun 2014 05:28:39 +0800, Alan Manuel Gloria <alm...@gm...> wrote:
>> (cond ... else) doesn't work in Guile 1.6 (it's why I coded them as
>> (cond .. #t) in the first place).
>
> Drat. As noted in the ChangeLog, (cond... #t) causes warnings in chicken Scheme.
>
> Hmm.  We already do some text processing of kernel.scm in the final build.
> Perhaps we could detect if (cond ... else) is rejected in configure, and if it is,
> then substitute the relevant "(else ..." into "(#t ...".
>
> Does replacing all "(else " with "(#t " in kernel.scm work in guile 1.6?
> That would also affect some cond-expand and case statements, as well as cond statements.
> If we have to only substitute some & not others, we could insert some comments
> to enable or inhibit text substitution.  That might be the simplest solution.
> That way most people just see "standard modern Scheme" while users of the
> old guile version 1.6 get working code.

*shrug* I am personally not bothered with (else ..).  I already do
have the working old code that works on 1.6, and I don't really
foresee any significant increase in the core functionality (viz.
INDENTED SCHEME) any time soon, and my code mostly works anyway, since
I copied the old version into my program (I run it as the program's
"compile" step from .sscm to .scm).

Since I'm pretty much the only one who wants Guile 1.6 support, and
I'm pretty satisfied with the perfectly working old version, feel free
to drop Guile 1.6 support.  I just wanted to make clear the reason for
why #t was used in the first place ^^.

>
> --- David A. Wheeler

Re: [Readable-discuss] Readable version 1.0.2 released!

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

On Wed, 25 Jun 2014 05:28:39 +0800, Alan Manuel Gloria <alm...@gm...> wrote:
> (cond ... else) doesn't work in Guile 1.6 (it's why I coded them as
> (cond .. #t) in the first place).

Drat. As noted in the ChangeLog, (cond... #t) causes warnings in chicken Scheme.

Hmm.  We already do some text processing of kernel.scm in the final build.
Perhaps we could detect if (cond ... else) is rejected in configure, and if it is,
then substitute the relevant "(else ..." into "(#t ...".

Does replacing all "(else " with "(#t " in kernel.scm work in guile 1.6?
That would also affect some cond-expand and case statements, as well as cond statements.
If we have to only substitute some & not others, we could insert some comments
to enable or inhibit text substitution.  That might be the simplest solution.
That way most people just see "standard modern Scheme" while users of the
old guile version 1.6 get working code.

--- David A. Wheeler

Re: [Readable-discuss] Readable version 1.0.2 released!

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

Drat.  What do you suggest?



On June 24, 2014 5:28:39 PM EDT, Alan Manuel Gloria <alm...@gm...> wrote:
>On Mon, Jun 23, 2014 at 3:41 AM, David A. Wheeler
><dwh...@dw...> wrote:
>> Version 1.0.2 of the "readable" package is now available!!
>>
>> It's a collection of small tweaks and improvements, primarily in the
>documentation and Scheme implementation.  Having many small
>improvements is a *good* thing.  In particular, there are no
>incompatible interface/language changes; I view avoiding incompatible
>language changes as critically important.
>>
>> Below is the ChangeLog entry for this version, which describes the
>highlights.  If you want more detail, "git log -p" will tell all.
>>
>> --- David A. Wheeler
>>
>>
>> ChangeLog for version 1.0.2:
>>         * Various minor Scheme bug fixes, e.g., improve EOF handling
>during
>>           symbol reading, fix detection of unsupported #.
>>         * Many portability improvements, especially for Chicken
>Scheme and
>>           rscheme.  E.G., remove all "#:" in source,
>>           change "throw" to "raise", rename internal "body" to
>"read-body".
>>           Modify sweet-run so it works unchanged on Mac OS Darwin.
>>         * Many changes to eliminate warnings in various Schemes,
>e.g.,
>>           change (cond .. #t) to (cond .. else); either is legal
>Scheme,
>>           but chicken Scheme emits warnings on the former.
>
>(cond ... else) doesn't work in Guile 1.6 (it's why I coded them as
>(cond .. #t) in the first place).
>
>>         * Add the following as delimiters: #\' and #\` and #\.
>>           These are not required to be delimiters in Scheme, but
>>           they can be, and doing so means that we can detect syntax
>errors
>>           of very dodgy constructs.  This means that x'y will be
>>           considered an error, not a 3-char symbol.  We can already
>express
>>           that as |x'y|, and (x 'y) or x('y) work for making a list.
>>         * Optimize read-digits.
>>         * Improve Scheme error reporting when giving "Unexpected text
>>           after n-expression" by reporting the next (peeked)
>character.
>>         * Add #!keyword-prefix and #!keyword-suffix support so can
>handle
>>           syntax like STUFF: and :STUFF.
>>         * Modify Scheme sweet-run so that it returns the program exit
>code.
>>         * Add type annotations in chicken format, and ensure it does
>not
>>           interfere with other Schemes like guile.
>>
>>
>>
>------------------------------------------------------------------------------
>> HPCC Systems Open Source Big Data Platform from LexisNexis Risk
>Solutions
>> Find What Matters Most in Your Big Data with HPCC Systems
>> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
>> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
>> http://p.sf.net/sfu/hpccsystems
>> _______________________________________________
>> Readable-discuss mailing list
>> Rea...@li...
>> https://lists.sourceforge.net/lists/listinfo/readable-discuss

--- David A.Wheeler

Re: [Readable-discuss] Readable version 1.0.2 released!

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

On Mon, Jun 23, 2014 at 3:41 AM, David A. Wheeler <dwh...@dw...> wrote:
> Version 1.0.2 of the "readable" package is now available!!
>
> It's a collection of small tweaks and improvements, primarily in the documentation and Scheme implementation.  Having many small improvements is a *good* thing.  In particular, there are no incompatible interface/language changes; I view avoiding incompatible language changes as critically important.
>
> Below is the ChangeLog entry for this version, which describes the highlights.  If you want more detail, "git log -p" will tell all.
>
> --- David A. Wheeler
>
>
> ChangeLog for version 1.0.2:
>         * Various minor Scheme bug fixes, e.g., improve EOF handling during
>           symbol reading, fix detection of unsupported #.
>         * Many portability improvements, especially for Chicken Scheme and
>           rscheme.  E.G., remove all "#:" in source,
>           change "throw" to "raise", rename internal "body" to "read-body".
>           Modify sweet-run so it works unchanged on Mac OS Darwin.
>         * Many changes to eliminate warnings in various Schemes, e.g.,
>           change (cond .. #t) to (cond .. else); either is legal Scheme,
>           but chicken Scheme emits warnings on the former.

(cond ... else) doesn't work in Guile 1.6 (it's why I coded them as
(cond .. #t) in the first place).

>         * Add the following as delimiters: #\' and #\` and #\.
>           These are not required to be delimiters in Scheme, but
>           they can be, and doing so means that we can detect syntax errors
>           of very dodgy constructs.  This means that x'y will be
>           considered an error, not a 3-char symbol.  We can already express
>           that as |x'y|, and (x 'y) or x('y) work for making a list.
>         * Optimize read-digits.
>         * Improve Scheme error reporting when giving "Unexpected text
>           after n-expression" by reporting the next (peeked) character.
>         * Add #!keyword-prefix and #!keyword-suffix support so can handle
>           syntax like STUFF: and :STUFF.
>         * Modify Scheme sweet-run so that it returns the program exit code.
>         * Add type annotations in chicken format, and ensure it does not
>           interfere with other Schemes like guile.
>
>
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> _______________________________________________
> Readable-discuss mailing list
> Rea...@li...
> https://lists.sourceforge.net/lists/listinfo/readable-discuss

[Readable-discuss] Readable version 1.0.2 released!

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

Version 1.0.2 of the "readable" package is now available!!

It's a collection of small tweaks and improvements, primarily in the documentation and Scheme implementation.  Having many small improvements is a *good* thing.  In particular, there are no incompatible interface/language changes; I view avoiding incompatible language changes as critically important.

Below is the ChangeLog entry for this version, which describes the highlights.  If you want more detail, "git log -p" will tell all.

--- David A. Wheeler


ChangeLog for version 1.0.2:
        * Various minor Scheme bug fixes, e.g., improve EOF handling during
          symbol reading, fix detection of unsupported #.
        * Many portability improvements, especially for Chicken Scheme and
          rscheme.  E.G., remove all "#:" in source,
          change "throw" to "raise", rename internal "body" to "read-body".
          Modify sweet-run so it works unchanged on Mac OS Darwin.
        * Many changes to eliminate warnings in various Schemes, e.g.,
          change (cond .. #t) to (cond .. else); either is legal Scheme,
          but chicken Scheme emits warnings on the former.
        * Add the following as delimiters: #\' and #\` and #\.
          These are not required to be delimiters in Scheme, but
          they can be, and doing so means that we can detect syntax errors
          of very dodgy constructs.  This means that x'y will be
          considered an error, not a 3-char symbol.  We can already express
          that as |x'y|, and (x 'y) or x('y) work for making a list.
        * Optimize read-digits.
        * Improve Scheme error reporting when giving "Unexpected text
          after n-expression" by reporting the next (peeked) character.
        * Add #!keyword-prefix and #!keyword-suffix support so can handle
          syntax like STUFF: and :STUFF.
        * Modify Scheme sweet-run so that it returns the program exit code.
        * Add type annotations in chicken format, and ensure it does not
          interfere with other Schemes like guile.

Re: [Readable-discuss] [PATCH] fix: sweet-run invokes mktemp in a Darwin-friendly way

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

On Sun, 15 Jun 2014 12:01:12 -0700 (PDT), "ELLIOTTCABLE" <me...@el...> wrote:
> I want to fix shebang semantics, but I am on the road right now. I will try to get a patch together by tomorrow.—

I already fixed sweet-run so that it returned the exit code of the underlying program.

At least, I *think* I fixed it.

Was there something else?

--- David A. Wheeler

Re: [Readable-discuss] [PATCH] fix: sweet-run invokes mktemp in a Darwin-friendly way

[ELLIOTTCABLE <me...@el...>]

I want to fix shebang semantics, but I am on the road right now. I will try to get a patch together by tomorrow.—
Sent from Mailbox

On Sat, Jun 14, 2014 at 5:04 PM, David A. Wheeler <dwh...@dw...>
wrote:

> On Sat, 14 Jun 2014 11:56:13 -0500, Elliott Cable <me...@el...> wrote:
>> This fixes the following error arising on Mac OS X machines:
>> 
>>     > sweet-run something.sscp
>>     usage: mktemp [-d] [-q] [-t prefix] [-u] template ...
>>           mktemp [-d] [-q] [-u] -t prefix
>>     /usr/local/bin/sweet-run: line 20: : No such file or directory
>>     chmod: fts_open: No such file or directory
>>     /usr/local/bin/sweet-run: line 30: ./: is a directory
>> 
>> The meat of the solution is by "krinkle" [on Stack Overflow.][1]
>>    [1]: <http://unix.stackexchange.com/a/84980> "Fix or alternative
>> for mktemp in OS X"
> Awesome, thanks!! That's now in the "devel" branch.
> I added a testcase specifically for sweet-run.  In the process, I found that sweet-run didn't
> return the exit code of the executed program.  So we now have a test case and another
> two improvements of sweet-run.
> Does anyone have any other changes before a new release?
> --- David A. Wheeler

Re: [Readable-discuss] [PATCH] fix: sweet-run invokes mktemp in a Darwin-friendly way

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

On Sat, 14 Jun 2014 11:56:13 -0500, Elliott Cable <me...@el...> wrote:
> This fixes the following error arising on Mac OS X machines:
> 
>     > sweet-run something.sscp
>     usage: mktemp [-d] [-q] [-t prefix] [-u] template ...
>           mktemp [-d] [-q] [-u] -t prefix
>     /usr/local/bin/sweet-run: line 20: : No such file or directory
>     chmod: fts_open: No such file or directory
>     /usr/local/bin/sweet-run: line 30: ./: is a directory
> 
> The meat of the solution is by "krinkle" [on Stack Overflow.][1]
>    [1]: <http://unix.stackexchange.com/a/84980> "Fix or alternative
> for mktemp in OS X"

Awesome, thanks!! That's now in the "devel" branch.

I added a testcase specifically for sweet-run.  In the process, I found that sweet-run didn't
return the exit code of the executed program.  So we now have a test case and another
two improvements of sweet-run.

Does anyone have any other changes before a new release?

--- David A. Wheeler

[Readable-discuss] [PATCH] fix: sweet-run invokes mktemp in a Darwin-friendly way

[Elliott C. <me...@el...>]

This fixes the following error arising on Mac OS X machines:

    > sweet-run something.sscp
    usage: mktemp [-d] [-q] [-t prefix] [-u] template ...
          mktemp [-d] [-q] [-u] -t prefix
    /usr/local/bin/sweet-run: line 20: : No such file or directory
    chmod: fts_open: No such file or directory
    /usr/local/bin/sweet-run: line 30: ./: is a directory

The meat of the solution is by "krinkle" [on Stack Overflow.][1]

   [1]: <http://unix.stackexchange.com/a/84980> "Fix or alternative
for mktemp in OS X"

Signed-off-by: elliottcable <me...@el...>
---
 src/sweet-run | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/sweet-run b/src/sweet-run
index b40952c..d4fdca9 100755
--- a/src/sweet-run
+++ b/src/sweet-run
@@ -11,7 +11,7 @@
 #   ;!#
 # Where "guile -s" might be "scsh -s" or similar.

-result="$(mktemp)"
+result="$(mktemp 2>/dev/null || mktemp -t 'sweet-run')"

 export PATH="@PATH_PREFIX@$PATH"

-- 
2.0.0

[Readable-discuss] Release updated "readable" package?

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

I'd like to release an updated readable package relatively soon.  Any objections?

There are no major changes, but we have a few minor ones, e.g., error-detection of x'x and static type declarations for systems that support them.  There are also small documentation improvements.

After trying it out a little bit I'm not sure I really want to create Lisp source files that have to undergo text processing.  So although I started that discussion months ago, I doubt I'll go that direction... so there's no particular reason to wait.

--- David A. Wheeler

Re: [Readable-discuss] readable 1.0.0 submitted to Homebrew for Mac OS X machines

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

On Fri, 13 Jun 2014 19:48:32 -0500, Elliott Cable <me...@el...> wrote:
> Installation on OS X is now as simple as `brew install readable`. (=

That is awesome!!  Thanks so much!


> I'm not familiar with Common Lisp, or setting up a Common
> Lisp-compatible system, so my formula only supports the Guile
> installation. They accept pull-requests, if any of you wish to fix
> that.
> 
> Much love. <'3

I don't have a Mac, so I can't fix that. Perhaps someone else can!

Many Common Lisp users use QuickLisp, or at least ASDF, so
Mac users aren't completely out in the cold.  But if we can make things
better that'd be great.


--- David A. Wheeler

[Readable-discuss] readable 1.0.0 submitted to Homebrew for Mac OS X machines

[Elliott C. <me...@el...>]

Installation on OS X is now as simple as `brew install readable`. (=

I'm not familiar with Common Lisp, or setting up a Common
Lisp-compatible system, so my formula only supports the Guile
installation. They accept pull-requests, if any of you wish to fix
that.

Much love. <'3


⁓ ELLIOTTCABLE — fly safe.
  http://ell.io/tt

Re: [Readable-discuss] spinoff wisp srfi

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

The specifications do not indicate what the supported elements are.
What happens if I input the C string "(define foo\n  bar)\n"? (or in
short, is parentheses supported?)  You reference SRFI-105, but only as
an indirect reference from SRFI-110.  I'd assume you want each "token"
in your syntax to actually be neoteric but it's not spelled out.  Or
is each "token" just a Lisp atom?  How about vector literals?

On Mon, Jun 9, 2014 at 1:50 AM, Arne Babenhauserheide <arn...@we...> wrote:
> Hi Alan,
>
> Am Sonntag, 1. Juni 2014, 08:35:58 schrieb Alan Manuel Gloria:
>> It might be better to extend your clarification section a little.  I
>> think your intent here is that : at the beginning of a line adds an
>> extra open parentheses that gets closed at end-of-line (rule 4.2.7)
>> *and* defines an indentation level.
>
> Thank you for spotting that - and thanks for checking the SRFI!
>
> Thank to your commetn, I also found another point where I wasn’t spelling the intent exactly enough: it defines an indentation level *at the position of the colon*.
>
> I now added your note to the clarifications. How should I reference you?
>
> Best wishes,
> Arne
>
>> On Thu, May 8, 2014 at 4:31 AM, Arne Babenhauserheide <arn...@we...> wrote:
>> > Hi,
>> >
>> > I worked quite a bit on my simplified readable-spinoff wisp, and since it now works pretty well, I drafted a SRFI. It is still quite rough, but the basics should be in.
>> >
>> > In the rationale I contrast it to readable, and it would be nice if you could check whether I’m fair towards readable in that.
>> >
>> > Also despite the different focus we chose, I consider you folks to be the experts on indentation-sensitive lisp, so I would be very happy to get your opinion.
>> >
>> >
>> >     http://draketo.de/proj/wisp/srfi.html
>> >
>> >
>> > Best wishes,
>> > Arne
>> > --
>> > A man in the streets faces a knife.
>> > Two policemen are there it once. They raise a sign:
>> >
>> >     “Illegal Scene! Noone may watch this!”
>> >
>> > The man gets robbed and stabbed and bleeds to death.
>> > The police had to hold the sign.
>> >
>> > …Welcome to Europe, citizen. Censorship is beautiful.
>> >
>> >    ( http://draketo.de/stichwort/censorship )
>> >
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
>> > &#149; 3 signs your SCM is hindering your productivity
>> > &#149; Requirements for releasing software faster
>> > &#149; Expert tips and advice for migrating your SCM now
>> > http://p.sf.net/sfu/perforce
>> > _______________________________________________
>> > Readable-discuss mailing list
>> > Rea...@li...
>> > https://lists.sourceforge.net/lists/listinfo/readable-discuss
>
> --
> singing a part of the history of free software:
>
> - http://infinite-hands.draketo.de
>