You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For now, @kayceesrk found that it will be very easy to write our own outcome printer by simply forking the upstream ML one. (Or at least we can get it to a very usable state quickly). Longer term, we decided the best approach is to create a general purpose converter from "outcome tree" to "parse tree", where certain nodes in the parse tree would have some kind of placeholder to represent nodes in the outcome tree which could not be represented in a parse tree. (Things like ... for large objects). For those, we could chose to convert them as ppx extension points [%largeObject].
The benefit here, is that the top level printer will always be kept in sync with your parser/printer. The downside is that it will take longer to do it this way, so we are making this issue to track the implementation long term.
The text was updated successfully, but these errors were encountered:
For now, @kayceesrk found that it will be very easy to write our own outcome printer by simply forking the upstream ML one. (Or at least we can get it to a very usable state quickly). Longer term, we decided the best approach is to create a general purpose converter from "outcome tree" to "parse tree", where certain nodes in the parse tree would have some kind of placeholder to represent nodes in the outcome tree which could not be represented in a parse tree. (Things like
...
for large objects). For those, we could chose to convert them asppx
extension points[%largeObject]
.The benefit here, is that the top level printer will always be kept in sync with your parser/printer. The downside is that it will take longer to do it this way, so we are making this issue to track the implementation long term.
The text was updated successfully, but these errors were encountered: