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

Re: [Readable-discuss] Using readable with clojure

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

On Mon, 27 Oct 2014 08:55:55 -0400, John Cowan <co...@me...> wrote:
> Well, indentation can model () or it can model []; it can't do both.
> In CL or Scheme that doesn't matter, because [] is inessential.  In
> Clojure it's essential.

I've been assuming that it'd model ().  Interesting thought though.

You can model many other things by creating a macro that passes the parameters through it.

--- David A. Wheeler

Re: [Readable-discuss] Using readable with clojure

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

David A. Wheeler scripsit:

> Not at all. The whole point is to have a syntax that is general, and
> not tied to a particular semantic. Clearly it needs to be useful for
> a given semantic, but not tied to it.

Well, indentation can model () or it can model []; it can't do both.
In CL or Scheme that doesn't matter, because [] is inessential.  In
Clojure it's essential.

-- 
John Cowan          http://www.ccil.org/~cowan        co...@cc...
After fixing the Y2K bug in an application:
        WELCOME TO <censored>
        DATE: MONDAK, JANUARK 1, 1900

Re: [Readable-discuss] Using readable with clojure

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

Not at all. The whole point is to have a syntax that is general, and not tied to a particular semantic. Clearly it needs to be useful for a given semantic, but not tied to it.

On October 26, 2014 10:43:17 PM EDT, John Cowan <co...@me...> wrote:
>David A. Wheeler scripsit:
>
>> In Clojure, "{" is already taken for maps, and "#{" for sets.  That
>interferes with {...} for infix.
>
>More importantly, [] is used to enclose lambda variables and in other
>situations in which Lisps use () for something other than application.
>I think that Readable would have to be substantially rethought, or at
>least enhanced greatly to understand the syntax (not just lexical
>syntax,
>but keyword syntax) of Clojure in order to be usable at all.
>
>-- 
>John Cowan          http://www.ccil.org/~cowan        co...@cc...
>Nobody expects the RESTifarian Inquisition!  Our chief weapon is
>surprise ... surprise and tedium  ... tedium and surprise ....
>Our two weapons are tedium and surprise ... and ruthless disregard
>for unpleasant facts....  Our three weapons are tedium, surprise, and
>ruthless disregard ... and an almost fanatical devotion to Roy
>Fielding....

--- David A.Wheeler

Re: [Readable-discuss] Using readable with clojure

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

David A. Wheeler scripsit:

> In Clojure, "{" is already taken for maps, and "#{" for sets.  That interferes with {...} for infix.

More importantly, [] is used to enclose lambda variables and in other
situations in which Lisps use () for something other than application.
I think that Readable would have to be substantially rethought, or at
least enhanced greatly to understand the syntax (not just lexical syntax,
but keyword syntax) of Clojure in order to be usable at all.

-- 
John Cowan          http://www.ccil.org/~cowan        co...@cc...
Nobody expects the RESTifarian Inquisition!  Our chief weapon is
surprise ... surprise and tedium  ... tedium and surprise ....
Our two weapons are tedium and surprise ... and ruthless disregard
for unpleasant facts....  Our three weapons are tedium, surprise, and
ruthless disregard ... and an almost fanatical devotion to Roy Fielding....

Re: [Readable-discuss] Using readable with clojure

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

On Mon, 27 Oct 2014 02:04:42 +0100, martijn brekelmans <tij...@ms...> wrote:
> Hello everybody,
> 
> 
> I'm fiddling around with clojure, and I'd like to use readable with clojure. I've scanned the wiki and mailing list for any pointers on how to use readable within a clojure project, but found nothing.
> 
> Clojure uses leiningen as its project and dependency management. There's a popular community repository for clojure libraries, but readable isn't on there. Apart from leiningen and the community repo, I have no idea how to get this working with clojure.
> 
> So, I'm looking for any pointers on how to get readable working with my clojure projects.

Thanks!  I'd love to see readable notations in Clojure,
but I have not tried to implement any of them in Clojure.
If you're willing to dive into it, that'd be great.

In some cases you could use the "unsweeten" as a preprocessor, at least as a starting point.
However, I think changes would need to be to it for serious Clojure work.

