<petter_>
It's just a quick hack, don't know if it breaks something
<Snark>
petter_: function composition?
<petter_>
Snark: yes, usually "."
<Snark>
petter_: how do you compose functions of several variables in a generic way?
<mflux>
petter_, I've used let (@.) a b c = a (b c)
<Snark>
which works ok for single variable functions, indeed
<mflux>
and very often, with currying et al, it's sufficient
<mflux>
of course when it isn't you need to write a lambda function
<petter_>
Snark: haven't thought about that
<petter_>
mflux: ahh, nice
<petter_>
Snark: I imagine you would use it mostly with single argument functions
<mflux>
petter_, I've also defined let @@ a b = a b
<mflux>
(@@) of course
<petter_>
mflux: an "apply" operator?
<mflux>
I'm not sure if that's what it's called, but yes
<mflux>
to reduce some parenthesis
<petter_>
yes
<Snark>
let (@#) a b = a#b ?
<Snark>
*g*
<petter_>
hmmm, I think in my syntax extension, "." accidentially became "apply" as well...
<petter_>
because you can write "f . 4" and it becomes "f 4"
<petter_>
...or not, think the associativity for "apply" is different
whee has joined #ocaml
HoneyBee2 has joined #ocaml
HoneyBee2 is now known as Oatmeat
batkins_ has joined #ocaml
r2d4 has joined #ocaml
batkins_ has quit [Remote closed the connection]
batkins_ has joined #ocaml
<r2d4>
I would like to create a union and pass it to a function and return based on the data type. How do I do that?
<r2d4>
never mind. figured that.
<petter_>
explain more exactly what you want to do
Q_ has joined #ocaml
<Q_>
I saw this error message in a buildd log for debian amd64: pcre_stubs.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
<Q_>
And I saw thig in the changelog of the last upload:
<Q_>
* debian/patches/asmcomp_amd64_emit.mlp.dpatch: patch from upstream bugfix
<Q_>
branch by Xavier Leroy to fix code generation on amd64 (reported by John
<Q_>
Skaller).
<Q_>
Are those related?
r2d4 has quit ["Chatzilla 0.9.68a [Firefox 1.0.4/20050511]"]
<petter_>
no idea, maybe look in the debian bugtracking-something?
<Q_>
I guess not.
<Q_>
I had a hard time finding the bug in the ocaml bug track system, but seems to be unrelated.
Tipsy2 has joined #ocaml
<Q_>
And just looks like a bug in the package I'm trying to build anyway.