John Cowan cowan@ccil.org writes:
Rather than allowing any CL S-expression (except that all symbols must be keywords), I propose that you allow only a more restricted variety of S-expressions so that they can be readily read and processed in any other language, while being compatible with a whole bunch of Lisp's read (without full validation) and print/write functions.
Specifically I propose POSE < https://github.com/s-expressions/pose/blob/master/README.adoc#specification%..., which allows only a restricted set of symbols, arbitrary integers, floats, and strings, and lists. (Most of that page is the rationale, which does not need to be read unless it interests you).
Hi John, thanks for the suggestion! I do agree that CLPI doesn't need the full expressivity of CL sexps and it's in fact not a good idea. Who wants to deal with reader macros or improper lists?
That being said, I see some potential issues with POSE that would be good to get your thoughts on.
First, I believe this is a typo otherwise keywords wouldn't be very useful:
colonsym = ':' | signsym
Second, it seems there's some disagreement between the spec and implementations when it comes to reading strings. The implementations all seem to treat the character sequences #\ #\n and #\ #\t as #\Newline and #\Tab, respectively. Additionally a #\ not followed by an #\n #\t #" or #\ will signal an error. This is at odds with CL:READ (and the POSE spec) and could cause issues if something like a system description has any of those characters. Which behavior is intended for POSE?
Third, I'm not sure how to deal with the case sensitivity of symbols. Is there any plan to add a :case argument or similar to POSE:READ? If not, it seems like we'd have to either mandate all symbols should be PRINTed upper case in CLPI, or do a post processing step on the POSE output to upcase everything, because writing |version|, |name|, etc. everywhere in the CL code would get real tired, real fast.
-Eric