The basic Clojure syntax is here:
  http://clojure.org/reader
In Clojure, "{" is already taken for maps, and "#{" for sets.  That interferes with {...} for infix.
An implementation of the readable notations would have to determine if it will use {...} for infix,
or switch to something else like #[...].  Clojure supports dispatching via "#", so that might not be *too* bad.
An implementation could support both, but I'm guessing that it'd be best to support a
backwards-compatible notation. I'm guessing that implementing x[...] as a synonym for
(x #[...]) would be okay, but that needs investigation.

For *serious* work it should be possible to embed it as part of the reader.
The Common Lisp implementation does this for all tiers, and SRFI-105 is now
built into guile (at least).

--- David A. Wheeler

[Readable-discuss] Using readable with clojure

[martijn b. <tij...@ms...>]

Hello everybody,


I'm fiddling around with clojure, and I'd like to use readable with clojure. I've scanned the wiki and mailing list for any pointers on how to use readable within a clojure project, but found nothing.

Clojure uses leiningen as its project and dependency management. There's a popular community repository for clojure libraries, but readable isn't on there. Apart from leiningen and the community repo, I have no idea how to get this working with clojure.

So, I'm looking for any pointers on how to get readable working with my clojure projects.


Thanks for the great work so far

Greetings,
Martijn
 		 	   		  

[Readable-discuss] RELEASE of readable-1.0.5

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

We have a new release of "readable", version 1.0.5.

This version is for the Common Lisp users; the Scheme materials are unchanged.
It fixes a parsing bug in Common Lisp when sweet-expression ends without ending on EOL.
It also adds built-in capabilities in Common Lisp to print using readable notations
(Scheme already had this).

The QuickLisp version should automatically update when they do their package updates.

Enjoy!

--- David A. Wheeler

[Readable-discuss] New release of readable?

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

We have several improvements in the Common Lisp implementation
of "readable", so I think it's time to update.  (Scheme-only users need not bother.)
In particular, we have a bug-fix when an expression ends on something other than EOL,
and basic mechanisms for printing.  The mechanisms for printing simply call "write"
on some types like array (including vector), but for a vast number of use cases
it works just fine.

Any objections or last-minute patches?  Silence is consent.

Below I've attached the information about the ability to write in Common Lisp.
The text itself is written in Markdown.

--- David A. Wheeler





Writing readable expressions
============================

The "develop" branch includes additional procedures to print expressions using these readable notations, so you can easily print these notations as well as read them.  Their interfaces are intentionally similar to the standard Common Lisp procedures, so they should be easy to use.

Procedure "write-readable" writes out its first parameter in a readable notation, similar to the standard procedure write.  It takes all the optional parameters of write (such as :stream), plus the optional ":notation" parameter for controlling the output notation.  By default, the output notation is the same as the input notation.  The ":notation" parameter can be 'basic-curly-infix, 'full-curly-infix, 'neoteric, or 'sweet.  "Write-readable" will always use at least basic-curly-infix notation.  Circularity detection is available; use ":circle t" to enable it.  It also includes similar procedures print1-readable, princ-readable, and print-readable.  You can write to strings instead of the current output with write-to-string-readable, prin1-to-string-readable, and princ-to-string-readable.

The current implementation directly supports circularity detection in cons cells.  The implementation directly supports the following Common Lisp types: cons, symbol, number, character, pathname, string, and bit-vector.  Note that the "cons" is fully supported, which means that proper lists, dotted lists, and circular lists are all supported. Other types are currently partly supported by calling the underlying "write" implementation; this includes the types array (including vector), hash-table, function, readtable, package, stream, random-state, condition, and restart, as well as those created by defstruct, define-condition, or defclass.  In most cases this partial support is more than enough, but you should be aware of its limitations.   First, the contents of partially-supported types will be presented in traditional Lisp notation instead of a more readable notation (though it will still be a valid format).  Also, if you use circularity detection, the circularity detection in any partially-supported types will be separate and will not synchronize with the detection in fully-supported types. There are merely limitations of the current implementation, not of the fundamental concept.  Patches are welcome!

Here are some examples, presuming that you use-package(:readable) first and that the current notation is neoteric or sweet:

    write-readable '(+ 1 2)       ; Writes {1 + 2}
    write-readable '(+ 1 (* 3 4)) ; Writes {1 + {3 * 4}}
    write-readable '(COS X)       ; Writes COS(X)
    write-readable '(LOG 10 100)  ; Writes LOG(10 100)
    write-readable '(COS (* 2 X)) ; Writes COS{2 * X}

Syntax for basic writing procedures
-----------------------------------

**write-readable** object &key array base case circle escape gensym length level lines miser-width pprint-dispatch pretty radix readably right-margin stream notation => object

**prin1-readable** object &optional output-stream => object

**princ-readable** object &optional output-stream => object

**print-readable** object &optional output-stream => object


Arguments and values are the same as for write, with the addition of "notation" in some cases.
write-readable is the general entry point to the readable Lisp printer.  The "notation" corresponds to \*print-notation\*.

prin1-readable produces output suitable for input to read. It binds \*print-escape\* to true.

princ-readable is just like prin1 except that the output has no escape characters. It binds \*print-escape\* to false and \*print-readably\* to false. The general rule is that output from princ is intended to look good to people, while output from prin1 is intended to be acceptable to read.

print-readable is just like prin1-readable except that the printed representation of object is preceded by a newline and followed by a space.

Syntax for string writing procedures
-----------------------------------

**write-to-string-readable** object &key array base case circle escape gensym length level lines miser-width pprint-dispatch pretty radix readably right-margin => string

**prin1-to-string-readable** object => string

**princ-to-string-readable** object => string

write-to-string-readable, prin1-to-string-readable, and princ-to-string-readable are used to create a string consisting of the printed representation of object in readable notation. Object is effectively printed as if by write, prin1, or princ, respectively, and the characters that would be output are made into a string.

write-to-string-readable is the general output function.  prin1-to-string acts like write-to-string with :escape t.  princ-to-string acts like write-to-string with :escape nil :readably nil. As a result, no escape characters are written.

[Readable-discuss] Common Lisp printing pushed into "devel" branch

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

The Common Lisp implementation now has a set of printing routines, just like the Scheme implementation,
on the "devel" branch.

The external interface is designed to look like Common Lisp, not Scheme.
For example, "write-readable" is intentionally similar to "write".  Thus:
(write-readable '(1 2 3))
does what you would expect.  It takes a ":notation" parameter if you
want to control the format; by default it uses the current format, but it will
always use at least basic curly-infix.

It implements circularity checking (if you enable it with :circle t).
The current implementation handles atoms (e.g., numbers and symbols) and conses,
though not other Common Lisp datatypes (yet).

--- David A. Wheeler

Re: [Readable-discuss] Error when no empty line at end of file

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

On Fri, 3 Oct 2014 02:18:32 +0200, martijn brekelmans <tij...@ms...> wrote:
> I'm trying out readable, and I'm already finding it brilliant. I found a little bug however, in common lisp, when the file doesn't end with an empty line, it will throw an Error, Error: Unexpected text after n-expression.
> 
> Code can be found here
> 
> When I add a newline at the end of the file, all works well again. I'm using GNU CLISP 2.49.

Ahah!  I managed to duplicate the bug.

Frankly, I *never* have source code without newline at end-of-file,
so to me this is an incredibly weird case.  That said, we should gracefully handle it.

The fix turns out to be trivial, and is included below for your amusement.
Basically, procedure "it-expr-real" didn't handle EOF-without-EOL gracefully.
I expect this patch will be in the next release.

--- David A. Wheeler

=======================================================

--- a/sweet.lisp
+++ b/sweet.lisp
@@ -665,6 +665,8 @@
                                 (read-body stream new-indent)
                     (list body-new-indent (my-append line-value body-value)))
                   (list new-indent (monify line-value)))))
