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:
• 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/readable-discuss
