Re: [Readable-discuss] I've got a problem with the readability.
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
--
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] I've got a problem with the readability.
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
--
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] spinoff wisp srfi
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 Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] I've got a problem with the readability.
On 07 May 2014 21:48:45 +0200, Jörg F. Wittenberger
joerg.wittenber...@softeyes.net 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
--
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] I've got a problem with the readability.
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
--
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] I've got a problem with the readability.
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/~cowanco...@ccil.org Uneasy lies the head that wears the Editor's hat! --Eddie Foirbeis Climo -- 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] I've got a problem with the readability.
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...@mercury.ccil.org 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 -- 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
