TheRuralJuror has quit [Ping timeout: 258 seconds]
mxns has joined #ocaml
mxns has quit [Ping timeout: 272 seconds]
Tuplanolla has quit [Quit: Leaving.]
mxns has joined #ocaml
olle has quit [Ping timeout: 260 seconds]
olle has joined #ocaml
mxns has quit [Ping timeout: 260 seconds]
borne has quit [Ping timeout: 260 seconds]
_whitelogger has joined #ocaml
borne has joined #ocaml
borne has quit [Ping timeout: 264 seconds]
<mrvn>
companion_cube: If fibers had stack frames on the heap then C calls would need to allocate a stack. But the runtime could just have a free-list of stacks and reuse them over and over.
<companion_cube>
C calls would have to copy the stack onto the real stack, I think?
<companion_cube>
not sure how it works anyway
<mrvn>
companion_cube: what real stack? Each ocaml function would allocate a stack frame and assign it to SP. For C calls you grab a big stack and assign it to SP and call the function.
<mrvn>
The stack frames would be on the minor heap so allocating them would be cheap. Same cost for incrementing the minor heap pointer as for decreasing the SP has now.
<mrvn>
small extra cost for the header.
<mrvn>
One big advantage of allocates stack frames would be that you can implement call-cc.
<companion_cube>
no one wants to implement call-cc :p
<mrvn>
things like coroutines become trivial
<companion_cube>
(I think effects are like one-shot delimited continuations?)
<companion_cube>
(and more efficient than full call-cc)
<mrvn>
Not sure what effects are. Saw them mentioned but not explained.
<companion_cube>
well, they're described on the wiki and in some papers I think
<companion_cube>
but apparently they're close to common lisp's conditions
<companion_cube>
a bit like a try/with but where you get, in the handler, a (one shot) continuation to the point that raised the effect
<companion_cube>
(so, the moral equivalent of `raise` returns a value `x` in case the continuation is called with `x`)
mxns has joined #ocaml
mfp has quit [Ping timeout: 256 seconds]
_whitelogger has joined #ocaml
<mrvn>
That "one shot" part scares me. That's not something the ocaml type system can express. I would love to have that for tother things too. Like a file descriptor. "close fd" mutates the type from an open FD to a close FD and read/write would only work with open FDs.
amiloradovsky has joined #ocaml
amiloradovsky has quit [Remote host closed the connection]
amiloradovsky has joined #ocaml
reynir has quit [Ping timeout: 240 seconds]
reynir has joined #ocaml
amiloradovsky has quit [Remote host closed the connection]
amiloradovsky has joined #ocaml
waleee-cl has quit [Quit: Connection closed for inactivity]
narimiran has joined #ocaml
mxns has quit [Ping timeout: 264 seconds]
osa1 has joined #ocaml
<dmbaturin>
mrvn: Do you know a type system that can express that?
mxns has joined #ocaml
mxns has quit [Ping timeout: 264 seconds]
<mrvn>
dmbaturin: linear type systems, rust has that
tane has joined #ocaml
<dmbaturin>
mrvn: Oh, I thought you mean a hypothetical stronger version. Need some coffee. ;)
vicfred has quit [Remote host closed the connection]
vicfred has joined #ocaml
Haudegen has joined #ocaml
borne has joined #ocaml
tane has quit [Quit: Leaving]
Tuplanolla has joined #ocaml
vicfred has quit [Quit: Leaving]
amiloradovsky has quit [Remote host closed the connection]
amiloradovsky has joined #ocaml
<adrien>
quick heads up for now, it seems that opam.ocaml.org doesn't compress the .js files it sends and not search.js in particular while it weighs 2MB compressed and a fourth of that uncompressed
<adrien>
erf
<adrien>
2MB uncompressed and a fourth of that compressed
bartholin has joined #ocaml
<d_bot>
<hhugo> They have deployed the dev version (without dead code elimination and minification)
bartholin has quit [Quit: Leaving]
amiloradovsky has quit [Remote host closed the connection]
amiloradovsky has joined #ocaml
hnOsmium0001 has quit [Quit: Connection closed for inactivity]
mxns has joined #ocaml
mxns has quit [Ping timeout: 260 seconds]
amiloradovsky has quit [Remote host closed the connection]
amiloradovsky has joined #ocaml
amiloradovsky has quit [Remote host closed the connection]
amiloradovsky has joined #ocaml
mfp has joined #ocaml
amiloradovsky has quit [Remote host closed the connection]
amiloradovsky has joined #ocaml
Haudegen has quit [Quit: Bin weg.]
amiloradovsky has quit [Remote host closed the connection]
amiloradovsky has joined #ocaml
kvik has quit [Ping timeout: 258 seconds]
amiloradovsky has quit [Remote host closed the connection]
amiloradovsky has joined #ocaml
Haudegen has joined #ocaml
osa1 has quit [Ping timeout: 256 seconds]
schlaftier has quit [Quit: Ping timeout (120 seconds)]
schlaftier has joined #ocaml
mmohammadi9812 has quit [Quit: Quit]
mmohammadi9812 has joined #ocaml
mmohammadi9812 has quit [Client Quit]
mmohammadi9812 has joined #ocaml
mmohammadi9812 has quit [Ping timeout: 260 seconds]
mmohammadi9812 has joined #ocaml
amiloradovsky has quit [Remote host closed the connection]
amiloradovsky has joined #ocaml
amiloradovsky has quit [Remote host closed the connection]
amiloradovsky has joined #ocaml
<adrien>
hhugo, ah, I see :/
<adrien>
well, at least gzip would help here
mxns has joined #ocaml
mxns has quit [Ping timeout: 240 seconds]
osa1 has joined #ocaml
ggole has joined #ocaml
<d_bot>
<Perry> On the file descriptor stuff above: see also typestate systems.
<d_bot>
<Drup> Eh, typestates.
<d_bot>
<Perry> someone had to invent it. I was at TJ Watson and knew Rob Strom. Note that this idea dates to 1983 or so, well before modern type theory became known to more than a handful of people.
<companion_cube>
mrvn: the OCaml type system already fails to represent a lot of things
<companion_cube>
including mutation, IOs, exceptions
<d_bot>
<Perry> Strom and Yemini did a lot of good work on the theory given that no one else was writing papers of that sort back then.
<d_bot>
<Drup> Oh, I'm aware of typesates, don't worry, i'm just highly sceptical of the practicality of it in a real usable programming language 🙂
<d_bot>
<Drup> the underlying type system machinery to make them work is just too overwhelming, imho
mxns has joined #ocaml
<d_bot>
<Drup> (and, more importantly, you can't seem to be able to hide the machinery under the carpet, unlike many other type system features)
kvik has joined #ocaml
<dmbaturin>
Got any links to those papers?
<d_bot>
<Drup> The old ones are probably very hard to read (old type theory papers always are). The more recent I know about are about languages called Plaid and Vault
<d_bot>
<Drup> dmbaturin: In general https://www.cs.cmu.edu/~aldrich/ is your guy, if you want to look deeper into typestate systems.
h11 has quit [*.net *.split]
chewbranca has quit [*.net *.split]
<Drup>
companion_cube: :surprised pikachu:
<companion_cube>
it's a good choice, I think
h11 has joined #ocaml
chewbranca has joined #ocaml
<companion_cube>
they expected a large ecosystem and picked ocaml 🤷
<companion_cube>
f# or scala would have been more reasonable
Manis[m] has quit [Ping timeout: 240 seconds]
BitPuffin has quit [Ping timeout: 240 seconds]
dash has quit [Ping timeout: 270 seconds]
bglm[m] has quit [Ping timeout: 244 seconds]
flux has quit [Ping timeout: 270 seconds]
lnxw37d4 has quit [Ping timeout: 260 seconds]
nkly has quit [Ping timeout: 264 seconds]
h11 has quit [Ping timeout: 246 seconds]
<Drup>
given their previous blogpost, I think a rewrite in F# will be strictly as beneficial as a rewrite still in OCaml would have been. They painted themselves into several corners by picking poor choices because of their lack of familiarity with the language/ecosystem, and complained about it. Some of the complaints are fair, but the rest is ... run of the mill.
aterius has quit [Ping timeout: 246 seconds]
labor[m] has quit [Ping timeout: 240 seconds]
peddie has quit [Ping timeout: 240 seconds]
aspiwack[m] has quit [Ping timeout: 244 seconds]
jimt[m] has quit [Ping timeout: 244 seconds]
Coueek[m] has quit [Ping timeout: 246 seconds]
ptival[m] has quit [Ping timeout: 246 seconds]
pqwy[m] has quit [Ping timeout: 272 seconds]
<companion_cube>
I'm not sure the .net ecosystem is as fragmented as OCaml
nkly has joined #ocaml
<companion_cube>
especially when it comes to IO and cloud stuff
<Drup>
does that really matter to build a product ?
<companion_cube>
if you're doing a super-cloud-heavy-thing, I think so
<dmbaturin>
So this is Ur/Web with cloud/serverless buzzwords, or I'm wrong? :)
<companion_cube>
and dark is clearly a language-in-the-cloud thing
<companion_cube>
(I don't like this idea, but well)
<dmbaturin>
* Elm, rather.
<companion_cube>
yep, it's a language where the devops is done for you! apparently.
<dmbaturin>
I may think Ur/Web is an evolutionary dead end workflow-wise, but I have to give Ur/Web the language a credit.
<Drup>
you mean tierless, or Ur/Web specifically ?
<companion_cube>
it takes a lot of marketing to sell a language
<dmbaturin>
>Result and Options will be types, not special cased into the language; but this made me think of Elm.
<Drup>
(imho, Ur/Web's compilation workflow/execution scheme is complete absurdity, but I would have lot's of things to say about ur/web :D)
<dmbaturin>
Drup: I mean even the choice of making Ur/Web a standalone language rather than a framework: if it takes M units of effort to market one, marketing both takes M squared...
amiloradovsky has quit [Remote host closed the connection]
amiloradovsky has joined #ocaml
<d_bot>
<Anurag> My takeaway from the initial post was that a lot of issues were related to them heavily locked into google cloud. AWS story is a little better when it comes to OCaml
waleee-cl has joined #ocaml
<d_bot>
<Anurag> and choosing not to use lwt or async was also probably something that ended up painting them into a corner
<companion_cube>
they seem to like using a lot of the "modern" cloud stuff
<d_bot>
<Anurag> True. We use AWS at work with services that correspond to the ones the talked about at google cloud. There have been some gaps in places, but it hasn't been difficult to find things that work well
<dmbaturin>
On a side note, now that my first patch to OCaml itself is merged, I suppose I need to add that to my CV. ;)
<Drup>
congrats :)
<dmbaturin>
Anurag: The question I'd be asking there is if they are helping users to _avoid_ the lock-in of "serverless" architectures.
<dmbaturin>
I mean Dark language.
<d_bot>
<Anurag> Dark definitely looks like it'll be a vendor lock-in. Worse than the cloud offerings from aws/google in my opinion
Manis[m] has joined #ocaml
lnxw37d4 has joined #ocaml
flux has joined #ocaml
dash has joined #ocaml
<companion_cube>
language lock in is the absolute worse
tane has joined #ocaml
bglm[m] has joined #ocaml
aspiwack[m] has joined #ocaml
labor[m] has joined #ocaml
aterius has joined #ocaml
BitPuffin has joined #ocaml
<dmbaturin>
companion_cube: If you are locked into a language, and that language is locked into a specific cloud provider, that's the worst situation I can imagine.
pqwy[m] has joined #ocaml
dash has quit [Quit: Bridge terminating on SIGTERM]
Manis[m] has quit [Quit: Bridge terminating on SIGTERM]
flux has quit [Quit: Bridge terminating on SIGTERM]
lnxw37d4 has quit [Quit: Bridge terminating on SIGTERM]
BitPuffin has quit [Quit: Bridge terminating on SIGTERM]
labor[m] has quit [Quit: Bridge terminating on SIGTERM]
aterius has quit [Quit: Bridge terminating on SIGTERM]
pqwy[m] has quit [Client Quit]
aspiwack[m] has quit [Quit: Bridge terminating on SIGTERM]
bglm[m] has quit [Quit: Bridge terminating on SIGTERM]
<companion_cube>
agreed
vicfred has joined #ocaml
<d_bot>
<glennsl> I might find it a bit ironic that they're complaining about the lack of an ecosystem for a langauge they chose to use.... to build an entirely new language and ecosystem from scratch...
<d_bot>
<Drup> @glennsl depends a bit on their FFI tho. If they have seamless call into js libs, it's not much of an issue.
<d_bot>
<glennsl> Sounds like it has an ML-like type system, so I imagine it wouldn't be that different from calling into C from OCaml.
<dmbaturin>
Type-safe calls into JS are never free.
<companion_cube>
I can't imagine how expensive the whole thing would be
<companion_cube>
it's like "serverless" but even worse
<dmbaturin>
glennsl: In one my project I'm calling OCaml from Python through C. :)
<d_bot>
<Anurag> From whatever i've read about their services before, their "FFI" just seems to be HTTP calls?
<mrvn>
dmbaturin: so two languages with a global interpreter lock. fun
<dmbaturin>
Soon™.
<mrvn>
dmbaturin: I'm hoping that at some point I can run 2 ocaml runtimes and call one from the other through C.
labor[m] has joined #ocaml
mxns has quit [Ping timeout: 264 seconds]
reynir has quit [Ping timeout: 240 seconds]
amiloradovsky has quit [Remote host closed the connection]
amiloradovsky has joined #ocaml
mxns has joined #ocaml
reynir has joined #ocaml
narimiran has quit [Ping timeout: 260 seconds]
Haudegen has quit [Quit: Bin weg.]
aterius has joined #ocaml
BitPuffin has joined #ocaml
jimt[m] has joined #ocaml
dash has joined #ocaml
lnxw37d4 has joined #ocaml
ansiwen[m] has joined #ocaml
pqwy[m] has joined #ocaml
Manis[m] has joined #ocaml
ptival[m] has joined #ocaml
Coueek[m] has joined #ocaml
h11 has joined #ocaml
bglm[m] has joined #ocaml
peddie has joined #ocaml
aspiwack[m] has joined #ocaml
xzax_[m]1 has joined #ocaml
flux has joined #ocaml
talyian[m] has joined #ocaml
quizzop[m] has joined #ocaml
<companion_cube>
me too, but one runtime would be bytecode and the other would be native
hnOsmium0001 has joined #ocaml
<motherfsck>
New to ocaml here and I have Question on global variables. Specific use case would be reading in a config file and setting defaults.
<motherfsck>
In a typical C program I'd define a global struct and access it with getters and setters. Naturally I reach for the tools I know so I have to ask; Is a mutable record type or global reference the way to go?
<motherfsck>
Or is there some other, more idiomatic way to accomplish this?
<Drup>
global mutable variables are, let's say, highly non-idiomatic
<companion_cube>
well, they come with the same set of problems as in C
<Drup>
it's slightly more usual to pass down a description of your options (with a record, for instance)
<mrvn>
You can just read in the config file into a immutable data structure.
<companion_cube>
these days I'm starting to have global `lazy …` using Sys.getenv_opt
<companion_cube>
for, say, debug configuration
<motherfsck>
immutable datastructure sounds like the best bet. I really don't want to be passing config options all over creation. That's going to get messy fast.
<mrvn>
motherfsck: no need to pass the options by themself. You can always pass a struct with all the options, or just the getter for options.
<mrvn>
If you have a fixed path to the options then I would just parse them into a global variable. If the config file can be specified on the command line then a ref might be simpler or passing a config object around. If you want to have default options and the config file can override stuff then mutable starts to sound better and better.
<mrvn>
practicality over idiomaticy
<companion_cube>
or you can have a merge operation on the config record
<companion_cube>
one that favors b in `merge a b`, so you can merge the user config with default config
<mrvn>
companion_cube: that requires mutability for a global variable
<motherfsck>
mrvn, thanks. I was talking about passing the struct all around, I'd still like to avoid that. I think I'll start with parsing them into an immutable global variable, then hiding that away behind getters.
<companion_cube>
mrvn: ah yes, or lazyness, depends on how you initialzie it
<motherfsck>
and a merge operation for mutable structures sounds really interesting
<mrvn>
motherfsck: a hashtbl might be a good choice.
<mrvn>
assuming your config is basically a key=value setup
<motherfsck>
yep, basic kv pairs so that'd work nicely
<mrvn>
hashtbl is mutable. So you can fill it with defaults, then parse the config file to update the settings and the getter is "let getter = hashtbl.find config"
<mrvn>
If you have a standard ini file with section "[foo]\n bla=blub ..." then hashtbl of hashtbl is practical.
<motherfsck>
noted
* mrvn
throws libinifiles-ocaml from ocaml-inifiles into the channel
<motherfsck>
thanks
amiloradovsky has quit [Remote host closed the connection]
amiloradovsky has quit [Remote host closed the connection]
amiloradovsky has joined #ocaml
narimiran has joined #ocaml
toppler has joined #ocaml
borne has quit [Ping timeout: 272 seconds]
amiloradovsky has quit [Remote host closed the connection]
amiloradovsky has joined #ocaml
<d_bot>
<Perry> I sometimes use pure functional maps to start for things like this and move to hash tables if and only if performance turns out to be an issue. usually it isn’t of course.
ggole has quit [Quit: Leaving]
berberman_ has joined #ocaml
berberman has quit [Ping timeout: 260 seconds]
Hrundi_V_Bakshi has joined #ocaml
mxns has quit [Ping timeout: 264 seconds]
mxns has joined #ocaml
madroach has quit [Ping timeout: 256 seconds]
osa1 has quit [Quit: osa1]
mxns has quit [Ping timeout: 264 seconds]
mxns has joined #ocaml
Anarchos has joined #ocaml
borne has joined #ocaml
borne has quit [Ping timeout: 264 seconds]
jnavila has joined #ocaml
Anarchos has quit [Quit: Vision[0.10.3]: i've been blurred!]
borne has joined #ocaml
jnavila_ has joined #ocaml
jnavila has quit [Ping timeout: 256 seconds]
amiloradovsky has quit [Remote host closed the connection]
amiloradovsky has joined #ocaml
narimiran has quit [Ping timeout: 258 seconds]
borne has quit [Ping timeout: 264 seconds]
borne has joined #ocaml
motherfsck has quit [Quit: quit]
Serpent7776 has quit [Quit: leaving]
<d_bot>
<ostera> @Drup do you have any thoughts on comparing two typedtrees?
<mrvn>
do you expect something else than getting equal/not-equal?
<d_bot>
<ostera> equal/not-equal would be enough
<mrvn>
then just compare them
<d_bot>
<ostera> i'd expect a structural equality to _sort of_ work
<d_bot>
<Drup> it won't
<d_bot>
<ostera> `a = b` -- but i'm not sure if there's something internally that is pointers to stuff
<d_bot>
<Drup> well, ok, what comparison do you want ?
<d_bot>
<ostera> so I want to know if `a` is _the same typedtree_ as `b`
<mrvn>
physically or structurally?
<d_bot>
<Drup> why not just use `==` ?
<d_bot>
<ostera> but _the same_ meaning, i arrived at it by a different compilation process, so structurally
<d_bot>
<Drup> ok, so not the same, but equivalent
<d_bot>
<ostera> better wording, yes, equivalent. their identity will be different.
<d_bot>
<Drup> right, so `=` is not going to fly, because of locations and billions of other reasons
<mrvn>
How does = work with C pointers? Does it check if a pointer goes outside the heap and then not follow it?
<d_bot>
<ostera> cool
<mrvn>
Drup: huh? = doesn't care about location
<companion_cube>
mrvn: C pointers (not naked ones) should point to a block
<d_bot>
<Drup> Can you explain the context/use case ?
<companion_cube>
which has a record of operations, including equality
<d_bot>
<ostera> yes
<d_bot>
<Drup> mrvn: the typedtree contains locations of each pieces of syntax
<mrvn>
companion_cube: C pointers, not ocaml blocks with a pointer to a block
<companion_cube>
C pointers are deprecated apparently :s
<companion_cube>
well, you're not supposed to directly manipulate C pointers
<d_bot>
<ostera> I have by unknown means fathomed two typedtrees from the netherrealm and I must tell if they are equivalent
<d_bot>
<ostera> (I'm trying to verify that the caramel compilation to erlang is in isomorphism)
<mrvn>
companion_cube: the non-naked pointers will eventually have a naked pointer too
<d_bot>
<Drup> I need a bit more context than that 🙂
<d_bot>
<ostera> so I got the path to and back from Erlang
<d_bot>
<Drup> okay, don't do that on the typedtree
<mrvn>
Wait? There is a language called caramel already or did you steal my compiler?
<d_bot>
<Drup> do that on the parsetree, either ocaml's or erlang's
<d_bot>
<ostera> should I just go for the parsetree there? 🤔
<companion_cube>
where would this naked pointer be?
<d_bot>
<Drup> you should now that public nudity is not allowed, wrap yourself and you'll be fine :3
<mrvn>
companion_cube: e.g. in a BigArray. Eventually you have a pointer to memory allocated by malloc.
<d_bot>
<ostera> (in wonder how does edits propagated to irc)
<companion_cube>
ah but when you see this pointer, you already know it's a C pointer
<companion_cube>
and you know how to compare since you saw the custom block already
<d_bot>
<ostera> @Drup okay, say i got the parsetrees ready
<mrvn>
companion_cube: I don't remember BigArray having custom blocks.
<d_bot>
<Drup> okay, now you need to be carefull about locations. 🙂
<d_bot>
<Drup> (and only that)
<d_bot>
<ostera> that sounds doable
<companion_cube>
mrvn: I suppose they do, if you can print them and compare them
<mrvn>
companion_cube: I think BigArray is a known type with builtin magic for that.
<d_bot>
<ostera> e.g, I can drop all location info from the parsetree that comes out of ocaml/parsing and then compare
<d_bot>
<Drup> one "simple" way is to use the parstree walkers to replace all locations by `Location.none` and then use poly equality
<d_bot>
<ostera> gotcha
<mrvn>
companion_cube: But lets say you really do have a totaly naked pointer. I don't think a = b would follow them and crash.
<d_bot>
<ostera> so the parsetree doesn't have any mutable stuff in it
<companion_cube>
mrvn: it might detect these pointers are out of heap, I'm not sure
<d_bot>
<Drup> No, the parsetree is a well behaved AST
<d_bot>
<ostera> how nice
<d_bot>
<ostera> alright, i'll brb
<mrvn>
companion_cube: I'm not sure too but believe the same.
<d_bot>
<Drup> (the typedtree is not, it has -~*°magic°*~- in it
<companion_cube>
I mean, is having references for unification really "magic"?
<mrvn>
ostera: Now I have to find a new name for my language. It's c/c++ like, minus the bad parts.
<companion_cube>
c-- ?
<mrvn>
About 19.160.000.000 results (0,60 seconds)
<d_bot>
<ostera> b++ ?
<mrvn>
About 521.000.000 results, getting better
<companion_cube>
this-should-be-rust-but-isnt
<companion_cube>
^ how about that? :p
<d_bot>
<Drup> ccube: you forget that the types are graphs, not trees, so the typedtree effectively has cycles, and that the physical equality should be used on the type variables, and ...
<companion_cube>
well, if they're references, of course
<companion_cube>
the graph part is funny though, yes
<d_bot>
<Drup> You can't just launch the polymorphic equality on it and expect anything reasonable
<companion_cube>
(is it the `as 'a` that causes it?)
<companion_cube>
oh sure
<companion_cube>
polymorphic equality is bad
<d_bot>
<Drup> (if you intend to compare it as ASTs)
<mrvn>
Does = still not do == or =?
<companion_cube>
right, right, that seems kind of doomed imho
<companion_cube>
the only ASTs worthy of comparison are hashconsed and use DB indices; not exactly what you find in ocamlopt
<d_bot>
<Drup> hence my suggestion to @ostera to sidestep the issue :3
jnavila_ has quit [Quit: Konversation terminated!]
<companion_cube>
as it happens, erlang ASTs are much more suited to comparison
<companion_cube>
they're almost purely structural afaik
<companion_cube>
made of tuples and atoms
tane has quit [Quit: Leaving]
<d_bot>
<ostera> writing the "location removal" function now
<d_bot>
<ostera> thanks for the hint @Drup 🙌
<d_bot>
<ostera> are there any traversal helpers in `parsing/*` ?
<d_bot>
<Drup> @ostera Funilly, when I upstreamed `Untypeast`, I wrote the same kind of thing to test it. I made a special ocaml driver that parse, type, untype and test for equality, and then I launched it on opam to find bugs.
<d_bot>
<Drup> yes, `Ast_mapper`, it's used for ppxs
<d_bot>
<ostera> so if I get this ast_mapper right
<d_bot>
<ostera> i build a mapper value from some default
<d_bot>
<ostera> override the bits that I care about
<d_bot>
<ostera> and the run it
<d_bot>
<Drup> yes
<companion_cube>
the default is deep identity
<d_bot>
<ostera> there we go: `Ast_mapper.default_mapper`
<d_bot>
<ostera> I should include modeuls like this in the erlang package too
<d_bot>
<ostera> would be very nice to write type-safe ppx's on the beam -- erlang parse transforms are gnarly and we avoid them like the plague
<d_bot>
<Drup> You can use the (very nice) library `visitors` to generate them
<d_bot>
<ostera> i mean, there's only a small part of the parsetree that is allowed
<d_bot>
<ostera> shouldn't be that much work..
<d_bot>
<ostera> wait, there's a location visitor!
<d_bot>
<ostera> `location = (fun _this l -> l)`
<d_bot>
<Drup> Well, of course 🙂
<d_bot>
<Drup> (precisely to write that code :D)
<d_bot>
<ostera> ah, but sadly the `map_loc` function is bound from within the module and can't be easily overriden in the visitor
<d_bot>
<ostera> so I have to pop open the entire thing now 😛
Jesin has quit [Quit: Leaving]
mxns has quit [Ping timeout: 260 seconds]
mxns has joined #ocaml
<d_bot>
<ostera> ```ocaml
<d_bot>
<ostera> $ caramelc verify a.erl a.ml
<d_bot>
<ostera> let f x = x
<d_bot>
<ostera>
<d_bot>
<ostera> module A = struct let rec f x = x end
<d_bot>
<ostera> [1]
<d_bot>
<ostera> ```
<d_bot>
<ostera> getting there
Jesin has joined #ocaml
Hrundi_V_Bakshi has quit [Quit: No Ping reply in 180 seconds.]
<Leonidas>
ostera: wow, a macro system worse than PPXes? That's quite the feat.
Hrundi_V_Bakshi has joined #ocaml
mxns has quit [Ping timeout: 256 seconds]
mxns has joined #ocaml
<d_bot>
<ostera> hey at least with ppxes you've got the type-system to help you
<d_bot>
<beheddard> I always hear people talking up the elixir macro system, so that's largely an elixir original then, not taking advantage of existing erlang constructs?
<d_bot>
<ostera> yup
<zozozo>
discovery of the day: recursive types cannot share field names (whereas if the types are not recursive, it works)
<d_bot>
<ostera> its very useful, but also not type-safe, so you can easily build very brittle things
amiloradovsky has quit [Ping timeout: 260 seconds]
<d_bot>
<ostera> can you think of anything that would be broken by making all functions `rec`? 🤔
larou has joined #ocaml
mxns has quit [Ping timeout: 240 seconds]
kvik has quit [Changing host]
kvik has joined #ocaml
larou has quit [Client Quit]
<companion_cube>
plz don't paste blobs of code here :p
<d_bot>
<ostera> oh right, you folks still get them line by line 🤦
<d_bot>
<ostera> we gotta fix that bot
larou has joined #ocaml
mxns has joined #ocaml
<mrvn>
ostera: let f x = x let f x = f x
Tuplanolla has quit [Quit: Leaving.]
<d_bot>
<JoanThibault> just wandering how does a code block looks on your end ?
<mrvn>
ostera: any reference to a previous binding of the same name breaks with rec
<d_bot>
<ostera> hm. I may need to enforce then that all module-level functions be declared with `rec` to begin with
<d_bot>
<ostera> since that's the semantics they'll have on the Erlang side
<d_bot>
<ostera> `let rec .. and ...` actually
<mrvn>
ostrea: relabel them to have unique names
mxns has quit [Ping timeout: 264 seconds]
<zozozo>
I'm trying to abuse gadts to optimize representation, with something along the lines of this : https://gist.github.com/Gbury/d18e9b00a9c1c1a9b4bc227a655e1546 , and of course what I'd like to do is not exactly allowed by the typechecker, although it'd tecnicall be correct in some sense (modulo some atomicity of assignments)
<companion_cube>
I swear, don't
<companion_cube>
don't use GADTs in ASTs
<companion_cube>
it's a lot of pain for little gain
<mrvn>
zozozo: That would put the t into an inconsistent state when you assign Bar
<zozozo>
companion_cube: it will be hidden and abstracted away by a view function which has a more reasonable definition, ^^
<mrvn>
zozozo: you need a { mutable x : 'payload head * 'payload } or so that you can set atomically
<zozozo>
@mrvn : yes, but if somehow the two assignments can be made at the same time, things would work out
<zozozo>
@mrvn : well, the goal of this gadt trickery is for the representation to be smaller, and particularly avoid some headers that are not really necessary/useful
<d_bot>
<ostera> @Drup okay, i got a rough `verify` command working -- tons of work left but it is a start, thankk again 🙌
<mrvn>
Is there a { t with head = Bar; payload = 1.0; } kind of syntax to change mutables?
<zozozo>
so using a tuple wouldn't work, :p
<d_bot>
<ostera> mrvn: i have some control over the names of things right now since the erlang I'm parsing is the erlang I've already generated
<Armael>
zozozo: would Obj.magic allow you to implement the function?
<mrvn>
Armael: Obj.magic allows everything
<zozozo>
Armael: yes, wrapping the two assignements in an Obj.magic should work
<zozozo>
@mrvn : well, here I suppose "work" in the sens of not break type safety after the assignments
<companion_cube>
oh well, good luck
<zozozo>
companion_cube: tecnically, the same thing I want could be achieved without gadts but by "inlining" the two definitions, using an adt with for each case, a record, with a lot of fields common to all the cases (well except for the mutability part, :p )
<mrvn>
zozozo: you could make a val set : t -> 'payload head -> 'payload -> t that's type save and uses Obj.magic internally.
<zozozo>
@mrvn : yeah, I know, but I was wondering if there was some less hacky way to do that, ^^
<mrvn>
zozozo: type t = Int of int | Float of float | App of t list ?
borne has quit [Ping timeout: 260 seconds]
<mrvn>
zozozo: or dropp the mutable and construct new t as needed
<companion_cube>
zozozo: you're so over optimizing :p
<zozozo>
companion_cube: maybe, :p
<companion_cube>
yes
<companion_cube>
not maybe
<companion_cube>
it's not going to be a proof AST, is it?
<zozozo>
no, but smtlib problems has that bad habit of being humongous sometimes
<zozozo>
I mean, some files have a singel term that takes around 500Mo of memory
<zozozo>
before typing
<companion_cube>
I know, but if you preserve the sharing you should be fine
<companion_cube>
(also: processing smtlib files should be done per-statement, not by parsing the whole file)
<companion_cube>
the whole syntax is designed so you can build a typed tree and assert it, in one pass, without having the whole content in memory ever
<zozozo>
yeah, maybe one point of the untyped ast is that input strings are not shared (i.e. when parsing f(x, x), the parser will generate two copies of the string "x")
<companion_cube>
(except for the solver terms)
<companion_cube>
yeah but now you're going to do scoping, right?
<zozozo>
companion_cube: I know, and I do, but there are really files that consist of a single BIG assert where a single term in a single statement takes up about 500Mo of memory
<companion_cube>
:D amazing
<companion_cube>
well fuck these files?
<zozozo>
well, these pass, juste take a lot of memory
<zozozo>
but that might be reasonable
<companion_cube>
(if you inline lets, it should also be smaller)
<zozozo>
anyway, I'll forget about the gadt optimization
<zozozo>
for now...
<companion_cube>
I mean, just rewrite the whole thing in rust at that point :p
<zozozo>
meh..., I like ocaml
<zozozo>
it's just that I spent too much time writing things for cmm and I have taken bad habits of trying to optimize the generated cmm, XD
<companion_cube>
yeah but I mean if you want to optimize the layout, OCaml is the wrong language :)
<zozozo>
I don't want a perfect layout, just, while staying in ocaml, try and not waste space.. ^^
<companion_cube>
you're trying to optimize the layout :p
<companion_cube>
(I mean, I get it, but I think it's a losing battle)
<zozozo>
let me dream a bit, :p
<mrvn>
zozozo: If you really want to optimize it then you should get it down to one field with the type as tag in the block header
mxns has joined #ocaml
mxns has quit [Ping timeout: 240 seconds]
Hrundi_V_Bakshi has quit [Ping timeout: 260 seconds]