jderque has quit [Read error: 113 (No route to host)]
Morphous has quit [Read error: 110 (Connection timed out)]
evn_ has joined #ocaml
evn_ has quit [Client Quit]
<letrec>
Hi?
<bluestorm>
dont ask to ask :-'
brooksbp has left #ocaml []
<letrec>
:) wasn't sure the channel was still inhabited. My question: assume I have a module A which depends on B. I wrote module A = struct include B ... end. I can use the stuff with ocaml, but how to compile with ocamlc? I'm reading the doc to find out but any help would be appreciated.
<bluestorm>
hm
<bluestorm>
ocamlc b.ml a.ml ?
<bluestorm>
if you compiled b to a .cmo first (ocamlc -c b.ml), you can use ocamlc b.cmo a.ml instead
<bluestorm>
besides, .cmo can be used in the toplevel too
<bluestorm>
ocaml b.cmo will make the B module accesible from the toplevel ( module B = B;; will show you B's interface )
<letrec>
I got 'Unbound module B' ?
<bluestorm>
hm, and the order is meaningful : is A depends on B, ocamlc a.ml b.ml won't work
<bluestorm>
letrec: what's your compile command like ?
<letrec>
Is 'include B' sufficient in a.ml?
<bluestorm>
what do you think "include" will do ?
<bluestorm>
you don't have to do anything to have a module accessible from a file
<bluestorm>
'include' has a specific meaning (import all of B public definitions as if they were part of A)
<bluestorm>
a bit like "inherit" in object oriented programming
<letrec>
Oh, ok, then how do I make sure in a.ml I don't need a prefix to access objects in B?
<bluestorm>
"open"
<bluestorm>
but if you've got "Unbound module B", it's not an 'open' problem
<bluestorm>
letrec: and you should be careful with 'open', as it may clutter the namespace
<bluestorm>
(and silently override some older bindings)
<letrec>
Arghh. Ok, in b.ml, I have module B = struct ... end. In a.ml I have module A = struct open B ...stuff using object from B... end. How should I compile that?
<letrec>
Thanks for your patience btw :)
<bluestorm>
hm
<thelema>
letrec: if you write "module B = struct ... end" in b.ml, you've defined a submodule of B : B.B
<bluestorm>
so the B module you're referring to
<bluestorm>
is B.B ::p
<bluestorm>
seems a bit awkard
<bluestorm>
but ocamlc b.ml a.ml -o exec should still work, if your code is correct
<bluestorm>
hmm
<bluestorm>
you've got B.B and A.A
<letrec>
Ok, I should not define a module for B then. But I wanted to do it to have a clean namespace.
<bluestorm>
hmm
<bluestorm>
all of b.ml definitions are automatically seen as inside a B module from the outside
<letrec>
Yes, but I wanted the module name to be different from the file name.
<bluestorm>
you can define modules inside B
<letrec>
So I open FileB.ModuleB ?
<bluestorm>
hm
<bluestorm>
if you want to
<bluestorm>
but if this is only a name question
<bluestorm>
why don't you change the file name ?
<bluestorm>
(you could also do a module alias : module Beautiful_name = B , would work in the other files)
<letrec>
Ok, I will do that. But aesthetically speaking I would have liked to have the file and modules name separate :) THANK!
<bluestorm>
i have to admit that, not being a native english speaker, i may use that word a bit too lightly (movies don't help)
<letrec>
bluestorm: nice statement, very persuasive! :)
<evn_>
i think dhh would agree with bluestorm
TheLittlePrince has quit [Client Quit]
<RobertFischer>
evn_: DHH? Mr. Beautiful Code himself?
<RobertFischer>
I doubt he'd say anything like "fuck aestheticism".
<RobertFischer>
:P
<evn_>
he's very practical
<evn_>
rails is all about not having to configure extra crap just because
<bluestorm>
actually i think a certain dose of beauty is necessary
|Catch22| has joined #ocaml
<bluestorm>
but defining an unnecessary module just because the filename don't fit is conceptually ugly
<RobertFischer>
Yeah. And certainly not The Rails Way To Do It.
<RobertFischer>
Although I've been hanging out in JavaLand for a long, long time.
<RobertFischer>
So the idea of a file name not corresponding to its contents shakes the very core of my being.
<letrec>
I thought that redefining a module at the top-level would overwrite the default module name taken out of the file name. Btw, if the filename is git_tree.ml, the module name is Git_tree. The needed upper-case is ugly for me (even though I know most people don't care). Anyway.
<bluestorm>
you can use Git_tree.ml if you want :-'
<bluestorm>
(*this* is what i find a little disturbing)
<bluestorm>
but letrec
<bluestorm>
the beautiful thing you haven't seen yet
<bluestorm>
is that there is no "toplevel"
<bluestorm>
there are just items in an (implicit) module declaration
<bluestorm>
ocaml "toplevel phrases" are "structure items", and interfaces phrases are "signature items"
<bluestorm>
wich i think is a very homogeneous and nice thing, worth a dozen of naming considerations :-'
<bluestorm>
hm
<bluestorm>
i think caml hump feeds should come with the program description
<bluestorm>
would be nicer in the aggregator
<letrec>
Which doesn't enforce encapsulation as a default behaviour then. But anyway, I'm learning Ocaml, and you should not take my comments as a judgement, just my 2 cents. I think it is a very fine language.
<bluestorm>
"encapsulation" ?
<bluestorm>
i don't really see what's the difference in encapsulation between explicit and implicit module declaration
<bluestorm>
(as long as you know it's there)
<bluestorm>
(actually i never know what people mean by "encapsulation")
<thelema>
bluestorm: when I hear encapsulation, I think "hiding the implementation"
<bluestorm>
hm
<bluestorm>
then it seems the .mli do a quite good job
<thelema>
bluestorm: I think letrec doesn't know about mli yet
<bluestorm>
aha !
<bluestorm>
letrec: don't you know about mli ?
Linktim has joined #ocaml
<letrec>
bluestorm: I've only heard that's an interface file. I agree that I must have a look at this before to issue any judgement on ocaml modules and namespaces...
<bluestorm>
hm
<bluestorm>
do you know about module signatures, more generally ?
<bluestorm>
a .mli is just a module signature
<bluestorm>
and it's the signature associated to the implicit .ml module
<bluestorm>
s/just/only/
<RobertFischer>
letrec: Before you "past judgement", you should also take a look at Functors.
<bluestorm>
if by "encapsulation" you mean "information hiding", then they may well be what you're looking for
<bluestorm>
basically, everything you don't include in the .mli is "private" to the module
<bluestorm>
and you can restrict types, and even make them abstract
Linktim_ has joined #ocaml
<bluestorm>
(meaning that apart from the public values of the module, nothing can construct values of that type, as the actual implementation is unknown)
RobertFischer has left #ocaml []
<letrec>
bluestorm: yes, that's exactly what I'm looking for..
<bluestorm>
as a bonus, there is a normalized format for documentation inside .mli
<bluestorm>
and then you can use ocamldoc to generate nice html/latex documents from them
<bluestorm>
(aha and there is a .dot output, wich is great for visualizing modules dependencies, at the module or type level)
<letrec>
RobertFischer: I don't intended to make any general judgment as I'm not an academic, a personnal one will be sufficient.
Linktim has quit [Read error: 104 (Connection reset by peer)]
<bluestorm>
hm
<bluestorm>
do you know about tab-completion in irc clients ? :-'
<bluestorm>
(might look like a stupid question, but sometimes people don't, and typing the loong name of an absent person is one of the symptoms)
Linktim- has joined #ocaml
<letrec>
I don't. I do copy/paste :)
<letrec>
Nice feature indeed.
<bluestorm>
unix peoples get used to tab-completion quite everywhere
<flux>
I had a perl script for irssi that sortof implemented emacs' dynamic completion, but it wasn't very useful
<flux>
more useful with programming and long variable names ;)
<bluestorm>
hm
<bluestorm>
wouldn't erc + dabbrev do the thing ?
<flux>
sure, if you want to switch your client
Linktim_ has quit [Read error: 110 (Connection timed out)]
Linktim_ has joined #ocaml
brooksbp has joined #ocaml
Linktim- has quit [Read error: 110 (Connection timed out)]
tjoad94 has joined #ocaml
tjoad94 has quit [Client Quit]
tjoad94 has joined #ocaml
Waleee has joined #ocaml
bongy has joined #ocaml
brooksbp has quit []
uuuppz has joined #ocaml
Yoric[DT] has joined #ocaml
<Yoric[DT]>
'evening
<tjoad94>
Hello
<tjoad94>
Do you use ocaml?
<flux>
..
<thelema>
jto: I do
<thelema>
err tjoad94
<tjoad94>
Do you find it reliable? I've never used in a production environment, for example, just as a hobby. It's awesomely fast.
<flux>
I've had zero reliability issues - other than due to my own bugs, which unfortunately are still possible even with its type system :)
brooksbp has joined #ocaml
brooksbp has quit [Client Quit]
jonathanv has joined #ocaml
<thelema>
I find it reliable.
* Yoric[DT]
had his first segmentation fault yesterday.
<Yoric[DT]>
And I've been using it for some time.
<Yoric[DT]>
Plus I was trying to extend the type system :)
<Yoric[DT]>
So, yeah, it's very reliable.
<ita>
Yoric[DT]: segmentation fault? how did you manage to do that? :-)
<flux>
Obj.magic, hmm?-)
<flux>
I've had segmentation faults too, but it's always been when interfacing with C libraries
<flux>
last time, sadly, with my own bindings
<tjoad94>
That's great news.
<letrec>
Say I have a type t = Const of int | Temp of string. I want to write a function that basically handle one part of the sum. So I write let f = function Temp s -> ... But the compiler complains as the pattern is not fully macthed. How can I overcome that (removed the warning, which makes sense as I'll always going to use the function on Temp of string argument).
<letrec>
s/handle/handles/
jonafan has quit [Read error: 110 (Connection timed out)]
<letrec>
s/removed/remove/
<thelema>
letrec: why not have the function just take the string?
<thelema>
and in the places you call it, do the matching.
<thelema>
letrec: the other solution involves a " | _ -> assert false" match case
<flux>
well, then there are polymorphic variants, but maybe they are overkill
<flux>
and then there is bluestorm's refutable pattern matching extension
<thelema>
flux: refutable seems a match for guarded patterns, not for normal variant matching.
<bluestorm>
letrec: in most cases it would be saner to define your function on string
<letrec>
thelema: well, in real life the string is a tuple, so I'd write a function that takes a tuple in input. Yes, why not indeed. Thanks.
<bluestorm>
because anyway, you can only use it when you're sure that it is not a Const
<bluestorm>
meaning that you have pattern matched anyway
<bluestorm>
so at that place you could've extracted the string
<flux>
it's almost akin to dynamic typing to do the function that way (check tag first, fail if mismatch) ;)
<bluestorm>
imho variants are a specific kind of dynamic typing
<bluestorm>
they defer "typing" choices to runtime
<letrec>
Can I write let f (a,b,c) =... ? (Input is a tuple)
<flux>
letrec, yes
<letrec>
flux: ok, thx
<flux>
bluestorm, btw, since you're so on fire with camlp4, when are you going to write that scheme/lisp (cut (bar _ 42)) extension?-)
<bluestorm>
hm
<bluestorm>
meaning (fun x -> bar x 42) ?
<flux>
yes
<bluestorm>
how do you handle multiple _ ?
<flux>
left to right
<flux>
but even a single _ would be ok for a first version
<bluestorm>
hmm
<flux>
I think the last time we discussed this there was the issue of finding a short syntax for this
<flux>
but iirc there was a solution..
<bluestorm>
dinner time anyway :]
<bluestorm>
(if you remember the solution, i'd be interested)
<flux>
I don't remember if it was any good, but I'll grep the logs :)
brooksbp has joined #ocaml
jonafan has joined #ocaml
<flux>
for some reason I can't find it; I'm sure I mentioned the word 'cut' the previous time
<flux>
however, I think this may have been the solution, but I'm not sure if it's a good one: (\foo _ bar)
<thelema>
variant tagging might be nice as a function instead of a language construct, except the casing rules would be hard to apply. (not that they're necessary, or even good)
<thelema>
but (cut (TInput _)) has 4 less characters than (fun i -> TInput i), and the second seems to strongly win on clarity for me
<flux>
the (cut) examples were scheme
<flux>
or lisp, wherever the idea comes from
<flux>
obviously a succinct syntax would need to be found to make it wortwhile
<flux>
I suggested (\ ) earlier, perhaps \() would btw be better
<flux>
thelema, and \(_.nn_a) with the extension
<flux>
and \(max _ _.dn_id), although that already assumes the support for multiple _'s
<flux>
there is the thing about clarity, though, as you say. I think it might be just the infamiliarity that makes it feel unclear, not the concept itself
ygrek has quit [Remote closed the connection]
<flux>
in the syntactical level I don't feel it's much more complicated concept than currying is
pec1 has joined #ocaml
<flux>
however the thing might be, it's difficult to say without trying it :)
marmottine has joined #ocaml
<bluestorm>
thelema:
<bluestorm>
by variant tagging you mean
<bluestorm>
TInput : 'a -> 'a input ?
<bluestorm>
if that's so, i've got an extension for you :-'
jlouis_ has joined #ocaml
<flux>
actually (maybe?) even a better alternative for \(bar _ baz): $(bar $1 baz)
<flux>
or % if $ is difficult
<flux>
but now I'm off to sleep, good night
<bluestorm>
better because of the free order ?
<flux>
yes
<flux>
and less _, which you see sort of plenty already
<bluestorm>
hm
<bluestorm>
_ is quite nice actually
<bluestorm>
as hm
<flux>
well, it's something to think about
<flux>
I'm off, happy hacking ;)
<bluestorm>
but i agree that the numbering scheme is cool
<bluestorm>
good night :p
<flux>
_1 maybe?
<bluestorm>
_1 is a valid identifier iirc
<flux>
but a rare one
dwmw2_gone is now known as dwmw2_GVA
<Yoric[DT]>
ita: more precisely, a combination of Obj.magic, phantom types and uncaught exceptions.
<bluestorm>
thelema: btw, iirc you launched a debate some time ago about the composition/application operators
<bluestorm>
for a little project of mine i've tried to use them
<bluestorm>
it's been quite successful so far
<bluestorm>
(i use both (fx, fgx) in both directions (xf, xgf))
jlouis has quit [Read error: 110 (Connection timed out)]
<thelema>
I'm glad that debate helped you.
<Yoric[DT]>
ita: plus I was trying to reproduce another bug :)
<thelema>
bluestorm: by variant tagging, I refer to how the name of a variant can't be used as a function (Tag) != (fun x -> Tag x)
<bluestorm>
yes
<bluestorm>
i've got an extension that automatically (if you say so in the type declaration) generate a _Tag function
tjoad94 has quit []
<thelema>
I wonder if I should start collecting these non-invasive syntax extensions...
<thelema>
for use in a 'best-of' camlp4 extension
<bluestorm>
there could have been a thread on the mailing-list on that topic
<bluestorm>
degenerated in a big debate around the ultimate community package management, again
<bluestorm>
s/around/about/
<bluestorm>
but anyway thelema
<bluestorm>
i think we can wait for the ocamlforge to be set up
* thelema
doesn't have use for big debates, only little ones.
<bluestorm>
and then try to put some extensions in a common vcs repository
<bluestorm>
trying to keep them coherent, documented, and camlp4 3.10 (and more) ready
marmottine has quit ["Quitte"]
<Yoric[DT]>
thelema: but yeah, please go ahead.
<thelema>
Yoric[DT]: you think a collection of quality camlp4 scripts would have value?
<bluestorm>
for now it seems that the only user of a camlp4 is the one that wrote it
<bluestorm>
(except from a few notable exceptions as ulex, where the camlp4 is part of a big package that people want)
<thelema>
with few exceptions
<bluestorm>
hm
<bluestorm>
and pa_openin maybe
<bluestorm>
(i should submit the free-variable-free patch, btw :p)
<bluestorm>
i'm not sure the ocaml community really *want* those tiny camlp4 scripts
<bluestorm>
but for now i don't know if they don't want, or if it's only that the distribution is awful (plus the camlp4/camlp5 balkanisation)
neale has joined #ocaml
<bluestorm>
so i think that a common repository (as a way to enforce coherence) would be handy
<neale>
I'm writing a C interface to Linux's epoll(2) and am faced with the prospect of storing an arbitraty value.
<neale>
I need to store away the value somewhere, and then somehow pass it back in a different call.
<neale>
I'm worried that it might get garbage-collected.
<neale>
Any suggestions?
<ita>
isnt there something for marking data as "in use" ?
<neale>
that'd be perfect
<pango>
if it's not allocated in OCaml's gc, there's no way it'll be collected
<pango>
s/gc/heap/
<thelema>
i.e. if your C code allocates the data, ocaml won't touch it.
<thelema>
if your C code uses the ocaml macros to create the value in the ocaml heap, you'll have to work to keep it.
<bluestorm>
hm neale
<bluestorm>
i don't know if it's exactly related
<neale>
the value is to be passed in from OCaml
<bluestorm>
but flux has been writing a binding for libev
<neale>
I won't be allocating it
<neale>
oh yeah?
<bluestorm>
(libevent, but faster)
<neale>
I wasn't totally satisfied with the libevent binding, it seemed overly-complicated
<thelema>
neale: if it's passed in from ocaml, and you want to hide it in the C side: 1) copy the value, or 2) register it as a root (inefficient if you do this lots)