<d_bot>
<iman> is there a quick way to get function bodies given an Ocaml source code? Like:
<d_bot>
<iman> ```
<d_bot>
<iman> let mark_prime i sieve =
<d_bot>
<iman> let rec mark_prime_aux i inc =
<d_bot>
<iman> if i < size sieve then begin
<d_bot>
<iman> sieve.(i) <- Composite;
<d_bot>
<iman> mark_prime_aux (i + inc) inc
<d_bot>
<iman> end in
<d_bot>
<iman> if sieve.(i) = Unknown then begin
<d_bot>
<iman> sieve.(i) <- Prime;
<d_bot>
<iman> mark_prime_aux (2 * i) i
<d_bot>
<iman> end
<d_bot>
<iman> ```
<d_bot>
<iman> giving me the function body for "make_prime" and "make_prime_aux" ? (generally a list of function names and their bodies)
<d_bot>
<iman> I've tried "ocamlc -dparsetree"/ dtypedtree, but parsing the output of that is a task on itself, I don't even need the extra info, just the textual info of function body.
mmalter has joined #ocaml
zebrag has quit [Quit: Konversation terminated!]
gravicappa has joined #ocaml
waleee has quit [Ping timeout: 240 seconds]
hendursaga has quit [Remote host closed the connection]
hendursaga has joined #ocaml
waleee has joined #ocaml
bartholin has joined #ocaml
Serpent7776 has joined #ocaml
Haudegen has joined #ocaml
hackinghorn has joined #ocaml
hornhack has quit [Ping timeout: 252 seconds]
mro has joined #ocaml
hendursa1 has joined #ocaml
hendursaga has quit [Ping timeout: 244 seconds]
hackinghorn has quit [Ping timeout: 248 seconds]
favonia has quit [Ping timeout: 252 seconds]
gravicappa has quit [Ping timeout: 248 seconds]
gravicappa has joined #ocaml
olle has joined #ocaml
PinealGlandOptic has quit [Ping timeout: 240 seconds]
krnkktz has quit [Quit: Bridge terminating on SIGTERM]
schube[m] has quit [Quit: Bridge terminating on SIGTERM]
Tardigreat[m] has quit [Quit: Bridge terminating on SIGTERM]
labor[m] has quit [Quit: Bridge terminating on SIGTERM]
smondet[m] has quit [Quit: Bridge terminating on SIGTERM]
fluxm has quit [Quit: Bridge terminating on SIGTERM]
mewfree[m] has quit [Quit: Bridge terminating on SIGTERM]
marinelli[m] has quit [Quit: Bridge terminating on SIGTERM]
krnkktz has joined #ocaml
labor[m] has joined #ocaml
fluxm has joined #ocaml
mewfree[m] has joined #ocaml
smondet[m] has joined #ocaml
schube[m] has joined #ocaml
Tardigreat[m] has joined #ocaml
marinelli[m] has joined #ocaml
hackinghorn has joined #ocaml
hornhack has joined #ocaml
PinealGlandOptic has joined #ocaml
hackinghorn has quit [Ping timeout: 252 seconds]
mro has quit [Remote host closed the connection]
mro has joined #ocaml
PinealGlandOptic has quit [Quit: leaving]
mro has quit [Ping timeout: 252 seconds]
bartholin has quit [Read error: Connection reset by peer]
mro has joined #ocaml
mro has quit [Remote host closed the connection]
mro has joined #ocaml
chrde[m] has joined #ocaml
<d_bot>
<Kakadu> Old versions of opam were able to give a name to a switch being created. Buy now I have issues with that. Any ideas?
<olle>
Would supporting LR(2) make sense, or is that the same amount of trouble as LR(x) (compared to LR(1))?
jonasbits has quit [Quit: No Ping reply in 180 seconds.]
jonasbits has joined #ocaml
<d_bot>
<Kakadu> @TheBloodlessMan I hade same issue. I was trying to use first-class pattern mathcing from ppxlib, but default combinator for type_declaration was not have a place for attributes. Whan I wrapped it with a combinator for attributes, the problem was solved
<d_bot>
<Alistair> I'm not using attributes though, just structure-level extensions
<d_bot>
<Alistair> Oh I've figured out what it is
jonasbits has quit [Ping timeout: 258 seconds]
<d_bot>
<Alistair> OCaml doc is adding attributes due to comments
bartholin has joined #ocaml
glassofethanol has joined #ocaml
<olle>
Hm, no GLR grammar for Menhir? Seems to be supported by Bison.
mro has quit [Remote host closed the connection]
jonasbits has joined #ocaml
mro has joined #ocaml
spip has quit [Ping timeout: 248 seconds]
mro has quit [Ping timeout: 240 seconds]
mro has joined #ocaml
cedric has joined #ocaml
mro has quit [Ping timeout: 258 seconds]
spip has joined #ocaml
mro has joined #ocaml
mro has quit [Ping timeout: 240 seconds]
Haudegen has quit [Quit: Bin weg.]
jonasbits has quit [Ping timeout: 240 seconds]
jonasbits has joined #ocaml
favonia has joined #ocaml
mro has joined #ocaml
mro has quit [Ping timeout: 240 seconds]
mro has joined #ocaml
mro has quit [Ping timeout: 252 seconds]
mro has joined #ocaml
Haudegen has joined #ocaml
mro has quit [Remote host closed the connection]
mro has joined #ocaml
mro has quit [Remote host closed the connection]
mro has joined #ocaml
hendursa1 has quit [Quit: hendursa1]
hendursaga has joined #ocaml
mro has quit [Remote host closed the connection]
kakadu has quit [Quit: Konversation terminated!]
adanwan has quit [Remote host closed the connection]
adanwan has joined #ocaml
glassofethanol has quit [Quit: leaving]
olle has quit [Ping timeout: 252 seconds]
mro has joined #ocaml
mro has quit [Remote host closed the connection]
mro has joined #ocaml
adanwan has quit [Ping timeout: 244 seconds]
adanwan has joined #ocaml
mro has quit [Remote host closed the connection]
Haudegen has quit [Quit: Bin weg.]
hackinghorn has joined #ocaml
hornhack has quit [Ping timeout: 248 seconds]
Tuplanolla has joined #ocaml
catern has quit [Ping timeout: 272 seconds]
olle has joined #ocaml
mro has joined #ocaml
Haudegen has joined #ocaml
hornhack has joined #ocaml
hackinghorn has quit [Ping timeout: 248 seconds]
mro has quit [Remote host closed the connection]
mro has joined #ocaml
<olle>
What's the question mark in Menhir parsing? Anyone knows?
<companion_cube>
zero or one of
<olle>
companion_cube: thanks!
<olle>
companion_cube: did they also switch the meaning of %token and %type compared to Bison?
<olle>
%token <d> NUMBER in Bison
<olle>
But %type <d> NUMBER in Menhir? 0o
<companion_cube>
I have no idea
<companion_cube>
%type declares types
<companion_cube>
doesn't seem too outrageous
mro has quit [Remote host closed the connection]
mro has joined #ocaml
gravicappa has quit [Ping timeout: 240 seconds]
* olle
needs to read more..,.
mro has quit [Remote host closed the connection]
landonf has quit [*.net *.split]
ks_ has quit [*.net *.split]
engil1 has quit [*.net *.split]
tristanC has quit [*.net *.split]
thvnx has quit [*.net *.split]
drakonis has quit [*.net *.split]
arg_ has quit [*.net *.split]
octachron has quit [*.net *.split]
thvnx has joined #ocaml
arg_ has joined #ocaml
tristanC has joined #ocaml
thvnx has joined #ocaml
thvnx has quit [Changing host]
landonf has joined #ocaml
engil1 has joined #ocaml
tristanC has joined #ocaml
tristanC has quit [Changing host]
drakonis has joined #ocaml
octachron has joined #ocaml
drakonis has quit [Signing in (drakonis)]
drakonis has joined #ocaml
octachron has quit [Client Quit]
octachron has joined #ocaml
ks_ has joined #ocaml
<d_bot>
<colin> I've never seen anyone use the latter for declaring the terminal (as a number would be). Seems pretty consistent with bison; %token for terminals, %type for resultant types of non-terminal's reductions.
mro has joined #ocaml
mro has quit [Remote host closed the connection]
catern has joined #ocaml
<olle>
colin, %type is also the AST, right?
adanwan has quit [Remote host closed the connection]
adanwan has joined #ocaml
<d_bot>
<colin> You'd usually make semantic actions associated with each non-terminal yield something of a certain type associated with how you represent the AST, yes. LR works bottom-up, so it's convenient for constructing ASTs where each rule containing a non-terminal in its body is already reduced.
<olle>
Hm
<d_bot>
<colin> Clarification: the non-terminals in a rule being reduced have already, themselves, been reduced. I say bottom-up, but of course, the tree is constructed towards the root, so it's a backwards metaphor there.
<olle>
I have a book here about flex & bison :)
<olle>
Comparing it to a Menhir implementation of C
<d_bot>
<NULL> `%type` allows for type hinting, it's no more than the `": t"` in `"let non_terminal : t = ..."` where `...` is what Menhir fills in
<d_bot>
<colin> I've used both and usually my efforts in constructing a bison grammar start by attempting to port menhir grammars directly (unfolding out things from the standard.mly). Despite the fact they generate different parsers by default (menhir is LR(1) and produces mutually-recursive functions; and I think bison is LALR - by default - and actually outputs an LR table), I've had no major problems in going between them.
<d_bot>
<colin> Must be said that bison's awkwardness is probably a core reason why LR generators leave a bad first impression. Thankfully they can be saved by menhir. :ocamllove:
<companion_cube>
menhir can also generate a table, I think
<d_bot>
<colin> So you can use `--table` to generate a table and must use that for incremental parsing.
<companion_cube>
iirc it can also be useful to avoid code bloat
<olle>
How is Menhir not awkward?
<companion_cube>
by being pretty cool
<companion_cube>
idk, it's overall quite nice, there's a good manual, the syntax is reasonably straightforward (notwithstanding the separators between sections)
<companion_cube>
that it doesn't exactly match what bison does, is super irrelevant
mro has joined #ocaml
waleee has quit [Quit: WeeChat 3.2]
<d_bot>
<colin> It's substantially more pleasant to use than bison, in my opinion.
<d_bot>
<colin> - Can integrate a menhir parser with like 1-2 stanzas in a dune file.
<d_bot>
<colin> - It has a standard.mly and syntax sugar (EBNF) for common production patterns ((non-empty)-lists, optionals, etc.).
<d_bot>
<colin> - You can ascribe .messages files to explain certain parsing errors based on states.
<d_bot>
<colin> - Can parameterise parser by a module. I do this to track locations w/ a symbol table. There's other ways, but that's what I use it for.
<d_bot>
<colin> - You don't need to work around historical weirdness or poorly documented features of flex or bison. If you want to get an AST out of bison, you probably wanna pass a double pointer via %parse-param.
<d_bot>
<colin> - Somewhat easier to debug grammars with. Although, I usually just refer to a subset of the parsing table using other tools.
<d_bot>
<colin> Flex and bison are some of the hackiest tooling to integrate with effectively. I'm convinced that people who hold a bad opinion of LR parsing do so purely because they tried bison once.
<d_bot>
<colin> Could argue that most of my points aren't bison-centric and are are just imposed by the language bison is intended to be used with. Either way, menhir is nicer (even if some of it is just because OCaml is nicer to work with).
<companion_cube>
@colin the errors when the grammar is ambiguous aren't bad either
<companion_cube>
you can ask for an automaton and the bad transitions