Arc Forumnew | comments | leaders | submitlogin
Should intrasymbol syntax be handled by the reader?
2 points by drcode 5988 days ago | 12 comments
At some point we'll most likely have a reader written in arc (Heck, sooner or later it's going to be painful enough not to have one I'll probably end up writing one myself for my own fork)

My question is, once this happens, should the processing of intrasymbol syntax live in the reader, instead of the arc->scheme translator?

To see what I mean, note that the following two commands give different results for obscure reasons:

  arc> (row odd.5)
  <tr><td>t</td></tr>
  arc> (row (odd 5))
  <tr><td></td></tr>
It seems to me this can be resolved by treating intrasymbol syntax as something handled by the reader- AFAIK this would handle all current intrasymbol syntax scenarios except foo:bar, but that scenario, too, could mostly be handled with some other adjustments (including implicit currying, which I hope is in the future too)

If it was handled by the reader, then (read "(row odd.5)") would return '(row (odd 5)) instead of '(row odd.5)

Anyway, just wanted to see what people's opinions are on that question.



3 points by almkglor 5988 days ago | link

No. Consider this: http://arclanguage.com/item?id=5570

In particular, you should notice that the syntax there involves some intrasymbol syntax, which it expects to have visible.

Specifically, if you make intrasymbol syntax part of the reader, you get the following potential problem:

intrasymbol syntax will have to be completely regular across the entire Arc environment. You can't do tricks like I did in 'w/html, where div.bar doesn't mean (div bar) but rather means "the <div> element with the bar id". Yes, you could probably modify w/html so that it can understand (div bar): but what if the programmer wants to, say, redefine the intrasymbol syntax for foo#bar to mean, say (en-number foo bar), then suddenly w/html will break. And what if programmer B wants to, say, redefine foo#bar to mean (number-en foo bar)? How will anything that uses a slightly different intrasymbol syntax work with that?

-----

3 points by CatDancer 5987 days ago | link

Well, you know how the reader expands ' ` , @ etc.?

  arc> '`(a ,b ,@c)
  (quasiquote (a (unquote b) (unquote-splicing c)))
so why not have

  arc> 'foo.bar
  (dot foo bar)
then if you want to write a macro that treats . or # differently, you can do that.

-----

1 point by almkglor 5986 days ago | link

Programmer A decides he or she wants to specially treat #\@. Programmer B decides he or she doesn't. Now, load Programmer B's code into Programmer A's environment. Oh, and Programmer B has been writing a lot of functions with "@" in their names.

If you're not going to allow #\@ to be specially treated, why should you specially treat #\., #\!, #\~ or #\: ?

#\' and friends, after all, aren't intrasymbol syntax. In fact, #\. is treated differently from within the context of a symbol from within the context of a list.

This is where "code is spec" fails, bad. Me, I say, someone has to choose one or the other, define it as "this is spec!", and everyone follows it. Your move, PG?

-----

1 point by stefano 5986 days ago | link

If the reader can be configured (e.g. by specifying wich read table to use) then two modules that uses different reading conventions can coexist by simply using their own configuration.

-----

1 point by almkglor 5986 days ago | link

Now programmer C wants to use both programmer A's module and programmer B's module. Which readtable does he use so that he can freely intermix macros from A with macros from B, which have different expectations on the reader?

Reader hacking is nice, but I don't see it often in CL libraries (note: counterexamples are welcomed; it's not like I've made an exhaustive search for them). Any reader hack must make the cut of being a good, generic enough meaning that it will always be used by everyone; take for example the Arc-type [ ... _ ... ] syntax

-----

1 point by stefano 5985 days ago | link

A and B should provide macros to let C write:

  (with-A what%ever)
  ...
  (with-B what%ever)
CLSQL modifies the read table to let you write embedded SQL queries such as [select "A" [where [= ...]]] and similar (I've never studied the exact syntax, but this should give you the idea). The special reader in CLSQL can be activated/disactived through function calls that modifies the default reader.

-----

1 point by almkglor 5985 days ago | link

But B doesn't want to treat #\@ or whatever syntax specially. Why should B bend over backwards to support this?

For that matter: what if C wants to use a macro in A within the context of a macro in B or vice versa?

  (with-A
    (macro-A
       @foo
       (with-B
         (macro-B
           (prn "this is:" '@foo)))))
?

> The special reader in CLSQL can be activated/disactived through function calls that modifies the default reader.

Not a bad idea. Difficult in SNAP though - which default reader? I'd have to add yet another process-local variable.

-----

2 points by cchooper 5980 days ago | link

It looks like CLSQL needs reader macros to switch the syntax on and off locally. If Arc had reader macros, then you could do this:

  #.(with-A (mac macro-A ..blah..blah..in special A syntax))
Assuming 'with-A is a function that set the read table locally, and macro-A uses quasi-quote to generate its result, this will produce a macro that produces standard Arc syntax, even though it's written in A syntax.

With reader macros, 'w/html could be implemented even if de-sugaring were moved to the reader, although you'd have to call it with #. all the time.

It makes sense to me that macros should always expand to vanilla Arc syntax (or maybe even pure s-exps without any ssyntax) so that they are portable across environments.

-----

1 point by drcode 5986 days ago | link

I like that idea. If I ever get around to writing something like this I may do it that way.

-----

1 point by absz 5987 days ago | link

Perhaps it should be a different phase entirely, so instead of a REPL, we have a RDEPL (read-desugar-eval-print loop). Then macros would avoid not just E, but DE. And perhaps we could have another sort of macro that does desugar, merely skipping the E, but that might make things more compilcated. And if we just have the no-DE kind, we could layer the no-E kind on top of it. This allows things like almkglor mentions with w/html, but is still consistent and Arc-in-Arc.

-----

1 point by almkglor 5987 days ago | link

Currently macros are part of the desugar phase - macroexpansion and intrasymbol syntax expansion are done in the same step. This allows a macro to return symbol syntax, which might be expanded into a macro call too.

-----

1 point by stefano 5988 days ago | link

Sure. This is work for the reader.

-----