expose readtables to users

[disnet]

Readtables are used internally but currently there is no way for users to extend them.

I'd like to use the directive lang <path> to do the exposing but beyond that I haven't thought too much about the API yet.

@gabejohnson besides figuring out the user surface API is there anything you know we need to handle first?

[gabejohnson]

We should get the reader at least not hanging on 262 tests (there's a list of them that appear to get stuck).

I also don't like the current API. CharStream seems unnecessary unless it's just there to hold state (which I don't like). I have some ideas that I've been meaning to write up in the readtables repo. I'll take a look at it this week and ping you for feedback.

[gabejohnson]

Also we should figure out what #519 is going to look like.

[gabejohnson]

#707 and #712 have been just the most recent of many request for custom punctuators. I'm rethinking my stance on exposing the API. While I don't want to upset users by changing the readtable API in the near future, I think exposing it using the current implementation could be very fruitful in exposing pain points.

@disnet what do you think?

[disnet]

@gabejohnson I think that's totally reasonable. We'd probably be fooling ourselves if we thought we could get away without some iteration on the API anyway. We should be sure an note in the documentation the API is experimental and will probably change.

[samuelgoto]

It seems like this was introduced and then has gone away. Just checking: is it deliberate that this documentation for the readtable is outdated? if so, is there a replacement?

[disnet]

@samuelgoto correct. Readtables were exposed in version 0.7 and then went away in the 1.0 rewrite. @gabejohnson has been working on their replacement. Like this issue mentions, Sweet is currently using @gabejohnson's readtables internally and we need to figure out the right way of exposing them to users.

[samuelgoto]

In the interim, is there a quick hack that you'd recommend to access them (forking and digging in is an option, but sounds undesirable/brittle)? On a side note, what is the best communication channel for me to ask some quick questions about feasibility of new syntax (github issues? IRC? hangouts? mailing list?) and whether sweet.js is the right tool for it?

…

On Mon, Jul 31, 2017 at 2:51 PM, Tim Disney ***@***.***> wrote: @samuelgoto <https://github.com/samuelgoto> correct. Readtables were exposed in version 0.7 and then went away in the 1.0 rewrite. @gabejohnson <https://github.com/gabejohnson> has been working on their replacement. Like this issue mentions, Sweet is currently using @gabejohnson <https://github.com/gabejohnson>'s readtables internally and we need to figure out the right way of exposing them to users. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#687 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAqV6lfbzmJE8AbrTQ96HNGhLz1-kzV5ks5sTkxUgaJpZM4M-0ym> .

-- f u cn rd ths u cn b a gd prgmr !

[disnet]

In the interim, is there a quick hack that you'd recommend to access them
(forking and digging in is an option, but sounds undesirable/brittle)?

Yeah, the reader is being run here for each module. The readtable is mutable and modified with setCurrentReadtable (e.g. here) so right before read is called you can dispatch to however you want to hack in your custom readtable.

On a side note, what is the best communication channel for me to ask some
quick questions about feasibility of new syntax (github issues? IRC?
hangouts? mailing list?) and whether sweet.js is the right tool for it?

Github issues work best for me. The gitter room is active occasionally but I'm pretty infrequent there.