+          ((eof-objectp (my-peek-char stream))
+            (list " " (monify line-value)))
           (t
             (read-error "Unexpected text after n-expression")))
         ; Here, line-exprs begins with something special like GROUP-SPLIT:

Re: [Readable-discuss] Sweetening code with #'

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

> On October 4, 2014 10:00:23 AM EDT, martijn brekelmans <tij...@ms...> wrote:
> >I'm following practical lisp and there's a little bit of code using a
> >#', I can't figure out how to sweeten this piece of code. Using the
> >sweeten tool replaces #' with syntax, (the result is also in the
> >pastebin link below), but it doesn't work when running, clisp tells me
> >syntax is undefined.

It may not be as obvious as it *should* be, but near the end of the Common Lisp tutorial is this text:
> Sweeten is designed to read Scheme (or more specifically, Guile) S-expression syntax.  The "-C" option  adds some support for Common Lisp notation instead, in particular, #'function.

So just use:
sweeten -C filename.lisp > filename.slisp

and you should have a sweetened version of "filename.lisp" in "filename.slisp".
If it used #'function, it should continue to work.  Sorry that you *have* to use -C,
but the semantics of #' differ between Scheme and Common Lisp, so the
"sweeten" program has to know that you're using Common Lisp semantics.

--- David A. Wheeler

