Rethink `!` and `#""` about hissp HOT 12 OPEN

So,

• '\n' (Python)
• #"\n" (Hash string, current Hissp)
• !#"\n" (Tag applied to raw string)
• .#"'\n'" (injected Python, even without a bundled tag)

It occurs to me that a hash string could be written as a dot string instead. Keep the special-cased atom, but just spell it differently.

• ."\n"

from hissp.

Reader macros with aliases (a major motivation for Extras in the first place).

b#"bytes" ; With b# in _macro_.

(hissp.._macro_.alias H hissp.._macro_)

H#!b"bytes" ; Current.
H##b"bytes" ; Using # instead of !
H#^b"bytes" ; Using ^ instead of !

Comment strings (a major motivation for keeping the current Extra system).

<<#
#;foo
#;bar
#;baz
."\n"

<<#
#;foo
#;bar
#;baz
!#"\n"

<<#
^;foo
^;bar
^;baz
#"\n"

Decorators

@#!str.swapcase
@#!str.title
(define spam 'spam) 

@##str.swapcase
@##str.title
(define spam 'spam) 

@#^str.swapcase
@#^str.title
(define spam 'spam) 

from hissp.

."" might not play nice with lisp-mode. Older Lisps used (foo . bar) dotted syntax for a cons. A single dot would have to be escaped to act as a symbol. You can't have more than one in a list. You also can't have one outside a list. Probably shouldn't be expected to be compatible with Lisp editors. !# is looking better now.

Another option might be :"". That's currently parsed as a control word followed by a string (Emacs Lisp parses it the same way). You could still get that by adding a space. (:\"\" is a control word, btw.)

from hissp.

Comment strings (a major motivation for keeping the current Extra system).

Not anymore! Parinfer has trouble with unbalanced quotes in comments. It can handle them spread over multiple lines, but not if there's any other token (like !) in between the comments. It is possible to stack !s, to avoid interleaving them but that gets awkward quickly.

Once I ran into this problem I started looking for alternatives. It turned out to be not that hard to tokenize comments in blocks, which means <<# will no longer need Extras at all. It's also not too hard to get the contents out of such blocks in a consistent way: strip the indents, followed by any number of ;s and up to one following space. The tokens must end it a newline for the REPL to continue properly, so the final newline must be stripped as well. That's enough for <<# to handle arbitrary raw strings.

The old version using extras had some stylistic benefits. The non-comment primary was a way to avoid the dangling bracket. (A discarded item will still do, as always, but it's less natural or enforced.) It also meant that there was no choice to be made about the number of leading ;s or whether or not to use a following space.

The new version also has advantages. Converting from a string literal is as simple as commenting out the lines with the editor and removing the quotes. Converting back is just the reverse of the process.

Without that motivation for keeping the current Extra system, I'm more willing to explore more diverse alternatives.

from hissp.

The arity/depth suffix ^^^ used in synexpand might be a viable alternative approach. I initially ruled it out because of the comment motivation. I think approximately arity four is a reasonable upper limit for heterogeneous positional arguments. Any more than that and you should be using kwargs instead, or you're imposing too much meaningless baggage in the ordering. (For homogeneous args, you can pass in/splat in an iterable instead.) That's why XYZW# doesn't have quinary analogue, just en#X#. The exceptions are rare enough that I'd rather make you write your own than include one and impose it on everybody else.

It's a much better design to have string literals require a closing quote than an opening quote and an upfront count (which used to be a thing in assembly languages). That's why this felt like a bad design. But that's only because counting that high accurately is hard. Humans have no difficulty counting to three. Four is pushing it, but it's less than the typical expected usage. Making them count in unary with a tally will probably make them reluctant to go too high.

So foo#!!! a b c primary works now and doesn't look too bad. foo#### a b c primary is pushing it with 4, but ought to be uncommon. foo## a primary and even foo### a b primary look fine.

But how to handle kwargs? It seems like options would be a common use for extras. It would be nice to have an easy way to pass them in. Currently, you're stuck with foo#!!! : bar spam primary. If it required all !s to be up front, then putting a symbol on the other side could be an indicator of something. Perhaps foo#bar!spam primary would resolve like foo(primary, bar=spam). foo#*!**! spam eggs primary would resolve like foo(primary, *spam, **eggs). This feels pretty good. At some point (4?) you'd stop stacking bangs and wrap the args in a tuple and splat with a *!.

I'm not sure how easily I could make the reader do this, but it's certainly possible.

One major issue is that symbols ending in a bang are a common warning about functions with side effects in other lisps. I'd rather not preclude that convention. Using # instead just makes them look like stacked reader macros, like the en#X# idiom. I don't want to preclude that either. ^ might be a good choice: foo#*^**^ foo#bar^spam, but it might conflict with synexpand now. Putting the # first for extras will cause the same editor issues that convinced me to switch to putting it last in the first place.

from hissp.