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

Re: [Readable-discuss] spinoff wisp srfi

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

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

Hmm?  A name in the acknowledgements section maybe?  As "Alan Manuel K. Gloria".

Sincerely,
AmkG

Re: [Readable-discuss] spinoff wisp srfi

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

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 didn't have a lot of time, but I took a few minutes & hope my comments help.

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.

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

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.

s/synatx/syntax/

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

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 :-).

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.  All we *really* need is 1 and 0; anything else is extraneous syntax :-).

--- David A. Wheeler

Re: [Readable-discuss] spinoff wisp srfi

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

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

Re: [Readable-discuss] Damage done.

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

On Sun, May 11, 2014 at 12:45 AM, John Cowan <co...@me...> wrote:
> Jörg F. Wittenberger scripsit:
>
>> With cdata we'd need to watch that no ]]> is in sweet lisp.
>
> Sweet-expressions don't use square brackets for anything.
>

Not quite.  Neoteric defines "[ x ]" to mean exactly the same thing in
your base Lisp as it normally does (e.g. "( x )" in R6RS, "(fn (_) x)"
in Arc).  Also, Neoteric redefines "foo[ x ]" to mean
"($bracket-apply$ foo x)".

Still, the character sequence "]]>" is highly unlikely in Sweet.

Re: [Readable-discuss] spinoff wisp srfi

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

In section 4.2.7:

A colon sourrounded by whitespace (" : ") starts a bracket which gets
closed at the end of the line.

However, in your earlier set of examples 4.1.3:

let
  : x 1
    y 2
    z 3
  body

It's not entirely clear how your example interacts with rule 4.2.7.

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.


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

Re: [Readable-discuss] Damage done.

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

Jörg F. Wittenberger scripsit:

> With cdata we'd need to watch that no ]]> is in sweet lisp.

Sweet-expressions don't use square brackets for anything.

> Cdata does not work for attribute values.

Sweet-expressions can't go in attribute values, because XML processors
convert all newlines to spaces anyway.  (Yes, this is a misfeature,
but we are stuck with it from SGML days.  At teh Goog, I was once asked
to figure out why email messages wrapped in XML weren't round-tripping:
it turned out to be because the whole message was being stuffed into an
attribute, and it was returned as a single line.)

> Many web devs need to be told what cdata actually is.

Many will need to be told what Lisp actually is, too.

> Most of this embedded code is rather short. The wrapping would - too - 
> defeat the purpose of a readable source.

That's your strongest point, I think.

-- 
John Cowan          http://www.ccil.org/~cowan        co...@cc...
If a soldier is asked why he kills people who have done him no harm, or a
terrorist why he kills innocent people with his bombs, they can always
reply that war has been declared, and there are no innocent people in an
enemy country in wartime.  The answer is psychotic, but it is the answer
that humanity has given to every act of aggression in history.  --Northrop Frye

Re: [Readable-discuss] Damage done.

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

On May 9 2014, John Cowan wrote:

>David A. Wheeler scripsit:
>
>> This would mean that {* x *} would be interpreted *differently* by a 
>> curly-infix reader (or a neoteric reader) compared to a sweet-expression 
>> reader.
>
>I think that's a killer.