Re: [Readable-discuss] Error when no empty line at end of file

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

On Fri, 3 Oct 2014 02:18:32 +0200, martijn brekelmans <tij...@ms...> wrote:
> I'm trying out readable, and I'm already finding it brilliant.

Thanks!

> I found a little bug however, in common lisp, when the file doesn't end with an empty line, it will throw an Error, Error: Unexpected text after n-expression.
> 
> Code can be found here
> 
> When I add a newline at the end of the file, all works well again. I'm using GNU CLISP 2.49.

I've been unable to reproduce the bug using clisp version 2.48.
Your code works as expected on my systems.

Can you give me more info on your setup?

--- David A. Wheeler

Re: [Readable-discuss] Sweetening code with #'

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

Are you using the -C option in sweeten?  By default, sweeten assumes scheme syntax.  You need -C so that it knows that you are processing Common Lisp

On October 4, 2014 10:00:23 AM EDT, martijn brekelmans <tij...@ms...> wrote:
>I'm new to lisp and I thought using readable would be a great bridge
>for learning lisp. So far it's been pretty good, except for one time :(
>I'm following practical lisp and there's a little bit of code using a
>#', I can't figure out how to sweeten this piece of code. Using the
>sweeten tool replaces #' with syntax, (the result is also in the
>pastebin link below), but it doesn't work when running, clisp tells me
>syntax is undefined.
>
>Here's the piece of code that I'd like to sweeten.
>
>It would be great if the docs contained examples on sweetening
>expressions that use #' (and probably also for similar symbols, like
>').
> 		 	   		  
>
>------------------------------------------------------------------------
>
>------------------------------------------------------------------------------
>Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS
>Reports
>Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Readable-discuss mailing list
>Rea...@li...
>https://lists.sourceforge.net/lists/listinfo/readable-discuss

--- David A.Wheeler

Re: [Readable-discuss] Sweetening code with #'

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

Alan Manuel Gloria scripsit:

> In Common Lisp, #'foo means "get the function binding of foo, not the
> value binding".  I'm not sure but I think Common Lisp does not specify
> what the s-expression it should translate to.

It means (function foo), and the CL version of readable should make it so.
See <http://www.lispworks.com/documentation/HyperSpec/Body/02_dhb.htm>.
I consider failing to support that a bug.

-- 
John Cowan          http://www.ccil.org/~cowan        co...@cc...
"Hacking is the true football."  --F.W. Campbell (1863) in response to a
successful attempt to ban shin-kicking from soccer.  Today, it's biting.

Re: [Readable-discuss] Sweetening code with #'

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

#' means different things in Scheme and in Common Lisp.

In Scheme, #'foo means (syntax foo).  It allows for #'(foo bar) to
mean (syntax (foo bar))

In Common Lisp, #'foo means "get the function binding of foo, not the
value binding".  I'm not sure but I think Common Lisp does not specify
what the s-expression it should translate to.

As you can see, out of the box the current readable-lisp interprets #'
using the Scheme meaning.

Note that you may find it easier to learn Scheme than Common Lisp; for
one, Common Lisp is a Lisp-2, which means that symbols have a function
binding and a value binding.

