Re: [Readable-discuss] Damage done.
On Sun, May 11, 2014 at 12:45 AM, John Cowan co...@mercury.ccil.org 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
Re: [Readable-discuss] Damage done.
Sure CDATA could solve the problem. So could encoding as lt; .
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...@mercury.ccil.org
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 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:
#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
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: #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 Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
[Readable-discuss] Damage done.
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 '()))
--- /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
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:
#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
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 co...@mercury.ccil.org 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: #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 Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
