[MathNotation] Implement Sectioning #299
Conversation
shingarov
force-pushed
the
sectioning
branch
6 times, most recently
from
de564dc to
3c13e37
Compare
shingarov
force-pushed
the
sectioning
branch
3 times, most recently
from
b63e3cc to
13ec844
Compare
There was a problem hiding this comment.
I think this need more work. Once you have hole, syntax highlighting just stop working (for the method). Any kind of refactoring (renaming a variable, say) just writes back the full block:
holeOne: x
self iconNamed: 'aaa'.
^ [ :_ß198 | x + _ß198 ]
Trying something like:
hole2: a
^ { □ }
gives you back error Unknown variable _ß123.
In the RB parser, nodes are stateful objects which perform some of the parser's work. For one example, nodes are reparented during parsing; this happens down a chain of sends between nodes. If a parse error is discovered during execution of a node's method, the RBParser's explicit (non-exception) juggling of RBParseErrorNodes is out of reach (at a minimum, because nodes don't know the parser who is manipulating them). This commit allows RBNodes to signal `parserError: aString` as if it happened in the RBParser, by unwinding to the nearest RBParser context. This is an ad-hoc hack, but the solution I would like (cf. megaparsec) would involve having a language with first-class composition, which is what we are trying to build, and need this support in the substrate for.
See RBHoleToken class comment for a general description of how this works. We shall give more meaningful examples when we implement Squiggol (hopefully in the next few PRs). Things are going to become much more interesting when we implement LqST so Smalltalk blocks are routed to Core.
Yeah, that's pretty annoying.
That would be "future improvements" to tooling. One could open a Feature Request to have "syntax highlighting of code with sectioned sends". This PR per se does not introduce a regression, because no-one on the planet ever had "syntax highlighting of code with sectioned sends" in the first place. With refactoring it's the same but worse. If by "refactoring" we mean what our competitors do in 2024, e.g. how MS VisualStudio can call LiquidHaskell to ensure the refactoring preserves semantics, then we simply don't have refactoring. If we mean 1997-ish John-Brant-style refactoring, I think I last used it in around 2000 or 2001, back then it seemed cool and potentially useful. To my taste, I'd simply remove those ~100KLOC from Useful8 just like many Calypso plugins are removed, when they crash tools, break text rendering etc without giving nothing in return. Oh, thanks for reminding me: I completely forgot to push a bunch more crud-removals to Useful8. |
The fact that you do not use it does not mean it is not useful nor nobody else uses it. Just like the fact I do not use vim does not mean not mean it is not useful to that nobody else uses it. The fact that tools are broken is not an excuse to break them even more. That being said, if you think it's okay, then merge it. |
No description provided.