For quote, both lisps uses the same symbol, so you can sweeten something like:

'(foo
  (bar quux)
  (nitz meow))
==>
' foo
!   bar quux
!   nitz meow

Note the space after the quote symbol in the sweetened version.
Without the space it will be interpreted as attaching to just the foo
symbol, not the entire sub-expression.

On 10/4/14, martijn brekelmans <tij...@ms...> wrote:
> I'm new to lisp and I thought using readable would be a great bridge for
> learning lisp. So far it's been pretty good, except for one time :(
> I'm following practical lisp and there's a little bit of code using a #', I
> can't figure out how to sweeten this piece of code. Using the sweeten tool
> replaces #' with syntax, (the result is also in the pastebin link below),
> but it doesn't work when running, clisp tells me syntax is undefined.
>
> Here's the piece of code that I'd like to sweeten.
>
> It would be great if the docs contained examples on sweetening expressions
> that use #' (and probably also for similar symbols, like ').
>

[Readable-discuss] Sweetening code with #'

[martijn b. <tij...@ms...>]

I'm new to lisp and I thought using readable would be a great bridge for learning lisp. So far it's been pretty good, except for one time :(
I'm following practical lisp and there's a little bit of code using a #', I can't figure out how to sweeten this piece of code. Using the sweeten tool replaces #' with syntax, (the result is also in the pastebin link below), but it doesn't work when running, clisp tells me syntax is undefined.

Here's the piece of code that I'd like to sweeten.

It would be great if the docs contained examples on sweetening expressions that use #' (and probably also for similar symbols, like ').
 		 	   		  

[Readable-discuss] Error when no empty line at end of file

[martijn b. <tij...@ms...>]

I'm trying out readable, and I'm already finding it brilliant. I found a little bug however, in common lisp, when the file doesn't end with an empty line, it will throw an Error, Error: Unexpected text after n-expression.

Code can be found here

When I add a newline at the end of the file, all works well again. I'm using GNU CLISP 2.49.
 		 	   		  

[Readable-discuss] Fwd: Readable Lisp - conment from Yves Cloutier

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

Fyi: we got a nice email, below, and I got permission to share it.


-------- Original Message --------
From: Yves Cloutier <yve...@gm...>
Sent: September 15, 2014 4:57:21 PM EDT
To: dwh...@dw...
Subject: Readable Lisp

Hello David,

I just came across your Readable Lisp page and wow, I'm sold!

I'm getting back into programming after almost 15 years of not doing it,
spurred by a personal project idea.

I started this project in Perl and then thought perhaps it could be done
better in another language - which eventually brought me to Lisp/Scheme.

Something really clicked with the Lisp/Scheme paradigm of doing things, but
the syntax is a bit unfamiliar from most other languages.  But the examples
of  Readable Lisp look quite familiar and I'm really interested in trying
it out.

Kudos for the initiative and work you are doing on this front.  I think
that if more people would know about this, it could be very important for
Lisp/Scheme....

Regards,

yves

--- David A.Wheeler

Re: [Readable-discuss] spinoff wisp srfi

[Arne B. <arn...@we...>]

Hi David,

Am Sonntag, 8. Juni 2014, 18:05:53 schrieb David A. Wheeler:
> A few comments, though, besides ones already made.  I have concerns that lone ":" is actually *widely* used for other purposes, e.g., type declarations, that this syntax interferes with.  Similarly, "_" has many uses on its own.  I think it'd be wise to grab a bunch of code and try to reformat it this way.  I did that a *LOT* to create SRFI-110; a lot of syntax that SEEMS like a good idea doesn't actually work well with real code.

For _ this should not be too bad: It only has a special meaning in wisp when used as the very first character in a line (then the underscore and consecutive underscores are treated as whitespace).

For : I am not perfectly sure. I know that typed racket uses it for type-declarations¹, so this is a regression. On the other hand this only hurts for top-level defines, where it is seldomly needed. I added some details under http://draketo.de/proj/wisp/srfi.html#sec-3-2 (disadvantages of wisp).

¹: http://docs.racket-lang.org/ts-guide/more.html?q=typed#%28part._.Type_.Annotation_and_.Binding_.Forms%29

Best wishes,
Arne

Re: [Readable-discuss] spinoff wisp srfi

[Arne B. <arn...@we...>]

Hi Alan,

Am Montag, 9. Juni 2014, 06:51:44 schrieb Alan Manuel Gloria:
> 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?)  

