<thelema>
option 3 is to functorize your whole module, but this has both runtime cost and unnecessary annoyance
<thelema>
you won't be able to build a list of these different types of bounds
<ezyang>
YEah, that'll be fine.
<ezyang>
wouldn't be able to do it w/o existential types or something :-)
<thelema>
just making sure that wasn't in your plan...
<ezyang>
On a completely different note, where do OCaml'ers like putting the hanging 'in's of their let statements?
<hcarty>
ezyang: It seems to vary. I usually put them on a new line. Others put them on the end of the previous line
<ezyang>
do you do foobar\nin\nblah blah?
<hcarty>
let foo =\nbar\nin\nblah -- for a sufficiently long bar
<thelema>
let foo = blah in OR let foo = \n blah blah blah \n in
<hcarty>
thelema: Yes
<hcarty>
thelema: Loading Camlp4Top.cmo after camlp4 has been loaded/activated in the toplevel seems to cause the problem
<hcarty>
npouillard: ping
<hcarty>
thelema: 16:02 < ezyang> YEah, that'll be fine.
<hcarty>
thelema: Sorry, errant paste
<hcarty>
thelema: http://vpaste.net/OkeQ3? -- These steps reproduce the bug for me, so it seems to be a camlp4 bug
<hcarty>
thelema: Either that or estring is not initializing itself with the toplevel properly. I don't know enough about camlp4 to know which.
<npouillard>
hcarty: pong (but was about to go sleeping)
<hcarty>
npouillard: If you're off to sleep, no rush. Just checking on a estring and/or camlp4 bug. I'm trying to figure out which program is causing the issue.
<hcarty>
npouillard: Loading Camlp4Top.cmo after camlp4 has been loaded/activated in the toplevel causes all types to be reported in revised syntax
<hcarty>
npouillard: This is how estring registers itself with the toplevel. I'm not sure if the bug is with estring or camlp4.
<npouillard>
hcarty: yes you may want to load some other modules to restore the original syntax
<npouillard>
in estring then (with the little knowledge kept about this)
<hcarty>
npouillard: Ok, thank you! I'll poke around to see what I can find. Any suggestions for other modules to try?
<hcarty>
npouillard: Regardless - thank you very much! Sleep well :-)
<npouillard>
however maybe a camlp4 limitation, if camlp4 does not provide a simple mean to load the basics stuff without commiting on the syntax
<npouillard>
camlp4o.cma ?
<npouillard>
thx
noisymouse has quit [Remote host closed the connection]
alexyk has quit [Quit: alexyk]
alexyk has joined #ocaml
Edward__ has quit []
decaf has quit [Remote host closed the connection]
drunK has quit [Remote host closed the connection]
oriba has quit [Remote host closed the connection]
alexyk has quit [Quit: alexyk]
decaf has joined #ocaml
Amorphous has quit [Ping timeout: 272 seconds]
Modius_ has joined #ocaml
ymasory has quit [Ping timeout: 240 seconds]
almaisan` has joined #ocaml
Amorphous has joined #ocaml
almaisan-away has quit [*.net *.split]
Modius has quit [*.net *.split]
rwmjones has quit [*.net *.split]
thelema has quit [*.net *.split]
albacker has quit [*.net *.split]
f[x] has quit [*.net *.split]
nimred has quit [*.net *.split]
alpounet has quit [*.net *.split]
julm has quit [*.net *.split]
snarkyboojum has quit [*.net *.split]
haelix has quit [*.net *.split]
thelema has joined #ocaml
albacker has joined #ocaml
f[x] has joined #ocaml
nimred has joined #ocaml
alpounet has joined #ocaml
julm has joined #ocaml
snarkyboojum has joined #ocaml
haelix has joined #ocaml
nimred has quit [Max SendQ exceeded]
nimred has joined #ocaml
rwmjones has joined #ocaml
ymasory has joined #ocaml
smerz has quit [Quit: Ex-Chat]
elehack has joined #ocaml
<thelema>
elehack: yay, matias giovanni wrote about batteries
<thelema>
oops, giovannini
<elehack>
yep :)
<elehack>
I've been meaning to turn some of the issues he describes into bug reports, but haven't gotten to it yet.
<elehack>
Some are clearly bugs - in_channel_length (open_in "foo") should type.
<thelema>
I'm thinking a 2.0 release needs to happen soon to clean up some of these lingering bugs
khia0 has joined #ocaml
khia0 has left #ocaml []
<elehack>
we at least need a 1.3 sooner rather than later.
<elehack>
but that doesn't fix the source-incompatible bugs.
<thelema>
yup, thus 2.0
<thelema>
List.sort also
<elehack>
yeah
<elehack>
I always thought that was kinda weird in extlib.
<thelema>
hmm, there seems to be no in_channel_length anywhere
<elehack>
ahh, it's probably just inherited from OCaml pervasives then.
<elehack>
Does our IO infrastructure even specify the ability to find the length of a channel?
<thelema>
not in general
<elehack>
I don't think we have seeking support either.
<thelema>
and it doesn't look like any specifics either
<thelema>
There's a patch that I almost finished updating to allow seekable channels
<elehack>
that could be nice, so long as it doesn't complicate the simple case for most channels.
<elehack>
So far, we do not have any C stubs in Batteries - are we opposed or at least reluctant to using them, or is it just that we haven't had a good enough need yet?
<thelema>
portability becomes an issue there
<elehack>
yeah
<thelema>
just reluctant to using them at this point
<thelema>
It's nice having batteries work everywhere that ocaml works
<elehack>
yeah
<elehack>
and I think that should stay a goal (or even a requirement)
<elehack>
I've been doing a little thinking about how to provide atomic integers.
<elehack>
for use e.g. by Std.unique
<elehack>
but in that case, it'd be a C stub to speed things up on platforms that provide native atomic integers, and a pure OCaml fallback to threads and mutexes everywhere else.
<mrvn>
Does any platform not have normal intergers atomic?
<thelema>
elehack: what operations atomically on ints?
<thelema>
std.unique has a proper ocaml solution involving OO
<mrvn>
So long as the ocaml GC doesn't do concurrent multithreading a simple int ref is atomic.
<elehack>
incr, decr, test-and-swap, most likely.
<elehack>
hmm... last I poked at std.unique I thought it just used a global ref.
<elehack>
yeah, it's just a global int ref that's incremented.
<elehack>
and is a different ref than the BatPervasives one (thought I filed a bug about that, but I can't find it).
<mrvn>
elehack: for true atomicity even with non ocaml threads you will need asm instructions. And then say goodby to portability.
<elehack>
mrvn: exactly. thus we would just implement the stubs where we know how (using the primitives exposed by GCC for starters), and use a slow mutex for all other platforms.
<mrvn>
elehack: or just stick with being atomic within ocaml and let the verry few special cases where you need to share an atomic with C code be special.
<thelema>
I'm not opposed to this, as long as it works compatibly on all platforms
<elehack>
thelema: looks promising, although I don't know that we need to support quite that many operations.
<thelema>
elehack: I hope not
<elehack>
mrvn: I'm hesitant to introduce a dependency on the current threading behavior of the GC.
<mrvn>
elehack: do you want BatIO to be a functor?
<elehack>
I don't think so.
<mrvn>
elehack: but that is what that is basically.
<elehack>
yeah, except being a functor doesn't allow for polymorphic usage.
<thelema>
batIO already uses a record of ... mutable functions... got me why they're mutable...
<elehack>
eww...
<elehack>
BatIO also has a bunch of things going on with thread-locked mutable global state.
<thelema>
if the kernel doesn't need single-char read/write, maybe batteries doesn't
<elehack>
which always gives me the eebie-jeebies.
<thelema>
ah, so an exception is raised when you read/write to a closed channel
<mrvn>
thelema: so you can write a buffering and non-blocking write that replaces itself with a idle or buffering function depending on wether there is something buffered.
<thelema>
definitely some things to think about...
<elehack>
yeah
<mrvn>
thelema: I would like a Unix module where file_descr is a custom type with finalizer. On close you set the FD to -1 and the finalizer can check if it was properly closed and close it otherwise
<thelema>
once I finish my current urgent project
<mrvn>
And maybe phantom types to say if the FD is a file, dir or socket.
<mrvn>
phantom types for readable/writable would be nice too
<elehack>
One of the Jane St. people (Yaaron, perhaps?) had a nice blog post a few months back on a nice way to do read/write phantom types with private types.
<thelema>
any suggest
<thelema>
any suggestions on how to benchmark memory of an ocaml program?
<elehack>
no - there have been some memory profiling patches here and there, but I don't know of a current one.
<thelema>
mrvn: the patch for seekable channels used phantom types for read/write/seekable
<elehack>
I thought I saw something cross caml-list in the last year, but don't remember for sure.
<thelema>
elehack: the best part is that it's mixed ocaml and C, so I can't just use the GC's numbers...
<elehack>
Well, the C part can be profiled with valgrind...
<mrvn>
I asked a while back but maybe now somebody knows: I want to extend the sha module to support Bigarray. But I don't want to force everyone to link in bigarray. Do I have to write 2 seperte modules for that or can one do that better?
<elehack>
mrvn: I think you'll need to write separate modules so the API can be typed properly.
<thelema>
mrvn: two modules - once you refer to bigarray in your module, it's gotta be linked in
<thelema>
elehack: maybe I'm just going about things the wrong way.
<mrvn>
thelema: doe Batteries have Unix.read/write for Bigarray?
<thelema>
mrvn: the best way I can think is to just have Sha and Sha_ba which includes Sha
<thelema>
mrvn: I don't think so...
<mrvn>
thelema: I was hoping to have Sha.String and Sha.Bigarray and then let Sha = Sha.Bigarray in the source.
<thelema>
you can have Sha_string and Sha_Bigarray
<thelema>
once you have a parent for them both, that parent will require them both, which will require Bigarray
<mrvn>
thelema: What if I compile them each for a pack but keep them seperate?
<thelema>
pack is just a compilation trick to avoid writing a parent module, it's equivalent as far as I can tell (including the dependency issue)
<thelema>
compiling w/ pack is equivalent to writing a full parent module with all the right submodules and signatures
<mrvn>
thelema: What I mean is that I have /usr/lib/ocaml/sha and /usr/lib/ocaml/sha_ba. In each there is a parent module Sha but one has Sha.String and the other Sha.Bigarray. would that work?
<mrvn>
Or would the dummy Sha modules then colide if you use both Sha.String and Sha.Bigarray?
<elehack>
mrvn: that would almost work. however, if someone writes a library against 'sha' and tries to use it in a program needing 'sha_ba', they will disagree on the signature of module Sha and be unable to link.
<mrvn>
elehack: :( That was what I'm afraid of.
<thelema>
I think it'd have many problems
<elehack>
I put some thought in to this very problem when I was trying to figure out a way to permit 'open Batteries' to do The Right Thing on both multi- and single-threaded platforms.
<mrvn>
I don't really want the Sha parent module. I just want the namespace.
<thelema>
mrvn: why do you want one namespace for two modules?
<mrvn>
elehack: well, threads have a compiler switch for this.
<mrvn>
thelema: because they are both Sha.
<elehack>
mrvn: yes, but there is still the issue of module signatures, and threaded code needs to be able to link against libraries built without threads.
<thelema>
what's wrong with Sha_bigarray and sha_string?
<mrvn>
thelema: looks ugly
<thelema>
_ vs .?
<mrvn>
thelema: yes.
<thelema>
deal with it and get on with your work.
mnabil_ has quit [Ping timeout: 260 seconds]
<mrvn>
And Sha_bigarray will have types and functions from Sha_string so you get them mixed in error messages
<thelema>
ocaml's module system doesn't do what you want.
<thelema>
... ah, the problem batteries has... maybe the ocaml devs would be so nice as to help us with that.
<thelema>
so far, no love.
<elehack>
If anyone cares, you can now (as of 2 min ago) set GODI_BATTERIES_VCS_CHECKOUT=yes in godi.conf to make the Batteries GODI package build from Git master rather than a release.
<mrvn>
thelema: the ocaml devs seem to not care about extending the modules at all.
<thelema>
mrvn: they've added one feature in 3.12 that helps with that, maybe they'll keep continuing along the path
<thelema>
elehack: nice. I wish I could test that for you. I should make a release. Maybe tomorrow.
<thelema>
Good night, all
<elehack>
g'night
<mrvn>
thelema: I've reported bugs with trivial patches and they just get ignored. E.g. add a prototype to the unix_support.h to make some more helpers public I need for Fuse. Or int31 support in Bigarray.
mnabil_ has joined #ocaml
decaf has quit [Remote host closed the connection]
myu2 has quit [Remote host closed the connection]
groovy2shoes has quit [Quit: groovy2shoes]
alexyk has joined #ocaml
alexyk has quit [Read error: Connection reset by peer]
elehack is now known as elehack|afk
joewilliams is now known as joewilliams_away
alexyk has joined #ocaml
alexyk has quit [Read error: Connection reset by peer]
eye-scuzzy has joined #ocaml
alexyk has joined #ocaml
jamii_ has joined #ocaml
alexyk has quit [Read error: Connection reset by peer]
ulfdoz has joined #ocaml
alexyk has joined #ocaml
alexyk has quit [Read error: Connection reset by peer]
Snark has joined #ocaml
ulfdoz has quit [Ping timeout: 246 seconds]
mnabil_ has quit [Ping timeout: 260 seconds]
almaisan` is now known as al-maisan
LeNsTR has joined #ocaml
Yoric has joined #ocaml
Tianon has quit [Ping timeout: 260 seconds]
edwin has joined #ocaml
ttamttam has joined #ocaml
myu2 has joined #ocaml
Yoric has quit [Quit: Yoric]
mnabil has quit [Read error: Connection reset by peer]
Snark has quit [Quit: Ex-Chat]
al-maisan is now known as almaisan-away
almaisan-away is now known as al-maisan
ymasory has quit [Ping timeout: 255 seconds]
mnabil has joined #ocaml
npouillard has quit [Read error: Operation timed out]
ikaros has joined #ocaml
npouillard has joined #ocaml
julien_t has joined #ocaml
Tianon has joined #ocaml
Tianon has quit [Changing host]
Tianon has joined #ocaml
Yoric has joined #ocaml
mnabil has quit [Remote host closed the connection]
<kerneis>
in other words, how can I detect in a Makefile that the linker is flexlink or gcc?
<kerneis>
(the project already uses autoconf, if that may help)
avsm has quit [Quit: Leaving.]
avsm has joined #ocaml
cthuluh has quit [Quit: "Our life is frittered away by detail... Simplify, simplify" -- Thoreau]
cthuluh has joined #ocaml
myu2 has quit [Remote host closed the connection]
ftrvxmtrx has joined #ocaml
Modius_ has quit [Quit: "Object-oriented design" is an oxymoron]
myu2 has joined #ocaml
myu2 has quit [Remote host closed the connection]
ikaros has quit [Quit: Leave the magic to Houdini]
<adrien>
try to pass flexlink-only flags?
julien_t has joined #ocaml
<kerneis>
what do you mean by flexlink-only?
<kerneis>
"-link -g" solves the issue
<kerneis>
but I need to be able to tell whether I'm talking to flexlink or gcc
<kerneis>
(but I think I found a way, matching on the target architecture)
<kerneis>
is that true that flexlink is *always* used on windows for native compilation?
<kerneis>
or is there some special case I should consider?
rien_ has quit [Ping timeout: 240 seconds]
boscop has joined #ocaml
myu2 has joined #ocaml
ftrvxmtrx has quit [Remote host closed the connection]
alexyk has joined #ocaml
roconnor has quit [Remote host closed the connection]
ftrvxmtrx has joined #ocaml
alexyk has quit [Read error: Connection reset by peer]
elehack|afk has quit [Ping timeout: 255 seconds]
elehack|afk has joined #ocaml
rien_ has joined #ocaml
alexyk has joined #ocaml
alexyk has quit [Client Quit]
elehack|afk has quit [Ping timeout: 276 seconds]
<flux>
does someone have an ocamlbuild environment for neatly compiling modules? I've been building mine with a script that requests building a bunch of .cmo-files, but that's less than satisfying..
<flux>
uh, for building ocsigen modules that is :-)
unkanon2 has joined #ocaml
rien_ has quit [Ping timeout: 276 seconds]
julien__ has joined #ocaml
unkanon2 has quit [Ping timeout: 276 seconds]
julien_t has quit [Ping timeout: 272 seconds]
rien_ has joined #ocaml
alexyk has joined #ocaml
poucet has joined #ocaml
philed has joined #ocaml
poucet has left #ocaml []
poucet has joined #ocaml
poucet has left #ocaml []
alexyk has quit [Read error: Connection reset by peer]
<kaustuv>
It turns out that the main reason why the Haskell version of that array increment program was slower yesterday than the final OCaml version was the strange design of the Haskell array type.
<kaustuv>
If one goes past the abstraction to the raw get/set operations (equivalent to Array.unsafe_get/unsafe_set), then the Haskell version is faster than even the OCaml int array based implementation.
<thelema>
3.80s vs 3.74s - down to basics finally?
<kaustuv>
Yes, except that it is not a fair comparison as the Haskell version uses unboxed native integers (i.e, 64 bits)
<thelema>
whereas ocaml uses taggeed ints, which are more expensive to update (maybe)
<kaustuv>
Well, if I use a nativeint Bitarray.Array1.t, then there are no (un)boxing calls (as shown by ocamlopt -dsel), but the time taken is still around 7 seconds as you saw yesterday
<thelema>
really... hmm, I wonder about the inner loop. I guess now is the time to get out the "-S" and inspect the asm
<mfp>
IIRC there's no code hoisting w/ Bigarray ops, so it always ends up computing the addr as base + size * offset as opposed to incrementing a pointer
<mrvn>
Boundary checks mean a pipeline stall. They are often quite expensive in small loops.
LeNsTR has quit [Quit: LeNsTR]
alexyk has quit [Client Quit]
<mrvn>
worse if the branch prediction fails
<mfp>
this -> sarq $1, %rsi movq 16(%rbx), %rdi movq 8(%rdi), %rdi movq (%rdi, %rsi, 8), %rdi for Array1.unsafe_get
bzzbzz has joined #ocaml
<mfp>
then recomputes the addr for unsafe_set
<mrvn>
luckily no mul
<kaustuv>
If I am reading the assembly right, then the spin function reloads the 'k' argument from the stack in every run instead of keeping it in a register. Is that right?
drunK has joined #ocaml
<kaustuv>
let me see what happens with a for loop instead of a tailrec function instead
<kaustuv>
It made it slower!
<thelema>
kaustuv: wow, that's impressive
<mfp>
doing let rec spin l k = .... (i.e. passing k explicitly instead of using outer k) is a tiny bit faster
<mrvn>
how about Array.iter?
<mfp>
and avoiding lexical capture of the other vars (arr, r) makes it nearly 2X faster
<mfp>
(I'm referring to the Bigarray version)
<mrvn>
Bigarray.iter?
<thelema>
really? I didn't expect that
<mrvn>
Passing vars explicitly or not can alter the unboxing.
<kaustuv>
mfp: heh, that's exactly what I just implemented and found as well. I guess the moral here is do closure conversion by hand if you care about raw serial performance
robthebob has joined #ocaml
<kaustuv>
Anyhow, my program (a simple physics simulator) needs roughly 9e7 integer updates per second, whereas even without any fiddling the nativeint bigarray gives me 14e7 integer updates per second, so I am not too displeased.
<kaustuv>
This is really frightening: just closure converting some simple functions by hand has given me a roughly 64% speed increase in my program. I think I should start getting paranoid about local functions.
<kaustuv>
(err, 64% runtime decrease, not speed increase.)
rien_ has quit [Quit: leaving]
<thelema>
hmm, why are closures so expensive?
Sieben has left #ocaml []
<f[x]>
gc + unboxing?
<thelema>
I can see the gc cost...
<kaustuv>
Based on -S and -dsel, it seems to me that the variables in the environment are always accessed through an explicit environment tuple instead of the captured variables being passed as additional arguments (i.e., lambda lifting)
<thelema>
I don't see why you need an extra box in this example
<thelema>
hmm, I wonder how much optimizing on the environment tuple can happen...
<kaustuv>
You would need it in the general higher order case, I think. Not sure if whole program analysis can eliminate it entirely.
alexyk has joined #ocaml
<thelema>
whole program analysis, nothing. I just want it within a single toplevel phrase
<thelema>
so I can continue to write internal recursive loops that refer to "constants" without performance cost
<julien__>
/msg NickServ identify am200782
<thelema>
julien__: time to change your password, quickly
<julien__>
oups
<julien__>
lol
julien__ is now known as julien_t
julien_t is now known as julien__
julien__ is now known as julien_t
joewilliams_away is now known as joewilliams
julien_t has left #ocaml []
julien_t has joined #ocaml
ttamttam has quit [Remote host closed the connection]
alexyk has quit [Quit: alexyk]
julien_t is now known as julien__t
julien__t is now known as julien_t
julien_t has quit [Quit: julien_t]
julien_t has joined #ocaml
LeNsTR has joined #ocaml
rossberg_ has quit [Quit: Leaving]
ccasin has joined #ocaml
rossberg has joined #ocaml
ccasin has quit [Ping timeout: 264 seconds]
<hcarty>
mrvn: It's ugly, but you could link a dummy Bigarray library for cases where Bigarray isn't wanted (Sha_bigarray)
<hcarty>
mrvn: And then link the actual Bigarray library when it is requested
ftrvxmtrx has quit [Quit: Leaving]
ymasory has joined #ocaml
ymasory has quit [Remote host closed the connection]
ymasory_ has joined #ocaml
<mrvn>
hcarty: how do I do that?
<mrvn>
In C I would use weak symbols but I don't think ocaml has that
<hcarty>
mrvn: I think you would have to provide a dummy bigarray.ml with empty/invalid_arg stubs for all of the Bigarray functions you use
<mrvn>
and have the user add that to the command lint when linking?
<mrvn>
s/lint/line/
<hcarty>
mrvn: The user, or the build system
<mrvn>
unaceptable. If the user has to selective add the module he might as well pick between sha and sha_ba directly.
<hcarty>
I think this is how cothreads worked. I never used it beyond toying with the examples, but I think it was intended as a replacement for the OCaml-provided thread support
<hcarty>
mrvn: What avoid Bigarray then in the first place?
<mrvn>
hcarty: with threads you have compiler option and then ocaml picks a different object file for your module if you so desire. I was hoping one could have something like that.
<hcarty>
mrvn: If it's installed with findlib then there could be sha and sha.bigarray packages
<hcarty>
Each would provide a Sha module
<mrvn>
hcarty: then you get problems when you need both.
<hcarty>
mrvn: I misunderstood then. I thought the goal was to be able to switch between the two relatively transparently.
<mrvn>
hcarty: no. SHA uses strings. I want Bigarrays. That completly changes the signature so you can't just switch.
<mrvn>
But nothing says you won't need to compute a shasum of both strings and bigarrays in an app.
<mrvn>
In /usr/lib/ocaml/METAS/META.unix you have archive(byte) and archive(byte,mt_vm). Where does the mt_vm come from? Is that built-in to the compiler or does it somehow get that from the META.threads?
<hcarty>
thelema: I haven't tested it extensively though, so I don't know what other implications it has
<jm_ocaml>
I am looking for an approximate solution to the expression problem in OCaml. I say approximate because I am willing to trade re-usability for a reduction in complexity.
<jm_ocaml>
The most elegant solution I have seen is to use polymorphic variants (Code reuse through polymorphic variants, Garrigue). However, I have never used polymorphic variants in a real project. Anything I should be aware of?
<adrien>
typos :P
<hcarty>
jm_ocaml: The types and type errors can become huge and complex without manual annotations.
<adrien>
they can appear quite late in the code too
<jm_ocaml>
Ok, that's bad news since I am dealing with data types (ASTs for different IRs) of considerable size.
<adrien>
flux: oh, btw, quite a long time ago, we talked about gcc-xml: one drawback is that it's on gcc-3.x, not 4, that's what put me off iirc
<adrien>
(and xml =) )
<jm_ocaml>
Right, next option: Data types à la carte, Wouter Swierstra. Very elegant solution but unfortunately I don't know enough Haskell to see how cleanly the code would map to OCaml. Any opinions? Or alternative approaches?
alexyk has quit [Ping timeout: 260 seconds]
ulfdoz has quit [Ping timeout: 255 seconds]
ttamttam has quit [Quit: Leaving.]
edwin has quit [Remote host closed the connection]
ymasory has joined #ocaml
<ymasory>
what are types of the form '_a called? "unknown types"?
<jonafan>
they're called sad types
<ymasory>
jonafan: that a joke?
<jonafan>
well, i'm not sure it qualifies as a joke, but they're definitely not actually called sad types
<ezyang>
Maybe monomorphic types?
hcarty has quit [Ping timeout: 265 seconds]
strangy has joined #ocaml
<ymasory>
what exactly is meant by "function applications are not polymorphic". is he just trying to say that the result of a function application can't have a polymorphic type?
bbc has quit [Quit: ou alors je mets mes derniers mots comme ça]
<ezyang>
where is this from?
<ymasory>
introduction to ocaml page 49
<ymasory>
when talking about eta expansion
<ezyang>
oh.
<ezyang>
Perhaps the easiest way to think about this is that "reference" types (i.e. things involving ref and := ) must be monomorphic: they can have no polymorphism.
<ymasory>
haven't gotten to ref and :=
<ymasory>
:(
<ezyang>
Hmm, then the reason why '_a is necessary won't be very clear.
<ezyang>
You can ignore it for now.
Yoric has quit [Quit: Yoric]
<ymasory>
sounds good, thanks
oriba has joined #ocaml
jm_ocaml has quit [Remote host closed the connection]
ikaros has quit [Quit: Leave the magic to Houdini]