Hrundi_V_Bakshi has quit [Ping timeout: 258 seconds]
Haudegen has quit [Ping timeout: 264 seconds]
mxns has joined #ocaml
tryte_ has quit [Quit: _]
tryte has joined #ocaml
inkbottle has joined #ocaml
zebrag has quit [Ping timeout: 260 seconds]
amiloradovsky has quit [Remote host closed the connection]
amiloradovsky has joined #ocaml
ski has joined #ocaml
mxns has quit [Ping timeout: 244 seconds]
mmohammadi9812 has quit [Ping timeout: 272 seconds]
ransom has quit [Quit: My MacBook has gone to sleep. ZZZzzzβ¦]
ransom has joined #ocaml
mxns has joined #ocaml
ransom has quit [Client Quit]
amiloradovsky has quit [Remote host closed the connection]
amiloradovsky has joined #ocaml
mmohammadi9812 has joined #ocaml
mxns has quit [Ping timeout: 272 seconds]
mxns has joined #ocaml
amiloradovsky has quit [Ping timeout: 268 seconds]
mxns has quit [Ping timeout: 260 seconds]
mxns has joined #ocaml
mxns has quit [Ping timeout: 244 seconds]
mxns has joined #ocaml
mfp has quit [Ping timeout: 246 seconds]
mxns has quit [Ping timeout: 260 seconds]
mxns has joined #ocaml
mxns has quit [Ping timeout: 240 seconds]
mxns has joined #ocaml
mxns has quit [Ping timeout: 244 seconds]
mjsor has quit [Quit: Konversation terminated!]
mxns has joined #ocaml
mxns has quit [Ping timeout: 240 seconds]
waleee-cl has quit [Quit: Connection closed for inactivity]
mbuf has joined #ocaml
narimiran has joined #ocaml
Serpent7776 has joined #ocaml
mxns has joined #ocaml
nicoo has quit [Remote host closed the connection]
mxns has quit [Ping timeout: 264 seconds]
nicoo has joined #ocaml
mbuf has quit [Ping timeout: 264 seconds]
mxns has joined #ocaml
mbuf has joined #ocaml
mxns has quit [Ping timeout: 268 seconds]
Haudegen has joined #ocaml
shawnw has joined #ocaml
<d_bot>
<wokalski> Has anyone built/attempted a version-aware schema migrator on top of atd?
steenuil has joined #ocaml
mbuf has quit [Ping timeout: 260 seconds]
mxns has joined #ocaml
<vsiles>
def: looks like `-S` for ocamlopt doesn't keep /tmp/camlstartupXXXX.{s,o}
borne has joined #ocaml
mxns has quit [Ping timeout: 246 seconds]
<def>
vsiles: indeed
<def>
my hack to work around that is to hook the as command :P
<def>
(dynamic scoping ftw: extend PATH, add a new as command that copies the input before exec'ing the system as)
<vsiles>
you nasty devil
<vsiles>
but yes, that's probably the right thing to do
<vsiles>
first I'm trying to understand how the error can happen: so I've got a linking error when I'm trying to build on the new FB platform (internal build with dune).
<vsiles>
I created a minimal ml file (hello world style) with no deps, and added all the libraries of a failing binary -> the linking error happens.
<vsiles>
I removed all the (dune) libraries one by one to only keep a subset that triggers the link error
<vsiles>
Now I'm trying to replace a library by its dependencies, to refine the setup, and the linking error no longer happens
<vsiles>
and the library itself is very simple ocaml code
<vsiles>
I'm puzzle
<vsiles>
+d
<vsiles>
I wish ld would be more expressive :)
<vsiles>
def: this camlstartupXXX.s file seems rather generic. Do you know if it is the same for every project ? Or maybe there's a way to get it from the sources ?
<def>
vsiles: it sounds like a name conflict (two different objects with the same name)
<def>
vsiles: the camlstartup is specialized based on the primitives and modules needed by the project
<vsiles>
strange that it doesn't trigger with the old platform, only when I pass `-B/-I/-L` with the path to libc (to avoid linking with the system library)
olle has joined #ocaml
<def>
maybe there are other files in that path that triggers the conflict.
<def>
(what is the linking error message?)
<vsiles>
File "caml_startup", line 1:
<vsiles>
Error: Error during linking
<vsiles>
(fuck ld)
<vsiles>
I'm trying to gather all the pieces to run the actual gcc command by hand
<vsiles>
hoping to get more info that way
<d_bot>
<ggole> That's one helpful error message
<def>
vsiles: add -verbose :D
<vsiles>
yes, I'm passing -Wl,--verbose to gcc, -verbose to ocaml and --display=verbose to dune :)
<vsiles>
thus hoping to run the gcc command by hand and maybe get more info
hnOsmium0001 has quit [Quit: Connection closed for inactivity]
andreas31 has quit [Remote host closed the connection]
andreas31 has joined #ocaml
<vsiles>
ok.. so that's strange again: because every .cmxa is referencing the same -I/-L/-B flags for our special platform, they get duplicated a lot on the command line (like _a_ _lot_). I removed the dups by hand
<vsiles>
and now gcc/ld is happy
<vsiles>
maybe something changed between the version of gcc in the size of the input...
<def>
Or the order in which the flags are passed.
<def>
(After deduping, they might be processed than before ...)
<vsiles>
true
<def>
differently*
<vsiles>
I'm using OCAMLPARAM to pass the right glibc -I/-L/-B to ocaml, thus every cmxa gets a copy of that
<vsiles>
maybe there's a more "central" way to do so (flags at the compilation of ocaml instead ?)
osa1 has quit [Ping timeout: 260 seconds]
<vsiles>
will investigate that
<def>
yes you can customize the toolchain when configuring ocaml
<vsiles>
in 4.07.1 it is hell :) But I saw some nice addition recently. Will try to push forward upgrading ocaml version first
<vsiles>
recenlty I updated only the version of JaneStreet library, and Flow got a severe perf issue: the new version of gcc did a worse job than the old one, and nobody regenerated the build artefact
<vsiles>
so, first, perf issue, then new ocaml !
osa1 has joined #ocaml
amiloradovsky has joined #ocaml
berberman has quit [Ping timeout: 260 seconds]
berberman has joined #ocaml
narimiran has quit [Ping timeout: 256 seconds]
bartholin has joined #ocaml
tryte has quit [Remote host closed the connection]
andreas31 has quit [Write error: Connection reset by peer]
reynir has quit [Write error: Connection reset by peer]
nicoo has quit [Read error: Connection reset by peer]
reynir has joined #ocaml
nicoo has joined #ocaml
tryte has joined #ocaml
andreas31 has joined #ocaml
mfp has joined #ocaml
jbrown has quit [Ping timeout: 240 seconds]
Haudegen has quit [Quit: Bin weg.]
jbrown has joined #ocaml
<vsiles>
ocamlopt is accepting `-cc` to get a different linker. Is there a nice way to tell opam "create a switch using -cc foo" ?
mmohammadi9812 has quit [Quit: Quit]
mmohammadi9812 has joined #ocaml
amiloradovsky has quit [Remote host closed the connection]
amiloradovsky has joined #ocaml
Haudegen has joined #ocaml
reynir has quit [Remote host closed the connection]
reynir has joined #ocaml
mxns has joined #ocaml
mxns has quit [Ping timeout: 260 seconds]
amiloradovsky has quit [Remote host closed the connection]
amiloradovsky has joined #ocaml
_whitelogger has joined #ocaml
mbuf has joined #ocaml
osa1_ has joined #ocaml
osa1_ has quit [Client Quit]
aaaaaa has joined #ocaml
amiloradovsky has quit [Remote host closed the connection]
FreeBirdLjj has joined #ocaml
amiloradovsky has joined #ocaml
osa1 has quit [Quit: osa1]
osa1 has joined #ocaml
FreeBirdLjj has quit [Ping timeout: 264 seconds]
osa1 has quit [Quit: osa1]
<d_bot>
<Drup> @BigOof Usecase for telltime solicited by a coworker: autofill doodles by excluding some patterns (weekend, lunch breaks, holidays). π
<d_bot>
<Drup> It would be neat to be able to be able to import calendars inline in the time expressions too
osa1 has joined #ocaml
narimiran has joined #ocaml
mbuf has quit [Ping timeout: 246 seconds]
osa1 has quit [Quit: osa1]
osa1 has joined #ocaml
osa1_ has joined #ocaml
narimiran has quit [Ping timeout: 264 seconds]
narimiran has joined #ocaml
<d_bot>
<darrenldl> @Drup as in doodle dot com?
<d_bot>
<Drup> yes
<d_bot>
<Drup> (and framadates, etc)
<d_bot>
<Drup> (should probably be in another project)
<d_bot>
<Drup> I propose doodlinator as name
mxns has joined #ocaml
<d_bot>
<darrenldl> still trying to figure out how to use their api and if they still provide one
<d_bot>
<Drup> Well, ideally, it should be possible to extend it to all meeting-based thingies (many companies/etc have their homebrew thing), so better if it grab the webpage and fill it
<d_bot>
<darrenldl> but ye, that is an interesting use case that i never thought of, thanks!
<d_bot>
<darrenldl> hm...if it needs to emulate browser interaction then it feels a bit fragile
<d_bot>
<Drup> well, it's probably just a POST
<d_bot>
<darrenldl> oh okay
<d_bot>
<darrenldl> curious how useful this would be in practice : D
<d_bot>
<darrenldl> well it would cut down a loooooot of boring work and data entry, so that's something
<d_bot>
<Drup> You could also make it a javascript bookmarklet!
aaaaaa has quit [Ping timeout: 244 seconds]
<d_bot>
<Drup> that would work really well, actually: no need to code browser interaction (just find the toggle in the DOM and fill them, which is easy), trivial to distribute, and reasonably easy to personalize (you just make a generator that ask for a time expression and generate the bookmarklet)
zebrag has joined #ocaml
inkbottle has quit [Ping timeout: 256 seconds]
<d_bot>
<darrenldl> doodlinator feels like another month long project : D
<d_bot>
<Drup> I'm tempted to try to write the web/dom part
tane has joined #ocaml
<d_bot>
<darrenldl> this actually feels pretty neat since its scalable - can have one time expr in file for public holidays, one for company events, one for people's hard constraints (day off), and just && them together
<d_bot>
<Drup> exactly
waleee-cl has joined #ocaml
nullcone has quit [Quit: Connection closed for inactivity]
Tuplanolla has joined #ocaml
shawnw has quit [Ping timeout: 264 seconds]
hnOsmium0001 has joined #ocaml
steenuil has quit [Read error: Connection reset by peer]
steenuil has joined #ocaml
olle has quit [Ping timeout: 256 seconds]
Haudegen has quit [Quit: Bin weg.]
mxns has quit [Ping timeout: 240 seconds]
mxns has joined #ocaml
webshinra_ has quit [Remote host closed the connection]
webshinra has joined #ocaml
nullcone has joined #ocaml
jnavila has joined #ocaml
bartholin has quit [Quit: Leaving]
<d_bot>
<Cyclomatic Complexity> not sure where i should ask, as it is more theoretic
<d_bot>
<Cyclomatic Complexity> but, in unification
<d_bot>
<Cyclomatic Complexity> when we have `f ~ forall a , a -> a`, and then `f` is used on an int and a string, don't we get `f ~ int -> int` and `f ~ string -> string`? thus by symmetransitivity, `int -> int ~ string -> string`?
<companion_cube>
every time you apply `f`, it's applied to a fresh `a`
<companion_cube>
one of which will unify with int, the other with string
<d_bot>
<Drup> Simpler answer: the typing judgement is not transitive in the presence of subtyping and/or typing instanciation (the same thing, really)
<d_bot>
<Drup> type *equivalence* is transitive, but the typing judgement isn't
<d_bot>
<Cyclomatic Complexity> > Simpler answer: the typing judgement is not transitive in the presence of subtyping and/or typing instanciation (the same thing, really)
<d_bot>
<Cyclomatic Complexity> do you mean the `~` is not transitive?
<d_bot>
<Cyclomatic Complexity> > every time you apply `f`, it's applied to a fresh `a`
<d_bot>
<Cyclomatic Complexity> So each new application is independent from `f`? As in, the type of `f` is fixed and I can not gain any more information on it?
<d_bot>
<Drup> your `~` is not a thing, since `f` is a name, I suppose it's the judgement: `Ξ : f β’ Ο`
Haudegen has joined #ocaml
<d_bot>
<Cyclomatic Complexity> How would you express transitivity of typing judgement?
<d_bot>
<Drup> you wouldn't, because it's false :p
<d_bot>
<Cyclomatic Complexity> i mean, how would you write it?
<d_bot>
<Cyclomatic Complexity> how would you write symmetry?
<d_bot>
<Drup> (I guess : if `Ξ : f β’ Ο` and `Ξ : f β’ Ο'` then ``Ξ : Ο β Ο'`)
<d_bot>
<Cyclomatic Complexity> `The unification algorithm takes a set of pairs of types that are supposed to be equal. A system of constraints looks like`
<d_bot>
<Cyclomatic Complexity> My `~` is this equality
<d_bot>
<Drup> 1. Unification is an algorithm, not a relation. You can use it as a relation, but then you need to be careful what you feed it
<companion_cube>
Drup: are you swapping \thesis and : ?
<d_bot>
<Drup> urgh, yes, sorry, typo
<d_bot>
<Drup> 2. in ML, quantification is not part of types, it's part of type schemes, and unification does not work on type schemes, it works on types
<companion_cube>
^ and you instantiate a scheme with fresh variables prior to unification
<d_bot>
<Drup> exactly
<d_bot>
<Drup> 3. In higher systems, you can have quantifications as part of types, but in these systems, you can definitively have different incompatible types for the same expression
<d_bot>
<Cyclomatic Complexity> oooooooooooooh
<d_bot>
<Cyclomatic Complexity> > 3. In higher systems such as system F, you can have quantifications as part of types, but in these systems, you can definitively have different incompatible types for the same expression
<d_bot>
<Cyclomatic Complexity> not sure how that's a problem though
<d_bot>
<Cyclomatic Complexity> > 1. Unification is an algorithm, not a relation. You can use it as a relation, but then you need to be careful what you feed it
<d_bot>
<Cyclomatic Complexity> > You can use it as a relation, but then you need to be careful what you feed it
<d_bot>
<Cyclomatic Complexity> Do you have more details on this?
<d_bot>
<Drup> not really, it just comes from the definition of unification (for a specific system)
<d_bot>
<Cyclomatic Complexity> ok
<d_bot>
<Cyclomatic Complexity> how do typers for system f look like?
<companion_cube>
tbh, ML polymorphism is not as simple as sometimes touted
<companion_cube>
precisely because of the type schemes
<companion_cube>
I root for explicit polymorphism! :p
<d_bot>
<Drup> @companion_cube you probably don't in practice though, it's not very nice to use π
<d_bot>
<Cyclomatic Complexity> Explicit annotations on polymorphic functions you mean?
<companion_cube>
Drup: I mean you can still have implicit arguments :D
<companion_cube>
like Coq does, I believe
<companion_cube>
it's just that internally you have application to types
<d_bot>
<Drup> right, that's the solution that works when you have dependent types
<companion_cube>
or when you want things to be simple internally, too
<d_bot>
<Drup> that's rather independent
<companion_cube>
I'm still salty about SMTLIB using ML like polymorphism
<d_bot>
<Drup> (we could have explicit applications in the internal language, Haskell does for instance)
<companion_cube>
yeah
<d_bot>
<Drup> (I would tend to agree with you that we should)
<d_bot>
<Drup> (but that's a distinct consideration than the surface language)
<companion_cube>
yes indeed.
<companion_cube>
(shit, am I agreeing with Drup now? :p)
<d_bot>
<Drup> @Cyclomatic Complexity I would suggest a textbook for system F, it's super classical :p
<d_bot>
<Cyclomatic Complexity> Yeah, I was mostly looking for something practical
<d_bot>
<Drup> practical for what ?
<d_bot>
<Drup> The TAPL's always good.
<d_bot>
<Cyclomatic Complexity> something that you can use
<d_bot>
<Cyclomatic Complexity> classical system f requires explicit annotations everywhere right?
<companion_cube>
the full system F, probably
<d_bot>
<Drup> I know I'm annoying but .... use for what ? π
<d_bot>
<Cyclomatic Complexity> not having to annotate lambdas in list maps?
<d_bot>
<Drup> a language to dev with, to do proof, or just trying to understand type theory ?
<companion_cube>
List.map in OCaml doesn't require annotations either!
<d_bot>
<Cyclomatic Complexity> to dev with
<d_bot>
<Drup> and what do you want more than in OCaml ?
<d_bot>
<Drup> (just asking what's the connection with your theoretic questions)
<d_bot>
<Cyclomatic Complexity> ~~row polymorphism, algebraic effects, forall not only in prenex positions, but I fail to see how it is relevant~~
<d_bot>
<Cyclomatic Complexity> oh, isee
<d_bot>
<Cyclomatic Complexity> nothing much here, possibly to see if it's possible to extend unification to richer things
<companion_cube>
forall not in prenex position definitely needs to go outside OCaml's algorithms
<companion_cube>
and you do want to check out TAPL for that
<d_bot>
<Cyclomatic Complexity> ye
<companion_cube>
(or at least see what papers do purescript and the likes use for, say, row polymorphism)
<d_bot>
<Drup> right, so the answer is a combination of "yes, but you loose other properties" and "if it was easy, we would probably have it already" :p
<d_bot>
<Drup> you might be interested by MLF by Didier Remy
<d_bot>
<Cyclomatic Complexity> > "if it was easy, we would probably have it already"
<d_bot>
<Cyclomatic Complexity> this sounds very wrong. ocaml dominates some other langs, which don't have what ocaml does, for a lot of legacy reasons that also apply to ocaml.
<d_bot>
<Cyclomatic Complexity> oh right, forgot about mlf
<d_bot>
<Cyclomatic Complexity> thx
<d_bot>
<Cyclomatic Complexity> > nothing much here, mostly to see if it's possible to extend unification to richer things
<d_bot>
<Cyclomatic Complexity>
<d_bot>
<Cyclomatic Complexity> > right, so the answer is a combination of "yes, but you loose other properties"
<d_bot>
<Cyclomatic Complexity>
<d_bot>
<Cyclomatic Complexity> do you have examples of systems with non-prenex foralls that use unification?
<d_bot>
<Drup> all dependent type languages, MLF, 1ML
<d_bot>
<Cyclomatic Complexity> didn't know they still used unification
<d_bot>
<Drup> (You can look up "Pattern unification" for a subset of high order stuff)
<companion_cube>
oh, are there uses of that in _type inference_ ?!
<d_bot>
<Cyclomatic Complexity> if you have everything fully annotated, you can just do a bottomup pass right
<d_bot>
<Drup> most "practical" dependent languages have a
<d_bot>
<Cyclomatic Complexity> you seem to equate inference and unification, that's because unification is always what's used for inference in practice?
<d_bot>
<Drup> companion_cube: sort of. It's a bit of a last resort, but Implicit search usually uses somethings like that. I think Haskell type classes + type families does too
<companion_cube>
interesting.
<companion_cube>
@Cyclomatic well, unification works very well for inference, so people try and stick with it, I suppose?
<companion_cube>
row polymorphism is still done with a form of unification, afaict
<d_bot>
<Drup> (I'm not really a specialist into that part of the litterature, but it kinda feels like the shotgun approach :D)
<companion_cube>
(it's just a form of unification which knows about labels and row variables)
<d_bot>
<Cyclomatic Complexity> hm
<d_bot>
<Cyclomatic Complexity> hmhmhmhmhmhhmh
<d_bot>
<Cyclomatic Complexity> ic, thanks
<d_bot>
<Drup> unification is just "a function that takes two types, and returns a substitution that makes them equal"
<companion_cube>
like, unifying `{x: a|Ο}` with `{x:int, y:float}`
<companion_cube>
means you unify `Ο` with `{y:float}`, for example
<companion_cube>
and a with int
<d_bot>
<Cyclomatic Complexity> here, i am talking about unification more as "doing a pass on all expressions, giving them a temporary unification var as a type, and unifying everything" or something
<companion_cube>
that's more "type inference" than "unification"
<d_bot>
<Drup> that's a particular implementation of substitutions.
<companion_cube>
unification is just the base operation
<mrvn>
If you think of records as being composed of all the fields one after the other then unifying int * float or { x: int, y:float } is basically the same.
<companion_cube>
used to constraint types that must match
<companion_cube>
mrvn: but row polymorphism is richer. firstly because order doesn't matter in it, only labels do
<d_bot>
<Cyclomatic Complexity> ic
<mrvn>
companion_cube: does it? I thought all labels have to be at the same offset
<d_bot>
<Cyclomatic Complexity> (btw, y'all are very regularly answering my questions, i don't take it for granted and i am very thankful to you)
<companion_cube>
in OCaml perhaps
<companion_cube>
but in, say, purescript, you compile to JS objects anyway
<d_bot>
<Drup> mrvn: No, just like objects in ocaml.
<companion_cube>
so order doesn't matter, what matters is that you can easily model objets
<mrvn>
Drup: objects are hashtables so having the same hash is sufficient
<d_bot>
<Drup> you are mixing typing and execution.
<mrvn>
yes
<mrvn>
usualy you don't type something you can't execute (efficiently)
<companion_cube>
row polymorphism wouldn't fit OCaml records
<companion_cube>
but it's useful in other situations
<d_bot>
<Cyclomatic Complexity> cc: can't you monomorphize all recordS?
<d_bot>
<EduardoRFS> I just wish that records could be extended to the right
<mrvn>
So what do you call it when you match identical prefixes of rows in records?
<companion_cube>
@Cyclomatic not necessarily
<d_bot>
<Cyclomatic Complexity> interested in whynot
<d_bot>
<EduardoRFS> also interested
<d_bot>
<Cyclomatic Complexity> i get the separate compilations concerns
<companion_cube>
you may want to have a function of type `{x:int | Ο} -> {x:float | Ο}`
<companion_cube>
for exampe
<d_bot>
<Drup> mrvn: you don't really call it, because nobody does that π
<mrvn>
Drup: C does
<companion_cube>
you can specialize that away but that's a whole program transformation
<d_bot>
<Cyclomatic Complexity> ok
<d_bot>
<Cyclomatic Complexity> yeah, that's what i had in mind
<d_bot>
<Drup> no it doesn't, the typing is not aware of it
<d_bot>
<Cyclomatic Complexity> thx
<d_bot>
<EduardoRFS> @Cyclomatic Complexity with flambda we already share a lot of data between compilation units for inlining, I don't think it would be that hard
<d_bot>
<Drup> (or to say it differently: it's not a type system feature)
<d_bot>
<Cyclomatic Complexity> @EduardoRFS I tend to agree
<companion_cube>
mrvn: you could have row polymorphism for tuples
<companion_cube>
in OCaml
<companion_cube>
that'd be neat actually
<d_bot>
<EduardoRFS> you could have row polymorphism only to the right also
<companion_cube>
so that `fst: 'a * Ο -> 'a`
borne has quit [Ping timeout: 268 seconds]
<companion_cube>
`snd : _ * 'b * Ο -> 'b`
<companion_cube>
etc.
<mrvn>
Drup: a struct can be cast to a smaller struct if it's a prefix of the other. A union of structs has the common prefix well defined for access through any member too.
<d_bot>
<Cyclomatic Complexity> @EduardoRFS is "only to the right" that big of a deal in practice?
<companion_cube>
it just depends on what the user expects
<companion_cube>
records have field names, so saying that `{x:int, y:float}` and `{y:float, x:int}` are incomparable might be surprising
<d_bot>
<EduardoRFS> not for me, I did even implement this partially to try and it seems to work, but then you're going to need open and closed records
<mrvn>
companion_cube: it would be nice if you could have a tuple int * float * ..
<d_bot>
<Cyclomatic Complexity> > records have field names, so saying that `{x:int, y:float}` and `{y:float, x:int}` are incomparable might be surprising
<d_bot>
<Cyclomatic Complexity> they are not though
<d_bot>
<EduardoRFS> @companion_cube that is why I was thinking on extending, vs creating a new type with an additional parameter
<d_bot>
<EduardoRFS>
<d_bot>
<EduardoRFS> ```
<companion_cube>
mrvn: yeah it would
<d_bot>
<EduardoRFS> type x = {x: int}
<d_bot>
<EduardoRFS> type xy = {...x, y: int}
<d_bot>
<EduardoRFS> ```
<d_bot>
<EduardoRFS> `...x` needs to be always on the left and only one
<mrvn>
EduardoRFS type xy = [ x with y: int}
<companion_cube>
:D
<d_bot>
<EduardoRFS> @mvrn great
<d_bot>
<EduardoRFS> but then functions that nowadays accept `x` will now accept `x+` or something like that?
<d_bot>
<EduardoRFS> not sure on the syntax for open records
<d_bot>
<Drup> @EduardoRFS so, question, if I have `a` of type `xy`, I create `b = (a :> xy)` and don't have any reference to `b`, should I garbage collect `y` ? π
<mrvn>
If you don#t need type x itself but only extensions xy, xz, ... then you can use type 'a x = {x: int, more: 'a}
<companion_cube>
Drup: of course not :p
<companion_cube>
it should still be one block
<d_bot>
<EduardoRFS> yeah /\
<d_bot>
<Drup> (if you answer "No", you get memory leak, if you answer "Yes", you have to do a major change in GC)
<d_bot>
<EduardoRFS> it's not a memory leak, it's a block
<companion_cube>
you have a memory leak in the same sense that creating a closure makes a memory leak
<mrvn>
Drup: why? a should be a block with 2 fields.
<d_bot>
<EduardoRFS> same if you create a block and cast it using Obj.magic
<d_bot>
<Drup> if `y` is big, it's a memory leak.
<d_bot>
<EduardoRFS> isn't a feature of the type system
<d_bot>
<EduardoRFS> sure because you still have a reference and it cannot be collected, it's a feature of the lambda
<d_bot>
<Drup> (assume here `y` is a pointer to something, not an int)
mmohammadi9812 has quit [Ping timeout: 256 seconds]
<companion_cube>
Drup: `b = {(a :> xy) with x=a.a}`
<companion_cube>
tada, copy!
<companion_cube>
(ahahah so terrible)
<mrvn>
Drup: maybe better describe it that b has pointer to y that isn't accessible.
<companion_cube>
x=a.x sorry
<d_bot>
<Drup> I'm just saying ,it's a shit UX, you get non-GCed unnaccessible data
<d_bot>
<EduardoRFS> @Drup okay got your point, how does it work nowadays with objects, when you do this kind of casting?
<d_bot>
<EduardoRFS> is the reference lost?
<d_bot>
<Drup> it's not because the object iself can still use it
<companion_cube>
Drup: just like anything else in OCaml? like closures? or even the roots of 'react', woo
<mrvn>
Drup: the record itself can still use it too
<mrvn>
Drup: e.g. the record can have a getter and setter
<d_bot>
<EduardoRFS> there is no "self" on records
<d_bot>
<Drup> then there is still a pointer to `a`
<d_bot>
<Drup> (which the getter/setter use)
<mrvn>
Drup: hmm, you are right. there is no self for a record to use there
<d_bot>
<EduardoRFS> I don't think of `:>` as cast the structure only the type but yeah that is a valid concern, I would prefer to keep the "memory leak" while the record is live
<d_bot>
<Drup> anyway, you can think about it very hard, and when you get a convincing answer/solution, you can propose the change π
<d_bot>
<EduardoRFS> because the memory model is so much simpler to reason about
<d_bot>
<EduardoRFS> and especially if you enter in Obj.magic area
<d_bot>
<Drup> Obj.magic is irrelevant, we are talking about language features
<mrvn>
Drup: I still want this feature because I want to pass the xy around as type x. If I coerce it into a smaller type I accept the memory leak.
<d_bot>
<EduardoRFS> sure but if the user does `a :> b` with `Obj.magic` he can do `b -> a` later and get the access back which seems desirable
<d_bot>
<EduardoRFS> but we don't have a precedent in OCaml for that which is a pain
mmohammadi9812 has joined #ocaml
<companion_cube>
Drup: I think the point is, this is useful, even though like most other OCaml features it can lead to leaks
<companion_cube>
I mean, do we ban bigarrays because you can retain only a slice of it?
<mrvn>
FYI: I wouldn't call it a leak because the memory isn't lost. The object just consumes more memory that it could.
<d_bot>
<EduardoRFS> same feeling for me
<mrvn>
And if you don't want that extra memory wasted then copy the record explicitly instead of coercing the type.
<d_bot>
<Drup> Well, then, you know what to do, it's not even that hard to implement π
<mrvn>
Drup: think of a function ('a :> x) -> 'a: f x = x. If you give it an xy you get an xy back.
<companion_cube>
`'a -> 'a constraint 'a :> x` ? :D
<mrvn>
inc_x x = {x with x.x = x.x + 1 }
<companion_cube>
(not even sure if `constraint` works for that)
<mrvn>
companion_cube: not for records.
<companion_cube>
mrvn: that's more like row polymorphism though
<companion_cube>
you would not want to use :>
<companion_cube>
but a row variable
<mrvn>
companion_cube: whatever you call it. It's the feature lacking in ocaml, needs Obj.magic currently.
<companion_cube>
especially because, afaik, `{a with x=a.x+1}` needs the actual type to generate the code
<d_bot>
<Drup> yeah, that's not an OCaml type (and it would be really hard to add and break lot's of things)
<companion_cube>
record update needs to know the fields
<mrvn>
companion_cube: it needs to create a new block as large as the old, copy the memory and then modify the fields.
<companion_cube>
that seems to fit the row polymorphism story better though :D
<d_bot>
<EduardoRFS> @companion_cube sure but if you're updating it just copy the block and update the known field
<mrvn>
for the runtime the only change would be that it uses the size of the old block rather then the size of the type it infered.
<companion_cube>
heh
<d_bot>
<EduardoRFS> but I feel like it's reasonable to copy from `xz` to `x` if it was casted
<companion_cube>
ok, I guess it works
<companion_cube>
(incidentally, I'm really annoyed that we have to write hacks like `{a with x=a.x}` to do a copy)
<companion_cube>
(that's really hackish)
<d_bot>
<Drup> if you copy, mrvn is going to yell at the top of his lung that it's innefficient, unlike C/Obj.magic π
<mrvn>
Drup: huh? The copy was the whole point.
<mrvn>
Drup: currently oyu have to Obj.magic AND copy.
<companion_cube>
`{mutable x:int | Ο}`
<mrvn>
companion_cube: that's a different type though
<companion_cube>
yeah I was kidding
<mrvn>
Syntax wise I would be against :> too, { x:int; .. } would describe the feature nicely.
<d_bot>
<Drup> you will not get implicit subtyping
<d_bot>
<Drup> sorry π
<mrvn>
Nice and visual that it is a record that starts with "x:int" and can have some more data.
<companion_cube>
no one is asking for implicit subtyping, I think
<mrvn>
{x:int, ..} and {x;int, y:float} should unify.
<d_bot>
<Drup> companion_cube: mrvn just did π
<companion_cube>
unification, not subtyping
<companion_cube>
well.
<mrvn>
What I mean is that you should be able to call a function expecting {x:int, ..} with {x:int, y:float}.
<companion_cube>
do you consider poly variants to be implicit subtyping, Drup ?
<d_bot>
<Drup> Depends. In the cases where unificaiton works, it's row polymorphism.
<companion_cube>
right, so that's what the `..` above is
<companion_cube>
or would be, rather*
<mrvn>
and I think row polymorphism would be sufficient to have. If you want more why not use objects?
<d_bot>
<Drup> yes, and as I said, highly doubtful you can make it work π
<companion_cube>
I imagine it'd be hard to implement in the concrete current typechecker
<d_bot>
<Drup> what you can make work is subtyping (like private types, or poly variants without `<` or `>` for instance)
<companion_cube>
but on paper, it doesn't seem particularly hard to least
<companion_cube>
at*
<companion_cube>
I mean, purescript does it
<companion_cube>
(although it's label oriented, not prefix, but anyway)
<mrvn>
Drup: do you think tuples ( int * float * .. ) would be simpler? For me that looks like the same problem.
<d_bot>
<Drup> companion_cube: records are nominal, not structural like objects/rows/poly vars/etc. I suggest you try to make it with principal type inference :p
<companion_cube>
ah, yes, sure
berberman_ has joined #ocaml
<companion_cube>
even just tuples would be nice, fst/snd are ugly
<mrvn>
companion_cube: one problem would be type inference. If you say { a with a.x = 1} that could be many different types.
berberman has quit [Ping timeout: 268 seconds]
<mrvn>
Do you infere it to the last record defining a label x? or the smallers? Or the smallest that is a prefix of the last?
<mrvn>
Probably needs to be the last record defining a label x for backward compatibility and require annotation for the polymorphism.
mmohammadi9812 has quit [Ping timeout: 246 seconds]
mmohammadi9812 has joined #ocaml
<d_bot>
<Drup> or you could just bear having explicit casts
<d_bot>
<Drup> (also, tbh, I highly doubt any other solution than explicit casts would be accepted in the compiler)
mmohammadi9812 has quit [Quit: Quit]
<d_bot>
<EduardoRFS> mrvn: that is why I was talking about open records
mmohammadi9812 has joined #ocaml
nullcone has quit [Quit: Connection closed for inactivity]
oriba has joined #ocaml
nullcone has joined #ocaml
steenuil has quit [Read error: Connection reset by peer]
<d_bot>
<joris> @wokalski not aware of any versionning migration tool for atd. I guess we are supposed to maintain atd now and we only use it for network packet and work around it by global update
<d_bot>
<joris> This is BTW why we use extprot for anything that is stored and requires backward compat not atd
sonologico has quit [Remote host closed the connection]
jnavila has quit [Quit: Konversation terminated!]
nullcone has quit [Quit: Connection closed for inactivity]
mxns has joined #ocaml
sagax has joined #ocaml
<d_bot>
<wokalski> @joris ah. Thatβs too bad. How do you deal with breaking changes when you use extprot? Or do you just not have breaking changes?
<d_bot>
<wokalski> Iβm in an early stage with the product and so I do a very dumb thing, I dump my whole state as a json and save it. Itβs really dumb and itβll have to change but for now I need some sort of migrations
tane has quit [Quit: Leaving]
Serpent7776 has quit [Quit: leaving]
_whitelogger has joined #ocaml
amiloradovsky has quit [Remote host closed the connection]