Re: [Readable-discuss] I've got a problem with the readability.
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
> 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 <* a 1 *> {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 < 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:
> • 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] 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 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: • 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] 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 "<*". -- 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: • 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] 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:
• 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] I've got a problem with the readability.
On 07 May 2014 21:48:45 +0200, Jörg F. Wittenberger
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:
• 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] 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:
>>
>> !
>> ! !
>>
>> 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:
• 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] 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:
!
! !
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:
• 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
[Readable-discuss] I've got a problem with the readability.
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: <* >*.
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
--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos. Get
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
___
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
