Open disnet opened 7 years ago
gabejohnson
commented
7 years ago 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
commented
7 years ago Also we should figure out what #519 is going to look like.
gabejohnson
commented
7 years ago @disnet what do you think?
disnet
commented
7 years ago @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
commented
7 years ago 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
commented
7 years ago @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
commented
7 years ago 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 notifications@github.com 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 https://github.com/sweet-js/sweet-core/issues/687#issuecomment-319207083, 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
commented
7 years ago 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.
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?