<nullcatxxx_>
starting from 3399. this has to be hardcoded.
<nullcatxxx_>
and the last number , 63348, is also hardcoded....
swgillespie has joined #ocaml
so has quit [Remote host closed the connection]
igoroliveira has quit [Quit: Connection closed for inactivity]
nullcatxxx_ has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
cthuluh has quit [Ping timeout: 255 seconds]
cthuluh has joined #ocaml
jao has quit [Ping timeout: 272 seconds]
rgrinberg1 has quit [Ping timeout: 244 seconds]
ontologiae has quit [Ping timeout: 272 seconds]
rgrinberg1 has joined #ocaml
keen__ has quit [Read error: Connection reset by peer]
keen__ has joined #ocaml
tennix has joined #ocaml
obadz has quit [Ping timeout: 240 seconds]
obadz has joined #ocaml
ollehar has quit [Remote host closed the connection]
siddharthv_away has quit [Read error: Connection reset by peer]
ollehar has joined #ocaml
NingaLeaf has joined #ocaml
antkong_ has quit [Quit: antkong_]
patronus_ has quit [Read error: Connection reset by peer]
patronus has joined #ocaml
gperetin has quit [Ping timeout: 268 seconds]
echo-area has joined #ocaml
swgillespie has quit [Ping timeout: 260 seconds]
gperetin has joined #ocaml
swgillespie has joined #ocaml
echo-area has quit [Remote host closed the connection]
antkong has joined #ocaml
echo-area has joined #ocaml
deavid has quit [Ping timeout: 244 seconds]
ollehar has quit [Remote host closed the connection]
NingaLeaf has quit [Quit: Leaving.]
siddharthv_away has joined #ocaml
siddharthv_away has quit [Read error: Connection reset by peer]
darkf has joined #ocaml
ryanartecona has joined #ocaml
mac10688 has quit [Ping timeout: 272 seconds]
mea-culpa has joined #ocaml
kushal has joined #ocaml
siddharthv_away has joined #ocaml
siddharthv_away has quit [Read error: Connection reset by peer]
deavid has joined #ocaml
demonimin has quit [Ping timeout: 240 seconds]
MercurialAlchemi has joined #ocaml
xet7_ has quit [Ping timeout: 260 seconds]
MercurialAlchemi has quit [Ping timeout: 255 seconds]
AltGr has left #ocaml [#ocaml]
AltGr has joined #ocaml
toolslive has joined #ocaml
toolslive has quit [Ping timeout: 252 seconds]
ryanartecona has quit [Quit: ryanartecona]
toolslive has joined #ocaml
ggole has joined #ocaml
ontologiae has joined #ocaml
shinnya has quit [Ping timeout: 246 seconds]
ontologiae has quit [Ping timeout: 268 seconds]
kushal has quit [Ping timeout: 240 seconds]
oscar_toro has joined #ocaml
AlexRussia has quit [Quit: WeeChat 1.3-dev]
mort___ has joined #ocaml
ibor has joined #ocaml
psy_ has quit [Ping timeout: 252 seconds]
rgrinberg1 has quit [Ping timeout: 272 seconds]
ggole has quit [Read error: Connection reset by peer]
ggole has joined #ocaml
kushal has joined #ocaml
ggole has quit [Ping timeout: 246 seconds]
oscar_toro has quit [Ping timeout: 240 seconds]
ygrek has joined #ocaml
ontologiae has joined #ocaml
mort___ has quit [Quit: Leaving.]
BitPuffin|osx has quit [Ping timeout: 250 seconds]
Haudegen has quit [Ping timeout: 240 seconds]
Haudegen has joined #ocaml
rossberg has quit [Ping timeout: 246 seconds]
oscar_toro has joined #ocaml
rgrinberg1 has joined #ocaml
psy_ has joined #ocaml
psy_ has quit [Max SendQ exceeded]
psy_ has joined #ocaml
ely-se has joined #ocaml
rgrinberg1 has quit [Ping timeout: 272 seconds]
rossberg has joined #ocaml
mort___ has joined #ocaml
mort___ has quit [Quit: Leaving.]
jonludlam has quit [Ping timeout: 260 seconds]
keen___ has joined #ocaml
keen__ has quit [Ping timeout: 240 seconds]
ibor has quit [Ping timeout: 244 seconds]
seako has quit [K-Lined]
Sorella has quit [K-Lined]
msch has quit [K-Lined]
yminsky has quit [K-Lined]
emmanueloga has quit [K-Lined]
lambdahands has quit [K-Lined]
lopex has quit [K-Lined]
jeroud has quit [K-Lined]
andreypopp has quit [K-Lined]
oldmanistan_ has quit [K-Lined]
pootler has quit [K-Lined]
sz0 has quit [K-Lined]
lwlvlpl has quit [K-Lined]
ggherdov has quit [K-Lined]
IbnFirnas has quit [K-Lined]
cojy has quit [K-Lined]
sspi has quit [K-Lined]
S11001001 has quit [K-Lined]
metadave has quit [K-Lined]
mariusae has quit [K-Lined]
steshaw has quit [K-Lined]
mankyKitty has quit [K-Lined]
l1x has quit [K-Lined]
bobpoekert has quit [K-Lined]
rfv has quit [K-Lined]
n1ftyn8_ has quit [K-Lined]
NhanH has quit [K-Lined]
sh0t has joined #ocaml
mankyKitty has joined #ocaml
lwlvlpl has joined #ocaml
bobpoekert has joined #ocaml
mort___ has joined #ocaml
Sorella has joined #ocaml
zpe has joined #ocaml
dhil has joined #ocaml
andreypopp has joined #ocaml
rgrinberg1 has joined #ocaml
antkong has quit [Quit: antkong]
demonimin has joined #ocaml
rgrinberg1 has quit [Ping timeout: 244 seconds]
sh0t has quit [Ping timeout: 250 seconds]
mort___ has quit [Quit: Leaving.]
foocraft has joined #ocaml
ggole has joined #ocaml
ely-se has quit [Quit: leaving]
ely-se has joined #ocaml
ollehar has joined #ocaml
mal`` has quit [Ping timeout: 250 seconds]
AltGr has left #ocaml [#ocaml]
mal`` has joined #ocaml
zpe has quit [Read error: Connection reset by peer]
zpe_ has joined #ocaml
mort___ has joined #ocaml
Lastpixl has joined #ocaml
rand__ has joined #ocaml
<Lastpixl>
hi! I'm wondering why ocaml header files are installed to /usr/lib/caml and not /usr/include? I'm compiling ocaml from the source. I'm writing a program in C that uses these headers, and it would be simpler if these headers were in a standard location, where gcc looks for headers by default.
<ely-se>
I'd go with Haskell first so you don't trash your mind with side-effects. :P
<mrvn>
nah, haskell is a pain with it rigid insistence on pure functional.
<monikers>
lol
<monikers>
ok
<monikers>
What is the size of a linux binary with "hello world" in Ocaml?
<monikers>
both Statically linked and Dynamically linked?
<mrvn>
17
ygrek has quit [Ping timeout: 272 seconds]
<monikers>
17 kb?
<mrvn>
nah, 17 potatoes
<monikers>
but it is not a unit?
<monikers>
how to convert potatoes in kbS?
<ely-se>
it's not important, really
<monikers>
sizes matter to me
gpietro has quit [Ping timeout: 240 seconds]
<mrvn>
monikers: your question makes no sense. The size of hello world is really irelevant and differs between architectures
<ely-se>
on my machine it's 120276 bytes
<mrvn>
ely-se: now use ocamlc
<ely-se>
I did
<mrvn>
without -custom
<ely-se>
ocamlc a.ml && ls -al a.out
<adrien>
11:10 Lastpixl : hi! I'm wondering why ocaml header files are installed to /usr/lib/caml and not /usr/include? I'm compiling ocaml from the source. I'm writing a program in C that uses these headers, and it would be simpler if these headers were in a standard location, where gcc looks for headers by default.
<mea-culpa>
monikers: today I've written a simple program that insertion-sorts an array in integers: it's about 700 kB on my x86_64 for native compilation. I'm a beginner too!
<adrien>
Lastpixl: they are architecture-dependant
<Lastpixl>
mrvn: this symlink does not seem to be created when installing ocaml from the source, or from the archlinux package. Symlink creation is not mentioned in README or INSTALL either
<monikers>
mea-culpa, Are you a complete beginner to programming itself?
<mrvn>
I does in Debian.
<adrien>
it's the packaging *you* have
<adrien>
it's not upstream
<adrien>
and it's not the behaviour wanted by upstream either
swgillespie has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<adrien>
I have /usr/lib64/ocaml/caml/config.h
<ely-se>
I'm going to start working on a new OCaml project tonight.
<adrien>
it's completely arch-dependant
<adrien>
usr/include is for arch-independant stuf
<adrien>
f
<adrien>
usr/lib* are for arch-dependant things
<mrvn>
adrien: worse if you install multiple versions
<adrien>
thus these headers must go somewhere under lib*
<mea-culpa>
monikers: I study cs and programming as a hobby and not very regularly but for a year or two. I don't know.
<mrvn>
adrien: /usr/include has /usr/include/<triplet>/
<adrien>
debian again
<adrien>
you can *never* take *anything* on debian as "standard"
<mrvn>
adrien: No. that is unix.
<Lastpixl>
adrien: thanks for the answer. Reading "man hier" on arch, I understood that /usr/lib was for libraries
<monikers>
mea-culpa, ok do you have that book from the very beginning?
<monikers>
:)
<mrvn>
Lastpixl: because arch follows the file hierachy standard
ibor has joined #ocaml
<adrien>
mrvn: I can't find /usr/include/<triplet> in FHS
<Lastpixl>
...but not for the ocaml package, if I understand it correctly
<mrvn>
adrien: then look harder
<adrien>
mrvn: help me find it then
<Lastpixl>
also, installing from the source does not follow FHS (maybe it should not? I have no idea)
<mrvn>
Lastpixl: /usr/lib/<package> is for package specific stuff. you can put pretty much anything in there.
<ely-se>
Use find / -name
<Lastpixl>
ok. I would have liked it to be somewhere gcc looks for it by default, to avoid adding "-I/usr/lib/ocaml" or "-I/usr/local/lib/ocaml" depending on the developer install, which requires writing some sort of script (./configure?). Also, the C program I'm writing is actually a Python module, which is currently build from a setup.py...
<mea-culpa>
monikers: book from the very beginning? You mean some introduction to computer programming (SICP would fit the gist of Ocaml, but it has no types) or to Ocaml language (I've started studying it with "Real world Ocaml", but be prepared for large native binaries due to Core module they use).
<mrvn>
Lastpixl: you have to ask your ocaml where the includes are. Users might have installed it somewhere else.
<adrien>
Lastpixl: use "ocamlc" to drive the compilation of .c files
ely-se has quit [Quit: leaving]
<mrvn>
or use an existing build system like myocamlbuild or oasis
<Lastpixl>
thanks for the answers.
<adrien>
Lastpixl: also
<adrien>
Lastpixl: if everything else fails: "man gcc" and read the "ENVIRONMENT" section
<Lastpixl>
thanks for the pointer. "export C_INCLUDE_PATH=/usr/lib/ocaml" works.
sspi has joined #ocaml
ibor has quit [Quit: Leaving.]
l1x has joined #ocaml
IbnFirnas has joined #ocaml
ygrek has joined #ocaml
S11001001 has joined #ocaml
nullcatxxx_ has joined #ocaml
lambdahands has joined #ocaml
cojy has joined #ocaml
emmanueloga has joined #ocaml
pootler has joined #ocaml
rfv has joined #ocaml
msch has joined #ocaml
lopex has joined #ocaml
NhanH has joined #ocaml
oldmanistan_ has joined #ocaml
jeroud has joined #ocaml
metadave has joined #ocaml
n1ftyn8_ has joined #ocaml
seako has joined #ocaml
mariusae has joined #ocaml
ggherdov has joined #ocaml
ollehar has quit [Ping timeout: 240 seconds]
yminsky has joined #ocaml
sz0 has joined #ocaml
rgrinberg1 has joined #ocaml
psy_ has quit [Ping timeout: 265 seconds]
Haudegen has quit [Ping timeout: 244 seconds]
rgrinberg1 has quit [Ping timeout: 255 seconds]
nullcatxxx_ has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
mea-culpa has quit [Remote host closed the connection]
ely-se has joined #ocaml
Haudegen has joined #ocaml
jonludlam has joined #ocaml
octachron has joined #ocaml
mort___ has quit [Quit: Leaving.]
monikers has left #ocaml ["Leaving"]
Kakadu has joined #ocaml
foocraft has quit [Remote host closed the connection]
echo-area has quit [Remote host closed the connection]
<ggole>
Ah yeah, bindings are monomorphic within let rec (without further annotation)
<Drup>
that works
<ely-se>
it defines when the inference algorithm is allowed to inferf polymorphic types
<ggole>
let first_of_first lst = let rec fst l = match l with | h::t -> h in let f1 = fst lst in fst f1;;
<Drup>
breadmonster: not that this code is wrong
<Drup>
note*
<Drup>
(and ocaml, unlike haskell, will output a warning by default)
<ggole>
Unless you wanted to return an option (which would be a bit safer), you'd probably just write List.hd (List.hd xs) instead of pattern matching
<breadmonster>
Can someone eli5?
<breadmonster>
ggole: Sure, but like this just broke my mental model.
<breadmonster>
Pattern matching failures aside, what's the problem with the code.
<breadmonster>
?
<nojebar>
the type of fst is 'a list -> 'a for some 'a, not for *all* 'a;;
<def`>
It is not possible to infer a principal type for recursive functions in general. Within a recursive binding, type variables are not generalized (e.g monomorphic, they can be instantiated to a single type).
<breadmonster>
One second, so unlike Haskell, OCaml doesn't have implicit universal quantification?
<ggole>
The restriction is only within the expressions of the bound variables
<breadmonster>
That's...strange.
Lis has joined #ocaml
<ggole>
It's like this
<def`>
Haskell works around by first computing a graph of mutual dependencies, to maximize generalization between components. OCaml is more explicit: recursive bindings are rarer, users are responsible for making components explicit.
<ggole>
let rec f = <mono> and g = <mono> in <poly>
<ggole>
The version I pasted into the channel type checks because I moved an expression from the <mono> region into the <poly> region
<ggole>
It's a bit strange, I know
<ggole>
Another way to recover the polymorphism is to use annotations, but that can be a bit notationally heavy (and isn't necessary here anyway)
<def`>
breadmonster: the problem is just you marked as recursive somehing that is not :)
ollehar has quit [Ping timeout: 250 seconds]
<breadmonster>
def`: Well, if I remove the rec it gives me a semantic error.
<breadmonster>
"fst is not defined"
<nojebar>
"and" -> "in let"
<breadmonster>
nojebar: Are they equivalent?
<nojebar>
no
<def`>
yeah that's part of the semantics of ml, within names are not visible within multiple bindings of a non recursive let
<def`>
-within sorry
<breadmonster>
Can someone explain what the design choices for this seemingly strange wart are?
<breadmonster>
I don't see any fundamental problem to automatic generalization since you can do it with annotations anyway.
<Drup>
breadmonster: Did you read the link I gave ?
<def`>
breadmonster: it's not about generalization
<breadmonster>
Drup: I'm reading, some of it is going over my head...
<ggole>
ML is definitely more "hands on" in this area than Haskell
<breadmonster>
def`: What is it about then?
<ggole>
Error: This kind of expression is not allowed as right-hand side of `let rec' is also fun
<ggole>
Laziness and purity definitely help out there
<breadmonster>
ggole: Sure, and I'm sure there are benefits to that, I just don't see what those benefits are in this scenario.
<Drup>
ggole: "Thou compiler frown upon you and you shall change your code"
<breadmonster>
Also, the error I got was completely baffling.
<ggole>
You mean, The type variable 'a occurs inside 'a list
<Drup>
breadmonster: OCaml is not especially good at writing haskell code, that's the main issue here, really
<breadmonster>
Drup: Hahaha true.
<breadmonster>
ggole: Yes, I just assumed that polymorphic types can unify with anything.
<breadmonster>
Okay, so can someone explain this to me? If 'a list can't unify with 'a list list, what are the unification rules in OCaml?
<ggole>
I think it's trying to tell you that the inferred type exists within itself
<Drup>
In this case, it's because recursive types are not allowed by default
<def`>
breadmonster: well, sorry I meant 'it's not about not doing generalization in general, just within recursive bindings'
<ggole>
Yeah, if you -rectypes it passes (but generates a different error, hooray)
<breadmonster>
lol
<Drup>
ggole: well, yeah, because that's not the actual reason here, the actual reason is that it doesn't generalize properly
<Drup>
(because recursive bindings)
<breadmonster>
Okay, I'm going to read RWO, I need to pick up OCaml soon and I can't have stuff like this breaking my mental model again.
<ggole>
Drup: right
<breadmonster>
Is that the best book on OCaml at the moment?
<ggole>
For somebody who doesn't need to start from the beginning, probably
<Drup>
it covers various advanced things, so it should be good for you
<ggole>
There are some nice books for beginners, but it seems like you'd be bored with them pretty fast.
<Drup>
(there is a blog post called "OCaml for the Haskeller" somewhere on the web too)
<Drup>
breadmonster: are you taking a job in the ocamlverse soon ? :p
<breadmonster>
I'd like to, are you hiring? :P
<Drup>
nope
gpietro_ has quit [Read error: Connection reset by peer]
<Drup>
just wondering "I need to pick up OCaml soon"
gpietro_ has joined #ocaml
xet7_ has joined #ocaml
<ggole>
breadmonster: so are you happy with your understanding of let rec?
<breadmonster>
Yeah I get it now, but I'd figure it out completely once I get my hands on RWO.
<enjolras_>
you might be bored by RWO pretty quick if you already know haskell
<breadmonster>
Drup: Ah, my friends and I have been thinking of launching a start up and the only language that we all know in common is OCaml.
<breadmonster>
Enjolras_: Any other suggestions?
<enjolras_>
not that i have a better suggestion though
<breadmonster>
Drup: Or rather, it's the least squares result.
<ggole>
(It's the same reason, but more obvious.)
<enjolras_>
I think you might want to read the backlog of the janestreet blog and other sources like that
<enjolras_>
might be worth doing a compilation of interesting ML threads one day
<enjolras_>
(ML ike mailing list, not like in ML)
<breadmonster>
Enjolras_: Ideally, I'd like to work there rather than just reading their blog :P
<enjolras_>
hehe
<zol1>
Which ML? MetaLanguage or Machine Learning?
<enjolras_>
breadmonster: just candidate
<enjolras_>
they are always hiring
<zol1>
Damnit, wrong channel again.
<breadmonster>
Enjolras_: I'll have to wait a little bit, I have nothing related to OCaml on my resume.
<ggole>
I suspect the Jane St people will be fine with non-OCaml FP experience
<enjolras_>
breadmonster: they don't require ocaml background iirc
<enjolras_>
they say they are fine with any FP experience, and even non FP if you just are really good
<dmbaturin>
Drup, breadmonster: The ocaml for haskellers post I remember of is outdated and was wrong in some parts even when it was new. :)
<breadmonster>
ggole: I'm an economics major. The only development experience I have is in development economics.
<breadmonster>
:P
<ggole>
Ah, then getting a bit of programming experience makes sense.
<breadmonster>
Yup, hence why I'm working with my friends.
<breadmonster>
They're refusing to learn Haskell and I don't want to use Ruby.
<dmbaturin>
To the contrary, haskell for ocamlers post I remember of is quite good.
<Drup>
dmbaturin: Ah, yeah, well, this one can help too
<ggole>
By the way, (somewhat off-topic) question: as I understand it, higher order type checking basically comes down to testing two (type level) functions for equivalence
<ggole>
Is that true, and if so is running them on an abstract value and testing the result for equality a reasonable way to do that?
<mrvn>
two types
ely-se has quit [Quit: leaving]
<mrvn>
ggole: and you only test one way usualy.
<ggole>
With higher order types you have to decide whether forall a . <expr> and forall b . <expr> are the same
<mrvn>
"val fn : 'a -> 'a" and "fn 1" will check if 1 can be unified with 'a
<ggole>
They're pretty much functions at the type level
<mrvn>
same for any other type
<ggole>
Structural equivalence does the job for other types. It doesn't work for type functions.
<ggole>
(Unless you normalize them in some way first, I suppose.)
<mrvn>
don't you just evaluate the type expression and then compare the result?
ely-se has joined #ocaml
<ggole>
They're functions!
<ggole>
The problem in comparing functions should be fairly familiar.
<ely-se>
I like a function that compares function and returns type Maybe = Definitely | Perhaps | DefinitelyNot
<Drup>
ggole: well, there is a différence, you can execute the functions since you have garanteed termination on the type language
<Drup>
(or at least, you really should)
<ggole>
I'm pretty sure I do
<ggole>
It's basically gimped system F
<ggole>
What I'm not quite certain of is whether running them with an abstract argument and comparing the result gives the right answer
<ggole>
I'm fairly sure it does, but it ain't hard to be wrong
gpietro_ has quit [Ping timeout: 264 seconds]
gpietro_ has joined #ocaml
nojebar has left #ocaml ["ERC (IRC client for Emacs 24.5.1)"]
ontologiae has quit [Ping timeout: 250 seconds]
slash^ has joined #ocaml
BitPuffin has quit [Ping timeout: 256 seconds]
mort___ has quit [Quit: Leaving.]
MercurialAlchemi has joined #ocaml
oscar_toro1 has quit [Ping timeout: 252 seconds]
mort___ has joined #ocaml
psy has joined #ocaml
obadz has quit [Read error: Connection reset by peer]
psy has quit [Max SendQ exceeded]
psy has joined #ocaml
ely-se has quit [Quit: leaving]
zpe_ has quit [Remote host closed the connection]
<zol1>
Heya! I would like to write a simple local service that exposes some data from a database (haven't chosen one yet, any recommendations on databases that cooperate nicely with OCaml? My data is relational by nature but NoSQL is fine also.) via JSON RPC to a web-server written in Opium. Is ocaml-rpc (https://github.com/mirage/ocaml-rpc/) the preferred way to do RPCs in OCaml?
zol1 is now known as zol
<Drup>
macaque and pgocaml (both with pgsql) works rather well
<Drup>
(and if your data is relational, then NoSQL is not fine :p)
snyp has joined #ocaml
jeffmo has joined #ocaml
obadz has joined #ocaml
psy has quit [Ping timeout: 246 seconds]
snyp has quit [Quit: WeeChat 1.3]
mort___ has quit [Quit: Leaving.]
breadmonster has quit [Ping timeout: 246 seconds]
ely-se has joined #ocaml
jeffmo has quit [Ping timeout: 252 seconds]
tennix has quit [Ping timeout: 240 seconds]
ontologiae has joined #ocaml
<Drup>
- The Coq back-end (designed and implemented by Jacques-Henri Jourdan) has been documented. Yes, Menhir can produce a provably correct parser, written in Coq's programming language.
<Drup>
Wow.
mort___ has joined #ocaml
srcerer has quit [Quit: ChatZilla 0.9.92 [Firefox 40.0.3/20150826023504]]
ollehar has joined #ocaml
ontologiae has quit [Ping timeout: 250 seconds]
xet7_ has quit [Ping timeout: 252 seconds]
ollehar1 has joined #ocaml
<dmbaturin>
Drup: What's that incremental API they are talking about?
<dmbaturin>
* In the same announccment
ygrek_ has quit [Ping timeout: 244 seconds]
srcerer has joined #ocaml
<Drup>
dmbaturin: you need to ask def`
ollehar has quit [Ping timeout: 264 seconds]
ollehar1 is now known as ollehar
jwatzman|work has joined #ocaml
psy_ has joined #ocaml
zpe has joined #ocaml
<ely-se>
"libc++.so: undefined reference to 'dladdr'"
<ely-se>
this is mildly amusing
zpe has quit [Ping timeout: 246 seconds]
mort___ has quit [Quit: Leaving.]
ely-se has quit [Quit: Leaving]
echo-are` has joined #ocaml
Haudegen has quit [Ping timeout: 240 seconds]
echo-area has quit [Ping timeout: 272 seconds]
octachron has quit [Quit: Leaving]
jao has joined #ocaml
xet7_ has joined #ocaml
oscar_toro has joined #ocaml
Haudegen has joined #ocaml
BitPuffin has joined #ocaml
shane has joined #ocaml
kushal has quit [Ping timeout: 246 seconds]
kushal has joined #ocaml
kushal has quit [Changing host]
kushal has joined #ocaml
ely-se has joined #ocaml
jonludlam has quit [Ping timeout: 264 seconds]
shinnya has quit [Ping timeout: 240 seconds]
jao has quit [Quit: Using Circe, the loveliest of all IRC clients]
jao has joined #ocaml
yomimono has joined #ocaml
dhil has quit [Quit: Leaving]
ely-se is now known as Mini_
Mini_ is now known as ely-se
<shane>
In Haskell, there are lots of useful abstractions like Typeable, Foldable, Applicative Functor (the Haskell meaning), Monads, Arrows etc...why does one not generally find similar abstractions in OCaml when OCaml modules and functors are so expressive
<shane>
?
octachron has joined #ocaml
<companion_cube>
they are more cumbersome to use (no typeclasses) and, currently, there are less optimizations done y ocaml
<shane>
Is it more cumbersome just because of the syntax fact that one needs to specify the functions explicitly like modulename.functionname? Or is it more than that which would outweigh the benefits of these abstractions?
<companion_cube>
you need to specify the instance you use, there is no overloarding
<dmbaturin>
shane: Abstraction themselves are rather common, but without syntactic support, they are less explicit.
<shane>
So when people say that Modules allow more powerful abstractions, which type of abstractions do they mean?
<dmbaturin>
A number of libraries are monads, even if they don't call themselved monads.
<dmbaturin>
* themselves
<shane>
Indeed, but in Haskell once you define something as monad, even say probability distributions, or lists, you get a lot functions like sequenceM, filterM etc for free that are very convenient
<shane>
I am wondering if such things are not too tough in OCaml using say functors and modules, and if so if they are commonly used or not?
<shane>
So it is not common practice in OCaml to use such general abstractions like for instance Travesable and Foldable which work on things as diverse as lists and trees?
jao has quit [Quit: Using Circe, the loveliest of all IRC clients]
<dmbaturin>
I can only speak for myself of course, but I rarely find myself in need to traverse different things in exact same way (ok, finite and infinite lists could be such a thing sometimes). For implementing datastructures that require e.g. equality or ordering, functors are commonly used.
<dmbaturin>
And with functors you can create different versions of the same datastrucure over the same type, but with different ordering. :)
<toolslive>
well, it could be useful to address different monoids in the same way. But, iirc this is quite recent in haskell as well ... ("burning bridges proposal")
<shane>
That is one example, but I mean for instance, if I want the cartesian product of lists, I can get it for free by using the Applicative functor of Haskell without knowing how it is implemented, simply by interpreting lists as non-unique outcomes as is done when defining the list monad
<toolslive>
also, since Haskell is lazy, there is a force pushing you towards higher abstraction and more cleverless in the compiler; like automatically deforesting a hylomorphism....
<shane>
Or if I want the power set of the list, I can use filterM_ (\_ -> [True, False])...I mean this is a rather contrived example, but you get the gist
<shane>
I see
<shane>
Can you give me an example of similar abstractions commonly used in OCaml? You said that abstractions themselves are common. Could you give a few examples
BitPuffin has quit [Ping timeout: 256 seconds]
jeffmo has joined #ocaml
<shane>
About rarely needing to traverse things in the same way, that is a problem indeed, without having ML style modules, but I was talking more on the lines of abstracting out what is common in say lists and trees in the form of traversable and foldable, which again allow you to use many functions for free once you have defined the basic foldMap or traverse that is required by the type class. This I imagine would be very useful.
<companion_cube>
shane: using Traversable is rare, using specific monads is common
<toolslive>
I can say lots of bad things about ocaml, but being a bit less abstract than haskell isn't really a problem.
<sgeisenh>
in no way is ocaml "less abstract" than haskell
<shane>
Can I get some examples of some general abstractions that are commonly used in OCaml?
<toolslive>
ocaml's stdlib certainly is less abstract than haskell's
<companion_cube>
ocamlgraph or mirage use a lot of functors
<Denommus>
shane: module signatures can fulfill most usecases for typeclasses
<companion_cube>
ocamlgraph, for instance, abstracts over the concrete type of a graph, edges, vertices
<sgeisenh>
shane: a simple example is any time that you want an ordered set of things
<Denommus>
shane: your generic code would be inside functors from that take modules with that sig
<sgeisenh>
you can construct an ordered set from any module that implements some comparison operator
Haudegen has quit [Ping timeout: 260 seconds]
<shane>
sgeisenh: There is no reason why it should be less abstract, but its just that in Haskell you come across very general abstractions like applicative functors, traversablem, foldable, etc... that work on very different data types that at first seem to have nothing in common. These abstractions seem to be discussed all the time in Haskell tutorials etc...i was only wondering why a similar thing is not seen in OCaml. I am not talking about simple things like or
<shane>
dering using a comparison operator, which I know can be done with modules. And I think all the rest can also be done by modules, but I am just wondering why in Ocaml or sml tutorials one hardly comes across them
obadz has quit [Remote host closed the connection]
<sgeisenh>
if you want me to be perfectly honest, it is because they're a direct obstacle to learning the core ideas of the language
<toolslive>
you can make module for a set of int32's with Set.Make(Int32) but trying the same with regular expressions (for example) will fail.
<shane>
I see
<toolslive>
that is true: addressing OCaml as if it were a poor relative of Haskell is a recipe for disaster.
<sgeisenh>
haskell has a lot of type classes baked into the language with syntactic sugar
<toolslive>
I've seen 'em do it man. they start out with ($) and flip and try to write Haskell.
yomimono has quit [Ping timeout: 240 seconds]
<shane>
When you say that they are a direct obstacle to the core ideas, could you elaborate a little more?
<dmbaturin>
shane: In the presence of ad hoc polymorphism and predefined type classes, you may want to check if the thing you implement can be a monoid/functor/etc just so you can use it with those functions easily. In the absence of it, however, you need a stronger reason to start thinking about it.
obadz has joined #ocaml
<sgeisenh>
hello world is a great example
<dmbaturin>
Most tutorials do discuss specializing predefined functors like Map or Hashtbl over modules that provide ordering.
<sgeisenh>
in haskell, you're stuck using IO or unsafePerformIO
<shane>
dmbaturin: that makes sense. In Haskell I personally do have a habit of asking if what I am defiining is a monad/ functor etc...
<sgeisenh>
in ocaml, effects aren't given any special treatment
<sgeisenh>
in that sense, there aren't any abstractions that are fundamental to writing programs in ocaml
<shane>
I see
<companion_cube>
ocaml favors simple, straightforward code; haskell tends to ues powerful abstractions more
<shane>
companion_cube: is that just a culture thing?
<shane>
companion_cube: this is exacly my impression too. And I was wondering if it's just the way the language cultures evolved or it had more to do with the language designs
<shane>
apart from of course some abstractions being forced on Haskell...but there are others which are not
<sgeisenh>
it is a combination of the cultures and the language designs; perhaps mostly with how the language design influenced the evolution of the culture
<companion_cube>
for instance flip is rarely used, because it may not be optimized away and because writing non-point free code is ok
<toolslive>
in haskell, you're sometimes in a discussion with the compiler where you say "No.I just want to flip this bit; I don't want a copy of the datastructure where the bit is flipped". In OCaml, you're sometimes wondering "what (side-effect) happened?"
<mrvn>
toolslive: you can't flip a bit, that's not functional. :)
<dmbaturin>
If any practical miranda and pre-type classes haskell programs survived, it could be fun to read them. :)
ollehar has quit [Quit: ollehar]
<companion_cube>
as fun as reading old OCaml
<companion_cube>
*shivers*
<toolslive>
that's the whole discussion with the compiler: you try to explain it in such a way the silly thing can fuse it.
Haudegen has joined #ocaml
<dmbaturin>
Well, fun from language culture research anyway.
<dmbaturin>
* point of view
<toolslive>
Yes, miranda and gopher are quite different, culturally
<companion_cube>
I'm really impatient flambda is merged
<shane>
Also are there any optimizations done in Haskell with regard to some of these abstractions, that are not performed in OCaml?
<shane>
compiler optimizations, I mean
<ggole>
OCaml doesn't really optimize much at the moment
<sgeisenh>
Yes, almost all of them.
<mrvn>
shane: ocaml doesn't optimize other than inlineing.
<Drup>
shane: You can see it that way: in Haskell, there is so much sugar and facilities for monad (and applicative functors) that the main goal, when designing an API, is to make it a nice monad, mostly
<Drup>
in OCaml ... it's cool if it happens, but it's cool if it doesn't
<Drup>
as long as the API is good, doesn't matter
<shane>
How does OCaml manage to be so fast, if it does not optimize?
<toolslive>
no, there's no automatic foldr/build optimization in OCaml.
<shane>
optimize much, I mean
<sgeisenh>
SML has MLton, which gives you abstractions for free, but SML doesn't have a very large community
<Drup>
(you have other "style" you are pushed towards in OCaml, like some usages of modules)
<toolslive>
ah. ocaml is not lazy.
Kakadu has quit [Quit: Page closed]
<companion_cube>
shane: good runtime, predictable perf, strictness
<toolslive>
laziness kills performance
<mrvn>
shane: ocaml source is usualy written with efficient algorithms and the compiler just produces efficient code for the input you give it.
<mrvn>
shane: things like common expression elimination you have to do yourself or your code will be slow(er)
<shane>
Drup: About monads, indeed that is a necessity sometimes because of Haskell's design, whereas in other languages alternatives are available, but Haskell tends to have many abstarctions that are not because there are no other alternatives.
<shane>
sgeisenh: When you say MLton gives you abstractions for free, what did you mean?
<Drup>
shane: I'm not sure I parsed the end of your sentence succesfully
<dmbaturin>
shane: You also have to make (or not make) your functions tail recursive yourself, it doesn't attempt to do it for you (but it does tail call optimization if they are in tail position).
<sgeisenh>
MLton is a whole program optimizing compiler, there are no penalties for using modules functors or ADTs
<shane>
Drup: I mean if you look at abstractions like Traversable and Foldable, (unfortunately these are the only ones that come to mind right now), they are not defined out of necessilty like monads were to bypass the purity...but they are defined because they tend to apply to a wide variety of data structures like lists and trees etc
<dmbaturin>
And it takes half a minute to compile hello world. :)
ineol has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<sgeisenh>
This is true, MLton's compile times aren't terrific
<Drup>
shane: Yes, in OCaml, this tends to be done to the form "this module implements a fold function"
<shane>
in Ocaml there are penalties for using modules? I thought all that would be taken care of at compile time?
<Drup>
shane: it's ... complicated
<ggole>
In SML there are restrictions on functors - basically, they only appear at top level
<ggole>
In OCaml there is no such restriction
<ggole>
The argument can vary at runtime.
<Drup>
sgeisenh: a good amount of those issues are going to disapear in the next version of OCaml, tbf
<sgeisenh>
Drup: yes, there are several changes I'm excited about in the near future
<ggole>
Additionally some of MLton's techniques, like whole program defunctionalisation, might be problematic in the context of some of OCaml's additions to ML
<ggole>
Polymorphic recursion, mostly
octachron has quit [Quit: Leaving]
<toolslive>
I really like Haskell; for example its type notation syntax is way more elegant than OCaml's. and you often do come up with more elegant code because of the purity and laziness....
<Drup>
shane: semantically, it's compile time
<ggole>
toolslive: what, you don't appreciate our diversity of application syntaxes? :o
<ggole>
(I agree: four is too many.)
<toolslive>
but both haskell and Ocaml did a poor job on record syntax
<ggole>
Hmm, what don't you like? Module qualification?
<Drup>
toolslive: eh ?
<shane>
toolslive: I feel so too about the elegance regarding laziness and purity. I know "being clever" in code can be a pain for someone trying to understand your code, but it's very nice when trying to apply a function to the cartesian product of lists, to use applicative functors and be done with it!
<Drup>
toolslive: what do you have against ocaml's one ?
<shane>
toolslive: plus the combination of infix notation like <$> and <*> makes the code more idiomatic.
<toolslive>
ow. infix notation just is your brain being damaged by high school arithmatic
kushal has quit [Quit: Leaving]
<toolslive>
about records, just try to use them in pattern matching... and see how pretty it is.
<shane>
toolslive: in this case the infix notation is helps me to think of <$> and <*> as replacing spaces between a function and it's arguments. In that sense, it is idiomatic
<ggole>
Ah, with all the names flying around?
<ggole>
Punning helps with that a bit
<ggole>
(But of course, that isn't always appropriate.)
moei has quit [Quit: Leaving...]
<toolslive>
yes, there are ways, but it feels rather clunky
<toolslive>
btw, my brain is damaged too: I find >>= simpler to read than bind
<dmbaturin>
shane: Infix composition operators with well known meanings/laws are indeed an advantage. There are ocaml syntax extensions for pseudo-overloading bind (local opens also help).
<toolslive>
but I have the illusion that decades of using infix notations for most operators caused that.
Submarine has joined #ocaml
johnf has joined #ocaml
<toolslive>
anyway, I was really disappointed with the recent "state of ocaml 2015".
<Drup>
oh ?
<shane>
toolslive: one more case where infix operators are useful is in reducing parenthesis when one is chaining the operator: for instance composition is better of being infix
<Drup>
toolslive: why so ?
<toolslive>
well, RPN fixes parentheses too.
<shane>
f . g . h is better than comp f (comp g h)...and if these are just three...as the number increases the latter gets a lot more unreadable
<toolslive>
completely ignored the state of multicore
<shane>
How likely is it that OCaml will offer good parallel support to exploit multicores?
<shane>
I mean in the new release
<Drup>
toolslive: mostly because it was already mentioned last year quite extensively ?
<Drup>
shane: it's not going to be in the next one, probably in the one after that
<toolslive>
btw, g(f(x)) can be written as x |> f |> g
<Drup>
toolslive: there is a good reason for not having it in the next one: It involves changing the GC. The compiler receives significant improvements in the next release and you really don't want two completely orthogonal changes resulting in segfaults in case of bugs in the same release.
<toolslive>
but a catenative notation could be useful too.
<dmbaturin>
Or f @@ g @@ x
<toolslive>
yes, I'm completly clueless on what the impact will be on libraries.
tennix has joined #ocaml
<toolslive>
I really would like to be able to write concurrent code and have multiple cores as resource.
<toolslive>
now I have 1 thread in ocaml doing the coordination and all other processing is pushed outside the the ocaml heap, which is ugly and tedious.
<Drup>
toolslive: the usual "fork and message passing" scheme doesn't work ?
<dmbaturin>
While we are at it, what do you use for this kind of message passing?
tennix has quit [Ping timeout: 265 seconds]
<Drup>
dmbaturin: fork and channels ? :p
jonludlam has joined #ocaml
<toolslive>
sure it works. but for example if I need to decompress the data in a buffer, I need to make sure it's in a bigarray, and then feed it to the decompression library on another thread ....
<toolslive>
so you tend to make sure you don't have to copy back and forth between C heap and OCaml heap. so your IO is suddenly using bigarrays too.
<toolslive>
but that gives garbage collection issues..... and suddenly I'm back to manual memory management ....
<Drup>
Ah, but that's because you are using C things for parallelism ?
<dmbaturin>
Drup: Well, I guess. I mean what are the most popular options for serializing and handling such messages. :)
<toolslive>
yes. parallelism is a resource. ;)
<Drup>
toolslive: you could just fork in OCaml and doing OCaml things
<Drup>
dmbaturin: between processes ? marshal
<Drup>
dmbaturin: look at awesome-ocaml, parallelism section
<dmbaturin>
Ah, thanks, will have a look.
<toolslive>
what about writing my code like: fill_buffer ... >>= fun buf -> decompress buffer >>= fun buf' -> ... and have a scheduler automatically mix IO and crunching across the available cores.
jwatzman|work has quit [Read error: Connection reset by peer]
ygrek_ has joined #ocaml
jwatzman|work has joined #ocaml
<toolslive>
"just use fork" as a suggestion to counter the absence of multi-core comfort is isomorphic with "just use shared_ptr" in the absence of a garbage collector.
<toolslive>
it's not that I can't, It's that I would very much like not to.
kushal has joined #ocaml
<toolslive>
in haskell, otoh, ;)
<mrvn>
and how would fork deal with shared data?
<toolslive>
basically I want an Erlang style runtime underneath a Hindley-Milner language.
<Drup>
toolslive: I kinda agree
<toolslive>
don't get me wrong: OCaml is way better than most other eco-systems.
<Drup>
toolslive: but it works for a significant amount of use cases
<toolslive>
ocaml has most things correct: functions are good for lego like composition and, static typing counters my tendency to do silly things. But I have all these idling cores that need herding.
<companion_cube>
are you writing server-side programs?
<dmbaturin>
I still can't believe Erland is dynamically types. :)
<dmbaturin>
* types
<dmbaturin>
** typed
<toolslive>
it's a distributed system...
<toolslive>
lot's of messaging for coordination, but also data that needs to be transformed (compression, erasure coding, encryption)
<dmbaturin>
Erlang, of course. When I've seen code samples, I was under impression it uses type inference.
<toolslive>
so you end up with a single ocaml thread doing the coordination, and the data crunching is outsourced to the C heap.