More atom types

[porglezomp]

Currently it seems impossible to distinguish when an atom was quoted or unquoted, which is annoying for use in a lot of different contexts. It'd be nice to be able to distinguish (print "hello") from (print hello).

[cgaebel]

You're right. That is annoying. I'll see what I can do to fix it.

[porglezomp]

Any progress on this? If not, would you like me to write a PR for it?

[cgaebel]

Uhh sure. Sorry this fell off my stack. I had some uncommitted code that I now no longer recognize.

A pr would be most welcome.

[porglezomp]

My current implementation adds a new atom Q to represent quoted strings, should we provide syntax for an S atom with whitespace in it?

[cgaebel]

I don't think so. Now that I think about it, I'm not sure I want a different representation for "hello world" and hello\ world. I don't think I have real quoting semantics in my head. What do real scheme implementations do about this? Do they tend to have multiple "quoted string" representations?

[porglezomp]

Real Lisps tend to make "hello" and hello different types, the former is a string and the latter is a symbol. They often call the single atom hello world, either hello\ world or |hello world|. Strings obviously have different semantics from symbolic atoms, since you can't (or don't want to) do anything with symbols but compare them for equality.

[porglezomp]

Clojure for example just doesn't give you a syntax for a symbol with whitespace in it. You can construct them programmatically (symbol "hello world") but you're unlikely to have a good use for them since they display as two separate symbols.

[guygastineau]

Hey, sorry to necro-bump this issue. I am considering using this crate as the basis for some SEXP based communication in a client/server architecture. SEXP are much nicer than JSON, and I love Scheme in case my motives are intriguing. I was thinking that the Atom::S is really SYMBOL and that the Atom::Q that @porglezomp suggests should rightfully be called Atom::String or something.

@porglezomp you basically said as much already, but I wanted to emphasize how Q would be semantically dishonest.

Anyway, I too would like a true difference between symbols and strings (perhaps even keyword, but that likely escapes the scope of this project).

So, @cgaebel do you intend to be active on this crate anymore, and would you still like a PR?
@porglezomp Are you still interested in a PR for this?

Finally, I am willing to put work into this, but I should state that I think the Atom variants should have more explicit names for better disambiguation. Given this and perhaps other semantic opinions of which I am not yet aware my work might refactor more than expected. So, @cgaebel would you welcome a PR that brings more significant change, or would you suggest I just keep it as a fork? I suppose I can always just try to PR after working on it, but my mindset will likely be different if I plan on making a PR here than if I plan on splitting off completely.

Anyway, cheers, and excellent foundational work on this!

[porglezomp]

I think my eventual solution here was I just wrote my own S-expression crate, ess. You can see if that already serves your needs, or if you'd need changes there too.

[guygastineau]

@porglezomp thank you. I like how you keep the source location.
My primary concern right now is the ability to use SEXP as an RPC data format, because I hate JSON ;) I already built a parser using nom by the time I saw your message here.

Your crate seems an ideal starting point for language parsing in order to tell the user the location of errors. My parser focuses on providing a type hierarchy and translation into a simple IR that can be used for simple data marshalling or for compilation (but compilers will lose source location after nom step).

Anyway, I am gonna have my crate public later this week I think. I will drop a link here if you want to see it.