<ELLIOTTCABLE>
also, you keep linking me comment-less, undocumented code, in a language I don't know, on a *subject* I don't understand, without any description of what you're telling me to look at :P
<ELLIOTTCABLE>
you forget I'm dumb!
<Cheery>
I keep doing that yeah, sorry.
<Cheery>
lets start over.
oldskirt_ has joined #elliottcable
oldskirt_ has joined #elliottcable
<Cheery>
I started doing an LR(1) parser before weekend.
<Cheery>
canonical LR. People used to do LALR because canonical LR tables grow large.
<Cheery>
I'll see how large they can get.
<Cheery>
I wrote a new tokenizer for my language just small while ago
<Cheery>
it's not space sensitive anymore, because that would increase amount of stupid rules
oldskirt has quit [Ping timeout: 250 seconds]
<Cheery>
sums -> sums space plus space term
<Cheery>
sums -> sums plus term
<Cheery>
or even space_sums
<Cheery>
I'll remove the form () ->
<Cheery>
as well.
<Cheery>
replacin it with: act arguments
<Cheery>
and act arguments return value
<ELLIOTTCABLE>
LR(1)?
<ELLIOTTCABLE>
I'm sure I could google it, but just sayin', define your terms if you're not in a setting where everybody's guaranteed to know what you mean. (=
<Cheery>
bottom up, left to right parsing with one lookahead t oken
<ELLIOTTCABLE>
also, I think we covered this briefly a while back, but,
<ELLIOTTCABLE>
do you have any interesting semantic goals, or are you purely investigating syntax / parser?
<Cheery>
your turn. what is an interesting semantic goal?
<ELLIOTTCABLE>
new paradigms, new thought-processes, new ways to ease developers' brain-loads for a specific kind of task;
<ELLIOTTCABLE>
new target markets previously left unfulfilled, new niches of productivity,
<ELLIOTTCABLE>
‘semantics:’ anything that isn't syntax :P
<Cheery>
by accident I may have hit something interesting like that, but I was merely investigating.
<Cheery>
sometime week back then, I tried to write a transcompiler. I called it axbattler.
<Cheery>
s/do not parse/do not interpret or compile/
<Cheery>
bash magic ):
<Cheery>
:)
<Cheery>
I love bash for what it lets me do.
<Cheery>
anyway I hit a problem with axbattler.
<Cheery>
Would like to parse type casts like this:
<Cheery>
int** <- malloc(stuff);
<Cheery>
binding would be same as with =, so it would make a chain like: vals = int** <- malloc(stuff)
<Cheery>
but with hand written parser, this is getting out of hand.
<Cheery>
I realised what I had done with axbattler is great. cool stuff.
<Cheery>
but couldn't do it for my second hand written parser in the language language.
<Cheery>
the one I should name.
<ELLIOTTCABLE>
"the language language"
<ELLIOTTCABLE>
I lol'd
<purr>
lol
<Cheery>
so started studying parsers again, and parser generators.
<Cheery>
LR parsers were some that I hadn't studied yet, so picked those and banged my head against them until I understood them.
<Cheery>
turns out, it's damn cool way to parse things. Writing the parser was almost like writing very nice interpreter.
<Cheery>
with reduce and shift instructions.
<ELLIOTTCABLE>
what's LR stand for?
<Cheery>
had to check it up. L means left to right and top to bottom across the full input file
<Cheery>
R means reversed rightmost derivation, which means that the output comes reversed, rightmost.
<Cheery>
LR parser is sort of like normal handwritten parser, but it jumps directly into deepest item in the grammar that matches, then starts reducing up from that.
<ELLIOTTCABLE>
reversed, rightmost
<ELLIOTTCABLE>
wat
<Cheery>
it means the order in which it works.
<ELLIOTTCABLE>
let me repeat, this is some excellent advice:
<Cheery>
I think I'll write up how the LR parsers work. trying to do it as clearly as I can.
<ELLIOTTCABLE>
Cheery: I'd read that. (=
<ELLIOTTCABLE>
or try to. >,>
<ELLIOTTCABLE>
Cheery: CORRESPONDINGLY, YOU SHOULD WRITE A PAWS, IN CASE I HAVEN'T MENTIONED THAT <3
<ELLIOTTCABLE>
or even better, because it seems to be your area of interest, build an interpretive-preprocessor for Paws. ;)
<Cheery>
could probably consider now.
<Cheery>
anyway why I'm interested on here is because it seems to be a feasible way to design a parser, which recognises only the stuff it can process, and which doesn't lug parse trees around.
<ELLIOTTCABLE>
LR's ignore shit they don't recognize? that's very interesting.
<ELLIOTTCABLE>
oh, on that note, devyn
<ELLIOTTCABLE>
I've been thinking: paired tokens *really* restrict later dynamic-syntax shit.
<Cheery>
rather doesn't ignore, they report syntax error
<ELLIOTTCABLE>
basically, “you can do whatever you want before the statements that resolve to parsing instructions, *but*, all quotes and all brackets have to match in any syntax before that, no matter what crazy shit you want to do.”
<ELLIOTTCABLE>
which leads me to want to minimize the set of paired brackets we squat on …
<ELLIOTTCABLE>
… which, and you'll hate me for this, leads me to want to remove execution literals entirely.
<ELLIOTTCABLE>
replacing them with a JavaScript-Function-constructor-ish solution: something that does the parsing at runtime.
<ELLIOTTCABLE>
then the only paired tokens are quote-marks.