support for some Common Lisp reader macros

[kowey]

It may be useful to provide some support for a handful of reader macros. For example, maybe things like #S(film :title "Jaws" :director "Steven Spielberg") should be interpreted as though they were (make-film :title "Jaws" :director "Steven Spielberg"). I don't claim to understand how they are supposed to be understood, BTW, this is just the result of typing things into SBCL and seeing what we get back

It's possible that this is thing is so specific to Common-Lisp that we'll need to ask ourselves some questions about what atto-lisp is supposed to do about the existence of multiple Lisp dialects

PS. hope this isn't spammy for you. Should be my last thought for the day. Thanks!

[nominolo]

Yeah, reader macros are fully programmable by Common Lisp programs, so it's impossible to support them all without implementing a full Common Lisp. I'm willing to support the common ones, like quote, backquote, comma. I'm unsure about sharing notation, but that may be important for some use cases:

#1=(cons 42 #1)   ; the infinite list of 42

I think before going further down this road, we should really think what the goals are for atto-lisp. ATM, I think it's about communicating with Lisp programs. This is different from a REPL which is supposed to be for human input. When communicating with Lisp programs we need to think about how to unambiguously send data to a Lisp and what form the output will take. For example, Lisp programs often print (quote foo) instead 'foo, so we may not even have to support the quote syntax.

If we want to extend our use cases to read some Lisp data structures (e.g., for configuration) then we may have to support a few more of the reader macros for human convenience.

What are you using atto-lisp for, and what are you perhaps planning to use it for?

[kowey]

Yeah, I was hoping for something like “using the standard syntax” or “using the standard readtable” (I may be getting the terminology wrong here, but basically to mean “read as though there were zero customisations or programmable bits”).

In my particular case, I'm actually only really interested in sharpsign-s macros and of course the basic ones like backquote, etc.

I think I'm also trying to communicate with Lisp programs, using Lisp as an interchange format like I'd use JSON. I've got is Common Lisp users trying to send a bunch of data to my Haskell programs. At first, I tried making them go through JSON, but realised that imposes a lot of implementation overhead on them pretty much unnecessarily, and format design overhead on me. Better to let them just do the equivalent of show foo is and sending me a big blop of Lisp to work with.

One day, I got a piece of data with an #S(...) in it. For now, we have workarounds that consist of me manually stripping the text and parsing structures crudely. But it could be nice to just be able to support whatever they throw at me.

[nominolo]

So the implementation of this reader macro is in sharpm.lisp (for SBCL), but it is rather complicated and perhaps even SBCL-specific. The problem is that not every constructor is named (make-). It can be overridden using the :constructor parameter to defstruct. I'm pretty sure you can also define your own print function for structs. I think we should not define such behaviour in the library even if it would cover the most common cases. I think we want a different constructor and then let the data consumer decide what to do with it.

So, in this case it should be something like ReaderMacro Char Lisp. This won't work for the vector syntax #(a b c) without some special care, though. This delays the decision how to interpret the data to the data library user and doesn't make a decision in the atto-lisp library (which doesn't have enough information).

[kowey]

I think I'm happy as long as I can slurp in my users' Lisp and yours sounds like a much more principled way to go about it.