<pyon>
Can OCaml's cycle detection algorithm for recursive type definitions be summarized as follows? (0) Make a graph where there's an edge from “foo” to “bar” when the definition of “foo” has “bar” in its right-hand side. (1) Find the graph's strongly connected components. (2) Make sure each strongly connected component has at least one sum type, record type or object type.
FreeBirdLjj has quit [Remote host closed the connection]
FreeBirdLjj has joined #ocaml
f- has quit [Ping timeout: 272 seconds]
f- has joined #ocaml
kushal has quit [Ping timeout: 240 seconds]
FreeBirdLjj has quit [Remote host closed the connection]
FreeBirdLjj has joined #ocaml
kushal has joined #ocaml
sdothum has quit [Quit: ZNC - 1.6.0 - http://znc.in]
Algebr` has quit [Read error: Connection reset by peer]
Algebr` has joined #ocaml
kushal has quit [Ping timeout: 264 seconds]
kushal has joined #ocaml
AlexDenisov has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
f- has quit [Ping timeout: 258 seconds]
justin_smith has joined #ocaml
f- has joined #ocaml
cat5e has quit [Ping timeout: 240 seconds]
FreeBirdLjj has quit [Remote host closed the connection]
FreeBirdLjj has joined #ocaml
f- has quit [Ping timeout: 250 seconds]
FreeBirdLjj has quit [Read error: Connection reset by peer]
FreeBirdLjj has joined #ocaml
f- has joined #ocaml
f- has quit [Client Quit]
f- has joined #ocaml
pyon has quit [Quit: brb]
pyon has joined #ocaml
AlexDenisov has joined #ocaml
huza has joined #ocaml
Soni has joined #ocaml
A1977494 has joined #ocaml
ggole has joined #ocaml
copy` has quit [Quit: Connection closed for inactivity]
jonasen has joined #ocaml
Simn has joined #ocaml
MercurialAlchemi has joined #ocaml
huza has quit [Quit: WeeChat 1.0.1]
AlexDenisov has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
MercurialAlchemi has quit [Ping timeout: 240 seconds]
FreeBirdLjj has quit [Remote host closed the connection]
FreeBirdLjj has joined #ocaml
butts_butts has joined #ocaml
AlexDenisov has joined #ocaml
AlexDeni_ has joined #ocaml
FreeBirdLjj has quit [Remote host closed the connection]
FreeBirdLjj has joined #ocaml
mcc has quit [Quit: Connection closed for inactivity]
AlexDenisov has quit [Read error: Connection reset by peer]
AlexDeni_ has quit [Ping timeout: 258 seconds]
AlexDenisov has joined #ocaml
butts_butts has quit [Ping timeout: 240 seconds]
MercurialAlchemi has joined #ocaml
AlexDenisov has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
AltGr has joined #ocaml
brab has joined #ocaml
AlexDenisov has joined #ocaml
MercurialAlchemi has quit [Ping timeout: 240 seconds]
nojb_ has joined #ocaml
tmtwd has quit [Ping timeout: 264 seconds]
Algebr` has quit [Ping timeout: 250 seconds]
Algebr` has joined #ocaml
MercurialAlchemi has joined #ocaml
Algebr` has quit [Ping timeout: 250 seconds]
silver has joined #ocaml
freusque has joined #ocaml
MercurialAlchemi has quit [Ping timeout: 260 seconds]
tane has joined #ocaml
<lyxia>
pyon: Doesn't this have just one strongly connected component type a = a b and 'a b = A of a
<pyon>
Yeah, right. I missed something.
<zozozo>
well generally, it's more that foo cannot appear in its type definition if it's not behind a sum constructor
<pyon>
What I need is an algorithm that (0) takes a single “type ... and ... and ...” definition, (1) reorders them conveniently, (2) splits the result in as many “type ... and ... and ...” definitions as possible. I'm guessing this will involve dynamic programming. :-|
<pyon>
splits the result into*
<companion_cube>
zozozo: or record
tmtwd has joined #ocaml
<zozozo>
right
<mrvn>
pyon: you can never split them all unless the user made a mistake. So why try?
dave24 has joined #ocaml
AlexDenisov has quit [Read error: Connection reset by peer]
AlexDeni_ has joined #ocaml
dwillems has joined #ocaml
tmtwd has quit [Ping timeout: 272 seconds]
dhil has joined #ocaml
larhat has joined #ocaml
larhat has quit [Remote host closed the connection]
pyon has quit [Quit: ... flowering silent scarlet piece of night.]
nicholasf has quit [Ping timeout: 244 seconds]
nicholasf has joined #ocaml
nicholasf has quit [Remote host closed the connection]
nicholasf has joined #ocaml
nicholasf has quit [Client Quit]
jwatzman|work has joined #ocaml
AlexDeni_ has quit [Read error: Connection reset by peer]
<companion_cube>
1/ a match is more readable than `foo |> function` :D
<companion_cube>
2/ you just want access to the underlying array (slice)?
<struk|desk>
ok, yeah, for readonly purposes though, to quickly wrap into lacaml vec basically
<companion_cube>
erf
<companion_cube>
but you would never copy the array, and would throw the buffer away?
<struk|desk>
not claiming to know lacaml that deeply, but it seems just to just wrap the array buffer directly, but lets ocaml gc manage the reference
<struk|desk>
and yes I would never copy in this case
<struk|desk>
instead I would dot product it
<struk|desk>
or some other type of fold
<struk|desk>
the dot product in particular is optmized a bit (generic folds would have less performance benefits)
<companion_cube>
I tought lacaml was using bigarrays
<struk|desk>
generally yes, but it doesn't do a copy when you call Vec.of_array either
<companion_cube>
huuuuu
<companion_cube>
I doubt it, to go from array to bigarray you *need* to copy
AlexDenisov has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<struk|desk>
let me double check code..
<companion_cube>
the representation of arrays and bigarrays is not the same
ais523 has joined #ocaml
<struk|desk>
dang, you're right. there's a copy in vec_SDCZ.ml of_array, for instance. however I *can* technically instantiate a bigarray version of a ringbuffer if I really wanted.
<struk|desk>
at this point, though, I will worry about the extra copy later
<companion_cube>
you should indeed
<companion_cube>
are you using the ring buffer for IO ?
<ais523>
I have a program that (simplified) works like this: f (a1 : [`x] list) = let a2 = g a1 in let a3 = (h : [`x] list -> [`y] list) a2 in let (a4 : [`y] list) = g a3 in a4
<struk|desk>
not really, more like time-sensitive algorithms
<ais523>
so far, g has had type ('a list -> 'a list) which was fine because it didn't care about 'a
<struk|desk>
so forgetting the k oldest things is part of the design algortihm
<struk|desk>
or remembering the k last, whatever
<ais523>
but now I need to change g so that its argument is a [< `x | `y] list; can I do that whilst asserting that its return value and argument have the same type?
<ais523>
(the actual example is more complex but follows this general pattern)
ygrek has joined #ocaml
<struk|desk>
companion_cube: btw, I was going to ask you if you have a good data structure that keeps track of at most the N "best" things given a comparator ?
<companion_cube>
I don't think so
<zozozo>
a set ?
<companion_cube>
you can use an in-array heap, I guess
<companion_cube>
hmmm, not even sure
<struk|desk>
zozozo: you can back it by a set, sure, but it needs more semantics than that to autoevict the worst element when you add new elements and the limit is reached
ais523 has quit [Read error: Connection reset by peer]
<zozozo>
struk|desk: well you use wrappers arounds the set so that whenever you add an element, you also remove the smallest element
<chelfi>
struk|desk: I think you may use a min heap. When trying to add you check the size, if it is full you compare against the min (and either pop the min and add the new element, or do nothing)
ais523 has joined #ocaml
<ais523>
sorry about that, client segfaulted
<ais523>
did I miss anything?
<struk|desk>
yeah, I was going to go with a strategy like that if there wasn't a bounded version out there already
FreeBirdLjj has quit [Remote host closed the connection]
FreeBirdLjj has joined #ocaml
ygrek has quit [Ping timeout: 246 seconds]
ais523 has quit []
ais523 has joined #ocaml
FreeBirdLjj has quit [Remote host closed the connection]
<mrvn>
ais523: ([< `x | `y] list as 'a) -> 'a
<ais523>
mrvn: thanks
FreeBirdLjj has joined #ocaml
<ais523>
let me try this
<mrvn>
ais523: the "as 'a" can be in many places given suitable ().
<ais523>
suppose I want to give a record field this polymorphic type
<mrvn>
'a . ([< `x | `y] list as 'a) -> 'a ?
<ais523>
I guess that's… 'a.([< `x | `y] list as 'a) -> 'a) ?
<mrvn>
or type 'a r = ...?
<ais523>
basically I want to pass this polymorphic type to a function, so I made a record to hold it
<ais523>
ah yes, this seems to work
<ais523>
let me see if my program compiles now :-)
ais523 has quit []
ais523 has joined #ocaml
<ais523>
mrvn: thanks
AlexDenisov has joined #ocaml
dwillems has quit [Ping timeout: 246 seconds]
kolko has quit [Ping timeout: 240 seconds]
kolko has joined #ocaml
ais523 has quit []
ais523 has joined #ocaml
AlexRussia has quit [Quit: WeeChat 1.5]
ais523 has quit []
ais523 has joined #ocaml
ais523 has quit [Client Quit]
ais523 has joined #ocaml
ais523 has quit [Read error: Connection reset by peer]
ais523 has joined #ocaml
sdothum has joined #ocaml
AlexRussia has joined #ocaml
ais523 has left #ocaml ["<fungot> fizzie: it makes demons fly out of my window, washing the windows api"]
dwillems has joined #ocaml
malc_ has joined #ocaml
AlexDenisov has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
AlexRussia has quit [Ping timeout: 276 seconds]
yomimono has joined #ocaml
FreeBirdLjj has quit [Remote host closed the connection]
AlexDenisov has joined #ocaml
FreeBirdLjj has joined #ocaml
AlexDenisov has quit [Client Quit]
AlexDenisov has joined #ocaml
AlexDenisov has quit [Client Quit]
FreeBirdLjj has quit [Remote host closed the connection]
FreeBirdLjj has joined #ocaml
Kakadu has joined #ocaml
aggelos_ has joined #ocaml
<justin_smith>
:b 1
<lostman>
hey folks. i've open an issue regarding building camlp4 with 32bit compiler on mac os but so far there haven't been any comments: https://github.com/ocaml/camlp4/issues/108. It has something to do with dynamic linking. anyone here would know about it? if this is something I could fix I'd look into this and make a PR but I don't know where to start
nivek has joined #ocaml
yomimono has quit [Ping timeout: 276 seconds]
<mrvn>
maybe fix the need for camlp4 and update to ppx
dexterph has joined #ocaml
FreeBirdLjj has quit [Remote host closed the connection]
FreeBirdLjj has joined #ocaml
<lostman>
camlp4 is needed by js_of_ocaml. since jsoo has ppx extension now I hope it won't be needed in the future
mcls has joined #ocaml
<Drup>
we still use camlp4 internally, to avoid breaking compat with old ocaml versions
yomimono has joined #ocaml
AltGr has left #ocaml [#ocaml]
octachron has joined #ocaml
AltGr has joined #ocaml
AlexRussia has joined #ocaml
alpen has quit [Ping timeout: 250 seconds]
alpen has joined #ocaml
tane has quit [Ping timeout: 276 seconds]
<Kakadu>
Folks, I have two modules defined in .cmxa file but when I make cmxs file I get only 1 module as a result
AlexDenisov has joined #ocaml
<Kakadu>
And I get messages like "Cannot load src/ppx_deriving_gt.cmxs: no implementation available for Parsetree_hack"
freehck has joined #ocaml
<Kakadu>
Ah, wait. It by default does .cmx -> .cmxs and I need .cmxa to -> cmxs
tane has joined #ocaml
<Kakadu>
Ok, I found solution
<Kakadu>
thanks :)
hongbo has joined #ocaml
M-ErkkiSeppl has joined #ocaml
<M-ErkkiSeppl>
hmm, so this thing works?
<flux>
apparently :)
<flux>
I guess that'll be my go-to web-irc-gateway if I need to suggest one, though creating account might be a hassle unless you've already created one (for matrix)
hcarty1 has joined #ocaml
<Kakadu>
Don't you think that vector.im has too much whitespace on the screen
<Kakadu>
I kind of don't like this UI
Denommus has joined #ocaml
<flux>
I don't mind it. but in principle you can fork your own and connect it to the same service, I think.
<flux>
but at least the session persists once I exit the service, plus it has a proper user account on the FreeNode instead of a single gateway bot.
NingaLeaf has quit [Quit: Leaving]
rgrinberg has joined #ocaml
FreeBirdLjj has quit [Remote host closed the connection]
FreeBirdLjj has joined #ocaml
FreeBirdLjj has quit [Ping timeout: 260 seconds]
Soni is now known as cat5e
tane has quit [Quit: Leaving]
agarwal1975 has joined #ocaml
tennix has quit [Ping timeout: 240 seconds]
nivek has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
pierpa has joined #ocaml
pyon has joined #ocaml
freehck has quit [Remote host closed the connection]
Denommus has quit [Remote host closed the connection]
groovy2shoes has quit [Remote host closed the connection]
groovy2shoes has joined #ocaml
al-damiri has joined #ocaml
freehck has joined #ocaml
MercurialAlchemi has joined #ocaml
kushal has quit [Ping timeout: 264 seconds]
sh0t has joined #ocaml
AlexRussia has quit [Ping timeout: 264 seconds]
<mrvn>
vishesh: you reload the segments later in init_pm, move that to the front
<mrvn>
ups, ewin
thizanne has quit [Ping timeout: 272 seconds]
cpdean has joined #ocaml
Kakadu has quit [Quit: Konversation terminated!]
A1977494 has quit [Quit: Leaving.]
<gasche>
lostman: I posted a comment on your 32bit darwin issue
<gasche>
blames your operating system that is happy to break its linker tools on each release
<gasche>
s/blames/blame/
<gasche>
(sometimes karma hurts back when you use OSX too much)
sh0t has quit [Remote host closed the connection]
copy` has joined #ocaml
shinnya has joined #ocaml
tennix has joined #ocaml
yegods has joined #ocaml
yegods has left #ocaml [#ocaml]
yegods has joined #ocaml
wiredsister has joined #ocaml
<lostman>
gasche: re your GH comment, how would I check host value? I remember seeing apple-darwin15.5.0 in some configure
profan has quit [Quit: leaving]
profan has joined #ocaml
AlexRussia has joined #ocaml
dexterph has quit [Ping timeout: 244 seconds]
jonasen has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
jonasen has joined #ocaml
rgrinberg has quit [Ping timeout: 244 seconds]
dwillems has quit [Ping timeout: 246 seconds]
mcls has quit [Ping timeout: 252 seconds]
yegods has quit [Read error: Connection reset by peer]
slash^ has joined #ocaml
jwatzman|work has quit [Quit: jwatzman|work]
dexterph has joined #ocaml
A1977494 has joined #ocaml
yegods has joined #ocaml
Algebr` has joined #ocaml
tane has joined #ocaml
nivek has joined #ocaml
jeffmo has joined #ocaml
AlexDenisov has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
tennix has quit [Ping timeout: 264 seconds]
yegods has quit [Read error: Connection reset by peer]
yegods has joined #ocaml
dexterph has quit [Ping timeout: 252 seconds]
chinglish has joined #ocaml
nojb_ has quit [Ping timeout: 276 seconds]
shinnya has quit [Ping timeout: 258 seconds]
Algebr` has quit [Ping timeout: 250 seconds]
yomimono has quit [Ping timeout: 272 seconds]
cpdean1 has joined #ocaml
cpdean1 has quit [Client Quit]
cpdean has quit [Ping timeout: 252 seconds]
AlexRussia has quit [Ping timeout: 240 seconds]
TheLemonMan has joined #ocaml
profan has quit [Quit: Lost terminal]
AlexDenisov has joined #ocaml
sh0t has joined #ocaml
yomimono has joined #ocaml
rgrinberg has joined #ocaml
ygrek has joined #ocaml
yegods has quit [Ping timeout: 240 seconds]
AltGr has left #ocaml [#ocaml]
yegods has joined #ocaml
butts_butts has joined #ocaml
nivek has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
seangrov` has quit [Ping timeout: 264 seconds]
Algebr` has joined #ocaml
yegods has quit [Ping timeout: 258 seconds]
yegods has joined #ocaml
yegods has quit [Read error: Connection reset by peer]
yegods has joined #ocaml
yomimono has quit [Ping timeout: 252 seconds]
dhil has quit [Ping timeout: 252 seconds]
tane has quit [Ping timeout: 240 seconds]
dave24 has quit [Quit: leaving]
<seliopou>
when people say "ADT's are expensive", I now believe them.
<seliopou>
:/
<Bluddy[m]>
seliopou: context?
<seliopou>
just shooting it into the ether
<companion_cube>
??
<jeffmo>
the ether is now confused
<seliopou>
related to angstrom
<companion_cube>
ah! well non-constant ADTs allocate
<companion_cube>
that's about it
<seliopou>
must not allocate...
<seliopou>
at all costs
<seliopou>
except if the cost is allocation
<zozozo>
in caml ? that's gonna be hard
<companion_cube>
you need to be very careful indeed
<zozozo>
some trivia I learned recently : reading a value from a float array allocates, :p
<Bluddy[m]>
zozozo: FLambda will be able to save us from that, hopefully
<Drup>
zozozo: only if it escape the local scope
<adrien>
bxing
<zozozo>
hurray for flambda !
<adrien>
but that one can be avoided
<Bluddy[m]>
adrien: if you read a float and only let-bind it, does current code elide the allocation?
<Bluddy[m]>
i think it should...
<companion_cube>
OCaml really really needs value types…
<companion_cube>
those hacks around flambda are ugly
<Bluddy[m]>
explain, c-cube. How do you keep the GC from going crazy?
<adrien>
Bluddy[m]: there are rules about it but I don't know them well enough to feel confident talking about them
tane has joined #ocaml
<Bluddy[m]>
companion_cube: I know you can mark value types in the stack with a bitmap. Would that be enough for value types?
<companion_cube>
I have no idea
<companion_cube>
I just say what we need :p
<Bluddy[m]>
hehe
<Bluddy[m]>
how does haskell do it?
<companion_cube>
well, you should decompose composite values into their components, and GC those independently, I think
<Drup>
Bluddy[m]: it often does, yes
<companion_cube>
of course floats are shit
<gasche>
seliopou: what kind of ADTs were you considering using?
<seliopou>
The regular ones :/
<_y>
companion_cube, what are value types?
<gasche>
seliopou: I wondered if you were looking for "newtype"-style with a single constructor
<seliopou>
Ah, well that would be amazing too
<seliopou>
unboxing would be tight. I'm using ADTs and a record type so i can get the right type quantification
<Algebr`>
don't bigarrays use single constructor stuff for some performance? Or was that something else.
<seliopou>
(existential?)
<Bluddy[m]>
AFAIK, haskell's scheme is: bitmap indicating non-GC types on the stack + number of non-GC types in data structures as an extra field. That suffices for the GC I believe. The only problem is, this isn't enough for generic comparison to work.
<seliopou>
getting rid of the record allocation would be great!
<gasche>
seliopou: but existential types may have to be boxed for type soundness reason
<gasche>
(currently)
<seliopou>
D:
<seliopou>
gasche lie to me so i can be happy
<seliopou>
:P
<gasche>
hm
<Bluddy[m]>
seliopou: why are you so unhappy? Performance isn't good enough?
<gasche>
so Damien Doligez has a PR with unboxed single-constructor datatypes
<seliopou>
nowhere close
<gasche>
but I'm not sure it extends to GADTs
<seliopou>
gasche yeah i saw that, was gonna try it out at some point
<Bluddy[m]>
seliopou: are you sure it's allocation's fault?
<seliopou>
Bluddy[m] yes
<seliopou>
gasche does it unbox the record if it has a type quantifier in it?
<hcarty1>
gasche: I thought single-constructor datatypes were already unboxed?
<hcarty1>
There were lots of mailing list posts about it a while ago
hcarty1 is now known as hcarty
<ggole>
<companion_cube> OCaml really really needs value types…
<ggole>
Floats are already "value types"
<companion_cube>
they are very badly handled
<companion_cube>
and I don't want floats :D
<ggole>
The problem there is how to compile polymorphism
<ggole>
You could have an unboxed float type with a different kind
<companion_cube>
well, F# has some interesting take on this: two styles of polymorphism
<Drup>
seliopou: inline record doesn't help ?
<companion_cube>
one of which is monomorphizing (like in C++ or rust)
<ggole>
Or you could monomorphise like MLton
<ggole>
(Or rust or C#, indeed.)
<seliopou>
Drup the record isn't used in conjuction with an adt
<Drup>
ah, I see
<Drup>
seliopou: to what are you comparing now ?
<ggole>
But that has issues of its own, like how to deal with polymorphic recursion or GADTs
<companion_cube>
I think monomorphization should actually be the default; polymrphic recursion or GADTs are quite niche
<seliopou>
though now that you mention it, i wonder if the type quantifer is actually supported in inline records...
<companion_cube>
ggole: well you couldn't mix those
<companion_cube>
but in practice I doubt it would be a problem
<companion_cube>
you woudl have monomorphizing arrays, say
<companion_cube>
^a array
<seliopou>
Drup a parallel implementation that doesn't use adts, but doesn't handle all the features (yet)
<companion_cube>
which would all have their own layout, etc.
<companion_cube>
also, it makes inlining more robust and more predictible
<ggole>
So return values would still be boxed?
<companion_cube>
if you know the ground type at compile time, I suppose you can put them on the stack
mcls has joined #ocaml
<Bluddy[m]>
companion_cube: putting on stack requires escape analysis or value types which will always be copied
<Drup>
seliopou: have you done the bench against menhir yet ? :p
<companion_cube>
yeah, I'd like value types, indeed
<seliopou>
not yet :D
<companion_cube>
but the current GC probably doesn't allow it in general
<Drup>
seliopou: and yes, type quantifier is supported inline
<seliopou>
too scared :|
<Bluddy[m]>
but that requires a way to tell the stack which parts shouldn't be followed like in haskell
<Bluddy[m]>
bitmap
<companion_cube>
yeah
<Drup>
seliopou: you should do that ...
<companion_cube>
same in arrays of value types, records, etc.
<Drup>
it's better to have an actual performance goal
<seliopou>
oh i have a performance goal
<Bluddy[m]>
yep. but generic comparison won't work. that's the problem
<companion_cube>
I think the header of blocks could be a pointer to some descriptor
<seliopou>
cohttp doing 30k reqs/sec with 10k connections
<companion_cube>
some shape descriptor*
<ggole>
Er, OCaml already has stack maps? It's heap objects that have that restriction
rgrinberg has quit [Ping timeout: 276 seconds]
<companion_cube>
Bluddy[m]: generic comparison is bad
<Bluddy[m]>
i agree
<Bluddy[m]>
i want to get rid of it
<Bluddy[m]>
but how?
<companion_cube>
with monomorphization à la F# you get overloading quite easily apparently
<companion_cube>
since types are resolved
<Drup>
I really wouldn't like using F# overloading
<ggole>
F# can rely on a JIT compiler to produce the necessary code.
<companion_cube>
Drup: I'd prefer it to polymoprhic comparison
<Drup>
it's messy and it doesn't really compose ..
<companion_cube>
which I don't actually use
<Bluddy[m]>
ggole: right. no need for a closed universe
<Bluddy[m]>
partially closed universe is enough for F#
<Bluddy[m]>
companion_cube: how about adding a single pointer to each allocation?
<Bluddy[m]>
leads to comparison functions
<zozozo>
implicits would surely help getting rid of polymorphic comparisons
<companion_cube>
Bluddy[m]: the descriptor coudl contain one
<Bluddy[m]>
zozozo: only partially. We'd still need to support the old method
<companion_cube>
s/descriptor/vtable/ if you want
<ggole>
I think the story is that designing for polymorphism and value types is probably reasonable, but retrofitting it is gonna suck
<companion_cube>
including a method for GC marking
<companion_cube>
ggole: yeah :/
<tormen>
Hi. Is there some syntactic sugar to shorten: List.map (fun x -> Int64.to_string (fst x)) some_lst ?
<companion_cube>
and the defautl really should be monomorphization
<ggole>
Object headers, object file formats, etc, all are affected
<Bluddy[m]>
ggole: yes and no. If you come out with better performance, you can convince people to switch
<companion_cube>
tormen: nothing I know of
<companion_cube>
Bluddy[m]: not if it breaks everything
<Bluddy[m]>
companion_cube: what do you mean by monomorphization? Are you referring to F#'s reified generics?
<ggole>
Bluddy[m]: that has its attractions, but also its costs.
<ggole>
For example, C code that people have written may break.
<Bluddy[m]>
companion_cube: I disagree. It's a breaking version. If it simplifies everything, you do it.
<Drup>
seliopou: and where are you now ? :p
<Bluddy[m]>
worst case, you declare it a new runtime, like js_of_ocaml. No guarantees.
<seliopou>
location-wise?
<seliopou>
Greece
<seliopou>
trying to get angstrom released before I leave
nivek has joined #ocaml
<seliopou>
which means final squeeze for perf
<Drup>
seliopou: I meant cohttp bandwith :p
<seliopou>
lol
<seliopou>
24k/sec
<seliopou>
the elusive 6k has been with me for a while
<Bluddy[m]>
companion_cube: can you think of syntax to specify comparison per type?
<Bluddy[m]>
how does F# do it?
<Drup>
seliopou: and what's the one with current cohttp ?
<seliopou>
or not been with me, depending on how you're counting
<Drup>
seliopou: don't you think that's a good enough improvement for a first release ? :3
<seliopou>
(i've been testing primarily with async)
<seliopou>
Drup: i prefer the coal mines :P
<tormen>
... an operator like let (|~) f g x = fun x -> g (f x) ... so that I could write List.map (fst|~Int64.to_string) some_lst ?
<ggole>
F# has some type constraint that allows for comparisons
<ggole>
It's a half-assed type class, a bit like SML
* tormen
somehow has the feeling to have seen this somewhere...
yegods has quit [Ping timeout: 244 seconds]
<companion_cube>
Bluddy[m]: heh, it would also affect the language
<companion_cube>
and if you remove generic equality, it will break
rgrinberg has joined #ocaml
nivek has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<companion_cube>
by monomorphization I mean that every instance of a polymprphic function is compiled (and optimized) separately
chinglish has quit [Quit: Nettalk6 - www.ntalk.de]
<Algebr`>
so templates
<seliopou>
Drup this is nowhere close to a fair comparison but here's the graph in the issue compared to what i have right now: http://i.imgur.com/Uk6Ufvr.png
<Bluddy[m]>
companion_cube: that's why if you have a whole story: simple addition of generic comparison (lanugage modification) + a large improvement to the runtime, I think it could work. Of course it's a lot of effort.
ygrek has quit [Ping timeout: 252 seconds]
<companion_cube>
you might as well fork OCaml into a new language
<companion_cube>
but good luck changing the typechecker
dwillems has joined #ocaml
<Bluddy[m]>
companion_cube: you can't do monomorphization without whole program optimization. This is why F# can do it -- JIT means they only monomorphize the stuff they've seen so far.
<companion_cube>
sure, but you can still do it at link-time
<companion_cube>
(well it's not trivial; but flambda is going this way anyway)
<Bluddy[m]>
yes, but it's a link-time optimization. whole world
<Bluddy[m]>
right
<ggole>
How do you monomorphise the argument of type t = Foo : 'a ty * ('a -> int) -> t at link time?
<companion_cube>
that's outside of the scope, of course
<Drup>
seliopou: better indeed
<Bluddy[m]>
companion_cube: I don't think the change is too hard from the typechecker's perspective. All known types will use the environment of known comparisons. All unknown types would use dynamic information.
<malc_>
tormen: List.map (fun x -> x |> fst |> Int64.to_string) [1L, ()];; is the closest i can think of
<companion_cube>
the change is super big, you need another kind for specializing type variables
<companion_cube>
^a -> ^b
<seliopou>
Drup yeah but not good enough. 99th percentile is still total garbage
<companion_cube>
specializing_map : (^a -> ^b) -> ^a list -> ^b list
<Bluddy[m]>
companion_cube: you're talking about monomorphization, I'm not. Monomorphization is hard, I agree.
<Drup>
Bluddy[m]: please never say "I don't think the change is too hard from the typechecker's perspective. " until you know how the typechecker works :/
<companion_cube>
Bluddy[m]: ah, you mean the bitfields for value types?
<companion_cube>
so purely a runtime thing? sure, but then you can't talk about value types at the language level
<Bluddy[m]>
yes. and getting rid of generic comparison
<Drup>
seliopou: you can do that on the version 0.2, just release the damn thing x)
<companion_cube>
so it remains a hackish optimization
<companion_cube>
+1 Drup, seliopou should release :p
<Bluddy[m]>
no it needs some language support to get rid of generic comparison
<seliopou>
Drup you make sense and i don't like it one bit!
<companion_cube>
Bluddy[m]: so... implicits? talk about changing the typechecker
<Bluddy[m]>
once you do that, you can switch to value types
<Bluddy[m]>
companion_cube: implicits won't save us -- we'll still need to support generic comparison
<companion_cube>
I wouldn't use generic comparison at all
<Bluddy[m]>
i'm saying using something like F#'s typeclass hacks for comparison
<companion_cube>
if I had implicits
<hcarty>
companion_cube: Ah, implicits... one day
<Bluddy[m]>
companion_cube (IRC): me neither, but the language would still need to support generic comparison in the runtime, which will limit optimization of the runtime
<gasche>
Bluddy[m]: thanks for the @infrastructure email
<companion_cube>
Bluddy[m]: why would it need generic comparison in the runtime?
<companion_cube>
if it was absent from the language?
<gasche>
(we need to link to the gmane archives for the mailing-list, and link to the logs for IRC, and link to an IRC web portal)
<ggole>
You can't really remove it from the language at this point...
hcarty has quit [Quit: WeeChat 1.5]
<ggole>
A new ML, eg, 1ML, could do that.
yegods has joined #ocaml
<ggole>
But OCaml has a few decades of written code that it is obliged to respect.
<Bluddy[m]>
companion_cube: how do you remove it from the language?
<companion_cube>
well, a breaking version of OCaml might actually be interesting
<ggole>
Badly breaking backwards compat tends to do awful things to languages
* ggole
points at Python 3
<Bluddy[m]>
companion_cube (IRC): I agree. So implicits first, then fix the runtime.
<gasche>
I think if/when implicits get upstreamed we can get more experience and see how it goes
<companion_cube>
ggole: in practice I don't expect anything really new in OCaml for at least 2 years
<Bluddy[m]>
ggole: sample size of 1 though.
<ggole>
Maybe you could tart Reason up a bit and call it a new language though
<companion_cube>
I wouldn't use it, the syntax is too ugly :p
<ggole>
If people don't expect existing code to work you could get away with breaking almost anything.
<companion_cube>
well, at this point, a really breaking OCaml could be a new language, with no expectation of being compatible with the old one;but no one will want to maintain a language, it's too much work
<rgrinberg>
companion_cube: once the reason toolchain is done it would be nice if someone would fork and remove all the coffee script lunancy
<rgrinberg>
call it "morereason"
<zozozo>
ggole: i though the goal of reason was to chaneg the syntax, and only the syntax ?
<companion_cube>
rgrinberg: I'd rather have the OCaml parser with a few more `end`
<zozozo>
*chenge
<ggole>
I dunno what the goal of reason was
<companion_cube>
and the parser would be cleaner, for it would have less ambiguities :D
<malc_>
zozozo: still wrong :)
<zozozo>
malc_: please expand
<malc_>
zozozo: chAnge
<zozozo>
:p
<ggole>
Seems to me that with a change of syntax you could sneak in a bit more if you were so inclined
<companion_cube>
the syntax is nice, let's keep it and remove the few warts :p
<companion_cube>
anyway, we're just speculating
<ggole>
Sure.
<companion_cube>
back to writing actual code
<gasche>
I think we've had a lot of nice progress in the OCaml community without forking yet
<gasche>
and we have room for more
<gasche>
also, it lets people focus on small pieces of the problem, reaching reasonable goals, instead of trying to fix everything at once
<gasche>
(when people don't realize that they don't have the same ideas on what needs to be fix)
<Bluddy[m]>
gasche: any ETA on when we could expect implicits? Just getting rid of generic comparison (at some level) would be huge
yegods has quit [Remote host closed the connection]
<companion_cube>
I'd say at least 2 years
<gasche>
GADTs, ppx, Merlin, flambda, implicits, multicore, that's a lot of large changes that people have been able to work on as they focus on one problem instead of all at once
<gasche>
Bluddy[m]: I'm not the right person to ask
<zozozo>
gasche: who's the right person to ask ?
<companion_cube>
def` obviously :D
<gasche>
well
<mrvn>
Is the work on starting multiple ocaml cores in a process progressing?
<gasche>
mrvn: yes
<mrvn>
anything usable yet?
<gasche>
not really, afaik
<mrvn>
I guess I will stick with my fork + copy-on-write hack then.
<gasche>
by the way, they recently announced that help implementing concurrent stuff using their Reagents library would be welcome
<gasche>
zozozo, Bluddy[m]: def` is currently working on implicits, but I'm not sure asking regularly about it is productive
<gasche>
(it could also be pressure-inducing and thus counterproductive)
<companion_cube>
^
<gasche>
I would encourage you to focus on whatever you can do to help, on implicits or something else
<gasche>
(for implicits I don't know exactly what could help them right now)
<gasche>
for example, getting the most of our "community communication channels" discussion still requires some work
<gasche>
such as updating the ocaml.org webpage
<companion_cube>
or setting up discourse?
<gasche>
it's a bit of work, any help is warmly appreciated
<gasche>
hm
yegods has joined #ocaml
<gasche>
Bluddy[m] made an explicit query on the gitter.im front
<Bluddy[m]>
gasche (IRC): has there been any thought given to merging algebraic effects before multicore is ready? Just having effects would help with doing concurrent programming without monads
<gasche>
I don't think there is a consensus on Discourse yet
<mrvn>
companion_cube: isn't that a webforum?
<companion_cube>
gitter is really a chat
<gasche>
indeed
<gasche>
so there is a bridge, so it's easy to say it's reasonable
<companion_cube>
discourse would be more suitable for long-term knowledge
<companion_cube>
yeah, why not
<gasche>
whereas Discourse may be more disruptive to current processes
<gasche>
which is why it requires more time to decide
<gasche>
but I'm tempted to give it a go, personally
<gasche>
(afk, see you)
<companion_cube>
++
Algebr` has quit [Remote host closed the connection]
butts_butts has quit [Read error: Connection reset by peer]
butts_butts has joined #ocaml
struk|desk has quit [Remote host closed the connection]
<Bluddy[m]>
I also support adding discourse. I think it'll do a better job of organizing long-term discussions.
<chenglou>
I do think new syntaxes will help ease the transition a bit. Look at JS land: coffeescript introduced new syntaxes that got rolled into the js standard
<chenglou>
and at one point the line really blurs between syntax and semantics
<chenglou>
like the coffescript class "syntax"
<chenglou>
right now either you're a core ocaml contributor or nothing
<chenglou>
it's hard to upgrade to a potentially breaking ocaml this way
<chenglou>
but if you can "shim" some of the features through small syntax transforms then this gets easier
<companion_cube>
chenglou: have you considered offering an almost vanilla syntax, with the biggest pitfalls removed?
<chenglou>
companion_cube: I myself made a lisp syntax =D
<companion_cube>
meh
<companion_cube>
I'm talking about something that would look like OCaml
<chenglou>
but no we didn't consider it yet (well, technically, we did, during our countless internal discussions)
<chenglou>
companion_cube: the syntax transform will ideally be integrated as a post commit hook
<chenglou>
so yes, theoretically, you can use your own syntax. That's ideal. But practically no we didn't develop such thing yet
octachron has quit [Quit: Page closed]
bruce_r has joined #ocaml
wiredsister has quit [Ping timeout: 258 seconds]
hcarty has joined #ocaml
dexterph has joined #ocaml
<hcarty>
Is there a .tar.gz download available anywhere for the 1.11 cryptokit release?
<bruce_r>
I just launched an AWS instance, and try to install opam on it with 'apt-get install opam', but for some reason it installs opam 1.1.1-1. When I run the same command from my other server is installs opam 1.2.2, And when I try to run opam init with 1.1.1 it tells me that I need a newer version. The box runs Ubuntu 14.04.4 LTS (Trusty Tahr). Has anybody had this issue?
uris77 has joined #ocaml
dhil has joined #ocaml
<chenglou>
companion_cube: sorry if you've mentioned this before, but what part of the vanilla ocaml syntax would you change?
<companion_cube>
I'd just remove `;;` and add `end` after if/match/try, I think
<justin_smith>
bruce_r: just dealt with it locally myself - I'm not sure what the best fix is, but what I did is uninstall the OS ocaml, built and install from git, get opam running, and use that to install everything else
<companion_cube>
the rest is not too bad
<hcarty>
companion_cube: I sometimes wonder if an 'end' after toplevel 'let's would help, particularly when starting out with the language
<ggole>
I'd change type and constructor application to match function application
<companion_cube>
I don't think so, you couldn't nest let easily
<justin_smith>
bruce_r: in retrospect it might have worked to leave the OS ocaml as is, install opam by hand, then bootstrap the rest from the opam
<companion_cube>
I tried SML and it's a nightmare
<companion_cube>
ggole: that is also a semantic change
<companion_cube>
you don't have currying with constructors, so the syntax should not reflect that
<ggole>
How so?
<justin_smith>
Bluddy[m]: thanks, I'll look at it next time
<hcarty>
companion_cube: You can't nest let now without adding "in"
<ggole>
Eh, you could just chuck an error (or better, add currying for constructors)
<justin_smith>
yeah, that looks much simpler than what I did (though my method did work)
<companion_cube>
the error would be weird
<companion_cube>
I'm really speaking about the minimal viable syntax change
<companion_cube>
(ah, keep `;;` in toplevel of course)
<companion_cube>
but otherwise, JUST the `end`
<bruce_r>
Thanks bluddy I'll try this right now
<Bluddy[m]>
companion_cube (IRC): +1
<companion_cube>
if there was a compiler flag for this syntax, I'd use it, same as I use safe-string
<companion_cube>
and ocp-indent could convert :]
<Bluddy[m]>
safe-end
<companion_cube>
heh
<companion_cube>
really, I'd use this :D
<companion_cube>
(oh wait, only problem is compatibility with old versions, meh)
<hcarty>
companion_cube: If you're willing to pay the matching "begin" price then you can have it all, right now
<hcarty>
For the low, low cost of "begin"
<companion_cube>
I often do
<Bluddy[m]>
Just put a new parser in the ocaml tree and only use it with the command line param.
<companion_cube>
but still
<hcarty>
That may be something which could be enforced with a ppx
<hcarty>
Kind of like ocamllint
<bruce_r>
Bluddy: it worked, thanks!
<Bluddy[m]>
begin is a pain. Why suffer an pay begin in some places where a constant amortized 'end' will solve all problems?
<Bluddy[m]>
bruce_r (IRC): glad to hear it
<Bluddy[m]>
s/an/and
<hcarty>
let f x = begin if x then begin 1 end else begin 0 end end --- clear as mud! :-)
<hcarty>
Admittedly much easier to read when broken up with sane newlines
<ggole>
It would be nice to be able to optionally terminate match with an end
<companion_cube>
but optionally isn't possible
<companion_cube>
it makes modules ambiguous, for instance
<Bluddy[m]>
ggole (IRC): it can't be optional, or you'll get into more problems
<ggole>
Yeah, figures
<ggole>
I was hoping for a nice way to do nested match
<Bluddy[m]>
every time you nest matches, you'll need begin/end, so why not just place 'end' at the end of every match?
<Bluddy[m]>
same with try/with
<ggole>
Because most matches are not nested.
<Bluddy[m]>
if/else/end
<Bluddy[m]>
yeah but it's a small cost
<Bluddy[m]>
one day you'll add a nesting and get annoyed
<Bluddy[m]>
with if, one day you'll add a semicolon and get wrong behavior
* ggole
has been there
pdewacht has left #ocaml [#ocaml]
jonasen has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<pierpa>
everyone has been there
<companion_cube>
yeah, more defensive programming
<bruce_r>
If you have to use 'begin end', it's that you probably should create smaller functions
<bruce_r>
And I don't think there's ever a good reason to write a one line conditional
yegods has quit [Ping timeout: 260 seconds]
slash^ has quit [Read error: Connection reset by peer]
yegods has joined #ocaml
<companion_cube>
I totally disagree :D
ygrek has joined #ocaml
<ggole>
Tiny conditional expressions seem fine (and common)
<ggole>
Side effecting stuff is another matter
<bruce_r>
It pretty much always is more readable nicely indented
<companion_cube>
you can write very imperative stuff in OCaml sometimes
<companion_cube>
and quite functional stuff some other times
<bruce_r>
but what's the link with one line conditionals?
AlexRussia has joined #ocaml
<Bluddy[m]>
bruce_r (IRC): these kinds of dismissive generalizations aren't very useful. Many people have experienced these issues with the language.
<Bluddy[m]>
functional languages often involve large functions, since you can create subfunctions in local scope for example. And deep pattern matching is a great idiom in functional programming, though it demands parentheses or begin...end
<bruce_r>
I think I agree with that yes
Mercuria1Alchemi has joined #ocaml
san_ has joined #ocaml
san_ has quit [Client Quit]
dhil has quit [Ping timeout: 246 seconds]
<justin_smith>
there's some good arguments for avoiding nesting of scope / information hiding if you are working with immutable stuff though - that is, prefering top level functions with more arguments over closed over functions using values in scope etc.
<justin_smith>
but that's slightly tangential
<companion_cube>
I have nested matches everywhere because I use opaque types with views
struk|desk has joined #ocaml
<justin_smith>
companion_cube: I hope to understand that statement some day soon (I'm relearning ocaml right now and was never an expert)
<companion_cube>
I have opaque types, and a function `t -> view` where `view` is a sum type
<companion_cube>
so I cannot match deeply (which is annoying, but well, OCaml doesn't provide real views)
Mercuria1Alchemi has quit [Ping timeout: 272 seconds]
<Bluddy[m]>
speaking of which, there was talk a while ago about view patterns. What happened to that?
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
AlexDenisov has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<gasche>
<chenglou> right now either you're a core ocaml contributor or nothing
<gasche>
<gasche>
I don't think that is true
<gasche>
and I would be interested in understanding your view on that
thizanne has joined #ocaml
<gasche>
many people do useful contributions to the OCaml compiler distribution and are on a spectrum between those
<gasche>
(and it's of course possible to evolve on this spectrum, in particular becoming what is perceived as a "core contributor")
yegods has quit [Read error: Connection reset by peer]
ggole has quit []
dwillems has quit [Ping timeout: 264 seconds]
yegods has joined #ocaml
octachron has joined #ocaml
agarwal1975_ has joined #ocaml
dwillems has joined #ocaml
agarwal1975 has quit [Ping timeout: 240 seconds]
agarwal1975_ is now known as agarwal1975
freusque has quit [Quit: WeeChat 1.4]
yegods has quit [Remote host closed the connection]
butts_butts has quit [Ping timeout: 240 seconds]
yegods has joined #ocaml
* mrvn
wonders if it's easier to port this 19348 lines c++ code to ocaml than to debug and fix the memory corruption and segfaults.
nivek has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<mrvn>
Has anyone worked on making a thread safe stdlib?
dwillems has quit [Ping timeout: 264 seconds]
<companion_cube>
erf
<companion_cube>
given the usefulness of threads in OCaml…
<flux>
mrvn, which parts were you thinking?
<mrvn>
threads exist and the data structures are not thread safe.
<mrvn>
flux: Buffer, Set, Hashtbl. Queue
<companion_cube>
people tend to favor Lwt
<companion_cube>
which is much simpler anyway
<mrvn>
well, with multicore that will blow up big time
<flux>
I would really advocate just using application locking for them. it makes more sense for an application anyway.
<mrvn>
application locking?
<Bluddy[m]>
mrvn: hopefully with multicore we'll finally be able to leverage the big advantages of persistent data structures
<flux>
Mutex.lock etc.
<mrvn>
flux: obviously you use that
<companion_cube>
mrvn: there is a proposal with reagent
<companion_cube>
which sounds much better than the usual locks
<flux>
so what do you mean? aren't those safe if you use mutexes?
<mrvn>
flux: I want thread save flavours of the standard module but also a way to add a Mutex to e.g. a record and have the data types used in the record use the common lock.
<flux>
reagents certainöy seem promising, even if the library isn't ready yet
<mrvn>
flux: and some syntax so you can't forget to lock/unlock.
<companion_cube>
meh
<companion_cube>
better write new structures around reagent if you're planning on using multicore
<companion_cube>
if you're planning on rewriting some concurrent C++, you might want to try rust
<companion_cube>
it should save you from the segfaults :p
<mrvn>
now I have to learn scala to understand what reagents is
<companion_cube>
hu
<companion_cube>
just read the slides
<companion_cube>
on the repo
dexterph has quit [Ping timeout: 276 seconds]
<mrvn>
so reagents are basically monats with thread savety garantees?
<companion_cube>
more or less? you just have primitives around CAS
<companion_cube>
it's more arrows than monads
<mrvn>
I don't like CAS. I always feel like it computes for nothing most of the time when there is contention.
<Bluddy[m]>
mrvn: CAS is very fast
<companion_cube>
you know that right now, threads in OCaml are useless if you want to gain preformance, anyway?
<mrvn>
Bluddy[m]: it's not the CAS that's the problem. It's the time and work between when you read the value and when you write the update (and see someone else change it so you repeat it all)
<companion_cube>
well it should be as short as possible
<companion_cube>
as any critical section, anyway
<companion_cube>
so I don't see the issue
<Bluddy[m]>
mrvn: that's usually a much better solution than sleeping, which uses os primitives. If the work is long-lived, mutex is better. Otherwise CAS rules.
<companion_cube>
it also seems to solve some deadlock issues
<mrvn>
CAS only works for small critical sections. But if reagents are composable and supposed to be composed they will grow and grow.
<Bluddy[m]>
mrvn: yeah I don't know much about reagents, though I've had the paper on my machine for a while
<mrvn>
Bluddy[m]: with many threads what you want is a wait queue. If the mutex is held and the holder isn't running then add yourself to a wait queue and go to sleep. When the holder frees the mutex the head of the queue gets it.
<mrvn>
If the holder is running (and the queue empty) you can loop a bit trying to get the mutex.
<companion_cube>
you can have a blocking queue with reagents
<Bluddy[m]>
mrvn: the problem is that sleep has a significant overhead. If you need quick response times, you want to stay awake. Also, how is the queue implemented? It needs locking as well.
<mrvn>
Bluddy[m]: the queue can use CAS as it should have a verry small critical section.
<mrvn>
Bluddy[m]: sleep is also verry cheap because when you yield the thread actually holding the mutex can run again.
<mrvn>
Bluddy[m]: ideally you yield to the holder of the mutex.
<mrvn>
Bluddy[m]: that needs user mode threads or kernel support though.
<mrvn>
I imagine with ocaml multicore it would be great to combine one kernel thread per core with lwt.
<companion_cube>
for now, you'd better use rust if you want C++-like multicore performance
<mrvn>
companion_cube: nah. I just have to support some threads for QT bindings.
<chenglou>
gasche: sorry I'll clarify: in order to test modifications to ocaml's semantics. Theoretically you can fork ocaml and try things out, but it's hard to imagine this approach getting adoption
<mrvn>
chenglou: I fork for every modification to ocaml I try. semantic or otherwise.
<chenglou>
whereas if your syntax is local (like Reason in the future), any random newcomer (that understands the parser & printer) could create a new piece of syntax and try it
<chenglou>
mrvn: but then I'd have to install your fork
<chenglou>
in the local syntax approach we're sharing the same core ocaml compiler
<chenglou>
all my dependencies will need to compile against _your_ fork too which is just not possible
<mrvn>
chenglou: and you get a million dialects of ocaml
<companion_cube>
that is a bit worrying indeed
<chenglou>
yes, but the one you care about are printed to your liking, always
<mrvn>
chenglou: how will my module with my syntax work with your moduel with your syntax?
<chenglou>
just like we have a million of different editor setups but that's not what you're looking at
<chenglou>
they're all the same AST
<mrvn>
chenglou: ahh, so you save the AST and the editor pretty prints that and can edit it directly?
<companion_cube>
well, assuming the parser is maintained, otherwise it's instant bitrot
<chenglou>
if you want to actually add new AST nodes then of course, you'd still have to fork the compiler and all. But that's not what most people do right
<chenglou>
mrvn: yeah we're checking in the AST
<chenglou>
and on top of that,
<mrvn>
chenglou: seems at least workable. You any custom formating though.
<chenglou>
if you have a purely AST-based editor, the newcomer only needs to write a printer, not a parser
<mrvn>
s/You/You loose/
<chenglou>
mrvn: what do you mean by custom fomatting
<mrvn>
chenglou: you would limit the choice of editor and IDE though.
<mrvn>
chenglou: like (foo + bar) \n + (x + y ) so the x aligns with foo
<chenglou>
more realistically, right now, instead of checking in the AST (no good tooling on e.g. github to visualize those in your preferred syntax yet), we check in an "official" syntax, that itself will be generated from a post-commit hook from your AST
<chenglou>
mrvn: that's part of your printer though?
<mrvn>
chenglou: no, just something done by hand for this one special case
Guest_84847 has joined #ocaml
<Guest_84847>
Allah is doing
<mrvn>
if you make a printer that covers all the little special cases you could just make your computer write code on its own.
<Guest_84847>
sun is not doing Allah is doing
yomimono has joined #ocaml
<Guest_84847>
moon is not doing Allah is doing
<Guest_84847>
stars are not doing Allah is doing
<Guest_84847>
planets are not doing Allah is doing
<companion_cube>
charming, but can you learn english?
<Guest_84847>
galaxies are not doing Allah is doing
<mrvn>
Guest_84847 is not doing Allah is doing
<Guest_84847>
oceans are not doing Allah is doing
<companion_cube>
syntactically I'd say Allah is a constructor
<Guest_84847>
mountains are not doing Allah is doing
<Guest_84847>
trees are not doing Allah is doing
<Guest_84847>
mom is not doing Allah is doing
<mrvn>
boring. just a bot running thoruhg a script. no reaction at all
nivek has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<Guest_84847>
dad is not doing Allah is doing
<companion_cube>
I think I'm seeing a pattern
<Guest_84847>
boss is not doing Allah is doing
<companion_cube>
mrvn: do you even +o ?
<Guest_84847>
job is not doing Allah is doing
<Guest_84847>
dollar is not doing Allah is doing
<mrvn>
companion_cube: sort --random-sort words | while read W; do echo $W is not doing Allah is doing; sleep 4; done
<Guest_84847>
degree is not doing Allah is doing
<chenglou>
mrvn: these situation-specific formatting are indeed a bit harder; I myself ran into these for e.g. empty lines between some statements. Our solutions is either using heuristics (https://github.com/facebook/reason/issues/41), or let you provide some formatting configuration file. But the idea is that whatever solution we find, these must not involve manual
<chenglou>
modifications
<chenglou>
manual modifications get lost
<mrvn>
chenglou: you can never get all
<mrvn>
companion_cube: +o? i have o?
<companion_cube>
chenglou: so the alternate syntax would not even touch disk?
<companion_cube>
mrvn: according to chanserv, I think so
<Guest_84847>
medicine is not doing Allah is doing
<chenglou>
mrvn: right now I personally don't, but I've found enough value in the auto formatting that I'm willing to drop the empty lines I want to preserve in some places
<Guest_84847>
customers are not doing Allah is doing
<companion_cube>
o/
<chenglou>
anyway, hope this is at least a bit more realistic. We're not asking people to check in 999 different syntaxes. That'd be horrible
Guest_84847 was kicked from #ocaml by mrvn [mrvn is not doing Allah is doing]
<companion_cube>
chenglou: it would be interested to have a lisp-like syntax (lambda/flambda/etc. are already)