seafood has quit [zelazny.freenode.net irc.freenode.net]
mattam has quit [zelazny.freenode.net irc.freenode.net]
dibblego has quit [zelazny.freenode.net irc.freenode.net]
mattam has joined #ocaml
SanguineV has joined #ocaml
<mrvn>
Maybe there should be an option for ocamlc/opt to generate a foo.h file with enum FooVariant { FOO = 0, BAR = 0, BAZ = 1 }; from type Foo = FOO | BAR of int | BAZ
<mrvn>
or #defines.
psnively has quit []
<SanguineV>
You want to define: 0:Foo 0:int->Foo 1:Foo ?
<mrvn>
Something so you can create a Foo in C and decode or encode it.
ulfdoz has quit [zelazny.freenode.net irc.freenode.net]
<mrvn>
SanguineV: Which leaves the problem of knowing what int/tag to use for each type. ocamlc/opt should have an option to export the values it uses into a header file for use in C.
<SanguineV>
The previous page has some info on how mlvalues are used in C. But I think a lot of it comes down to careful C programming as you can do things in C that ocaml objects to.
<mrvn>
still leaves you yourself to define the int/tag values. And if you then change the type in .ml without changing the .c file you get a total mess.
<SanguineV>
mlvalues.h doesn't have all the ones you need? (Admittedly custom types may be an issue, but I am not sure how easy/hard some simple script/code would be to work it out...)
<mrvn>
how could it? The values are depending on what you declare in type FOO = ....
* SanguineV
ponders programming something to manipulate the code of your program...
<Smerdyakov>
SanguineV, it seems like you are really not reading what mrvn is writing....
<mrvn>
SanguineV: you only need to write a little and then you can let it write the rest itself.
<Smerdyakov>
Incidentally, my compiler handles this nicely, with predictable enum tags for datatypes in C. ;)
<mrvn>
predictable helps in now way. The problem is duplicating.
<mrvn>
Programming Rule 23: If you have the same information in two places one of them will differ.
Ched- has quit [Read error: 110 (Connection timed out)]
Proteus has quit [Read error: 110 (Connection timed out)]
<SanguineV>
So the solution is to use Smerdyakov's compiler and only ever create one instance of anything? :P
seafood has quit []
netx has joined #ocaml
sporkmonger has joined #ocaml
Proteus has joined #ocaml
Proteus has quit [No route to host]
Proteus has joined #ocaml
sporkmonger has quit []
Philonous1 has joined #ocaml
Philonous has quit [Connection timed out]
coucou747 has quit ["bye ca veut dire tchao en anglais"]
Asmadeus has joined #ocaml
Mr_Awesome has quit [Read error: 110 (Connection timed out)]
SanguineV has quit [""Managing students""]
coucou747 has joined #ocaml
Asmadeus has quit ["rebooting..."]
Asmadeus has joined #ocaml
Axioplase has joined #ocaml
jeddhaberstro has quit []
Snark has joined #ocaml
Mr_Awesome has joined #ocaml
ttamttam has joined #ocaml
ulfdoz has quit [Remote closed the connection]
Axioplase has quit ["leaving"]
code17 has joined #ocaml
ulfdoz has joined #ocaml
filp has joined #ocaml
filp has quit [Client Quit]
mishok13 has joined #ocaml
<Asmadeus>
Hum, I've got a bot on a shared server with multiple ips (i.e. interfaces eth0:1, eth0:2, etc), and I need to choose one of them - does anyone know how I can do that ? (It currently chooses the first one given on the route table, and I can't/don't want to edit it)
<Asmadeus>
I suspect it has to do with the integer you give when creating the socket, "protocol type", but I have no clue on what to put here, and it fails if I try to give a random number there anyway...
<Eridius>
Asmadeus: I don't know anything about OCaml networking, but "protocol type" doesn't mean interface
<Eridius>
can't you specify an IP to listen on?
<Eridius>
default for sockets is usually "0.0.0.0" which means all interfaces. But you can specify an IP and that means only use the interface with that IP
<Asmadeus>
Can I set one to listen and then connect to another addr ?
<Asmadeus>
s/listen/connect, since that's the fonction I'll probably need to use
<Asmadeus>
trying
<Eridius>
the same socket doesn't listen *and* connect
<Eridius>
if a socket listens, it waits for incoming connects
<Eridius>
btw, the process of choosing an ip is usually called binding
<Asmadeus>
that's the point.. I know what binding is. I don't want to listen to incoming conections
<Eridius>
ok
<Asmadeus>
I want to go outsite, but choosing which ip I come from
<Asmadeus>
outside
<Eridius>
try binding anyway
<Eridius>
bind != listen
<Asmadeus>
yeah, got confused with the names
<Eridius>
the unix bind call just assigns a "name" to the socket
<Eridius>
in this case, name means IP address
<Asmadeus>
yay, that worked. thanks
itouch has joined #ocaml
<flux>
hmm.. I have function let value = 42 in let rec loop () = if check_condition then value else do_postbone (fun () -> return (loop ())) in loop ()
rwmjones has joined #ocaml
<flux>
ergh, I just need to think if I actually have a problem there :)
<flux>
I thought I wanted polymorphic recursion
<Eridius>
return?
<flux>
it would be a monadic return function
<flux>
because the postboned function will be evaluted within a monad
<mfp>
it boils down to: is Batteries just a stdlib or a "platform"? I used to believe it was the former, but after your mention of Ocamlnet and the JDK it seems to be the latter?
<Yoric[DT]>
I think of ExtLib as stdlib and Batteries as a "platform".
<Yoric[DT]>
Of course, the platform starts with the stdlib.
<mfp>
If so, (and if more libs are going to be integrated), scaling could be painful.
<Yoric[DT]>
Quite possibly.
<Yoric[DT]>
But we need to start somewhere.
<mfp>
hmm wouldn't things be easier if instead of importing the upstream sources into a single svn tree, the libs to be integrated were kept as separate submodules, with batteries being mostly glue?
<Yoric[DT]>
That's the eventual idea.
<flux>
I wonder if the Batterise and ExtLib provide their interfaces in a way that can be built upon, extended, by third party libraries
<Yoric[DT]>
Still, for now, work on the stdlib is required.
<flux>
atleast enum, channels and ocamlnet's stuff is extensible
<Yoric[DT]>
That's the idea.
<Yoric[DT]>
Hopefully, everything should be extensible.
<flux>
whereas stdlib is not very extensible
<flux>
(the standard stdlib that is)
<Yoric[DT]>
Yep.
<mfp>
ah I see, so the stdlib is being imported because it's hard to extend, OK
<Yoric[DT]>
mfp: actually, the stdlib is *not* in the repository.
<Yoric[DT]>
It's just repackaged using [module A = B].
<mfp>
well, extlib is, no?
<Yoric[DT]>
Sure.
<Yoric[DT]>
I meant OCaml's stdlib.
<mfp>
I think of OCaml's stdlib as "base" and extlib as "stdlib" :)
<Yoric[DT]>
Sounds like a good naming convention.
<Yoric[DT]>
So ExtLib is being imported because we're working on improving it.
<Yoric[DT]>
Hopefully, the whole extlib/ directory of the svn should disappear and be replaced by a GODI dependency.
<Yoric[DT]>
Of course, that means a lot of testing first.
<mfp>
I see
<flux>
so ExtLib improvements are passed on upstream?
<Yoric[DT]>
Slowly.
<Yoric[DT]>
(but that's largely my fault)
<Yoric[DT]>
I'm planning to send a few more patches by the end of the week.
<Yoric[DT]>
You'd have to ask Edgar Friendly about Rope and Vect, that's not my work.
asmanur has quit [Read error: 110 (Connection timed out)]
<mfp>
I wrote them heh
<Yoric[DT]>
Which ones?
<mfp>
rope.ml(i) and vect.ml(i)
<Yoric[DT]>
The ones imported in Batteries?
<mfp>
yes
<Yoric[DT]>
Ok.
<Yoric[DT]>
Well, I got them from him :)
<mfp>
they need more testing, I barely used them
<Yoric[DT]>
I don't handle the work on strings and UTF-8.
<flux>
that filliâtre-guy's been busy
<mfp>
from Filliâtre, you could take Patricia trees, persistent union-find, hashset, rbset, persistent arrays, maybe more stuff
<Yoric[DT]>
Yeah, I'm taking notes at the moment.
<mfp>
since there's effectively no "upstream release", there's not much need for upstream patches; batteries would mostly adapt the API, I suppose
<Yoric[DT]>
Well, I guess that would be committed to ExtLib.
<mfp>
it's all LGPL with static linking exception so it should be OK
<mfp>
ah btw.
<mfp>
did anyone notice the typo in OCaml's license, replicated in nearly all OCaml software under LGPL + static ex. license?
Ched- has joined #ocaml
<Yoric[DT]>
Nope.
<mfp>
it refers to clause 3 of the LGPL (the one about being able to turn the sw. into GPL)
<mfp>
instead of clause 2 (about preserving the LGPL)
<mfp>
actually s/refers/referred/, it was fixed in OCaml's CVS fairly recently
<mfp>
but the bug remains in most LICENSE files out there :-P
<Yoric[DT]>
:-P
<mfp>
this got me scratching my head; I did s/3/2/ for my stuff but didn't know if I was somehow breaking the license hehe
asmanur has joined #ocaml
* Yoric[DT]
goto afk
travisbemann is now known as travis|away
* Yoric[DT]
is back
guillem_ has joined #ocaml
<Yoric[DT]>
How would you call a full replacement for module Printf?
<mfp>
Batlib.Printf? :-) something like Fmtprint or Unparsing makes sense, but Printf is more recognizable
<Yoric[DT]>
Probably IO.Printf, I guess.
<Yoric[DT]>
I can't get it away from IO without breaking ExtLib anyway.
gdmfsob has joined #ocaml
mishok13 has quit [Read error: 110 (Connection timed out)]
<det>
Just call it Something.Printf so that you can open Something to replace the built-in Printf
<Yoric[DT]>
Yeah, that's what I'm doing.
<mrvn>
How do you get it to have the same signature though?
<Yoric[DT]>
Not exactly the same signature.
<Yoric[DT]>
Every occurrence of [out_channel] is replaced by ['a output].
<mrvn>
That is probably not too confusing.
<mrvn>
I would call it Fprintf though if it takes an output.
<Yoric[DT]>
Well, there's a [printf] with the same signature as legacy [printf] (except for channels being replaced by outputs).
<Yoric[DT]>
And a [fprintf], a [sprintf], a [bprintf], [eprintf]...
<Yoric[DT]>
Next step will be adding [k*printf].
<Yoric[DT]>
Well, it seems my [sprintf] needs a little bit more work.
<Yoric[DT]>
(*&%*& format6
<Yoric[DT]>
Got it.
redocdam has joined #ocaml
bluestorm has joined #ocaml
<mfp>
there's something strange with the shootout: it's got a quad 2.4 GHz core 2 but runs OCaml's spectral-norm over 3 times slower than my 3GHz AMD Athlon 64 X2
<mfp>
Haskell is also 2 times slower than for me
Proteus has joined #ocaml
seafood has quit []
seafood has joined #ocaml
<Proteus>
this is probably a newbie question but is there an elegant way to interface ocaml with c++? And yes, I'm aware of the c interface.
<Proteus>
keyword elegant
<Yoric[DT]>
Has anyone used kfprintf?
<Proteus>
but I'm open to ideas
<mfp>
ditto for the C++ version, 3 times slower in the shootout than for me; wth is going on, is Intel's quad processor 3 times slower than an oldish dual AMD??!
<Yoric[DT]>
Proteus: no idea whatsoever, I'm afraid.
<Proteus>
unfortunate
<bluestorm>
Proteus: have you looked at SWIG ?
<Proteus>
yeah
<Proteus>
but have no idea how to use it with languges like ocaml
<Proteus>
I've seen tons of projects using it for, say, python->c++
<Proteus>
but I doubt ocaml is high on their list of priorities
<Yoric[DT]>
Okay, kfprintf works.
sporkmonger has joined #ocaml
<Yoric[DT]>
Proteus: iirc, that's because noone was actually using it.
<Yoric[DT]>
Not even the maintainer.
<Proteus>
do we have _any_ up to date and complete bindings to the current top of the heap scripting languages?
<Proteus>
I'm think I could use one as an intermediate between ocaml and c++
<Camarade_Tux>
if not to python, perl4caml ?
<bluestorm>
Proteus: you should try python, ruby, perl and erlang
<Yoric[DT]>
Okay, that's it, Printf replicated.
<Proteus>
the python libs I've found are either old or incomplete, perl isn't an optoin and I'm not aware of what we have for ruby
<bluestorm>
they're barely used so you should not expect them to be "up to date and complete", but at the same time there is probably little maintainance cost, and _you_ (the potential user) are responsible for their survival (that is, use)
<mrvn>
Although that would allow a few combinations that aren't allowed.
<bluestorm>
you can have a "either this, or that parameter" situation
<bluestorm>
foo(int x) and foo(float x) for example
<mrvn>
bluestorm: ~int_x -> ~float_x -> unit -> ....
<bluestorm>
well that's ugly, isn't it ? :p
<mrvn>
Although there I find `Int x and `Float x better.
<mrvn>
I would call the float f. :)
<bluestorm>
n or x would be fine
<bluestorm>
(n and x)
<bluestorm>
anyway, i think the idea is to have an easy and reasonable default, and a relatively painful but reliable scheme for all the cases
<bluestorm>
they are still subtleties, for example it's difficult to choose between argument_name and argument_type based schemes
<mrvn>
How do you solve the const/non-const variants?
<bluestorm>
mrvn: i'm not sure we encountered it actually
<bluestorm>
i bet something like `const_int ..
sporkmonger has joined #ocaml
sporkmonger has quit [Client Quit]
<bluestorm>
but the tool extracting the type information (kalyptus) was a bit strange and i'm not sure he outputted reliable things in this case
sporkmonger has joined #ocaml
<bluestorm>
Proteus: anyway, i encourage you to try the wxcaml thing
<bluestorm>
you probably don't need something "complete" and "up to date" but only good enough for your needs
<bluestorm>
the problem is that people tends to craft incomplete and good-enough solution themselves, because they think the other solutions are incomplete
<bluestorm>
so we end up having tons of incomplete and already dead things because the authors were happy with them, but nobody use them anymore (so they're "old" and "not up to date" and not "complete")
<mrvn>
bluestorm: It probably depends on the C++ persons style. I really like using const wherever possible so one knows where things change the class and where not. Others don't care.
<flux>
const sounds like a case for phantom types ;)
<mrvn>
On that note, does ocaml have any const modifier at all?
<asmanur>
no we have a mutable modifier, though :)
<mrvn>
Yeah. But In c++ you can say that a member function of a class does not modify any of the mutables and is save to be called with a const of the class.
<mrvn>
Can make a huge difference to the compiler. Function calls that have no side effects can be optimized away.
Philonous1 has quit ["Leaving."]
<mrvn>
e.g. List.length l; List.iter l; List.length l; can skip the second List.length as it must be the same as the first.
Philonous has joined #ocaml
seafood has quit []
<mrvn>
(to draw a comparison)
<bluestorm>
well, an OCaml compiler could infer that
<bluestorm>
the current compiler does not
<mrvn>
Not across compilation units.
filp has joined #ocaml
<Proteus>
I'd love to get a project or two going that would encourage adoption of ocaml, wxcaml is pretty specialized. As I said last night though, I need to build pretty complex toolsets for manipulating game assets, ruby isn't a bad language for throwing up gui code and an easy interface with ocaml gives me a lot of options
<mrvn>
Proteus: MooseFS
<Proteus>
huh. what distinguishes this from other distributed file systems like, say, andrew
<Yoric[DT]>
Okay, improved IO submitted upstream.
<Proteus>
mrvn, nm found website
<Proteus>
I'm still gettign used to the new sourceforge website
<Proteus>
this looks cool
<Proteus>
a cursory glance though has me wondering about a couple problems. first, it looks like it relies on a master server and two, I was under the impression that FUSE has a significant performace penalty
<Proteus>
though both aren't showstoppers
<mrvn>
Proteus: huh? There is a website for moosefs? did someone else use my name?
<Camarade_Tux>
fuse is not less performant, it's drawback is rather that you can't boot on it afaik
<Camarade_Tux>
moosefs.sf.net
<mrvn>
Fuse inherits some memcopying and context switches. Compared to disk media they are normal irelevant though.
<Proteus>
coda and intermezzo are also interesting
<hcarty>
Proteus: The qtcaml Jane St. OSP is supposed to be, partly, tools for easing interface generation between C++ libraries and OCaml
<Proteus>
hcarty, that's good news
<hcarty>
bluestorm: I saw the pa_scope project - it was annouced the day after (or perhaps two days after?) we discussed the same thing here in #ocaml
<hcarty>
bluestorm: Once the OSP is over, I think I will likely switch to pa-do
<Proteus>
It's exciting that companies like Jane's St. are contributing major work to ocaml under liberal liscences
<Proteus>
hcarty, do you know off hand when the OSP ends?
<hcarty>
The final meeting is some time in the next few weeks. Early September... not sure of the exact date
hkBst has joined #ocaml
<bluestorm>
Proteus: 11-12th iirc
<bluestorm>
last year, the project died painfully right after the end of the summer
<bluestorm>
(and actually, if it was not for the final-meeting slides on the web, we would hardly have been aware of most projects existence)
<hcarty>
Yes, I think Reins was the closest any of the projects came to having a life post-OSP
<flux>
I haven't heard of recent releases, though?
<bluestorm>
hcarty: if think it's related to the topic
<bluestorm>
being algorithmic code, there is relatively little maintainance cost
<hcarty>
flux: I haven't either. The author(s?) just setup an external web site with, IIRC, some amount of documentation
<hcarty>
bluestorm: Yes, probably
<hcarty>
Hopefully the changes in the OSP structure will help keep the projects maintained.
<flux>
changes?
<hcarty>
I think they required students' advisers to be more heavily involved
<hcarty>
The groups seem to be large this year as well, which may or may not be helpful
<Smerdyakov>
They didn't have any concept of "advisors" outside Jane Street in the first version.
<bluestorm>
do you think the advisor (being academic members, i gues teachers) will motivate a maintainance+communication effort on the midterm ?
<ssp>
Does somebody knows ocaml 2D-graphics library with support for animation?
<ssp>
In fact, i just want to see it's design and to port to F#.
<ssp>
I want to model FSM where each node have some properties i want to animate and links between nodes also will have payload to represent.
<ssp>
So, i suupose small 2D game programming library will satisfy my requirements.
<bluestorm>
i'm not so sure (i'd think people tend to wipe the plate at the end of the school year)
<Smerdyakov>
bluestorm, no. In general, the more people you have telling you what to do, the less you care about a project.
<Smerdyakov>
ssp, it shouldn't be that hard to wrap Allegro, if that hasn't already been done.
<bluestorm>
ssp: well, SDL / allegro ?
<Camarade_Tux>
there are bindings to chipmunk, it's a physics library (so not doing the display part)
<flux>
I would like to see a library for ocaml that does the same what they do with in the F# demos :)
<flux>
so, a thread runs everything, and you can manipulate/create/etc objects from the toplevel
<flux>
seemed like fun
<flux>
it would be nice if replacing functions (from toplevel) was easier than it is now. now you need to decide that beforehand, and make the value a reference to a function instead of just putting the function there
<flux>
and it's more difficult if you have a polymorphic function
<flux>
ssp, someone mentioned mlgame earlier
<bluestorm>
you could also rebuild the values that depends on this function
<bluestorm>
hm
<flux>
bluestorm, but that too requires planning
<flux>
which reminds me: for example visual C++ has a feature where you can stop the program, change a function, and it changes it in the live program
<flux>
it doesn't always work :-)
<bluestorm>
that sounds difficult :p
<flux>
perhaps the program could be compiled with a special mode that replaces all function definitions with references to the function
<flux>
with camlp4 ;)
<bluestorm>
for your first thing, we could imagine a toplevel that would record the dependencies between interactive values, and a keyword to "redeclare" all the affected values
<flux>
that might be difficult, if you have closures etc around, which you have originally built by receiving network data?
<bluestorm>
true
<bluestorm>
hm
<bluestorm>
i'm not sure you can add the benefits of dynamic scope while retaining the static scoping coherency
<flux>
I was thinking of modifications that wouldn't change function types
<bluestorm>
you'll probably always run into corner case like closures or marshalled values
<bluestorm>
hm
<flux>
or possibly even add any code that would need a new capture
<bluestorm>
we could probably enforce interactivity at the module boundaries (that's basically what Dynlink allows, isn't it) but that probably not fine-grained enough for a toplevel use
<bluestorm>
hm
<bluestorm>
flux: i'm afraid references could create polymorphism problems
<bluestorm>
but
<bluestorm>
an uglier thing using Obj might work :-'
<flux>
bluestorm, but then you might wrap them into a record of their own
<flux>
but that would need explicity type annotations
<flux>
but right, perhaps Obj.magic would be ok too :-o
<flux>
assuming the compiler has compiled the original version successfully
<bluestorm>
hm
<bluestorm>
we could store a pointer to each function in a table, and manipulate them with Obj upon request (eg. replace a function with a fresh just-compiled new version)
<bluestorm>
but that makes type check difficult : how can you check that the new function is type-compatible with the old one ?
marmotine has joined #ocaml
<flux>
while supporting polymorphic functions? yes, I don't quite know..
<flux>
recompile the original source with the code replaced, and check if the mathing .annot-file textually matches the old one :-)
<flux>
that's even less complicated than I expected :-o
<flux>
how can that be?
<flux>
you add a call to bye?
<bluestorm>
nope
<bluestorm>
you replace hello content with bye content
<bluestorm>
hm
<flux>
ah
<bluestorm>
the problem is that you have to be careful with partially-applied functions wich have a different representation
<bluestorm>
(but you could probably disallow the user to replace a well-defined function with a partially applied value)
<flux>
I'm thinking let replace_function a b = Obj.set_field (Obj.repr a) 0 (Obj.field (Obj.repr b) 0) goes into my .ocamlinit :)
<flux>
perhaps a small type annotation will remove the most obvious mistakes
<bluestorm>
hm
<bluestorm>
you should try something like
<bluestorm>
ignore (a == b) before
<bluestorm>
to ensure the type are the same
<bluestorm>
( [a; b] would work as well but == has a delightful taste of "look ! function equality !")
<flux>
well yes, let replace_function (a : 'a -> 'b) (b : 'a -> 'b) = Obj.set_field (Obj.repr a) 0 (Obj.field (Obj.repr b) 0);;
<bluestorm>
would that enforce equality ?
<bluestorm>
oh, right
<bluestorm>
flux: replace_function ((+) 1) incr would still fail
<bluestorm>
you should add a check, wait
<bacam>
You could check that the enviroments have the same size, at least.
<bluestorm>
et is_sane a = let a = Obj.repr a in assert (Obj.tag a = Obj.closure_tag && Obj.size a = 1)
<bluestorm>
+l
<bluestorm>
s/is_sane/check_sane/
<flux>
hm, can you replace standard library functions the same way?
<flux>
replace_function List.rev (fun i -> i);; makes the assertion trig
<flux>
removing the assertion solves the problem
<bluestorm>
well
<flux>
whee, a fun new way to torture software :P
<bluestorm>
"solves the problem", you mean that will explode later ?
<flux>
no, it works
<bluestorm>
hm
<flux>
replace_function' List.rev (fun i -> i);;
<flux>
List.rev [1; 2; 3];; -> [1; 2; 3];;
<bluestorm>
i don't know the closure encoding system enough to know why it works that way
<bluestorm>
so i wouldn't play with that personally but if you find it fun :p
<flux>
;)
<flux>
actually what would be nice would be that the debugger was integrated with the toplevel
<Smerdyakov>
It seems clear to me that very well-separated modules communicating by message passing are the way to go to support flexible upgrading.
<flux>
smerdyakov, yes, if you want to have sort of live upgrading
<flux>
but this is mainly for playing and finding out why a function doesn't work
Jedai has quit [Read error: 110 (Connection timed out)]
Myoma has joined #ocaml
gdmfsob has quit [Read error: 110 (Connection timed out)]
pango_ has quit [Remote closed the connection]
redocdam has quit [Read error: 60 (Operation timed out)]
pango_ has joined #ocaml
redocdam has joined #ocaml
Axioplase_ is now known as Axioplase
jeddhaberstro has joined #ocaml
ttamttam has left #ocaml []
filp has quit ["Bye"]
<flux>
say, is there an existing datastructure like c++'s std::multimap: a map that can have the same key multiple times?
<flux>
(..an implementation for ocaml, that is)
<bluestorm>
flux: Hashtbl ?
<flux>
ah, right, I didn't remember that
<flux>
thanks :)
<bluestorm>
(you can also emulate that very easily with a ('key, 'value list) Map if you want something pervasive)
<flux>
its support isn't perfect
<flux>
yes, it's easy, but you also need to deal with creating the list and removing the entry when it's empty
<flux>
it's bothersome :)
jeddhaberstro has quit []
<mrvn>
Note that a Hashtbl is imperative.
<mrvn>
flux: You can probably easily write a Functor to make a map that a handles multiple keys.
<flux>
perhaps I'll do that some day
Kopophex has joined #ocaml
Asmadeus has quit ["rebooting"]
jderque has joined #ocaml
jlouis has joined #ocaml
Asmadeus has joined #ocaml
bfrog has joined #ocaml
<bfrog>
does ocaml have object introspection?
<flux>
ocaml does not have any introspection capabilites; all type-related information is removed during compilation
<flux>
bfrog, what kind of features are you looking for?
<Smerdyakov>
This isn't entirely true. Basic shape information is still around and is used at least by the garbage collector.
<bfrog>
well basically, automated serialization akin to python-pickle
<flux>
bfrog, perhaps sexplib can do what you're looking for
<flux>
there are a few other similar libraries around
<flux>
one cannot serialize objects, though, only records
<bfrog>
forgive me, but I'm seeing which language I'd like to play around with next and write a program in, but what is a record in ocaml terms?
<flux>
actually, there's also the Marshal-module
<flux>
bfrog, type r = { a : int; field : char; another : string }
<bfrog>
is that essentially a typed tuple then?
<flux>
yes
<flux>
I forgot about Marshal, because I rarely, if ever, use it
<bfrog>
nice :-) thats basically what python uses
<flux>
I haven't tried serializing objects with it, though
<bfrog>
gotcha
<flux>
apparently serializing objects is also possible, with the same limitation as with serializing other functions: the receiving end must be the same exact binary as the sending end
<flux>
isn't that a backwards way to put the signature? in the end?
<flux>
but, nice anyway :)
<flux>
bluestorm is so easy to persuade into writing stuff ;)
<bluestorm>
hm
<bluestorm>
that was quite fun actually
<bluestorm>
however, there are unanswered questions left
<bluestorm>
regarding especially remove_one, compare and equal
<flux>
ah, right
<flux>
equal will likely not work
<bluestorm>
i originally intended remove_one to be key -> 'a t -> 'a -> 'a t
<flux>
perhaps a set of maps?
<flux>
uh
<flux>
a map of sets?
<bluestorm>
but you can't do that without an equality over the elements
<bluestorm>
flux: so we'd require an OrderedType on values also ?
<flux>
I agree, that's not optimal
<flux>
especially as it removed more polymorphicity
<bluestorm>
we could sort the lists before comparing them
<bluestorm>
(to have them behave like sets)
<flux>
well, they still need to be sorted
<flux>
I mean, compared
<flux>
so they need to be comparable
<bluestorm>
but we i'm not sure it's possible with equal
<bluestorm>
hm
<bluestorm>
compare asks for a comparison function so that's ok
<flux>
ah, right
<bluestorm>
(btw i don't remember having seen those compare and equal functions previously, aren't they new ?)
<flux>
I think they've been there
<flux>
I don't remember when I've needed them, though
<bluestorm>
flux: given a ('a -> 'a -> bool) function, is there a not-too-innefficient way to derive a ('a -> 'a -> int) function suitable for sorting ?
<flux>
bluestorm, you will need two comparisons..
<bluestorm>
"two comparisons" ?
<bluestorm>
ah
<bluestorm>
'a -> 'a -> bool is an equality function
<bluestorm>
not an order
<bluestorm>
that would be too easy
<flux>
:)
<flux>
I don't think there's any way
<bluestorm>
hm
<bluestorm>
yes it should be possible to build something
<bluestorm>
for each element you keep a list of "previously compared"
<flux>
oh you just want some order?
<bluestorm>
with that information you can ensure that your answers are not too incoherent
<bluestorm>
yes
* rwmjones
can't believe he missed the Buffer.add_substitute function before
<flux>
bluestorm, in any case it will be slow
<bluestorm>
probably :p
<bluestorm>
hmm
<bluestorm>
actually i can probably say if two lists are "reasonably equal" (when they encode a multiset) without sorting the elements
<bluestorm>
for each element of the first list, i take the equal element of the second list off, then retry
<bluestorm>
it's only quadratic
<bluestorm>
so no worse than the slow sort method
Camarade_Tux_ has joined #ocaml
Camarade_Tux has quit [Read error: 110 (Connection timed out)]
Camarade_Tux_ is now known as Camarade_Tux
jlouis has quit [Remote closed the connection]
jlouis has joined #ocaml
bfrog has left #ocaml []
itouch has quit ["KTHXBYE"]
psnively has joined #ocaml
<mrvn>
If you have "less_than : 'a -> 'a -> bool" you can do a partial order.
<mrvn>
If you also have a < b <=> not (b < a) then a total order.
<mrvn>
On what conditions does Pervasives.compare raise Invalid_argument when used on functional values?
<Eridius>
you can compare functional values?
<mrvn>
"compare applied to functional values may raise Invalid_argument."
<mrvn>
That implies that sometimes it does not.
<Eridius>
I would assume the condition is: when applied to functional values
<mrvn>
Nope. Vor >= it says "Comparison between functional values raises Invalid_argument." making it a certainty.
<Eridius>
I think it means compare may raise Invalid_argument, and the condition is when applied to functional values
<mrvn>
Eridius: would be odd to use different wording for >= and compare then.
<Eridius>
I just tested, and compare raises Invalid_argument "equal: functional value"
<Eridius>
so it's actually = raising the error here
<Eridius>
and = says Equality between functional values raises [Invalid_argument].
<mrvn>
odd.
<mrvn>
Why doesn't it compare the address of the code and the structure of already bound arguments?
<Eridius>
hrm, maybe it doesn't raise the exception if they're literally the same object?
<Eridius>
I was right
<mrvn>
Eridius: you mean if == is true?
<Eridius>
let x = (fun x -> x + 1) in compare x x
<Eridius>
that returns 0
<Eridius>
yeah, I guess I do mean if == is true
<Eridius>
compare probably tests ==, then tests =, then tests < and/or >
<mrvn>
For the question in hand you probably have to make a list of functions and compare with ==.
<Eridius>
hrm, I think Pervasives ( = ) and other operators are actually implemented in terms of compare
* Eridius
is reading the source
<Eridius>
compare checks the addresses of the two objects first. If they're the same, it returns EQUAL regardless of the object
<Eridius>
one thing I don't understand is Pervasives declares externals like "%equal", but the docs don't say anything about the % symbol. Plus, it appears the actual C code names these caml_foo
<Eridius>
oh hey, there's actually a hashtable of these "%foo" tokens
<Eridius>
inside the compiler
<Eridius>
curious
<Eridius>
so "%equal" actually transltaes into a sequence of instructions
<Eridius>
huh, "%eq" maps directly to the instruction to do an integer comparison (presumably this means address comparison). neat
<Smerdyakov>
mrvn, looks like what you really want is a functor.
<Smerdyakov>
mrvn, you may never refer to signatures in types.
<mrvn>
I want two objects with a common signature in a list.
<bluestorm>
hm
<Smerdyakov>
mrvn, also, you are breaking the module abstraction boundary by using the fact that [t] is a [ref] type in each case.
<Smerdyakov>
mrvn, there will never be any ML feature that would let you do that.
<mrvn>
The OO part will let me.
<bluestorm>
i'd have said, higher-order polymorphism
<bluestorm>
type 'a callable = { v : 'a . ('a ref) * ('a -> unit) }
<Smerdyakov>
mrvn, you have two separate problems: trying to use a signature in a type and trying to use sealed information about a module.
<mrvn>
Smerdyakov: "val cal : t ref -> unit" in Module M should fix that.
<Smerdyakov>
mrvn, no, that won't be sufficient.
<mrvn>
For breaking the abstraction I mean
<Smerdyakov>
mrvn, that doesn't expose whether the underlying type is [int], [float], etc..
<mrvn>
Smerdyakov: I want it to understand that the underlying type is "M.t", whatever that means for the object that implements M
<Smerdyakov>
mrvn, underlying type of what?
<mrvn>
For the parameter to call.
<Smerdyakov>
mrvn, OK, your signature [M] already expresses that.
<Smerdyakov>
mrvn, but every sealed instance of [M] is provably useless, in a certain sense.
<mrvn>
But I can't make the list understand that it doesn't matter what the actual type is
<Smerdyakov>
mrvn, you don't know what the instance's choice of [t] is, so you can never create any values of [t], so you can never call [call].
<mrvn>
The value of t should be taken from the respective object that has call and then it must fit.
<Smerdyakov>
mrvn, (I'm still talking about the "trying to use sealed information about a module," so lists have nothing to do with it.)
<Myoma>
Smerdyakov: Have you written a lazy evaluator?
<Smerdyakov>
mrvn, that's just not how the ML module systems work.
<Smerdyakov>
Myoma, I don't know.
<mrvn>
Smerdyakov: then maybe something else.
<Myoma>
how could you not know?
<Smerdyakov>
mrvn, when you write [M1 : M], thereafter you may only use the facts about [M1] that [M] implies.
<mrvn>
apart from using a class hierachy.
<Smerdyakov>
Myoma, I don't care enough to think about it.
<Myoma>
aww
<Smerdyakov>
mrvn, [M] contains no information on concrete values of [t], so you must treat [M1.t] as abstract.
<Smerdyakov>
mrvn, I get the impression that it's time for you to sit down with a book on ML.
<mrvn>
Smerdyakov: which is fine by me. I (outside of the module) don't touch it.
<Smerdyakov>
mrvn, absolutely false.
<Smerdyakov>
mrvn, you try to use the fact the [M1.t = int ref].
<mrvn>
Smerdyakov: The example code is obviously flawed. I just don't know how to write it right or I wouldn't ask.
<Smerdyakov>
mrvn, please fix this problem before asking about the "trying to use a signature in a type" problem.
<mrvn>
Smerdyakov: that is the problem.
<Smerdyakov>
mrvn, the canonical solution would be to add a new member function to [M], for creating a new [t].
<mrvn>
"val make : unit -> t"?
<Smerdyakov>
mrvn, after that, you still have the "trying to use a signature in a type" problem left. You might not understand this, but my last line of advice is for solving a completely orthogonal problem.
<Smerdyakov>
Yes, that would work.
<mrvn>
let list = (M1.make (), M1.call) :: (M2.make (), M2.call) :: []
<mrvn>
This expression has type M2.t ref * (M2.t ref -> unit)
<mrvn>
but is here used with type M1.t ref * (M1.t ref -> unit)
<Smerdyakov>
Duh. I just told you that that left another problem.
<mrvn>
Can I somehow case them to M?
<Smerdyakov>
No, I'll say it again, and it's worth paying attention and taking me literally this time: it is _impossible_ to mention signatures in types.
<mrvn>
Smerdyakov: It doesn't have to be a signature.
<mrvn>
I'm open to any suggestion
<Smerdyakov>
[M] is a signature, and it's [M] you asked about.
<Smerdyakov>
You either find a way to resolve all such polymorphism at run-time, and implement this with functors; or you use the higher-rank polymorphism that they snuck into records and objects.
<mrvn>
Smerdyakov: The goal is to get objects of type M1 and M2 into a list
<Smerdyakov>
Sorry, "resolve at compile-time."
<Smerdyakov>
Lists are homogeneous by definition.
<Smerdyakov>
You will never get values of different types into the same list.
<bluestorm>
mrvn: why would you *want* to have those different things in a list ?
<bluestorm>
i think you think you want that because of the second-order polymorphism
<Smerdyakov>
Another class of solution to this problem is to encode the relevant behavior inside of closures, which hide existential type variables.
<bluestorm>
and that's not related to the signature problem
<Smerdyakov>
For instance:
Kopophex has quit [Connection timed out]
<Smerdyakov>
let t1 = M1.create ()
<Smerdyakov>
let t2 = M2.create ()
<Smerdyakov>
let list = [(fun () -> M1.call t1); (fun () -> M2.call t2)]
Kopophex has joined #ocaml
<Smerdyakov>
Now [list : unit -> unit]; no tricky typing problems left.
<mrvn>
bluestorm: File "foo.ml", line 7, characters 22-35:
<mrvn>
This field value has type int ref * (int ref -> unit)
<mrvn>
which is less general than 'a. 'a ref * ('a ref -> unit)
<mrvn>
bluestorm: That doesn't seem to work.
<bluestorm>
yes
<bluestorm>
you have to encode the call logic into callable
<bluestorm>
hmm
<mrvn>
bluestorm: I don't see how that could be fixed short of doing what Smerdyakov suggested.
<mrvn>
i.e. have only closures that don't have a 'a in it anymore.
<Eridius>
what's the . in the type?
<bluestorm>
i must have been wrong actually because the "callers" described by the callable type probably can't specialize over int and floats as you do
<bluestorm>
Eridius: second-order polymorphism, an little used feature except in OOP
<bluestorm>
-n
<Smerdyakov>
bluestorm, you have misunderstood what these sneaky existentials let you do.
<bluestorm>
well
<bluestorm>
" 'a callable" is certainly wrong
<bluestorm>
at first
<Smerdyakov>
What mrvn wants is quite possible, but it requires a CPS encoding in the record type.
<bluestorm>
hm.
<Smerdyakov>
Or, now that I think about it, that wouldn't really buy anything over unit-closures.,
<bluestorm>
yes i think so
<Smerdyakov>
You can encode existentials that you only ever want to "run" with no results without using fancy features.
<Smerdyakov>
You can also use interior universal quantifiers in records to encode existentials for values that you want to analyze functionally, but that doesn't seem called for here.
<mrvn>
bluestorm: 'a . would be usefull for a Sort module that gets an 'a list and 'a compare function and then sorts them.
<bluestorm>
hm ?
<bluestorm>
simple polymorphism seems to be enough on that one
<flux>
bluestorm, but if you want to put such a function into a non-polymorphic record..
itouch has joined #ocaml
<mrvn>
Smerdyakov: thanks again for the hint about closures. works perfectly.
<mrvn>
Quite obvious solution once you've seen it.
Snark has quit ["Ex-Chat"]
Associat0r has quit []
jderque has left #ocaml []
netx303 has joined #ocaml
Kopophex has quit [Read error: 110 (Connection timed out)]
Kopophex has joined #ocaml
hkBst has quit [Read error: 104 (Connection reset by peer)]
tomh_-_ has joined #ocaml
tomh_-_ is now known as tomh
sporkmonger_ has joined #ocaml
seafood has joined #ocaml
sporkmonger_ has quit [Client Quit]
Kopophex_ has joined #ocaml
itouch has quit ["KTHXBYE"]
sporkmonger has quit [Read error: 110 (Connection timed out)]
Kopophex has quit [Connection timed out]
seafood has quit []
Axioplase is now known as Axioplase_
rby_ has joined #ocaml
Proteus has quit [Read error: 104 (Connection reset by peer)]
Proteus has joined #ocaml
rby_ has quit ["Leaving"]
netx303 has left #ocaml []
Asmadeus has quit ["poof"]
Proteus has quit [Read error: 104 (Connection reset by peer)]
Proteus has joined #ocaml
Kopophex_ has quit [Connection timed out]
Kopophex_ has joined #ocaml
Amorphous has quit [Read error: 110 (Connection timed out)]