<d_bot>
<Et7f3> I don't think you could. To expose all value the value has to be computed and `let () = smth` may be useful for the rest of the file. So no hope for this.
osa1 has joined #ocaml
decentpenguin has quit [Read error: Connection reset by peer]
decentpenguin has joined #ocaml
Haudegen has joined #ocaml
jbrown has joined #ocaml
<d_bot>
<EduardoRFS> anyone knows a good solution in OCaml for the "typed AST problem"?
<d_bot>
<ostera> isn't this what Parsetree -> Typedtree is doing?
<d_bot>
<EduardoRFS> yeah the parsetree -> typedtree is one of the solutions, essentially "have two ASTs"
<d_bot>
<ostera> i presume you could parametrize your AST type with a type type
<d_bot>
<ostera> and then every node could carry around either some or no type info, like they describe in the link
<d_bot>
<EduardoRFS> another solution, I think this one is the one selected by Coq, but yeah I'm more inclined for that
<d_bot>
<ostera> you mean you're inclined for the dual ast or the coq approach? (and what is the coq approach btw?)
<d_bot>
<EduardoRFS> coq approach is to have the parameter in the AST to carry additional info, this is what I'm more inclined for
<d_bot>
<ostera> i guess it is more a question of what properties would you want the resulting AST to have
<d_bot>
<ostera> e.g, is it okay for some nodes to not have type information at all after the pass?
<d_bot>
<ostera> (since that would be representable)
<d_bot>
<EduardoRFS> nope, but that is okay with the AST having additional type info, you can enforce that all nodes need to have the additional info, the problem is that if you have a bunch of types, then at some point your type will have a bunch of parameters
<d_bot>
<EduardoRFS> like the additional kind of data that goes in a function parameter is different than the data that goes in a expression value
<d_bot>
<ostera> yes, that is true, you'd have to use GADTs for this
<d_bot>
<EduardoRFS> so expr would effectivelly be `type ('expr_data, 'parameter_data) expr`
<d_bot>
<EduardoRFS> hmmm
<d_bot>
<ostera> (and now I get why @octachron mentioned building a tiny language with them)
<d_bot>
<ostera> so that all your typed expressions end up as a single `type_info` type with a consistent set of visible parameters
<d_bot>
<EduardoRFS> yeah that's exactly what I'm doing, just implementing a full compiled language pipe for fun, on a sunday
<d_bot>
<ostera> except its monday already haha
<d_bot>
<ostera> (here)
<d_bot>
<EduardoRFS> here too, I'm just lost at this point
<d_bot>
<EduardoRFS> the GADT thing may be interesting, thank you will give a look
<d_bot>
<ostera> but sounds like a lot of fun 🙂 I've been writing an ocaml -> erlang compiler for the past 10 days and I'm thankful for not having to deal with the syntax itself of OCaml, but just work on the typedtree
<d_bot>
<ostera> (i know the typedtree is very close to the syntactic representation anyway)
<d_bot>
<EduardoRFS> yeah this one for me is a way to develop a little bit more intuition when handling type systems
<d_bot>
<ostera> I'm sure someone in #coq will be able to shed some light on their approach
zebrag has joined #ocaml
inkbottle has quit [Ping timeout: 272 seconds]
camlriot42 has left #ocaml ["Kicked by @appservice-irc:matrix.org : Idle for 30+ days"]
reynir has quit [Quit: WeeChat 2.3]
reynir has joined #ocaml
<d_bot>
<Drup> (you don't really need GADT for that particular kind of thing)
worc3131 has quit [Remote host closed the connection]
reynir has quit [Client Quit]
reynir has joined #ocaml
worc3131 has joined #ocaml
reynir has quit [Client Quit]
reynir has joined #ocaml
reynir has quit [Client Quit]
reynir has joined #ocaml
reynir has quit [Client Quit]
reynir has joined #ocaml
borne has joined #ocaml
<d_bot>
<ostera> @Drup how'd you do @EduardoRFS's `type ('expr, 'param) expr` AST without them?
<d_bot>
<EduardoRFS> just add the parameter to every self reference
<d_bot>
<dinosaure> even if it's an interesting job, it's not very useful - may be to use it with `malfunction` but it's just for "fun"
<d_bot>
<EduardoRFS> yeah was thinking on what Drup sent
<d_bot>
<ostera> okay, so the ast would look like?
<d_bot>
<ostera>
<d_bot>
<ostera> something like:
<d_bot>
<ostera> ```ocaml
<d_bot>
<ostera>
<d_bot>
<ostera> let ast =
<d_bot>
<ostera> | If_then_else of bool expr * 'a expr * 'a expr
<d_bot>
<ostera> | Let of name * 'a expr
<d_bot>
<ostera> ```
<d_bot>
<ostera>
<d_bot>
<ostera> wouldn't work and will force you to parametrize `ast` as well, unless you have a language over a specific `'a` (int, bool, etc),
reynir has quit [Quit: WeeChat 2.3]
reynir has joined #ocaml
<d_bot>
<ostera> i mean, I can see it working if there's no `'a` whatsoever, like in OCaml's `Texp_ifthenelse of expression * expression * expression option`
<d_bot>
<ostera> @Drup, but the moment you parametrize your expressions like that, don't you lose the composability of the `ast` type unless you purposefuly hide that `'a`? 🤔
sagax has joined #ocaml
<d_bot>
<Et7f3> also how during parsing you can emit a bool expr / other expr ?
<d_bot>
<Et7f3> ah nevermind we can just parse the whole if/then/else.
<d_bot>
<EduardoRFS> @ostera parameterizing everything is what I was thinking so ast will accept an 'a
<d_bot>
<Drup> @ostera no, `bool expr` doesn't make sense here, it's not the content of the node, it's the annotation
<d_bot>
<Drup> so, ,`ast = unit expr` and `tast = types expr`
<d_bot>
<EduardoRFS> +1
<d_bot>
<ostera> unless you're planning on using different types for `types`, wouldn't you be able to write `annot: types option` ? 🤔 no parameters.
<d_bot>
<ostera> but yeah i see the point now, thanks Drup 🙂
<d_bot>
<EduardoRFS> I'm also looking at attribute grammar
<d_bot>
<Drup> no, if you use an option, you might have places without types
<d_bot>
<Drup> the result of typing is a fully typed ast
<d_bot>
<Drup> no options.
<d_bot>
<Drup> Also, you could have another pass for some form of static analysis where you add other annotations, and so on
<d_bot>
<ostera> yup, i see it
<d_bot>
<EduardoRFS> with the drup approach I just need a traverse that will add the annotations doing `('a -> 'b) -> 'a expr -> 'b expr`
<d_bot>
<ostera> ```ocaml
<d_bot>
<ostera> type 'annot expr = {
<d_bot>
<ostera> desc: 'annot desc_expr;
<d_bot>
<ostera> annot: 'annot
<d_bot>
<ostera> }
<d_bot>
<ostera> ```
<d_bot>
<ostera>
<d_bot>
<ostera> what tripped me here was that I was thinking of `'a` as the `'expression_type` instead of the annotation type
<d_bot>
<ggole> You can do that, but it becomes pretty complicated
<d_bot>
<ostera> yeah, that's where I thought you'd have to end up using GADTs to be able to compose the expression values, while hiding the final expression type
<d_bot>
<ggole> GADTs aren't necessary, you just have a knot-tying type
<d_bot>
<ggole> But when you have mutually recursive types it is finicky
<d_bot>
<ostera> what would this knot-tying type be?
<d_bot>
<EduardoRFS> I think I should try to search for some alternatives, maybe adding data to the AST shouldn't be the way to do things
<d_bot>
<ggole> ```ocaml
<d_bot>
<ggole> type 'a open_expr =
<d_bot>
<ggole> | Int of int
<d_bot>
<ggole> | Add of 'a * 'a
<d_bot>
<ggole>
<d_bot>
<ggole> type expr_plain = Plain of expr_plain open_expr
<d_bot>
<ggole>
<d_bot>
<ggole> type expr_with_loc = WithLoc of loc * expr_with_loc open_expr
<d_bot>
<ggole> ```
<d_bot>
<ggole> Like that
<d_bot>
<ggole> Another alternative is to stash an id in each node and then have a map from that id to whatever info you like
<d_bot>
<ostera> but there's nothing guaranteeing you won't build a `bool open_expr` using `Add (True, False)`
<d_bot>
<Drup> You do need GADT for "return type tying"
<d_bot>
<Drup> I do not recommend it
mbuf has joined #ocaml
<d_bot>
<Drup> (at least in non-toy use cases)
<d_bot>
<ggole> `bool open_expr` isn't a real problem though
<d_bot>
<EduardoRFS> `| Add of 'a open_expr * 'a open_expr`
<d_bot>
<ggole> The functions you write will either be written to be polymorphic over the `open_expr` or to use one of the concretised expr types (which exclude `bool open_expr`)
<d_bot>
<EduardoRFS> Then you have the constraint
<d_bot>
<ostera> i guess it depends on whether you need to have the return type constrain the compositionality of the expression type
<d_bot>
<ggole> And `bool open_expr` existing is not a problem for either case
<d_bot>
<ggole> `Add of 'a open_expr * 'a open_expr` does not include the annotation info
mfp has joined #ocaml
<d_bot>
<ostera> ```ocaml
<d_bot>
<ostera> | Add of int open_expr * int open_expr
<d_bot>
<ostera> ```
<d_bot>
<ostera>
<d_bot>
<ostera> would constrain add to ints, but you can still build a `bool open_expr` from it, since `'a` is now just a phantom
<d_bot>
<ostera> not saying that this doesn't work, just trying to figure out what are the limits of the static guarantees 🙂
<d_bot>
<ggole> The point of `Add of 'a * 'a` is that you can make `'a` contain whatever info you like (including none)
<d_bot>
<ggole> Once you hardcode `Add of 'a open_expr` that is gone (and the name `open_expr` is no longer accurate)
<d_bot>
<ostera> ah, so it was more about "here's how you can add any annotation information to an expression"
<d_bot>
<ostera> okay yeah, i see that as well with the Plain and WithLoc constructors, your `'a` is growing to include more data by extending the tuple
<d_bot>
<ggole> open types can also express some other things, eg, expressions with holes
<d_bot>
<ggole> So they do actually give you a fair amount of flexibility in exchange for the pain
<d_bot>
<Drup> You are talking about 2 different things. Return typing vs extensible datatypes
free_beard has joined #ocaml
webshinra has joined #ocaml
zozozo has quit [Remote host closed the connection]
Haudegen has quit [Quit: Bin weg.]
zozozo has joined #ocaml
<mbuf>
Base is not ported to build with 4.12.0 trunk yet?
waleee-cl has quit [Quit: Connection closed for inactivity]
webshinra has quit [Remote host closed the connection]
webshinra has joined #ocaml
waleee-cl has joined #ocaml
vicfred has quit [Quit: Leaving]
<d_bot>
<ostera> Hey folks, i'm getting a "lexing: empty token" from the runtime/lexing.c -- is this normally because the file lexbuf i'm passing is in fact empty, or does this error mean that we can't even parse the first thing we see? 🤔
vicfred has joined #ocaml
worc3131 has quit [Ping timeout: 272 seconds]
<d_bot>
<ostera> neeevermind, turned out I had unsupported characters 🆗
narimiran has quit [Ping timeout: 256 seconds]
DanC has joined #ocaml
dckc has quit [Ping timeout: 265 seconds]
osa1 has quit [Ping timeout: 272 seconds]
nicoo has quit [Quit: WeeChat 1.7.1]
nicoo has joined #ocaml
ggole has quit [Quit: Leaving]
DanC has quit [Ping timeout: 246 seconds]
dckc has joined #ocaml
averell has joined #ocaml
webshinra has quit [Read error: Connection reset by peer]
<d_bot>
<gar> Hi folks. I need some help debugging an " inconsistent assumptions over interface" bug. I'm trying to build and archive from foo__Bindings.cmx and foo_Vector.cmx. The former depends on the latter. The latter, but not the former, has an mli file. The modules compile just fine, but I'm getting this:
<d_bot>
<gar> and bazel-out/darwin-fastbuild/bin/src/camlsnark_c/bindings/Camlsnark_c_bindings__Vector.cmx
<d_bot>
<gar> make inconsistent assumptions over interface Camlsnark_c_bindings__Vector
<d_bot>
<gar> ```
<d_bot>
<gar> I gather this means the cmx files were produced against different vector.cmi files? The build pipeline (using my own Bazel code) looks like this: compile vector.mli, compile vector.ml (using the vector.cmi from first step), compile bindings.ml (depending on vector.cmx and cmi from prev. step). But obviously something has gone awry. Not sure how to debug this, suggestions welcome.
<d_bot>
<gar> Also, what does "Internal path X is dangling" mean?
<d_bot>
<Titou> @Zeti 👆🏻
bronsen has quit [Remote host closed the connection]
bronsen has joined #ocaml
Tuplanolla has quit [Quit: Leaving.]
reynir has quit [Ping timeout: 256 seconds]
reynir has joined #ocaml
jbrown has quit [Ping timeout: 272 seconds]
Haudegen has quit [Ping timeout: 258 seconds]
sonologico has quit [Remote host closed the connection]