tristram has quit [Read error: 110 (Connection timed out)]
cmeme has quit ["Client terminated by server"]
cmeme has joined #ocaml
mauke has quit [Remote closed the connection]
mauke has joined #ocaml
pango_ has joined #ocaml
tristram has joined #ocaml
pango has quit [Read error: 110 (Connection timed out)]
ski has quit ["bbl"]
mauke has quit [Remote closed the connection]
mauke has joined #ocaml
bd_ has quit [Read error: 104 (Connection reset by peer)]
mauke has quit [Remote closed the connection]
mauke has joined #ocaml
Herrchen has joined #ocaml
Herrchen_ has quit [Read error: 110 (Connection timed out)]
rK| is now known as ramkrsna
_fab has quit [Remote closed the connection]
mauke has quit [Remote closed the connection]
mauke has joined #ocaml
quamaretto has quit ["bye"]
Submarine has joined #ocaml
mauke has quit [Remote closed the connection]
mauke has joined #ocaml
Smerdyakov has quit ["Leaving"]
pango_ has quit ["bbl"]
pango has joined #ocaml
mauke has quit [Remote closed the connection]
mauke has joined #ocaml
vodka-goo has joined #ocaml
Submarine has quit [Remote closed the connection]
Raziel has quit ["Yo soy goma. Tú eres cola."]
Skal has joined #ocaml
ulfdoz has quit ["deprecated"]
ulfdoz has joined #ocaml
ulfdoz has quit [Client Quit]
ulfdoz has joined #ocaml
revision17_ has joined #ocaml
Revision17 has quit [Read error: 110 (Connection timed out)]
Amorphous has quit ["arg... must... shutdown... computer burnin..."]
Amorphous has joined #ocaml
oxygene has left #ocaml []
mauke has quit [Remote closed the connection]
mauke has joined #ocaml
gim has joined #ocaml
Raziel has joined #ocaml
kryptt has joined #ocaml
kryptt has quit [Client Quit]
Yorick has joined #ocaml
<vincenz>
anyone around?
<vodka-goo>
yep
* dylan
yawns
Mozillion has joined #ocaml
<Mozillion>
Hi
<dylan>
Greetings.
Smerdyakov has joined #ocaml
<Mozillion>
I was splitting up libs a bit Java/Python like, but that didn't seem to work.. I've for example foo.ml and core/foo.ml and was under the impression that 'open Core.Foo' mapped to the second file
<Mozillion>
because foo.ml implements some general functions and I want to make them more specific for several cases
<vincenz>
ah
<vincenz>
well basically someone messed up the ocaml imipl of regex-dna on the shootout
<vincenz>
they compiled it without str.cmxa
<vincenz>
even though it clearly states so
<vincenz>
this is lowering the ocaml score!
<vodka-goo>
Ocaml isn't java/ython-like
<vodka-goo>
Mozillion: the directories don't care for OCaml
<Yorick>
vincenz: I think that's a feature.
<vincenz>
Yorick: what? having an error on the shootout?
<vodka-goo>
so if both . and core and in the include path (use -I) OCaml will complain that there are two Foo
<Yorick>
vincenz: For not taking them seriously, yes.
<vincenz>
the haskell people are actively working to get their score up
<Mozillion>
vodka-goo: so what's the general way of doing these things?
<Mozillion>
yeah
<vincenz>
blegh
<Yorick>
vincenz: Then let them. I think it's a bloody disgrace.
<vodka-goo>
Mozillion: you can name the second one core_foo.ml or core/core_foo.ml
<vincenz>
I think it's a bloody disgrace the ocaml community is as dead as a fallen leaf
<Yorick>
vincenz: Oh, it's not. More likely people have better things to do than participating in silly useless toy "benchmarks".
<vincenz>
Yorick: there's never any discussion on here
<vincenz>
the extlib mailing list is as good as dead
<Smerdyakov>
vincenz, yet hundreds of people are creating exciting software with OCaml every day..
<vincenz>
trust me, the ocaml community is rather dead, and if it ain't dead, it's doormant
<vincenz>
dormant even
<Yorick>
vincenz: I wouldn't worry too much about it.
<vincenz>
Smerdyakov: without a community languages have a good chance of ending up in the disuse bin
<Yorick>
vincenz: Ocaml isn't so much a language as a tool (there's only one as far as I know)
<vodka-goo>
vincenz: there
<vodka-goo>
vincenz: there *is* a community
<vincenz>
vodka-goo: hardly
<vincenz>
not much exciting going on
<vodka-goo>
as Smerdyakov pointed out, we just don't spend time on the shootout, nor trolling here
<vincenz>
I mean if you look at haskell...
mauke has quit [Remote closed the connection]
mauke has joined #ocaml
<Yorick>
vincenz: There isn't supposed to be "exciting" things happening. It's the boring pedestrian things that keep it alive.
<vodka-goo>
haskell is a sect :)
<dylan>
ocaml has a community, it seems.
<vincenz>
Yorick: no there's a serious need of a more mature and extended library set
<vincenz>
vodka-goo: I'm not advocating haskell, besides I hardly know the language itself, I'm noticing a trend which I'd rather see reversed
<Smerdyakov>
vincenz, you seem to be suffering from GNU disease, where the quality of a toolset is judged by how many fanboys are yammering about it per unit time.
<vincenz>
Smerdyakov: You can publish that in the GJB
<Smerdyakov>
vincenz, OCaml is predominantly used by extremely well informed and dedicated people.
<vincenz>
Smerdyakov: a lack of a community leads to a lack of new people
<vincenz>
meaning that it'll suffer starvation
<Smerdyakov>
vincenz, you will find some of the best support for question-answering around with OCaml. I don't understand _at_all_ what you could mean by "community" where OCaml would fail to have an excellent one.
<vincenz>
Smerdyakov: this channel is typically dead, I mentioned something about the shootout being buggy and I got shot down for it being pointless. Not everyone buys into technically best will survive, how else do you explain java
<dylan>
vincenz: Strong drugs. Very strong drugs from California.
<Smerdyakov>
vincenz, ah, but the beauty is that the OCaml community is made up mostly of serious engineers who _do_ care about technical merit.
<vincenz>
ocaml used to be an order faster than haskell and sml, but that is changing as well
<Smerdyakov>
vincenz, we don't care if we convince the masses to convert; we'll take our competitive advantage over them any day!
<vincenz>
Smerdyakov: so basically a community of experts, funny you should metnion, just read an article today by stroustrup saying how he wants to make c++ more usable by non experts, cause that's what drives the industry
<vincenz>
Smerdyakov: if you don't get new people, yu'll inevitably lead to a starved community
<Smerdyakov>
vincenz, not true.
<vincenz>
which is just the leadup of death
<Smerdyakov>
vincenz, you're thinking in terms of a fundamentally flawed model along the lines of "everybody should be able to program."
<dylan>
I'm a new people... and I've managed to convince some people to look at ocaml for technical merits...
<Smerdyakov>
vincenz, when in fact, we want more stringent standards for engineers who work on even remotely critical software.
<vincenz>
Smerdyakov: No I'm thinking in the model of "I don't want to reinvent the wheel in ocaml by making my own libs to standard stuff but will most likekly have to as the community is so small that noone else has done it"
<Smerdyakov>
vincenz, there are lots of libraries for OCaml, and they are easy to write. I've not yet wished for one that I couldn't find.
<vincenz>
I'm glad you live in that niche
<Yorick>
dylan: That's nice. It isn't beautiful, but at least it's somewhat useful :)
<Smerdyakov>
I'd argue that it's the most important niche today -- the one where the most effort is needed to lift software development out of the ditch where it lives now.
<Smerdyakov>
So I'm not going to expend much effort on other areas, namely those other than the infrastructure needed to support the construction of correct software.
<vincenz>
Smerdyakov: besides ocaml is not -the- summit. I took it cause at the time haskell was a slow beast, but I personally seriously prefer typeclasses over module functors
<dylan>
Yorick: I am afraid I do not understand that prose. Huh?
<Yorick>
dylan: I was merely congratulating you in convincing someone else to look at ocaml despite what it looks like by refering to its utility.
<Smerdyakov>
vincenz, OCaml is supported by researchers. That is a fundamental flaw in the model. That's why SML is getting ahead, and why I prefer to use it whenever possible.
<dylan>
Yorick: Ah. Yes. camlp4r helps in this area. As people are scared of the normal syntax.
<Smerdyakov>
vincenz, however, OCaml is key to some of the greatest developments in the history of formal methods. In that sense, as a research platform, it is enormously successful and has a _very_ active "community."
<vincenz>
Smerdyakov: To give you an example, clean seems to be superior to haskell, but it has SUCH a small community, even though it's backed by researchers, that most likekly it'll die out cause everyone will just port it's innovations into haskell
<Yorick>
dylan: I agree, but it's a bit of a crutch.
<vincenz>
what's wrong with the normal syntax?
<Smerdyakov>
vincenz, I don't know. Monads are easier to formalize in a minimal language than linear types.
<vincenz>
Smerdyakov: Clean does have exisential types which allow for more checks for concurrency
<Yorick>
vincenz: It's completely fucked up. But who cares, ocaml is dead, isn't it?
<vincenz>
Yorick: You presume I'm a troll instead of a saddened supporter
<dylan>
vincenz: people used to ancient languages find ocaml's syntax confusing.
<Yorick>
dylan: Well, not just ancient (but what is then a "modern" language? c#? :)
<vincenz>
2hmm
<vincenz>
small ocaml impl question
<dylan>
I try my best to ignore C#'s existence.
<vincenz>
does ocaml instantiate general functions for each call site?
<vincenz>
like c++ templates
<ertai>
no
<vincenz>
ah, but the fact that everythiing is boxed anyways, it doesn't really matter?
<ertai>
of course it helps
<Yorick>
Partial evaluation is always nice
<vincenz>
so are there cases when runtime dispatching is necessary?
<vincenz>
(or instantiation ala templates)
<vodka-goo>
for objects yes
<vodka-goo>
for functors I'm not sure but I don't think so
<vincenz>
no I meant generic functions
<vincenz>
I can think of one example
<vodka-goo>
then no
<vincenz>
any function taking an 'a array
<vincenz>
it must have special case for float arrays
<vincenz>
cause there the floats are not boxed
<vincenz>
so there must be some runtime switching based on type, no?
* vodka-goo
actually wonders about that point..
<vincenz>
or a seperate instantiation of any generic function taking an array specifically for float
<vodka-goo>
we should look at the generated ASM
<vincenz>
like arraymap f a
<vodka-goo>
maybe unboxing happens only when static dispatch is doable
<vincenz>
cause yeah, if everything is boxed, it hardly matters
<ertai>
vodka-goo: for functors, no it static
<vincenz>
ertai: take for instance a function that maps over an array
<vodka-goo>
so they duplicate and specialize the function ?
<vincenz>
yeah
<vodka-goo>
or is the runtime dispatch more local ?
<vincenz>
what happens to the code of the function
<vincenz>
or is the dispatch on each float?
<ertai>
yes but it is a special case just for arrays containg floats
<ertai>
on each cell
<vincenz>
darn
<vincenz>
be better to just instantiate each function working on arrays for floats
<vincenz>
as extra special case
<vincenz>
and then just do a dispatch at the call of that function
<ertai>
yes but you need to do this instanciation over many levels sometimes
<vincenz>
true I guess
<ertai>
if your code is polymorphic
<vincenz>
but you should only really need to instantiate it for the callsites
<vincenz>
that use arrays
<vincenz>
so it's not excessive
<Smerdyakov>
ertai, floats are almost the exclusive domain of scientific computing people, who won't have many levels of abstraction to specialize. :)
<ertai>
vincenz: and call sites of any functions that use array of floats
<vincenz>
ertai: that's what I meant
<ertai>
with respect to the separate compilation it become harder
<vincenz>
true
<Smerdyakov>
The TIL compiler showed how to support this for separate compilation, though they _didn't_ show that they can do it with acceptable performance. :)
<vincenz>
but I just checked
<vincenz>
let head a = a.(o)
<vincenz>
if I specialize it for int array
<vincenz>
the code for head is just a MOV and a RET
<vincenz>
otherwise it's a comparison as well, and after that a lot of code bloat ANYAWYS for the floating case
<vincenz>
might as well special instantiate by callsite
<Smerdyakov>
Whole program optimization is the way to go.
<vincenz>
I fully agree
<Yorick>
ha
<vincenz>
c# actually has a nice solution for this
<vincenz>
they keep the imiplementation type-independent
<vincenz>
and then JIT it at runtime
<Smerdyakov>
I prefer static approaches.
<vincenz>
Smerdyakov: how do tackle libraries then?
<vincenz>
or do you suggest an intermediate compiled form
<vincenz>
and then a final whole code compiled form
<vincenz>
(which then poses questions for dynamic linking)
<Smerdyakov>
vincenz, I suggest an intermediate compiled form for code that should be specializable.
* vincenz
nods
<Smerdyakov>
vincenz, sometimes you need to prevent specialization to maintain abstraction.
<vincenz>
how so
<Smerdyakov>
If client code can see the representation of an abstract data type, he can subvert an interface.
<vincenz>
ah
<vincenz>
it's actually rather sad that haskell uses runtime dispatching, it has such an amazing compiletime type system and then for the implementatio nbasically reaches for the same solution as a dynamically typed langauge
poco has joined #ocaml
<poco>
hi
<poco>
i was reading old ml and found a Cons called a constructor function, any idea of what it was an what it is now?
<Smerdyakov>
I don't think I've entirely understood you.
<Smerdyakov>
Are you asking what Cons became, or what the idea of constructor functions became?
<poco>
both :)
<Smerdyakov>
Constructors are just constructors in OCaml parlance today, not constructor functions.
<Smerdyakov>
The two list constructors are [] and (::).
<vincenz>
constructor functions are informal lingo for defining a function that basically only creates a certain data type. The reason to have those is because constructrs are not first class.
<vincenz>
like
<vincenz>
let cons a b = a::b
<vincenz>
with the example Smerdyakov gave
<poco>
mmm.. okay...
<poco>
my example was this one: "let rec constant n = Cons (n, lazy (constant n));;"
<poco>
(the one i found in the ml)
<vincenz>
ah, then it's what Smerdyakov said
<vincenz>
it's a data constructor
<vincenz>
most likely somewhere you have
<vincenz>
seems like a lazy list
<vincenz>
yip
<Smerdyakov>
poco, I would think any OCaml tutorial would explain these concepts.
<vincenz>
poco: that's hardly old
<poco>
i tried but i just can find what it means :p the cons isn't documented anymore
<vincenz>
poco: It's most likekly something like
<vincenz>
type 'a lazylist = Cons of 'a * 'a lazylist
<Smerdyakov>
poco, "Cons" isn't built in. It's probably part of a library whose identity is clear in the context of that code.
<poco>
cons of?
<vincenz>
woops
<poco>
it works but what is it?
<vincenz>
I forgot to add a lazy type
<Smerdyakov>
poco, if you don't understand the "of," then it's time to read a tutorial.
<Smerdyakov>
poco, any tutorial covers it.
<poco>
ah!
<poco>
thanks by the way :)
<poco>
hopefully i found this chan
mauke has quit [Remote closed the connection]
mauke has joined #ocaml
<Smerdyakov>
If you need to join a language-specific channel to get the advice, "take the time to actually read the documentation," then you have bigger problems! ;)
* vincenz
ponders
<vincenz>
how do you force a lazy value again
<Smerdyakov>
vincenz, take the time to actually read the documentation.
<vincenz>
Lazy.force
<poco>
Smerdyakov: i was just trying to find what cons is it sin't documented
<vincenz>
poco: it's a data constructor
<vincenz>
poco: that's what you should be looking at "union types"
<Smerdyakov>
poco, I'm sure you skipped some documentation that would have explained it to anyone who had read a tutorial.
<vincenz>
and basically that tiny bit of code represents an infinite list that is constructed lazily
<vincenz>
(a constant list of all n's)
<poco>
yeah it was for streams programming...
<poco>
(the prog paradigm)
<poco>
Smerdyakov: let rec constant n = Cons (n, lazy (constant n));; <= it is *not* on the fm
<vincenz>
poco: of course not
<Smerdyakov>
poco, what is a "fm"?
<vincenz>
poco: but cons could be anything
<vincenz>
it might as well say
<vincenz>
let rec constant n = FooBar (n, lazy (constant n));;
<vincenz>
the very first chapter treats it
<Smerdyakov>
vincenz, you are not helping him by saying anything besides "read this tutorial through before asking any questions about the language."