Within parentheses whitespace parsing is disabled, so you can just
throw in any lisp code without changing its behavior.

I just saw that I only said this in the clarifications. It’s fixed
now. Thanks!

> 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?

If I understand your question correctly, generally each token is
simply a Lisp atom. It can be used as neoteric if you activate
SRFI-105 (so you can use suffix-parens to make it a function-call).

Best wishes,
Arne

> 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
> >

--
Ich hab' nichts zu verbergen – hab ich gedacht: 

- http://draketo.de/licht/lieder/ich-hab-nichts-zu-verbergen

Re: [Readable-discuss] spinoff wisp srfi

[Arne B. <arn...@we...>]

Am Montag, 9. Juni 2014, 06:34:16 schrieb Alan Manuel Gloria:
> Hmm?  A name in the acknowledgements section maybe?  As "Alan Manuel K. Gloria".

It’s in.

Best wishes,
Arne

Re: [Readable-discuss] spinoff wisp srfi

[Arne B. <arn...@we...>]

Hi David,

Sorry for answering so late. I already adjusted the draft according to some of your comments, but did not get out of the todo-torrent far enough to answer you and finish the rest…

Am Sonntag, 8. Juni 2014, 18:05:53 schrieb David A. Wheeler:
> On Sun, 08 Jun 2014 19:50:45 +0200, Arne Babenhauserheide <arn...@we...> wrote:
> > > > 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

> I don't think that wisp "supercedes" SRFI-105 or SRFI-110; I would instead say it describes an "alternative to".
> Indeed, I suspect a system could simultaneously use SRFI-105 and wisp.

For 105 the SRFi uses the wording “builds upon”: That’s what it actually does: I nowadays use SRFI-105 and wisp together. Sadly the integration isn’t quite as seamless as with SRFI-110, because curly infix and neoteric expressions as first element on a line have to be prefixed by a dot. I wish that were different, but to achieve this I would have to increase complexity quite a bit. And I guess an adaption to treat ({1 + 2}) as {1 + 2} (which would be a simpler version of SRFI-105) could disable some options (like using curly infix to chain functions).

For 110 I now use “alternative to” (which is much closer to what wisp actually is: A different style to achieve the same). Only SRFI-49 is really superceded by wisp.

> > "SRFI-110 improves a lot over the implementation of SRFI-49 and resolves the group-naming by introducing 3 different grouping-syntaxes ($, \\ and <* *>). These additional syntax-elements however hurt readability for newcomers a lot. They make some code written in SRFI-110 look quite similar to perl and bash:"
> I don't agree that they "hurt readability" at all, indeed, I think they help.  I suggest changing this (and elsewhere) to something like "The author believes that these additional syntax elements impede readability because...".  Also, I know both perl and bash, and the resulting code doesn't look anything like either.  The "$" stuff looks like Haskell, if anything.

To me they look very, very strange: They use rare characters (seldomly used in normal prose) which makes the code look alien to non-programmers. Even simple constructs like this->run() look strange to non-programmers - which is far too easy to forget when we’re deep in code.

Also they look like they were bolted on - not in the initial design - and as if they were taking over more and more of the code. In this they are similar to list comprehensions in Python: They are very convenient and powerful - too powerful to understand them easily. You show how 4 lines of code can be contracted bit by bit into 1 line with $. And this is 

> The spec overview in 4.1 needs to clearly define *what* each syntax element does, at least as a basic case.  Examples are great for clarifying definitions, but do not *replace* them.  E.G., "A lone period at the beginning of a line (after any indentation) causes that line to continue the previous line."  Or something like that.

I had expected that the headlines did that, but doing so used headlines for something out of their normal usecase - likely that’s a bad idea. Thanks for spotting it!

I now moved the rules from the headlines to the subsection body and used short headlines.

> s/synatx/syntax/

Thanks!

