Re: [Readable-discuss] Damage done.
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
--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
___
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Damage done.
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 "" 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/~cowanco...@ccil.org
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
--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
___
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Damage done.
> 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 wrote:
> I think that's a killer.
>
> Frankly, this is what CDATA sections were made for. Wrap your Lisp
> code in "" 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:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
___
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Damage done.
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/~cowanco...@ccil.org Would your name perchance be surname Puppet, given name Sock? --Rick Moen -- Is your legacy SCM system holding you back? Join Perforce May 7 to find out: • 3 signs your SCM is hindering your productivity • Requirements for releasing software faster • Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Damage done.
On Fri, 9 May 2014 16:00:58 -0400, John Cowan 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 -- Is your legacy SCM system holding you back? Join Perforce May 7 to find out: • 3 signs your SCM is hindering your productivity • Requirements for releasing software faster • Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Damage done.
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
> wrote:
>> I think that's a killer.
>>
>> Frankly, this is what CDATA sections were made for. Wrap your Lisp
>> code in "" 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: • 3 signs your SCM is hindering your productivity •
> Requirements for releasing software faster • Expert tips and advice
> for migrating your SCM now http://p.sf.net/sfu/perforce
> ___ Readable-discuss mailing
> list Readable-discuss@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/readable-discuss
--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
___
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Damage done.
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 "" brackets, and < is no longer magic.
>(Note that > is never magic, though there is an escape for it anyway.)
>
>
--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
___
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Damage done.
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/~cowanco...@ccil.org 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 -- Is your legacy SCM system holding you back? Join Perforce May 7 to find out: • 3 signs your SCM is hindering your productivity • Requirements for releasing software faster • Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Damage done.
On Sun, May 11, 2014 at 12:45 AM, John Cowan 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. -- Time is money. Stop wasting it! Get your web API in 5 minutes. www.restlet.com/download http://p.sf.net/sfu/restlet ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
