kaustuv changed the topic of #ocaml to: Discussions about the OCaml programming language | http://caml.inria.fr/ | 3.11.1 out now! Get yours from http://caml.inria.fr/ocaml/release.html
mlak has left #ocaml []
ulfdoz_ has joined #ocaml
erickt1 is now known as erickt
julm has quit [Remote closed the connection]
julm has joined #ocaml
ulfdoz has quit [Read error: 110 (Connection timed out)]
ulfdoz_ is now known as ulfdoz
Amorphous has quit [Read error: 110 (Connection timed out)]
Amorphous has joined #ocaml
travisbrady has quit []
lutter1 has joined #ocaml
lutter has quit [Read error: 60 (Operation timed out)]
verte has joined #ocaml
ulfdoz has quit [Read error: 110 (Connection timed out)]
ccasin has joined #ocaml
ccasin has quit ["Leaving"]
mlak has joined #ocaml
mlak has left #ocaml []
Mannerisky has quit [Read error: 113 (No route to host)]
oct_ has joined #ocaml
bluestorm has joined #ocaml
Mannerisky has joined #ocaml
oct_ has quit [Read error: 104 (Connection reset by peer)]
angerman has joined #ocaml
smimou has joined #ocaml
Yoric[DT] has joined #ocaml
tab has quit [hubbard.freenode.net irc.freenode.net]
qwr has quit [hubbard.freenode.net irc.freenode.net]
noj has quit [hubbard.freenode.net irc.freenode.net]
Jedai has joined #ocaml
qwr has joined #ocaml
tab has joined #ocaml
noj has joined #ocaml
verte_ has joined #ocaml
verte has quit [Nick collision from services.]
_zack has joined #ocaml
verte_ is now known as verte
Mannerisky has quit [Read error: 104 (Connection reset by peer)]
Mannerisky has joined #ocaml
Demitar has quit [Remote closed the connection]
hkBst has joined #ocaml
dzlk has joined #ocaml
dzlk has left #ocaml []
Lomono has joined #ocaml
verte has quit [Read error: 60 (Operation timed out)]
verte has joined #ocaml
bluestorm has quit [Remote closed the connection]
yziquel has quit [Ping timeout: 180 seconds]
Yoric[DT] has quit ["Ex-Chat"]
bluestorm has joined #ocaml
acatout has quit [Read error: 60 (Operation timed out)]
marteo has joined #ocaml
yziquel has joined #ocaml
bluestorm has quit ["Leaving"]
verte has quit [Read error: 110 (Connection timed out)]
verte has joined #ocaml
yziquel has quit [Ping timeout: 180 seconds]
verte has quit [Read error: 110 (Connection timed out)]
verte has joined #ocaml
marteo has quit [Read error: 110 (Connection timed out)]
|Jedai| has joined #ocaml
marteo has joined #ocaml
acatout has joined #ocaml
Demitar has joined #ocaml
Jedai has quit [Read error: 110 (Connection timed out)]
julm has quit [Read error: 110 (Connection timed out)]
julm has joined #ocaml
angerman has quit []
_andre has joined #ocaml
julm has quit [Read error: 110 (Connection timed out)]
julm has joined #ocaml
marteo has quit [Read error: 110 (Connection timed out)]
marteo has joined #ocaml
smimou has quit ["bli"]
angerman has joined #ocaml
rwmjones is now known as rwmjones-lunch
julm has quit [Read error: 110 (Connection timed out)]
julm has joined #ocaml
angerman has quit []
bombshelter13_ has joined #ocaml
willb has joined #ocaml
jimmyb2187 has left #ocaml []
jimmyb2187 has joined #ocaml
rwmjones-lunch is now known as rwmjones
Submarine has joined #ocaml
angerman has joined #ocaml
angerman_ has joined #ocaml
willb has quit [Read error: 110 (Connection timed out)]
sgnb` has quit [Read error: 104 (Connection reset by peer)]
sgnb` has joined #ocaml
Olf has joined #ocaml
angerman has quit [Nick collision from services.]
angerman_ is now known as angerman
brendan has quit [Read error: 113 (No route to host)]
verte has quit ["~~~ Crash in JIT!"]
willb has joined #ocaml
julm has quit [Read error: 110 (Connection timed out)]
smimou has joined #ocaml
r0bby has quit [Connection timed out]
julm has joined #ocaml
slash_ has joined #ocaml
travisbrady has joined #ocaml
munga has joined #ocaml
<munga> hello. I'm compiling my ocaml bindings to minisat with ocamlfind ocamlc -linkpkg -custom -cclib -lstdc++ -ccopt -Lminisat -cclib -lminisat minisat.cmo solver.cmo libminisat_stubs.a -o solver.byte but I get this error
<munga> libminisat_stubs.a(libminisat_stubs.o): In function `minisat_new':
<munga> libminisat_stubs.c:(.text+0x463): undefined reference to `caml_alloc_small(unsigned long, unsigned int)'
<munga> collect2: ld returned 1 exit status
<munga> ... what am I missing here ?
<munga> the only 'strange' thing is that I'm creating bindings for a c++ library ... do I have to add an ocaml specific library by hand ?
<smimou> munga: are you using the extern "C" trick ?
<munga> you mean ...
<munga> extern "C" value minisat_new(value unit) {
<munga> ...
<munga> ?
<smimou> yes
<smimou> from what I remember this was the only subtilety when binding C++ libs
<munga> the other subtilety is to add -cclib -lstdc++
<munga> but know I'm wondering if I have to link some other ocaml library
<smimou> I didn't have to use -lstdc++ if I remember correctly
_zack has quit ["Leaving."]
<munga> uhmmm yes, you are correct ...
<munga> I'll have a look
<munga> !!! I didn't wrap the ocaml includes in extern "C" ! now it work. thanks :)
amuck_ has joined #ocaml
Narrenschiff has joined #ocaml
angerman has quit []
mlak has joined #ocaml
r0bby has joined #ocaml
sramsay has joined #ocaml
ulfdoz has joined #ocaml
franksalim has joined #ocaml
willb has quit [Read error: 110 (Connection timed out)]
Narrenschiff has quit [Read error: 60 (Operation timed out)]
aldebrn has quit [Read error: 110 (Connection timed out)]
willb has joined #ocaml
angerman has joined #ocaml
julm has quit [Read error: 110 (Connection timed out)]
julm has joined #ocaml
Submarine has quit [Read error: 110 (Connection timed out)]
Submarine has joined #ocaml
Mannerisky has left #ocaml []
bluestorm has joined #ocaml
peddie has quit [Read error: 110 (Connection timed out)]
<bluestorm> am I coming in the bad time period, or has the chan been mostly dead for a few months ?
_andre has quit ["Lost terminal"]
<marteo> bluestorm, dead since 18h50
<Camarade_Tux> bluestorm: since the end/middle of last week
<Camarade_Tux> I believe it's (partly) because of the holidays
<bluestorm> ok
<bluestorm> I'm a bit ashamed than, due to increased workload at school (and general life), I have barely been there this year
<kaustuv> It's too nice outside to code
<Camarade_Tux> well, it varies for everybody
julm has quit [Read error: 110 (Connection timed out)]
julm has joined #ocaml
Elive_user7_fr has joined #ocaml
marteo has quit [Read error: 110 (Connection timed out)]
Elive_user7_fr is now known as marteo
ulfdoz has quit [Read error: 110 (Connection timed out)]
bombshelter13_ has quit []
chupush has joined #ocaml
brendan has joined #ocaml
<brendan> is there any way to do something like forward declarations in a module?
<kaustuv> "forward declarations"?
<kaustuv> You can do mutual recursion using and: let rec f x = g x and g x = f x ;;
<brendan> if I'm doing a module definition I need to put 'and' between each function?
<kaustuv> Just between the ones that are mutually recursive
<kaustuv> Though you are free to put in more if you wish
<brendan> hmm. better than nothing, but not very pretty
hkBst has quit [Read error: 104 (Connection reset by peer)]
<kaustuv> On the contrary, it's better to be explicit about it than to have inadvertent mutual recursion, which will often only be detected at runtime
<Camarade_Tux> I find it catches a few design errors too
<brendan> forward declarations are also explicity. I tentatively agree that making everything rec is a bad idea
<kaustuv> no, with what you're calling "forward declaration", you simply say that everything that follows the declarations can be mutually recursive. You can't *syntactically* define two separate strongly connected recursive components.
smimou has quit ["bli"]
<brendan> that wouldn't have to be the case. the function being forward-referenced could be only allowed to see what was above the forward declaration, for instance
<kaustuv> How would you define the f and g example I said earlier then?
<brendan> what? that's deliberate mutual recursion. I was proposing a way to avoid accidental mutual recursion
sramsay has quit ["Leaving"]
<brendan> honestly I suspect the problem of accidental mutual recursion may be overstated. It doesn't seem to happen often in other languages
<kaustuv> I doubt you can back that up with data, but you are entitled to your opinions.
<brendan> I'd be happy to see data contradicting it :)
<kaustuv> Well, it's one of my biggest issues with Haskell, for one. The fact that everything is recursive with everything else in a module has bitten me several times. And I like saying thins like: let x = x + 1
<brendan> I also like let x = x + 1, but that's not really _mutual_ recursion is it?
<kaustuv> Sure it is. Think: let (x, y) = (y, x)
<brendan> hmm, maybe. But that seems like a perverse thing to want to do
_Jedai_ has joined #ocaml
willb has quit [Read error: 110 (Connection timed out)]
<kaustuv> It seems perverted because it's a contrived example for the purposes of argument, but the general problem of lack of explicit shadowing in Haskell is something I miss greatly.
<kaustuv> You might argue that there is a happy middle ground between explicit always and implicit always, and I'll agree, even though I myself subscribe to the explicit always school of thought
<brendan> does haskell have any kind of 'notrec' keyword?
<kaustuv> Not in Haskell 98, but I'm sure there's some magic GHC flag or extension
<brendan> I don't really mind explicit declaration of mutual recursion, I just wish there were also a way to do a non-mutually-recursive forward declaration, so I could structure my module better.
<brendan> or some way in general to separate declaration from definition
<kaustuv> When you say declaration, do you mean declaring the types of things? If so, you can write a module type or the .mli file
<chupush> took me a while, but -XNoRelaxedPolyRec is the only thing I could find thus far in the GHC manual
<brendan> no, I mean I want to put the definitions of the api of the module (stuff that would go into the signature) at the bottom, and helpers at the top, and maybe have a helper be able to call one of the public methods
<chupush> and it's not *really* what was requested
marteo has quit ["Debian GNU/Hurd is Good."]
<brendan> like if I have a finalizer that I want to call a public close method
<brendan> google doesn't like -XNoRelaxedPolyRec
<kaustuv> Is there any particular reason why you don't want to move the definition of the close method above its uses?
<chupush> that's GHC anyway, nothing to do with O'Caml; just a search on kaustuv's point, 'tis all
<brendan> only cosmetic -- I just like to put the public API all together in one place
<brendan> ideally in the same order that the functions appear in the signature
<kaustuv> Can't you have a trivial definition in the "API" area such as: let close = close
<kaustuv> or let public_close = private_close
<brendan> yeah, I could do something like that. I probably will. it's just not very pretty imho
|Jedai| has quit [Read error: 110 (Connection timed out)]
<kaustuv> I've often written functions such as:
<kaustuv> let f, g, h =
<kaustuv> let rec inner_f = ... and inner_g = ... and inner_h = ... in
<kaustuv> inner_f, inner_g, inner_h
<kaustuv> Well, not really "often". More "occasionally".
julm has quit [Excess Flood]
julm has joined #ocaml
angerman has quit []
chupush has quit [Client Quit]
<brendan> is that just to draw a clearer line between the mutually recursive stuff and everything else?
amuck_ has quit []
<kaustuv> Usually it's when I want to encapsulate some state that should be visible only to the inner functions
<brendan> ah, sure
<kaustuv> Don't ever do this, but: http://ocaml.pastebin.com/d21325ec7
<brendan> hehe, much prettier ;)
<kaustuv> actually, I think a safe version of this can be hacked together with Camlp4 pretty easily.
seafood has joined #ocaml
<bluestorm> brendan: the forward declaration problem is not simple
<bluestorm> i have made attempts with a "where" syntax extension
<bluestorm> eg. let g = .... where val f = ...
<bluestorm> wich allows a reasonable amout of forward declaration
<bluestorm> it would be nicer to specify some sort of prototype beforehand and define f anywhere
travisbrady has quit []
<bluestorm> but that's unclear what that would mean in presence of multiple declarations of f
<brendan> 'where' is like haskell's?
<bluestorm> yes
<bluestorm> except there is "where .." or "where let ..." for local let, and "where val .." for structure items
<bluestorm> but I'm not happy with the current state of the syntax extension
<bluestorm> (tricky precedence decisions to make)
<brendan> I hadn't considered forward declarations followed by multiple definitions, but conservatively I'd say that deserves an error message
<bluestorm> brendan: I think the best way, semantically speaking, to have forward declarations right now is using functors
<kaustuv> IMHO, "where" is a misfeature
<bluestorm> module Outer (Inner : sig val f ...) = struct let g .... end include Outer (struct let f ... )
<bluestorm> that's plain caml, doing the right thing, and I think it's the best solution right now
<bluestorm> if you find it syntaxically heavy, we could do a camlp4 extension for that (syntaxic sugar)
<bluestorm> and brendan, your "error message" idea does not looks like the right solution
<brendan> probably it's not very ocaml
<bluestorm> I mean you won't get anything clean if you keep adding special behaviour for corner cases
<brendan> yeah
<bluestorm> what do you think of the functor thing ?
<brendan> I need to think longer about it. I'm still an ocaml newbie
<kaustuv> The functor thing adds some (admittedly trivial) overhead
<brendan> seems reasonable if wordy
<bluestorm> well, updating ocamldefun is still the top one of my "Imaginary OCaml Todo List"
<bluestorm> kaustuv: a problem with your Obj solution is that it only works if nothing actually evaluates f
<bluestorm> (only function definitions)
<kaustuv> Sure. And I wouldn't glorify it with the description "solution".
<bluestorm> hm and what's the problem with "where" ? I find it nice style when used appropriately
<bluestorm> typically I find the "auxiliary tail-rec function then use" pattern benefit greatly of a where
<kaustuv> I like looking in only one direction when I see a symbol I don't recognize.
<bluestorm> let fac n = fac 1 n where rec fac acc = function 0 -> acc | n -> fac (n * acc) (n - 1)
<bluestorm> brendan: if you're an OCaml beginner
<bluestorm> I think you should begin with accepting the usual ocaml way
<bluestorm> with is to think that inside module boundaries, declaration order is constrained the usual way
<bluestorm> and that real flexibility comes from publishing the module interface
<brendan> my first stupid idea was that the signature would act like a forward declaration
<kaustuv> That's beginner level? I would have thought you'd have to be quite an accomplished ocaml hacker before you saw the default way of doing things as the best solution
<bluestorm> (eg. if you have so many auxiliar functions that hinder the main logic of your code, put them in another module)
<brendan> it was mostly a cosmetic objection while I was writing a finalizer
<bluestorm> hm
<bluestorm> maybe if you're a beginner you should try not to use Ocaml OOP
<brendan> I'm not.
<bluestorm> (but i'm not sure you're really a beginner in the "newbie" sense)
<bluestorm> oh
<bluestorm> I misunderstood your "public method" thing then
<brendan> I just meant a function I defined in a module signature
<brendan> er declared
<kaustuv> surprisingly, objects would be one way to do forward referencing cleanly.
<bluestorm> open recursion
<bluestorm> you could also use a recursive module :-)
<brendan> yep, that does look fine
<kaustuv> if you use immediate objects (like in the example) instead of classes, you prevent inheritance and therefore have only closed recursion. Unfortunately, methods are still indirectly called (I think), adding some overhead.
<bluestorm> I prefer the functor solution as it makes for a clean separation, and you have the interface of the forward-defined values
<kaustuv> I don't seriously advocate this, if it wasn't clear.
<bluestorm> but in case were there is no clean separation between "the auxiliary part" and "the main part", a recursive solution such as an object or a recursive module could be easier to use
<kaustuv> Wow, methods are never inlined? That kills that idea right there.