> I would move "justification" to separate section.  Users often don't care WHY something is so... they just need to know what it is.

Good idea.

> I obviously agree that a better homoiconic syntax is needed for Lisp.  I also obviously don't agree that the choices you've made are the best ones, since I made different choices :-).

Yepp.

> A few comments, though, besides ones already made.  I have concerns that lone ":" is actually *widely* used for other purposes, e.g., type declarations, that this syntax interferes with.  Similarly, "_" has many uses on its own.  I think it'd be wise to grab a bunch of code and try to reformat it this way.  I did that a *LOT* to create SRFI-110; a lot of syntax that SEEMS like a good idea doesn't actually work well with real code.  And while simplicity is a *great* goal, too simple is its own problem. 

I agree. It’s just that we don’t agree on the right degree of simplicity ☺

And I think that’s OK: It comes down to taste. I’m used to the mostly hidden syntax of Basic Python¹, so what I try to find is a syntax and semantic which combines the power of Scheme with the syntax of Basic Python. Seeing code with such little syntactic ballast impressed me so deeply that I actually wrote a song about it ☺ http://draketo.de/english/songs/light/with-python-from-the-shadows

¹:  With Basic Python I mean everything short of list/dict comprehensions. As soon as you throw in these advanced concepts, the syntax of Python actually shows more and more - which is a bad thing in my opinion. See py2guile for more arguments in that direction: http://draketo.de/proj/py2guile/#sec-4-1

> All we *really* need is 1 and 0; anything else is extraneous syntax :-).

☺

