-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Which kinds of symbols should we support? #3
Comments
My preference is to go with the simplest thing first. Going with the draft you mention sounds good. |
The complex behavior is already implemented :) It re-uses the subroutine that reads strings because the two syntaxes are so similar. |
Sounds good in that case 😄 |
As has been discussed in #s-expressions recently, I believe that internationalization is not an issue for symbols in what POSE does, namely data interchange (as distinct from code, which POSE is not meant for). I also think it's important that while POSE libraries are a Good Thing, the native Therefore I have looked at the following Lisp standards: CL, R6RS, R[57]RS, Elisp (de facto), Interlisp 83, and come up with the following intersection:
UPDATE: There is no universal escaping convention for symbols, so we have to do without them. |
Thanks for commenting, John. Please see also https://github.com/s-expressions/pose/blob/master/symbol.text |
Excellent. I've modified Twinjo.md (now at s-expressions/twinjo) to point to this. |
@wallymathieu Do you have a preference for how wide-ranging the symbol support should be?
The current draft uses the vertical-bar notation known from Common Lisp and Scheme (R7RS). That means any text that can be encoded as a string as in
"foo bar"
can also be encoded as a symbol as in|foo bar|
. The vertical bars support backslash escapes like strings do:"foo \" bar \\ baz"
and|foo \| bar \\ baz|
.We've had some discussion of whether that's too fancy, and symbols should be restricted to a character set that is mostly portable to many Lisp implementations as it stands. I'm still in favor of vertical bars and symbol-string uniformity but the others are not.
The text was updated successfully, but these errors were encountered: