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 
>> 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:
>> Or brackets with quills:
>> Some folks have tried to create a list of these paired characters here:
>> 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.

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
Readable-discuss mailing list

Reply via email to