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