One could also argue that there are three tokens effecting whitespace 
handling: (, { and {*

{* is only valid in sweet as <* is - as required by spec. It shifts to 0 
indent.

{ shifts to curly. ( to noteric.

I'd say this is a fairly consistent and clear set of rules.

Frankly, I'd expect a dev to be a quite advanced one until the need to write

{* x -}

and want an infix operator "x" applied to * and -. By that time the dev 
should easily see that in whitespace mode {* is a marker and not the begin 
of a curly expr and figure a space would help. After all neoteric rule have 
taught the lesses to look twice for spaces.

>
>Frankly, this is what CDATA sections were made for.  Wrap your Lisp
>code in "<![CDATA[" and "]]>" brackets, and < is no longer magic.
>(Note that > is never magic, though there is an escape for it anyway.)
>
>

Re: [Readable-discuss] Damage done.

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

Sure CDATA could solve the problem. So could encoding as < .

With cdata we'd need to watch that no ]]> is in sweet lisp.

Cdata does not work for attribute values.

Many web devs need to be told what cdata actually is.

Most of this embedded code is rather short. The wrapping would - too - 
defeat the purpose of a readable source.

On May 9 2014, David A. Wheeler wrote:

>> David A. Wheeler scripsit:
>> > This would mean that {* x *} would be interpreted *differently* by a 
>> > curly-infix reader (or a neoteric reader) compared to a 
>> > sweet-expression reader.
>
> On Fri, 9 May 2014 13:37:04 -0400, John Cowan <co...@me...> 
> wrote:
>> I think that's a killer.
>> 
>> Frankly, this is what CDATA sections were made for.  Wrap your Lisp
>> code in "<![CDATA[" and "]]>" brackets, and < is no longer magic.
>> (Note that > is never magic, though there is an escape for it anyway.)
>
>Ah! Of course!  CDATA was specifically created for this.
>
>If you can limit yourself to XML (including XHTML) and SGML,
>using CDATA sections is almost certainly the best answer.
>The one caveat is that HTML doesn't support CDATA directly.
>However, if you're just *processing* it as XML, you can always
>read it as XML and then transform it however you like.
>
>--- David A. Wheeler
>
>  
> ------------------------------------------------------------------------------ 
> 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

Re: [Readable-discuss] Damage done.

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

On Fri, 9 May 2014 16:00:58 -0400, John Cowan <co...@me...> wrote:
> In HTML, <* and *> Just Work, without a problem, at least if they are
> surrounded by whitespace.

Agreed.  If I read the HTML5 spec on whatwg correctly,
"<*" MUST be passed through as text in HTML5:
  http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#tag-open-state

--- David A. Wheeler

Re: [Readable-discuss] Damage done.

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

David A. Wheeler scripsit:

> If you can limit yourself to XML (including XHTML) and SGML, using
> CDATA sections is almost certainly the best answer.  The one caveat
> is that HTML doesn't support CDATA directly.

In HTML, <* and *> Just Work, without a problem, at least if they are
surrounded by whitespace.

-- 
John Cowan          http://www.ccil.org/~cowan        co...@cc...
Would your name perchance be surname Puppet, given name Sock?
                --Rick Moen

Re: [Readable-discuss] Damage done.

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

> David A. Wheeler scripsit:
> > This would mean that {* x *} would be interpreted *differently*
> > by a curly-infix reader (or a neoteric reader) compared to a sweet-expression reader.

On Fri, 9 May 2014 13:37:04 -0400, John Cowan <co...@me...> wrote:
> I think that's a killer.
> 
> Frankly, this is what CDATA sections were made for.  Wrap your Lisp
> code in "<![CDATA[" and "]]>" brackets, and < is no longer magic.
> (Note that > is never magic, though there is an escape for it anyway.)

Ah! Of course!  CDATA was specifically created for this.

If you can limit yourself to XML (including XHTML) and SGML,
using CDATA sections is almost certainly the best answer.
The one caveat is that HTML doesn't support CDATA directly.
However, if you're just *processing* it as XML, you can always
read it as XML and then transform it however you like.

--- David A. Wheeler

Re: [Readable-discuss] Damage done.

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

David A. Wheeler scripsit:

> This would mean that {* x *} would be interpreted *differently*
> by a curly-infix reader (or a neoteric reader) compared to a sweet-expression reader.

I think that's a killer.

Frankly, this is what CDATA sections were made for.  Wrap your Lisp
code in "<![CDATA[" and "]]>" brackets, and < is no longer magic.
(Note that > is never magic, though there is an escape for it anyway.)

-- 
John Cowan          http://www.ccil.org/~cowan        co...@cc...
And now here I was, in a country where a right to say how the country should
be governed was restricted to six persons in each thousand of its population.
For the nine hundred and ninety-four to express dissatisfaction with the
regnant system and propose to change it, would have made the whole six
shudder as one man, it would have been so disloyal, so dishonorable, such
putrid black treason.  --Mark Twain's Connecticut Yankee

Re: [Readable-discuss] Unused procedures

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

On Fri, 09 May 2014 14:07:36 +0200, "Jörg F. Wittenberger"
	<Joe...@so...> wrote:

> BTW: I'm getting warnings about unused procedures:
> 
> appende
> 
> represent-as-brace-suffix?
> 
> should those go?

These *used* to be used, and my Scheme doesn't give those kinds of warnings.

Hmm, I don't know of any reason they need to stay.
I'd probably comment out appende, instead of removing it, just
in case it has to return someday.

--- David A. Wheeler

Re: [Readable-discuss] Damage done.

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

On Fri, 09 May 2014 13:58:50 +0200, "Jörg F. Wittenberger"
> continuing on alias tokens for collecting lists.
> 
> Two aspects have made my feelings stronger that I'd actually like {* and 
> *}:  A) As noted before, users usually know how to key them in. B) My 
> emacs will make it easy to skip over the block in most editing modes.
> 
> To get a feeling what it would take I go my hands dirty.  Resulting diff 
> below.  Note that this code is a dirty hack by now.  Where 
> `my-read-delimited-list` returns '<* I should probably attach source 
> info, shouldn't I?

Almost certainly yes, though I haven't examined it in detail.

> Let alone that I tend to believe that the token ought 
> to be generated more generic.  Furthermore there should be a 
> configuration option to switch it off entirely as the other reader 
> features already have.
> 
> There is one more nice thing if the alias was actually to work correct: 
> one could drop two more characters from the special set the programmer 
> has to be aware of < and >.
> 
> So far there is only so much test coverage.  But I have not yet managed 
> to write a test case which returns surprising results.
> 
> To my current knowledge there is actually only one user-visible change 
> besides {* *} becoming an alias for <* *>: the way one has to actually 
> get a symbol "star" read after a {: separate it by white space to avoid 
> it being taken as opening a collecting list. Is this actually all the 
> damage it did?  What am I missing?

This would mean that {* x *} would be interpreted *differently*
by a curly-infix reader (or a neoteric reader) compared to a sweet-expression reader.
You might want to thoroughly test what happens as you vary the number
of parameters inside {*...*}, to ensure that you're aren't reordering in that case.

For the Scheme implementation, I don't see any other issues offhand.
I'm not really a fan of the approach, but experimentation is always useful.

It's not clear that it'd be as easy to tweak the current Common Lisp implementation.
The sweet-reader, once it sees "{", immediately dispatches to the reader until }.
You might need to insert some additional logic to ensure that it doesn't do the
reordering that is normally done inside {...}.

--- David A. Wheeler

[Readable-discuss] Unused procedures

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

BTW: I'm getting warnings about unused procedures:

appende

represent-as-brace-suffix?

should those go?

[Readable-discuss] Damage done.

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

Hi all,

continuing on alias tokens for collecting lists.

Two aspects have made my feelings stronger that I'd actually like {* and 
*}:  A) As noted before, users usually know how to key them in. B) My 
emacs will make it easy to skip over the block in most editing modes.

To get a feeling what it would take I go my hands dirty.  Resulting diff 
below.  Note that this code is a dirty hack by now.  Where 
`my-read-delimited-list` returns '<* I should probably attach source 
info, shouldn't I? Let alone that I tend to believe that the token ought 
to be generated more generic.  Furthermore there should be a 
configuration option to switch it off entirely as the other reader 
features already have.

There is one more nice thing if the alias was actually to work correct: 
one could drop two more characters from the special set the programmer 
has to be aware of < and >.

So far there is only so much test coverage.  But I have not yet managed 
to write a test case which returns surprising results.

To my current knowledge there is actually only one user-visible change 
besides {* *} becoming an alias for <* *>: the way one has to actually 
get a symbol "star" read after a {: separate it by white space to avoid 
it being taken as opening a collecting list. Is this actually all the 
damage it did?  What am I missing?

Best regards

/Jörg
----

--- /media/u/Arbeit/jfw/build/armhf/askemos/ball/mechanism/srfi/srfi-110.scm	2014-02-18 14:26:17.819821953 +0100
+++ srfi-110-ndbg.scm	2014-05-09 13:33:41.296085721 +0200
@@ -1634,9 +1634,19 @@
                 (my-read-delimited-list neoteric-read-nocomment #\] port)))
             ((char=? c #\{ )
               (my-read-char port)
-             (attach-sourceinfo pos
-               (process-curly
-                 (my-read-delimited-list neoteric-read-nocomment #\} port))))
+             (let ((c (my-peek-char port)))
+	       (if (eqv? c #\*)
+		   (let ((e (underlying-read neoteric-read-nocomment port)))
+		     (if (eq? e '*)
+			 '<*
+			 (attach-sourceinfo
+			  pos
+			  (process-curly
+			   (cons e (my-read-delimited-list neoteric-read-nocomment #\} port))))))
+		   (attach-sourceinfo
+		    pos
+		    (process-curly
+		     (my-read-delimited-list neoteric-read-nocomment #\} port))))))
             ((my-char-whitespace? c)
               (my-read-char port)
               (neoteric-read-real port))
@@ -1759,14 +1769,20 @@
      (let ((c (my-peek-char port)))
        (let-splitter (results type expr)
                      (n-expr-or-scomment port)
-        (if (eq? (car results) 'scomment)
+        (if (eq? type 'scomment)
              results
              (cond
                ((and (eq? expr sublist) (eqv? c sublist-char))
                  (list 'sublist-marker '()))
                ((and (eq? expr group-split) (eqv? c group-split-char))
                  (list 'group-split-marker '()))
-              ((and (eq? expr '<*) (eqv? c #\<))
+	      ((eq? expr '*)
+	       (if (eqv? #\} (my-peek-char port))
+		   (begin
+		     (my-read-char port)
+		     (list 'collecting-end '()))
+		   results))
+              ((and (eq? expr '<*) (or (eqv? c #\{) (eqv? c #\<)))
                  (list 'collecting '()))
                ((and (eq? expr '*>) (eqv? c #\*))
                  (list 'collecting-end '()))

Re: [Readable-discuss] I've got a problem with the readability.

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

Am 08.05.2014 04:00, schrieb David A. Wheeler:
> I exclaimed:
>>> Hmm. Technically I don't think "<*" is legal at all in XML.
> On Wed, 7 May 2014 20:05:52 -0400, John Cowan <co...@me...> replied:
>> It's illegal in the surface syntax.  To express it in element
>> content or an attribute value, you must write "<*".
> Yes.  Which means you could write it, and then use some preprocessor to transform it into valid XML (or use a tweaked XML processor that interpreted it specially).

Yes, precisely.  That's the problem.  I can't change all the xml parses 
a user might want to throw at the code.  Hence tweaking the XML 
processor is no option.

What I can do right now using the sweet parser as it is, is simply write

let &lt;* a 1 *&gt; {a + a}

And get a 2 back.

That's how it ends up in the file according to XML spec.  No way 
around.  Developer will see it.
Ugly, hard to type, hence bad.

XML parser will resolve &lt; char reference.

What I'd like to have in the XML encoded file would be - taking { } - as 
grouping:

let {* a 1 *} {a + a}

This overloads the meaning of #\{ in sweet, thus might not be 
desirable.  In return it minimizes the amount of special characters.  
And it looks almost like

let <* a 1 *> {a + a}

though no XML quoting will be superimposed.

Since any character already handled special by the reader would also 
fulfill the desire to not allocate more special characters, one could 
thing for instance about #\# instead of the braces:

let #* a 1 *# {a + a}

Sorry, but I would take that as something like a block comment, maybe a 
special block comment?  maybe some compiler hint magic, that sort of 
thing. YMMV.

The the { } pair however is in SRFI-110 already used to "modify the 
indentation rules and position of implicit parenthesis" so to speak.  
Having {* and *} do the other kind of the same seems not that bad to me.

Please excuse my ignorance, ANTLR sweet.g is beyond my capacity for a 
timely reply.

The CL implementation looks at the first glance like an almost 
mechanical translation wrt. the Scheme code I read before.

If not the sweet.g, I don't see how it could come that dispatching on 
#\{ would be hard to change.  Characters are read one-by-one using 
my-read/peak-char, aren't they?

>
> --- David A> Wheeler
>
> ------------------------------------------------------------------------------
> 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

Re: [Readable-discuss] I've got a problem with the readability.

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

I exclaimed:
> > Hmm. Technically I don't think "<*" is legal at all in XML.

On Wed, 7 May 2014 20:05:52 -0400, John Cowan <co...@me...> replied:
> It's illegal in the surface syntax.  To express it in element
> content or an attribute value, you must write "<*".

Yes.  Which means you could write it, and then use some preprocessor to transform it into valid XML (or use a tweaked XML processor that interpreted it specially).

--- David A> Wheeler

Re: [Readable-discuss] I've got a problem with the readability.

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

David A. Wheeler scripsit:

> Hmm. Technically I don't think "<*" is legal at all in XML.

It's illegal in the surface syntax.  To express it in element
content or an attribute value, you must write "&lt;*".

-- 
John Cowan          http://www.ccil.org/~cowan        co...@cc...
Uneasy lies the head that wears the Editor's hat! --Eddie Foirbeis Climo

Re: [Readable-discuss] I've got a problem with the readability.

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

On Wed, 07 May 2014 21:18:34 +0200, "Jörg F. Wittenberger" said:
> ... However in my case the XML 
> parser *always* gets the source code first.  And the source is 
> re-created from the parsed tree upon need.  The sweet-read procedure 
> only sees some element's literal content.
> 
> In other words: the users sees all #\< and #\& characters within 
> sweet-read LISP code always quoted according to XML.

Hmm. Technically I don't think "<*" is legal at all in XML.
It's not a legal Start-Tag in XML, for example, see:
  http://www.w3.org/TR/xml/#dt-stag
  http://www.w3.org/TR/xml/#NT-NameStartChar

HTML5 similarly says that "<*" won't be treated as a tag, and is instead
just output as text:
  http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#tag-open-state

You might be able to exploit that fact to automatically convert in an easy-to-use way.
In particular, you may be able to convince your library to just pass that through
unscathed, or pre/post process it to make it work easily.


> Hm.  I must admit that I understand much too little about Common List to 
> make a qualified statement.
> 
> Let alone that I'd dare to judge how hard the implementation would end 
> up to be.
> 
> However: Am I correct to understand that this would be one 
> implementation problem?

Yes, though it's rather specific to {} and [].

> If so, than I'd rather wholesale defer the consideration.  In favor of 
> readability of the source code and "being the most natural choise" 
> (whatever that would be ;-).
> 
> At the moment I'm behind the language design, since I see this as the 
> whole point of readable lisp.  Once it's clear what would be the best 
> thing to have, I'd return to consider the hardship of implementation.  
> At worst that might end up being an iterative process.

Excellent!!

I said: 
> > Here's an idea: Can you use full Unicode (encoded, say, as UTF-8)?

> For a couple of seconds I thought: this genius!  I should have though of 
> that.
...
> But there's the catch: we are still talking about source code to be 
> keyed in by developers.  Some keyboards might have additional pairing 
> characters.  Mine for instance has « and ».
> 
> Though from a developers point of view, I'd expect myself to be in a 
> situation sooner or later, where I need to key them in from a dump terminal.
> 
> That's why I feel we should avoid those here.

Even "dumb" terminal emulators almost always have mechanisms to input other characters.
The problem is that they differ from system to system, so you may have to look up
how to do it.  A survey is here:
  https://en.wikipedia.org/wiki/Unicode_input

If you choose an unusual Unicode pair, and always use UTF-8 encoding,
it might be easy to pre/post process.  Practically everyone's fonts have lots of
glyphs (though maybe not ALL the glyphs you want!).

> After all: If I have to deviate from the spec, it does not matter how 
> much.  The hardship of maintaining an implementation remains.

Some deviations are a lot easier to implement or undo later, though.

--- David A. Wheeler

Re: [Readable-discuss] I've got a problem with the readability.

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

On 07 May 2014 21:48:45 +0200, Jörg F. Wittenberger
	<Joe...@so...> wrote:
> it just occured to me that |* and *| might be good aliases to <* and *> 
> too. If { and } could be problematic.

Those would *look* okay but wouldn't work on many Lisps (Common Lisp, Scheme).
The "|" introduces a literal atom on many Lisps.

> Just: those in turn... hm, does the sweet read code actually rely on the 
> read implementation of the underlying Scheme? I had the impression that it 
> would read char by char anyway.

There are currently at least 3 current implementations of sweet-expression readers:
1. The Scheme one (tested mostly with guile)
2. Common Lisp
3. ANTLR/Java implementation (primarily for grammar analysis).

Anyone can always implement another.  We want it to be as easy as possible
to implement it, while limiting the difficulties of doing so.

--- David A. Wheeler

[Readable-discuss] spinoff wisp srfi

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

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 )

Re: [Readable-discuss] I've got a problem with the readability.

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

it just occured to me that |* and *| might be good aliases to <* and *> 
too. If { and } could be problematic.

Just: those in turn... hm, does the sweet read code actually rely on the 
read implementation of the underlying Scheme? I had the impression that it 
would read char by char anyway.

On May 7 2014, "Jörg F. Wittenberger" wrote:

>Thanks for your anwser.
>
>Am 07.05.2014 15:11, schrieb David A. Wheeler:
>> On Thu, 01 May 2014 13:58:07 +0200, "Jörg F. Wittenberger"
>>> Q2: Would it be a good idea to allow this in the official spec?
>>> Embedding in XML seems to have broad uses these days and I foresee use
>>> cases for sweet list especially in domain specific languages.
>> I really want to keep the spec stable for a while (though that doesn't 
>> stop experimentation with various extensions).
>>
>> I've done some experiments generating HTML/XML, but like this:
>> <html>
>> ! <head>
>> ! ! <title>
>> ....
>> and with that approach there's no issue.
>
>Sure, that' when *generating* the X/HML.  However in my case the XML 
>parser *always* gets the source code first.  And the source is 
>re-created from the parsed tree upon need.  The sweet-read procedure 
>only sees some element's literal content.
>
>In other words: the users sees all #\< and #\& characters within 
>sweet-read LISP code always quoted according to XML.
>
>> Using {*...*} would probably be a challenge for many implementations. 
>> IIIRC, in the Common Lisp implementation "{" and "}" are treated a lot 
>> like "(" and ")", that is, they are their own tokens, and there's no 
>> real opportunity to re-connect them later. So I'd discourage the use of 
>> {*...*} specifically.
>
>Hm.  I must admit that I understand much too little about Common List to 
>make a qualified statement.
>
>Let alone that I'd dare to judge how hard the implementation would end 
>up to be.
>
>However: Am I correct to understand that this would be one 
>implementation problem?
>
>If so, than I'd rather wholesale defer the consideration.  In favor of 
>readability of the source code and "being the most natural choise" 
>(whatever that would be ;-).
>
>At the moment I'm behind the language design, since I see this as the 
>whole point of readable lisp.  Once it's clear what would be the best 
>thing to have, I'd return to consider the hardship of implementation.  
>At worst that might end up being an iterative process.
>
>> Here's an idea: Can you use full Unicode (encoded, say, as UTF-8)?
>
>For a couple of seconds I thought: this genius!  I should have though of 
>that.
>
>> You could then use additional pairing markers, there are a whole bunch
>> in math and quoting markers.  Then there'd be no overlap.
>> For example, you could use the Ogham feather mark pairs:
>> U+169b Ps OGHAM FEATHER MARK ᚛
>> U+169c Pe OGHAM REVERSED FEATHER MARK ᚜
>> Or brackets with quills:
>> U+2045 Ps LEFT SQUARE BRACKET WITH QUILL ⁅
>> U+2046 Pe RIGHT SQUARE BRACKET WITH QUILL ⁆
>> Some folks have tried to create a list of these paired characters here:
>>     
>>  
>> https://stackoverflow.com/questions/13535172/list-of-all-unicodes-open-close-brackets 
>> I'm not sure what the best symbols would be... we could try them out on 
>> many systems to see how they look. These could be considered synonyms, 
>> as extensions to the existing system.
>
>But there's the catch: we are still talking about source code to be 
>keyed in by developers.  Some keyboards might have additional pairing 
>characters.  Mine for instance has « and ».
>
> Though from a developers point of view, I'd expect myself to be in a 
> situation sooner or later, where I need to key them in from a dump 
> terminal.
>
>That's why I feel we should avoid those here.
>
>
>After all: If I have to deviate from the spec, it does not matter how 
>much.  The hardship of maintaining an implementation remains.
>
>/Jörg
>

Re: [Readable-discuss] I've got a problem with the readability.

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

On Thu, 01 May 2014 13:58:07 +0200, "Jörg F. Wittenberger"
> Q2: Would it be a good idea to allow this in the official spec? 
> Embedding in XML seems to have broad uses these days and I foresee use 
> cases for sweet list especially in domain specific languages.

I really want to keep the spec stable for a while (though that doesn't stop
experimentation with various extensions).

I've done some experiments generating HTML/XML, but like this:
<html>
! <head>
! ! <title>
....
and with that approach there's no issue.

Using {*...*} would probably be a challenge for many implementations.
IIIRC, in the Common Lisp implementation "{" and "}" are treated a lot like
"(" and ")", that is, they are their own tokens, and there's no real
opportunity to re-connect them later.  So I'd discourage the use of {*...*}
specifically.

Here's an idea: Can you use full Unicode (encoded, say, as UTF-8)?
You could then use additional pairing markers, there are a whole bunch
in math and quoting markers.  Then there'd be no overlap.
For example, you could use the Ogham feather mark pairs:
U+169b Ps OGHAM FEATHER MARK ᚛
U+169c Pe OGHAM REVERSED FEATHER MARK ᚜
Or brackets with quills:
U+2045 Ps LEFT SQUARE BRACKET WITH QUILL ⁅
U+2046 Pe RIGHT SQUARE BRACKET WITH QUILL ⁆
Some folks have tried to create a list of these paired characters here:
  https://stackoverflow.com/questions/13535172/list-of-all-unicodes-open-close-brackets
I'm not sure what the best symbols would be... we could try them out
on many systems to see how they look.
These could be considered synonyms, as extensions to the existing system.

--- David A. Wheeler

[Readable-discuss] I've got a problem with the readability.

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

Hi all,

I'm just gaining experience with writing sweet lisp code.  Maybe I don't 
see the right solution.

I use sweet code in the context of a web application at the moment. The 
framework is template based.  A page can be plain HTML or - for dynamic 
content - elements or attributes in a special namespace are evaluated.

So the sweet expressions show up always as either content or attribute 
values in the source.  That's fine except for collecting lists.  The <* 
*> markers just don't look nice under XML quotation rules: &lt;*  &gt;*.

Too bad.

By design I want tools like xmllint verify my spiced up html source.

I feel I need an alternative marker for them.

Anybody having better idea?

Assuming no better idea:

Q1: Which marker would be "good in spirit"?  I'd propose to use {* and 
*} as alternatives since { and } are already taken special anyway.

Q2: Would it be a good idea to allow this in the official spec? 
Embedding in XML seems to have broad uses these days and I foresee use 
cases for sweet list especially in domain specific languages.

Best Regards

/Jörg