Differently put: All Turing complete languages differ solely on syntactic sugar. (Adventures of a Pythonista in Schemeland: http://www.phyast.pitt.edu/~micheles/scheme/scheme12.html#are-macros-just-syntactic-sugar)

Best wishes,
Arne
-- 
1w6 sie zu achten,
sie alle zu finden,
in Spiele zu leiten
und sacht zu verbinden.
→ http://1w6.org

Re: [Readable-discuss] Readable Lisp version 1.0.4 released!!

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

I haven't heard any complaints, so I presume version 1.0.4 fixed the earlier portability regressions.  I did test it on a variety of systems. It *should* even work on guile 1.6, but I don't have test system for that.

Alan: If you get a chance, let us know if it's working again on guile 1.6.  The code is *written* with modern Scheme, but it tries to detect guile 1.6 and then patch as necessary.

--- David A. Wheeler

[Readable-discuss] Common Lisp printing - early feedback/comments?

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

The Scheme "readable" implementation includes ways to write out values using the new notations,
but the Common Lisp implementation lacks these capabilities.  I'd like to modify the Common Lisp
implementation to add this (giving it parity with the Scheme functionality).

Below is a start at adding them, focusing more on which functions to add.
Any comments?

The trick is to make it appear relatively "native" to Common Lisp.
Currently I'm just defun'ing several standard Common Lisp functions with "-readable"
in the names.  Yes, they're in separate packages, but I want people to be able to
bring them into their local namespace without problems.

--- David A. Wheeler


=========================================




;;;; Output routines for readable notations.
;;;; Use *print-notation* to decide what notation to use when writing.

;;;; Some of this code is derived from SBCL, which was in turn
;;;; derived from the CMU CL system, which was written at
;;;; Carnegie Mellon University and released into the public domain.

(cl:in-package :readable)

(defun write-readable (object &key
                     ((:stream stream) *standard-output*)
                     ((:escape *print-escape*) *print-escape*)
                     ((:radix *print-radix*) *print-radix*)
                     ((:base *print-base*) *print-base*)
                     ((:circle *print-circle*) *print-circle*)
                     ((:pretty *print-pretty*) *print-pretty*)
                     ((:level *print-level*) *print-level*)
                     ((:length *print-length*) *print-length*)
                     ((:case *print-case*) *print-case*)
                     ((:array *print-array*) *print-array*)
                     ((:gensym *print-gensym*) *print-gensym*)
                     ((:readably *print-readably*) *print-readably*)
                     ((:right-margin *print-right-margin*)
                      *print-right-margin*)
                     ((:miser-width *print-miser-width*)
                      *print-miser-width*)
                     ((:lines *print-lines*) *print-lines*)
                     ((:pprint-dispatch *print-pprint-dispatch*)
                      *print-pprint-dispatch*)
                     ((:suppress-errors *suppress-print-errors*)
                      *suppress-print-errors*)
                     ((:notation *print-notation*) *print-notation*))
  #+sb-doc
  "Output OBJECT to the specified stream, defaulting to *STANDARD-OUTPUT*."
  (output-object-readable object (out-synonym-of stream))
  object)

(defun prin1-readable (object &optional stream)
  #+sb-doc
  "Output a mostly READable printed representation of OBJECT on the specified
  STREAM."
  (let ((*print-escape* t))
    (output-object-readable object (out-synonym-of stream)))
  object)

(defun princ-readable (object &optional stream)
  #+sb-doc
  "Output an aesthetic but not necessarily READable printed representation
  of OBJECT on the specified STREAM."
  (let ((*print-escape* nil)
        (*print-readably* nil))
    (output-object-readable object (out-synonym-of stream)))
  object)

(defun print-readable (object &optional stream)
  #+sb-doc
  "Output a newline, the mostly READable printed representation of OBJECT, and
  space to the specified STREAM."
  (let ((stream (out-synonym-of stream)))
    (terpri stream)
    (prin1 object stream)
    (write-char #\space stream)
    object))

(defun pprint-readable (object &optional stream)
  #+sb-doc
  "Prettily output OBJECT preceded by a newline."
  (let ((*print-pretty* t)
        (*print-escape* t)
        (stream (out-synonym-of stream)))
    (terpri stream)
    (output-object-readable object stream))
  (values))

(defun write-to-string-readable
    (object &key
            ((:escape *print-escape*) *print-escape*)
            ((:radix *print-radix*) *print-radix*)
            ((:base *print-base*) *print-base*)
            ((:circle *print-circle*) *print-circle*)
            ((:pretty *print-pretty*) *print-pretty*)
            ((:level *print-level*) *print-level*)
            ((:length *print-length*) *print-length*)
            ((:case *print-case*) *print-case*)
            ((:array *print-array*) *print-array*)
            ((:gensym *print-gensym*) *print-gensym*)
            ((:readably *print-readably*) *print-readably*)
            ((:right-margin *print-right-margin*) *print-right-margin*)
            ((:miser-width *print-miser-width*) *print-miser-width*)
            ((:lines *print-lines*) *print-lines*)
            ((:pprint-dispatch *print-pprint-dispatch*)
             *print-pprint-dispatch*)
            ((:suppress-errors *suppress-print-errors*)
             *suppress-print-errors*)
            ((:notation *print-notation*) *print-notation*))
  #+sb-doc
  "Return the printed representation of OBJECT as a string."
  (stringify-object object))

(defun prin1-to-string-readable (object)
  #+sb-doc
  "Return the printed representation of OBJECT as a string with
   slashification on."
  (let ((*print-escape* t))
    (stringify-object object)))

(defun princ-to-string-readable (object)
  #+sb-doc
  "Return the printed representation of OBJECT as a string with
  slashification off."
  (let ((*print-escape* nil)
        (*print-readably* nil))
    (stringify-object object)))

;;; This produces the printed representation of an object as a string.
;;; The few ...-TO-STRING functions above call this.
(defun stringify-object-readable (object)
  (let ((stream (make-string-output-stream)))
    (setup-printer-state)
    (output-object-readable object stream)
    (get-output-stream-string stream)))


;;; TODO: Output but possibly using extended notation (depending on
;;; the value of *print-notation*). Use the traditional values of "write".
;;; The following is a stub.
(defun output-object-readable (object stream)
    (output-object object stream))

[Readable-discuss] Readable Lisp version 1.0.4 released!!

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

The readable lisp library version 1.0.4 is now released!!  This version improves its portability, so it should work on more systems; it includes a regression fix for guile 2.

Download from:
 https://sourceforge.net/projects/readable/files/

Install instructions:
 https://sourceforge.net/p/readable/wiki/Install-howto/

Website for all other information:
 http://readable.sourceforge.net/

Enjoy!

--- David A. Wheeler