Yoric[DT] has quit [Nick collision from services.]
Yoric_ is now known as Yoric[DT]
Ched- has joined #ocaml
<Yoric[DT]>
Paper is complete !
<Yoric[DT]>
At last!
<Yoric[DT]>
Now back to home, to grab some dinner and prepare a release of the code.
<cpfr>
what paperr?
<Yoric[DT]>
Submission for ML 2008.
<cpfr>
ml?
<Yoric[DT]>
Workshop on ML.
<cpfr>
machine learning or like meta language
<Yoric[DT]>
And the paper is about error-handling in OCaml.
<Yoric[DT]>
ML as in SML/OCaml/F#
<cpfr>
what you think of F#?
<Yoric[DT]>
Only gave it a cursory try.
<Yoric[DT]>
But I think it's a good idea.
<Yoric[DT]>
Too bad it's not open-source.
<Yoric[DT]>
That being said, I promised myself some dinner.
<Yoric[DT]>
See you later.
Yoric[DT] has quit ["Ex-Chat"]
Kopophex has joined #ocaml
Yoric[DT] has joined #ocaml
* Yoric[DT]
suffers from deadline headache.
rogo has left #ocaml []
OChameau has quit ["Leaving"]
coucou747 has joined #ocaml
bluestorm has joined #ocaml
psnively has joined #ocaml
<mbishop>
F# is open source
<mbishop>
well...it will be, anyway
<mbishop>
F# is under the MS-PL or whatever license now, which is FSF compliant, they just haven't gotten around to releasing it all
<cpfr>
but it it any good
<Yoric[DT]>
Is it?
<Yoric[DT]>
That's good.
<cpfr>
yes
<mbishop>
It's a pretty good language, lot's of nice additions
<cpfr>
is it really nice to have access to the .net libs
<Yoric[DT]>
When I asked Don Sume one or two years ago, I was disappointed to hear a negative answer.
<bluestorm>
mbishop: but some missing things (eg. functors)
<Yoric[DT]>
Well, given .Net's dynamic features, I can only assume that they're going to get typeclasses one day or the other.
<bluestorm>
hm
<mbishop>
Yeah, althrough I admit to never using functors in ocaml, either heh
<mbishop>
It uses a supposidly "better" module system (that of .NET)
Ched- has quit []
<psnively>
?
<flux>
so how does F# implement Set with sane semantics?
<psnively>
OCaml's module system is positively brilliant.
<mbishop>
er, sorr, I ment object system
<flux>
(that is: merging two sets works)
<mbishop>
sorry*
<mbishop>
but then, I don't use ocaml's object system either, which is why "better" was in quotes :P
<psnively>
Ah, that does make more sense on some level. LOL
Ched- has joined #ocaml
<flux>
difficult to see it would be better, ocaml's is brilliant :)
<bluestorm>
are type classes really a dynamic thing ? afaik their use is statically inferred, and using introspection or something would be dead slow, wouldn't it ?
<flux>
I suppose it supports both up- and downcasting though
RobertFischer has quit []
<psnively>
Which wouldn't make it "better," but rather "worse."
<bluestorm>
hm
<flux>
it would make it "a better fit"
<psnively>
Yes.
Ched- has quit [Client Quit]
<psnively>
The sloppiness of objects designed without a calculus behind them winning over the rigor of the usual FP type systems.
<bluestorm>
I don't know F# enough, but i've been interested in the "active patterns" feature, and the #light syntax; and actually, i think both could be reasonably imitated in pure OCaml with some camlp4 preprocessing
<mbishop>
most of what I like about F# is indeed it's sugar
<flux>
bluestorm, I suppose you know of Patterns? however twt doesn't currently use camlp4, although it plans to
<bluestorm>
i've seen some other interesting things (for example the ability to add functions/methods to a datatype declaration), but i'm not sure about them
RobertFischer has joined #ocaml
<bluestorm>
flux: "plans to" is nice, but in practice i'm not aware of any work in that direction. The current state (independent but camlp4-friendly preprocessor, line numbers preserved) is quite a good compromise, though.
Ched- has joined #ocaml
<palomer>
back
<mbishop>
"Around March last year we got permission to release the compiler and library source on CodePlex under MS-PL. We still plan to do so at some point, so my apologies for the delay."
<mbishop>
quote by Don Syme about F# (yes it took me this long to find it :P)
<palomer>
flux, I found this interesting: type foo = [`Bar | `Baz] let (x:foo) = match x with `Bar -> () <--throws a type error
* palomer
wishes it was possible to put a try..with block in every let binding, would save him time trying to find out who threw the exception
<flux>
hmm.. why won't exception stacktraces tell you that?
<bluestorm>
palomer: match x with `Bar -> () | _ -> () would work
Ched- has quit [Remote closed the connection]
<bluestorm>
(and your code as-is doesn't compile, btw)
<palomer>
yeah
<palomer>
flux, the exception never reaches the toplevel
<palomer>
bluestorm, yeah, the compiler gives a type error, not a nonexhaustive match error
<palomer>
that always surprised me
<flux>
palomer, how about the cvs where you can print the stack trace anywhere you like?
<palomer>
flux, doesn't using the cvs mean recompiling everything?
<flux>
afaik yes
<palomer>
isn't that a _huge_ pain?
<flux>
depends
<flux>
if you're using godi, not so much ;)
<flux>
..in theory..
tomh has joined #ocaml
Ched- has joined #ocaml
<flux>
or if you have a semi-solid build environment you can just make clean and make all
<flux>
(I don't ;))
Ched- has quit [Read error: 104 (Connection reset by peer)]
<palomer>
flux, last I checked, godi doesn't support ocaml cvs
<flux>
palomer, well, my godi is running ocaml cvs
<palomer>
flux, 3.11 ??!?
<psnively>
flux: you're special. :-D
<flux>
well
<flux>
maybe not the HEAD
<palomer>
flux, a release with backtraces?
<flux>
nope
<flux>
I haven't updated it recently
<flux>
OCAML_CVS_CHECKOUT=yes
<flux>
I guess that should mean it takes the HEAD
<flux>
The Objective Caml compiler, version 3.11+dev12 Private_abbrevs+natdynlink (2008-02-29)
<flux>
from godi
coucou747 has quit [Read error: 110 (Connection timed out)]
<palomer>
ooooh
<bluestorm>
hm
<palomer>
could you show me step by step:P?
<flux>
I've forgotten how to do it :)
<psnively>
natdynlink not for PPC = Fail
<palomer>
argh!
<flux>
but iirc it was documented with the natdynlink stuff
coucou747 has joined #ocaml
<flux>
also there was something that didn't compile. libtk I think.
<palomer>
yeah
<palomer>
libtk doesn't compile for me
<flux>
had to hack something to make it compile through
<flux>
(to finish make install)
* orbitz
just ignroes libtk
<psnively>
I always used the getting started on OS X instructions on the Wiki to make OCaml work with framework Tk.
<orbitz>
flux: ./configure didn't take care of it?
<flux>
but, if you ignore libtk you also ignore ocamlbrowser
<flux>
no
<psnively>
==flux
<orbitz>
for me, ./configure sees libtk fail and just doesn't try to use it
<flux>
it was a patch that failed to commit
<flux>
and if you drop ocamlbrowser, you lose some other godi package
<flux>
can't remember what
<palomer>
my kingdom to anyone who can help me get ocaml cvs + libraries working!
<psnively>
I always pass -tk-no-x11 and the -tklib etc. flags to tell it where the framework is.
<bluestorm>
palomer: be careful, you already have quite an habit to report a lot of (supposed bugs)/problems/questions, using the CVS would make the situation a bit more dangerous
<flux>
;)
<palomer>
bugs? I barely ever report bugs
<palomer>
I only found 2
<palomer>
and my questions are never version related
Ched- has joined #ocaml
LordMetroid has joined #ocaml
<RobertFischer>
Anyone else having trouble accessing SVN on forge.ocamlcore.net?
<palomer>
well, one of my bugs was version related
mbishop has quit [Remote closed the connection]
mbishop has joined #ocaml
<Yoric[DT]>
bluestorm: I'd say that writing typeclasses is easier with dynamic objects.
<bluestorm>
hm, could be
mbishop_ has joined #ocaml
mbishop has quit [Nick collision from services.]
mbishop_ is now known as mbishop
<cpfr>
mbishop, can i emulate typeclasses with functors?
<bluestorm>
cpfr: depends on what you mean by "emulate"
<bluestorm>
but i guess you can do the same kind of things
<bluestorm>
typeclasses are more implicit
<cpfr>
well i want to emulate having functions that do different things depending on their type
<bluestorm>
but you could do something "similar" with a quite simple functor solution
<bluestorm>
the idea is to encapsulate your printable type in a module with a "show" method, and to functorize the using code
<cpfr>
eww
<cpfr>
oops
<cpfr>
i was saying eww to the code
<bluestorm>
so instead of a function do_something :: Show t => t -> ... , for example, you'll have a functor functor (T : Showable) -> struct let do_something = .... end
<cpfr>
right
<bluestorm>
i think this approach is at least equivalent in expressiveness to type classes (although i'm not sure), but of course it's fully explicit so a bit heavier (but not so much)
<cpfr>
so what would that functor have
<bluestorm>
hmm
<bluestorm>
the same thing the Show typeclass in Haskell have
<bluestorm>
cpfr: this approach can be generalized, you need a library that provide the instances for the built-in types (you'll have to generate instances for your own types by hand). Such a library is Core , an alternative to the stdlib ( seehttp://ocaml.janestcapital.com/?q=node/28 , "Standardized interface includes" ), although i'm not sure it's widely used outside janestreet right now
<cpfr>
i was looking at Core
<cpfr>
I liked it
<cpfr>
and I am happy to include it
<cpfr>
so what ends up happening is I put my types in their own modules
<cpfr>
and then call a functor on the module-type to get the function i want
<bluestorm>
that's the idea
<bluestorm>
but that entails a lot of functorization of your code
LordMetroid has quit [Read error: 104 (Connection reset by peer)]
LordMetroid has joined #ocaml
Linktim- has quit [Remote closed the connection]
det has quit [Read error: 110 (Connection timed out)]
ygrek_ has quit [Remote closed the connection]
<cpfr>
well maybe the macro system can ease the burden a bit