mrsolo_ has quit [Read error: 110 (Connection timed out)]
GreyLensman has joined #ocaml
ez4 has quit ["Quitting!"]
monochrom has quit [Remote closed the connection]
CosmicRay has joined #ocaml
monochrom has joined #ocaml
ez4 has joined #ocaml
mlh has quit [Client Quit]
ianxek has joined #ocaml
<Smerdyakov>
Does anyone remember the name of a theorem that says "every group of <some particular kind> has a generator"?
Godeke has quit [Remote closed the connection]
GreyLensman has quit ["Leaving"]
CosmicRay has quit [Read error: 113 (No route to host)]
monochrom has quit ["Don't talk to those who talk to themselves."]
Nutssh has joined #ocaml
ianxek has quit ["Leaving"]
_fab has quit [Remote closed the connection]
_fab has joined #ocaml
async has joined #ocaml
<async>
how do you catch the exception that is thrown when you try to open a non-existent file?
<async>
oh wait
<async>
gah, im dumb
Hipo has joined #ocaml
mlh has joined #ocaml
Herrchen has joined #ocaml
srv_ has joined #ocaml
srv has quit [Read error: 232 (Connection reset by peer)]
Nutssh has left #ocaml []
pflanze has quit [Read error: 110 (Connection timed out)]
Tristram has quit [Remote closed the connection]
velco has joined #ocaml
<vincenz>
we know
mlh has quit [Client Quit]
eugos has joined #ocaml
vezenchio has joined #ocaml
_fab has quit [Remote closed the connection]
pflanze has joined #ocaml
kdka has joined #ocaml
slashvar[lri] has quit [Remote closed the connection]
rossberg has joined #ocaml
mlh has joined #ocaml
ianxek has joined #ocaml
kdka has quit [Read error: 104 (Connection reset by peer)]
<vincenz>
Can on have a functor taking more than one param?
kdka has joined #ocaml
mlh has quit [Client Quit]
ianxek has quit ["Leaving"]
ianxek has joined #ocaml
<vincenz>
What does type +'a t mean?
<vincenz>
what does the + do?
srv has joined #ocaml
srv_ has quit [Read error: 232 (Connection reset by peer)]
cjohnson has joined #ocaml
cjohnson has quit [Client Quit]
eugos has quit ["Leaving"]
pango has quit [Nick collision from services.]
pango has joined #ocaml
Godeke has joined #ocaml
ez4 has quit ["Quitting!"]
velco has quit ["Client exiting"]
_fab has joined #ocaml
kuribas has joined #ocaml
vincenz has quit [Read error: 232 (Connection reset by peer)]
vincenz has joined #ocaml
async has quit ["Lost terminal"]
tld has joined #ocaml
menace has joined #ocaml
<tld>
Any have experience with both Python and Ocaml?
<Smerdyakov>
Why do you ask?
mrsolo_ has joined #ocaml
<tld>
Just curious about where they are compared to one another on the 'language tree'.
<tld>
Both in terms of development speed and runtime performance.
<Smerdyakov>
Python is in the "runtime performance? ha!" part of the tree.
<Smerdyakov>
OCaml is in the "second only to C" category for performance.
<kuribas>
Runtime performance is not the point of a scripting language as Python or Ruby
<Smerdyakov>
Python makes it very hard to develop correct applications of non-trivial size. OCaml provides some of the best support around for doing that.
<Smerdyakov>
kuribas, he asked!
<tld>
kuribas: I did. :)
<kuribas>
ok, then :)
<tld>
Part of the question is, would it be cheaper to buy more hardware to run the slower Python, than it would to pay for more hours of Ocaml development?
<tld>
IE: How fast is the language to develop in?
<Smerdyakov>
tld, OCaml requires fewer hours to develop large applications with many opportunities for mistakes.
<tld>
Sounds good.
<Smerdyakov>
tld, perhaps Python is quicker for "toy" programs, where errors don't cost you as much debugging time.
<vincenz>
tld: I do
<vincenz>
tld: I ported a python app to ocaml
<tld>
vincenz: Any comments on how that went? (speed of developing in python compared to ocaml, how comfortable ocaml is to use etc?)
<vincenz>
and ocaml does not take more development time, if anything it reduces testing-time as it's strongly typed (statically)
<tld>
nice.
<tld>
It's OO, right?
<kuribas>
Aren't both language suitable for different problems?
<vincenz>
I find that my development time with both is the same, except that with python I have a lot more testing time due to the dynamism of the typing syste
<vincenz>
kuribas: no they overlap quit a bit
<tld>
Oh, and if I want to use something not already provided (such as postgresql connection), what are my options?
<vincenz>
tld: check the humps
<vincenz>
there should be modules for that
<Smerdyakov>
tld, experience OCaml programmers tend to avoid using OO features.
<tld>
hmm, ok.
<Smerdyakov>
OO is a bad fit for almost all problems.
<vincenz>
not really
<vincenz>
it depends on what you awnt to do
<vincenz>
stop bashing oo
<tld>
Bad example if there's a postgresql module, but humour me... Can I link to shared libs for example?
<vincenz>
oo like modules each have their place
<Smerdyakov>
vincenz, and OO is far less applicable than modules....
<vincenz>
not really
mrsolo has quit [Connection timed out]
<kuribas>
Smerdyakov OO is very useful for gluing parts of code
<Smerdyakov>
vincenz, well, your opinion is different from that of most OCaml users.
<Smerdyakov>
kuribas, such "glue" where OO is truly appropriate makes up a very small part of a well-designed system.
<vincenz>
Smerdyakov: I have an abstract statemachine and then depending on which option the user passes I instantiate a different statemachine which does different stuff but has th same interface
<Smerdyakov>
vincenz, and that should be a tiny part of your code.
<vincenz>
tld: link to share dlibs? you can't do that with python either, for either you'd have to write a wrapper which I think is about the same
<vincenz>
Smerdyakov: yes but it's still useful
<vincenz>
you're just bashing it cause you like SML more and ti doesn't have OO
velco has joined #ocaml
<tld>
vincenz: Python can dlopen the lib...
<vincenz>
of course to you it will seem less useful, you come from a place that doesn't ahve it, it doesn't fit into your programming model
<tld>
Anyway, I can make a wrapper for a shared lib to make a ocaml module?
<vincenz>
tld: oh, that can't be done with ocaml unless you make a wrapper....
<Smerdyakov>
vincenz, no. It seems you agree that OO is a niche feature and not the appropriate tool for overall application structuring, so I don't know what we're arguing about.
<kuribas>
Smerdyakov, I wouldn't say an interface is a small part of a system
<Smerdyakov>
kuribas, look at the amount of code and you will find that it is.
<kuribas>
I think most desktop apps could be better written in an OO-language
<kuribas>
for example a spreadsheet
<Smerdyakov>
And they could be even better written using an ML-like module system as the main structuring technique.
<tld>
OO has it's advantages, but you can get same advantages with a struct and a function pointer in C.
<velco>
tld: ever tried that ?
<kuribas>
tld: that's not the same as OO
<kuribas>
tld: try smalltalk or Ruby
mrsolo_ has quit [Connection timed out]
<tld>
velco: Yeah.
<velco>
tld: multiple inheritance by hand? "this" pointer adjustment thunks by hand ?
<kuribas>
I would say a functional language is best for difficult problems as compilers or parsers
<tld>
kuribas: True. For one thing, it'd be a everyone-rolling-their-own thing.
<Smerdyakov>
kuribas, what level of experience with ML-like languages do you have?
<tld>
kuribas: I've used Ruby. Didn't get the mature fuzzy feeling I was looking for though.
<kuribas>
almost none ;)
<kuribas>
So take my ideas with a grain of salt...
<Smerdyakov>
kuribas, OK. Then I think you should be honest and say that you have no idea what the best language choices are for those problems.
<kuribas>
Smerdyakov: what level of experience do you have with Ruby?
<Smerdyakov>
kuribas, none
<tld>
Hmm, so to sum it up. If I lean Ocaml, I'll be able to develop in rougly the same time as I'd use in Python, but my programs will run a lot faster. I can make wrappers for shared libs if I need it, and there's already quite a bit of stuff available.
<tld>
What about learning curve for the language itself?
<Smerdyakov>
Broaden that to "Ruby-like languages" as I did, and then I have a bit more.
<Smerdyakov>
tld, that depends on what programs you are writing.
<Smerdyakov>
tld, I maintain that you will be able to develop programs of non-trivial complexity in much _less_ time than with Python.
<tld>
Smerdyakov: Nice!
<kuribas>
Smerdyakov: wasn't that just my point?
<velco>
with ocaml ? or with sml ?
<Smerdyakov>
kuribas, what was?
<Smerdyakov>
velco, about the same with both.
<tld>
Let's say I want to make a web application... I'd typically need a webserver (already available?), database connection, templating engine, and some business logic.
<kuribas>
that functional languages are good for hard problems, and OO languages for creating interfaces
<velco>
hmm, that's good, since ocaml seems to be much more widespread, whereas I somehow lean towards sml, for reasons I can't explain, gut feeling maybe ..
<Smerdyakov>
velco, that's for historical reasons. More resources expended on practical tools at an earlier point in time.
<tld>
Hmm
<Smerdyakov>
kuribas, no, I think ML-style module systems are much better at creating interfaces.
<tld>
I was thinking about Ocaml, not sml... Hard to convert between the two?
<kuribas>
Smerdyakov: you can argue, but saying I have more experience is a bad way to prove your point
<Smerdyakov>
tld, I prefer SML. The non-OO part of OCaml is almost identical to SML, modulo surface syntax.
<Smerdyakov>
kuribas, why? I have lots of experience with both ML and OO,.
<Smerdyakov>
kuribas, it should be clear that ML-style module systems provide a much richer language for describing interfaces, so they can only be _better_ at this. There's not really any room for argument.
<tld>
Smerdyakov: What about runtime speed of Ocaml compared to SML?
<Smerdyakov>
tld, rougly equal now. I am betting on SML having better tools in the long run.
<Smerdyakov>
tld, the best SML compiler comes out slightly ahead of OCaml for runtime speed in the latest Programming Language Shootout.
<kuribas>
Smerdyakov: richer language than what?
<tld>
nice
<tld>
What about unicode and XML?
<Smerdyakov>
kuribas, any primarily OO language I've ever seen.
<Smerdyakov>
tld, there are XML libraries, and you can use most any C libraries with a bit of work.
<kuribas>
Smerdyakov: Try ruby!
<kuribas>
are those compilers free?
<Smerdyakov>
kuribas, you're claiming that Ruby has a richer interface language than an ML module system?
<haakonn>
but ruby is interpreted and probably not as fast
<Smerdyakov>
All the compilers on the Shootout are free.
<kuribas>
haakonn: absolutely
<kuribas>
the nice thing about OO is that you can let components talk to other components without putting any restrictions
<Smerdyakov>
That's not an interface. That's a _lack_ of one. Make up your mind about what you're talking about. :P
<tld>
Smerdyakov: Any suggestions on which SML compiler I should look at?
<Smerdyakov>
tld, SML/NJ
<kuribas>
Smerdyakov: That's a minimal one, with maximal flexibility
<Smerdyakov>
tld, MLton for compiling release versions.
<avlondono>
tld, as a side question, what languages do you really know? why do you have to choose one now?
<Smerdyakov>
kuribas, and minimal ability to catch bugs at compile time.
<Smerdyakov>
kuribas, and minimal ability to understand program structure by reading comment-free code.
<mellum>
Smerdyakov: why MLton only for release versions? Is it too slow, or are the error messages too bad?
<tld>
I wouldn't say I feel comfortable with all those anymore though.
<kuribas>
Smerdyakov: Hey, I don't need to convince you OO is better, if you don't want to use it
<tld>
Currently using mostly Python.
<Smerdyakov>
kuribas, you're saying that you can quickly determine the component structure and interfaces of a Ruby program just by looking at comment-free code?
<kuribas>
Smerdyakov: yes
<Smerdyakov>
melchus, too slow. The error messages are probably good enough now, but they weren't always.
<Smerdyakov>
kuribas, I don't believe you.
<kuribas>
Smerdyakov: fine
<tld>
avlondono: I don't have to choose one now, but I thought it'd be interesting to look for alternatives. Also, I'm thinking about starting some projects that I don't think I want to use Python for.
<tld>
avlondono: And development in C is really slow.
<Smerdyakov>
kuribas, I presume that you must look at the implementations of classes/objects to do that?
<avlondono>
then go for both, ocaml and ml, I think it will be easier to atack ocaml first
<Smerdyakov>
kuribas, in ML, you need only look at signatures.
<avlondono>
then ml will come easily
<kuribas>
tld: yes
<tld>
avlondono: If Ocaml delivers speed comparable to C, with development speed comparable to Python, it should be really interesting.
<avlondono>
it is interesting by far more reasons
<avlondono>
that will be apparent as you try them
<kuribas>
Smerdyakov: yes
<kuribas>
what about using both?
<Smerdyakov>
kuribas, what?
<tld>
avlondono: Yeah, I'm guessing. But it's what makes it have anything to offer that the languages I know don't.
<kuribas>
Smerdyakov: looking at the classes
<Smerdyakov>
kuribas, why would I want to do that when I don't need to?
<avlondono>
no, I think the correctness of the code is far more important
<kuribas>
Smerdyakov: you can use rdoc to generate documentation, but the classes are the interfaces
* tld
will bbiab.
<Smerdyakov>
kuribas, why would I want to use English documentation when the code can be self-explanatory?
<kuribas>
Smerdyakov: you need to use it only when it isn't of course
<Smerdyakov>
And I assert that that will be much more often with Ruby than ML.
det has quit [Read error: 104 (Connection reset by peer)]
det has joined #ocaml
<avlondono>
Smerdyakov: that's very much deppending on the programmer and how it was structured.
<Smerdyakov>
avlondono, I'm saying that ML allows the optimal programmer to make more understandable code than Ruby does.
<kuribas>
Smerdyakov: I cannot agree with that
<kuribas>
Smerdyakov: You cannot get more understandable code than with Ruby
<Smerdyakov>
kuribas, I wouldn't expect you to, since you know almost nothing about the features ML provides.
<avlondono>
I won't argue that. I prefer ml in any case. an issue is that most people was almost grown using OO or impreative languages, so it's actually harder for them. and so, it's reltive.
<mflux>
smerdyakov, so taken one optimal programmer for ML and one optimal programmer for Ruby, the code written for ML for the same task will always be more understandable then for Ruby?
<kuribas>
Smerdyakov: I hope to learn about them :)
<Smerdyakov>
mflux, for the majority of tasks, at least.
<kuribas>
Smerdyakov: It was not my intention to say which is best, but which is best for which kind of task
<kuribas>
Smerdyakov: But I think you want to use ML for all of them
pango has quit [Connection timed out]
<kuribas>
Smerdyakov: I thought that the ocaml compilers produce more efficient code than sml compilers
<Smerdyakov>
kuribas, not anymore.
<kuribas>
And those sml compilers are free?
<avlondono>
and those sml compilers are slow
<Smerdyakov>
Yes
<velco>
slow?
<Smerdyakov>
avlondono, slow compilation doesn't matter, really. You develop with a fast compiler and compile release versions with the slow, optimizing compiler.
<avlondono>
it bothers me :-) of course I can get used to it
<kuribas>
or use the interpreter...
<kuribas>
Is there an ML compiler for the Palm-platform?
<avlondono>
no, the interpreter is not an option in my case
<avlondono>
it would be too slow for most testing cases
<avlondono>
anyway, I better work now
karryall has joined #ocaml
<kuribas>
There is a caml-light compiler for palm, but it doesn't seem to work
docelic has joined #ocaml
<vincenz>
What does "type +'a t" mean?
<vincenz>
what does the + mean?
<karryall>
vincenz: variance information
<karryall>
in this case covariance
<vincenz>
?
<karryall>
it means that if u is a subtype of v
<karryall>
then u t is a subtype of v t
<vincenz>
yes
<vincenz>
ah :)
CosmicRay has joined #ocaml
<kuribas>
Wouldn't it be nice to have an ocaml or sml compiler for palm?
* vincenz
made a trie library, it pretty much as all the same functionality as Map (I mean the same functions) except for compare (there is no total ordering....) and I'm not sure how to do iter
<karryall>
don't you have a fold ?
<vincenz>
no
<vincenz>
not either
<vincenz>
not quite sure how do to fold over something which does not have an ordering
<vincenz>
I mean
<vincenz>
how should order be defined? lexically?
<karryall>
I don't see the problem
<vincenz>
hmm
<karryall>
no order
<vincenz>
there's also the issue of printing out the structure
<vincenz>
I mean Trie.iter...
<vincenz>
if I have "ab" -> 0 and "abcd" -> 0
<karryall>
there is (at least one) trie implementation in Baire
<vincenz>
then a simple iter could print this
<karryall>
you could have a look
<vincenz>
but
<vincenz>
hmm
<vincenz>
ok
<karryall>
but really I don't see the problem
<vincenz>
well I would like something like
<vincenz>
a ->
<vincenz>
b-> 0,
<vincenz>
c->
<karryall>
just do a traversal of your tree and that's it
<vincenz>
d->0
<vincenz>
yes but ... some nodes don't have an entry, some do
<vincenz>
so should I make the iter function take an 'option' value?
<karryall>
it depends on how you want your datastructure to behave
<vincenz>
yeah I'll do it like that
<vincenz>
it's the most generic solution
<karryall>
if you want something equivalent to Map, no do not care about empty nodes
<vincenz>
it's different tho
<vincenz>
from outside Map can be seen as a set/list
<vincenz>
structure is not important
<vincenz>
for a trie it is
<karryall>
a trie is just a map whose key type happens to be a list
<vincenz>
not really
<vincenz>
well yes
<vincenz>
but I'm envisioning it more like a structured thing
<vincenz>
so "abcd" is inside "ab"
det_ has joined #ocaml
det has quit [Read error: 113 (No route to host)]
<karryall>
ok
<mflux>
how useful is ocaml's lazy evaluation in practice? you can't use with with for example pattern matching, can you?
<mflux>
s/with/it/
<karryall>
indeed, you cannot
<mflux>
without using guards that is, but that's more work
<mflux>
perhaps a nice set of operators could make using them more convenient
<Demitar>
Sounds like a job for... Captain Camlp4! (* No, it's not me. :) *)
<karryall>
:)
<karryall>
not sure though
<karryall>
you can't bind identifiers in guards
<mflux>
it's a shame that the pattern matching doesn't support evaluating functions, dunno what the syntax would be though ;)
<Demitar>
It would be insane for pattern matching to evaluate anything. Then it would have to evaluate every case to make sure all side-effects are predictable.
<tld>
I completely forgot to ask... Does Ocaml offer threading?
monochrom has joined #ocaml
<mflux>
yes. within the bounds of a single cpu though if you stick to pure ocaml.
<tld>
thanks
<tld>
Is Ocaml functional-programming-only?
<mflux>
functions may have side effects
<mflux>
it is a bit unclear what you mean though
<mflux>
you can write something that resembles imperative code if you wish, assign values to variables etc
<tld>
I mean, is Ocamls a pure functional programming language?
<mflux>
no
<mflux>
in that area I believe haskell is a worthy contender
pflanze has quit ["[x]chat"]
Nutssh has joined #ocaml
<tld>
Hmm, any thoughts on Ocaml vs. Lisp?
<mflux>
I very much prefer ocaml over lisp
<tld>
Any particulair reasons?
<mflux>
static typing
<mflux>
fast compiled code
<mflux>
nicer syntax ;)
<velco>
lisp is fast too
<Nutssh>
LISP has the faster code, and compilers can have some static compile-time type checking.
<tld>
Nutssh: LISP is faster than Ocaml?
<Nutssh>
Its close enough that there's not much point in worrying about the difference.
<tld>
Any good arguments for choosing one over the other (in either direction?)
<Nutssh>
However, cmucl does have a real optimizing compiler. ocaml has a native code compiler, but its not an optimizing compiler.
<velco>
ML has a wonderful module system
* velco
has just read about it :D
<Smerdyakov>
OCaml is a tool for a scientist.
<Nutssh>
modules.. Typing and type inference can be nice when you're doing second and third order functions. Easy to make a mistake.
<Smerdyakov>
Lisp is a tool for a wishy-washy fau artist. ;)
<Nutssh>
And they're both worthless languages made by academics. Real coders use C++. If you can't have a buffer overflow, its not a real language. :)
<Demitar>
Oh the joys of spurious segfaults!
* Demitar
dreams back to his C++ days...
<Nutssh>
Forgot about those.. I guess i"ve been coding ocaml&lisp too long.
<velco>
Nutssh: indeed, I can't see any optimization source in ocaml (except some scheduling)
<velco>
Nutssh: but it appears competetive nevertheless
<Nutssh>
ocaml does dead code elimination.
<velco>
Nutssh: wonder why ?
<tld>
Nutssh: I'll probably learn both, right now I'm trying to figure out which to learn first, ocaml or lisp.
<Demitar>
I'd say OCaml.
<velco>
SML
<tld>
For which reasons?
<Nutssh>
It doesn't do *any* sort of redundancy elimination... Look at let f x = x*x*x*x*x and cry.. It copies x into 5 registers, detags all of them (right shift by 1 bit), and does the multiplication. I could cry. I suspect it is competative because modern CPU's are superscalar enough that the extra operations are absorbed in the ILP headroom.
<Demitar>
The typing does it all. At first you get confused, then you get curious, then you get angry and finally you get enlightened and is forever hooked. ;-)
<Nutssh>
Type inference.. But, I've been thinking back on lisp with more fondness.. I might switch from ocaml back to lisp.
<karryall>
Nutssh: hmm, how would you proceed with the x*x*x*x*x ?
<tld>
Anyone know if there's a webserver framework I could use to make a web application in Ocaml? Seems like a waste to use it as a CGI under Apache.
<Smerdyakov>
Nutssh, waaait... OCaml's lack of optimization makes you want to switch to _Lisp_?
<Nutssh>
Detag the x once, reassociate it, perform 2 mults in paralel, then two more sequentially. Need fewer registers. Or be smart and use 3 mults.
<Demitar>
tld, you want a webserver or a constantly running ocaml application speaking with apache?
<karryall>
yeah ok
<Smerdyakov>
tld, I've done it before with SML.
<Smerdyakov>
tld, nothing released, though.
<Nutssh>
Smerdyakov: Lol. No. They're both competetive with each other and with C++. (Lisp isn't slow, damn it!) Because of the ability to write code transformers in lisp when you need to. Ability to automate a lot more of the coding process.
<jbm>
hmmm. smerdyakov -- is that the servant in brothers karamazov?
<Demitar>
WDialog itself seems to have fallen into a bit of disrepair though.
<Demitar>
(Which of course could mean it's working so good noone bothers. ;-)
<Smerdyakov>
jbm, he is the illegitimate brother.
<Smerdyakov>
Nutssh, I see. Good. :-)
<Smerdyakov>
Did anyone here submit anything to TLDI 2005?
<jbm>
Smerdyakov: yeah; also the servant of fyodor though, right?
<Smerdyakov>
jbm, I forget the details.
<jbm>
ah. heh.
<kuribas>
so if ocaml doesn't optimize, that's the reason it comes after C in the shootout?
<velco>
the programs were hand optimized, probably
<mflux>
the language shootout programs are available, and they don't seem terribly 'unfair'
<kuribas>
except fibonacchi :)
<jbm>
so write and submit a new one.
<kuribas>
it uses an accumulator, while the others are recursive
<velco>
and note that "close" to C means "twice slower"
kdka has quit []
<kuribas>
velco: so with optimizations, it might be faster
<velco>
nope
cmeme has quit [Remote closed the connection]
<velco>
a) gcc will become better too, b) there might not be much room for optimization
<Smerdyakov>
velco, you are quick to give that answer. How do you justify it?
<kuribas>
velco: C doesn't always give the best machine code
cmeme has joined #ocaml
<Smerdyakov>
I've verified that MLton produces faster code than gcc for summing the elements of large arrays, for instance.
<kuribas>
Pointers can make C code slower than it could be
<kuribas>
the compiler must asume the pointer could be accessed outside a function, even when it isn't
<velco>
kuribas: nope
<velco>
kuribas: not necessarily
<kuribas>
velco not necessarily what?
<velco>
Smerdyakov: justify what? predictions for relative quality of compilers ?
<velco>
kuribas: "escape analysis" are the keywords
<velco>
kuribas: "alias analysis" too
<kuribas>
velco: how can the compiler now that for functions out a header file?
<velco>
kuribas: I said "not necessarily"
<kuribas>
It is the side-effects that prohibit certain optimizations
<velco>
and for functions "out a header file" I guess the compiler knows everything about them, unlike the case of function declarations out a headre file :)
<kuribas>
velco: that last one is what I meant
<velco>
kuribas: and copies directly pessimize code
<velco>
and have utterly negative cacche effect
<kuribas>
what do you mean with copies? Inline functions?
<velco>
I wouln;t worry that much about side effects
<Smerdyakov>
Unless you copy into a register. :)
<velco>
Smerdyakov: yeah, if you happen have one available :)
<velco>
kuribas: I mean the purely functional way with persistent data structures
<jbm>
isn't it obvious that gcc has room for improvement since it falls behind icc and msvc ?
<velco>
although I /suspect/ compilers could optimize copies away ...
<mflux>
velco, why would you need to make copies of persistent data structures?
<kuribas>
velco: yes
<Smerdyakov>
Compilers don't need to be _too_ smart to detect that it's possible to write over old functional data structures that become dead after an operation.
<velco>
(dunno, I'm yet to read something abut suck optimizations)
<velco>
s/suck/such/
<kuribas>
velco: pointers are not good for an optimizing compiler
<velco>
mflux: think for examle how would you insert in a stack without side effects
<velco>
kuribas: sure
<kuribas>
I think a compiler could do more analysis on a functional language, and generate better code
<mflux>
velco, 'insert in a stack'?
<velco>
kuribas: but pointers are good for writing /different/ algorithms
<docelic>
jbm: nothing falls behind msvc..
<mflux>
stack being cpu stack or some language data structure?
<velco>
mflux: ok, "push in a stack"
<velco>
mflux: abstract stack
<mflux>
let stack_with_inserted_item = new_item :: current_stack;;
<kuribas>
velco: they are close to the machine, but they aren't an essential part of computing
<mflux>
it merely references to the current stack
<velco>
yup and now you have two stacks
<jbm>
docelic: as a compiler I believe the msvc one beats out gcc in a lot of tests.
<mflux>
I can't see how much more work that is than inserting something to an existing stack
<jbm>
in terms of performance.
<mflux>
you still need to copy stuff around, maybe even more so
<jbm>
compliance is a different issue ;)
<velco>
mflux: and it doesn not merely reference the old stack, which you can check by popping from both stacks
<mflux>
uh
<kuribas>
C compilers are more advanced because everyone uses C
<mflux>
maybe so, as it seems to me that you are ;)
<velco>
<velco> mflux: think for examle how would you insert in a stack without side effects
<velco>
now, mopdifying memory cells is a side effect. assignment is a side effect.
<mflux>
of course the cpu will have 'side effects'
<mflux>
but from the pov of the program there aren't side effects
eugos has joined #ocaml
<mflux>
the above I think is a replica of code let foo = let old_item = [1] in let new_item = 2::old_item in let popped_item_1 = List.tl new_item in let popped_item_2 = List.tl old_item in ();;
<mflux>
and as far as I can see there aren't any side effects
<velco>
it is not
<velco>
you have assignment. assignment is a side effect.
<mflux>
and?
<mflux>
you have a program for some cpu that doesn't use assignment?
<velco>
here's your stack without side effects and lotsa copies
<mflux>
I see
<mflux>
what assignment were you referring to btw?
Axioplase has joined #ocaml
<mflux>
in the ml- or c++-code?
<velco>
in the C++ code
<mflux>
I saw only initializations
<Axioplase>
Chat Lu!
<haakonn>
i'd like to see a C++ program that does anything interesting and doesn't have assignments :)
<velco>
which *modifies* the structure inplace
<mflux>
initialization modifies a structure?-o
<mflux>
which statement is that?
* kuribas
is very disappointed in ocamls native code generation
<Nutssh>
A lot of software is branch prediction or cache-miss limited. Extra instructions don't matter as much, especially withy superscalar CPU's. I do wish that ocaml did loop-invariant code motion. I write all of my loops expecting the compiler to be at least that smart. Ocaml's isn't.
<mflux>
let's rewrite it without the annoying assignment operators: Foo& popped_item_1(*new_item.next); Foo& popped_item_2(*old_item.next);
<Nutssh>
Also, redundancy elimination usually extends register lifetimes increasing register pressure and spilling on something register-poor like x86.
<velco>
mflux: indeed, there are no assignments, but there are no pops too
<velco>
mflux: pop is supposes to eventually empty the stack
<mflux>
velco, if you take that view then neither does the ml-code you provided either
<haakonn>
Nutssh: so don't use imperative loops :)
<mflux>
velco, c++ just doesn't have garbage collection so the stuff stays in memory
<velco>
mflux: sure it does
<velco>
just execute the last line several times
<mflux>
it doesn't empty the old stack
<mflux>
the old stack is there
<mflux>
you just view it from the second element
<mflux>
very much like the c++ code
<velco>
mflux: yep, it creates a new stack
<velco>
mflux: i.e. conceptually copies
<velco>
and the new stack has less elements
jbm has left #ocaml []
<mflux>
I thought we were talking about real copies, as the topic was optimization?-o
<velco>
and the old stack is there
<velco>
anbd yuo can push in it
<kuribas>
ocaml generates an imull instruction for 3 * a
<velco>
val (elt, si) = S.pop (si)
<kuribas>
that's many clock cycles
<velco>
well if I rewrite this as
<velco>
val (elt, sii) = S.pop (si)
<velco>
there si and sii will be bound to different values
<velco>
and pushing on either one would not affect the other
<Nutssh>
Happens even with tail recursive loops. Tail recursion/closure generation happens as one of the first passes. I don't want to have to factor loop invariant code out of a loop manually, thats what a compiler's for! (And no, I don't.. 2ghz cpu's are fast enough that I seldom even notice the difference.. my last two programs were performance limited on the random number generator.)
<mflux>
that's just nice way of saying 'put a copy of the first value to the 'variable' elt and a reference to the second element in the stack to var si'
<Smerdyakov>
Damn those random numbers!
<kuribas>
Nutssh: a compiler could even make recursive loops tail-recursive
<velco>
mflux: ok, stack is a bad example, try with a queue
<Nutssh>
Not all recursion is tail recursion.
<mflux>
velco, bad example of what?
<Smerdyakov>
Nutssh, it is with a CPS transform!
<Nutssh>
How about we get rid of recursion entirely and compile to turing machines instead of the lambda calculus? :)
<kuribas>
Smerdyakov: true, but then you are building up continuations, which is back the same problem
<Smerdyakov>
Let's get rid of computation by compiling to oracles.
<velco>
mflux: bad example for demonstrating the difference between purely functional and imprerative programs
<Smerdyakov>
kuribas, 'twas but a joke.
<kuribas>
Smerdyakov: oh, sorry
<Smerdyakov>
kuribas, now you owe me fifty cents.
<Nutssh>
Awe.. I wanted a pet oracle of my very own. :)
* kuribas
thinks ocaml would beat C if it did extensive optimizations
<mflux>
velco, writing a purely functional O(1) queue might turn out to be tricky..
<velco>
make it O(n)
<mflux>
for insert or removal? apparently code to do that can be found from the net
<velco>
fun pop (h::t) = (h, t); fun add (a, q) = q @ a;
<Smerdyakov>
Everyone knows the functional queue implementation with amortized constant time. :)
<mflux>
well, trivial implementation being that ;)
<Smerdyakov>
Do you fellas know what I'm talking about?
<Nutssh>
Chris Osaki's PhD thesis out of CMU.
<velco>
Smerdyakov: as a n00b in (mostly) functional programming, I don't.
<Smerdyakov>
It was an example of amortized analysis given in a Data Structures class that I took.
<Smerdyakov>
Represent a queue as a pair of stacks.
<velco>
ah
<Smerdyakov>
Every so often, you need to transfer one stack to another, but you can "charge" this time to the original insert operations.
eugos has quit ["Leaving"]
<velco>
I just read something similar in Harper's book
<vincenz>
euhm
<vincenz>
with a doubly linked list, queues are O91)
<Nutssh>
Robert Harper has a book out?
<vincenz>
O(1)
<mflux>
too bad functional languages usually don't provide functional doubly linked lists ;)
<Smerdyakov>
velco, you mean Intro to SML?
<vincenz>
you can make one
<velco>
yup, 18.2.1
<vincenz>
it ain't pretty but it should be possible
<Smerdyakov>
Nutssh, he's had that book in unpublished form for many years.
<mflux>
and it propably would be O(1) only if amortized analysis is taken into account
<Nutssh>
mflux: Its doable, but unless you want an O(n) insert/delete, you gotta be able to mutate the list and then its not functional.
<velco>
vincenz: we're talking purely functional
* Nutssh
worked with him for about a year, a few years ago as an undergrad.
<Smerdyakov>
Nutssh, same for me. I just got a paper with him into a workshop, in fact. :)
<Nutssh>
Congrats!
<Nutssh>
You know Walid Taha?
<vincenz>
oh, no. purely functional it's not possible :/
<Smerdyakov>
Nutssh, I know the name and I've seen him at ICFP, I think, but that's it.
<mflux>
well, there are some tricks you can use
<Nutssh>
Ok.
<mflux>
like building the reverse list while iterating forwards the list
<mflux>
but then you can't insert anywhere else than at the iterator without even more tricks ;)
<Nutssh>
vincenz: Oh doh, yeah.. how does one make a cyclic functional graph. AFAICT, purely functional can only create dag's.
<vincenz>
Lazy evaluation put the non-functional stuff at a level under the language level so it's transparent..
<vincenz>
lazy evaluation needs side-effects to wor
<vincenz>
(isnide the evaluation engine_
<velco>
the point is that they do not mess with the compiler's reasoning about the program
<vincenz>
no, but that's only cause the compiler knows where the side-effects are, not cause there are none
<velco>
nope, it's the compiler, which puts the side effects there
<vincenz>
well yes
<vincenz>
but from a purely semantical point of view
<vincenz>
lazyness requires side-effects
<velco>
that's an implementation idionsyncrasy
<Smerdyakov>
Idiotsynchronization!
<vincenz>
I do not believe so
<velco>
*shrug*
<vincenz>
anyways.... this discussion is theoretical
<vincenz>
and I wouldn't be able to compete in it
<velco>
one can reason abiut the program (correctness, termination, invariants, etc) without the notion of "side effect" hence the side effect is purely implementation phenomena
<vincenz>
yes
<vincenz>
but to be able to reason how the program would work, you do need side-effects, at least that's my gut feeling
<Smerdyakov>
vincenz, bullshit.
<vincenz>
just a gut feeling
<vincenz>
either way, my point is that for cyclic structures you need side-effects
<Smerdyakov>
vincenz, the main _benefit_ of functional style is that you _don't_ need to consider side effects.
<velco>
e.g. a CPU operates with no side effects inside
<Smerdyakov>
vincenz, the semantics is equivalent to one based on a purely mathematical view of programs.
<vincenz>
hmm
<vincenz>
maybe I should read up on this, this ain't my field
<vincenz>
but imho I think that for cyclic datatstructures you need side-effects at some level
<Smerdyakov>
This isn't something that involves "opinions."
<Smerdyakov>
You don't need "side effects" for that any more than you do for recursive functions.
<Smerdyakov>
Both recursive kinds of objects are defined as the least solutions to sets of equations.
<velco>
for me whether it is *needed* is a purely theoretical question as I *will* use side effects :D
<vincenz>
velco: :)
<vincenz>
Smerdyakov: yes but seeing that solutions are calculated as fixpoint solutions, any solution is an iterative solution that builds upon the previous result, you cant' get recursivity in that
<vincenz>
you need side-effects, even if it's hidden by a language-feature, to get cyclic structures
<Smerdyakov>
vincenz, I see you are not familiar with domain theory? :)
<vincenz>
I'm an EE
<vincenz>
CS isn't my background
<Smerdyakov>
vincenz, domain theory provides a completely function account of fixed points.
* vincenz
read a book lately on domain theory
<vincenz>
forgot by whom
<vincenz>
Smerdyakov: well there you go, in domain theory you can't get cyclic domains
<vincenz>
cause it's constructive
<vincenz>
anyways, I'm not getting itno this
<Smerdyakov>
Nonsense. I can have a domain of cyclic lists.
<Smerdyakov>
It's even an example in a book I have. :)
<vincenz>
I'm not a CS background, I don't have the terminology nor the theory to get into this dicussion
<vincenz>
Smerdyakov: denotational semantics?
<Smerdyakov>
Yes
* vincenz
read it
<Smerdyakov>
I mean that's the subject, not the name of the book.
<vincenz>
there's a famous book from 86
<Smerdyakov>
The book is "The Formal Semantics of Programming Languages," by Winskel.
<vincenz>
no that's not
<Smerdyakov>
I mean "that's the book I referenced above."
<vincenz>
Denotational Semantics by David A. Schmidt
<Smerdyakov>
Oh, thanks. I almost forgot he is giving a talk here in a few hours. :D
<vincenz>
cool :)
mattam has quit [Remote closed the connection]
mattam has joined #ocaml
<Axioplase>
++
Axioplase has quit [Remote closed the connection]
<vincenz>
--
eugos has joined #ocaml
velco has quit ["I'm outta here ..."]
CosmicRay has quit ["Client exiting"]
ianxek has quit [Remote closed the connection]
Godeke has quit ["Leaving"]
eugos has quit ["Leaving"]
kuribas has quit ["Leaving"]
tld has quit ["Leaving"]
Niccolo has left #ocaml []
Niccolo has joined #ocaml
dxlvi has joined #ocaml
<dxlvi>
:[
<dxlvi>
read_line ();; crashes the windows version of ocaml
<Smerdyakov>
Don't use Windows!
* Demitar
ponders the Free-ness of felix.
<dxlvi>
Smerdyakov, i dont want to... but
<dxlvi>
hm but it's already in bts :/
async has joined #ocaml
<monochrom>
that is odd.
<Demitar>
Isn't it horribly non-free actually? Due to the included frontc and cil with a "... Permission to use, copy, modify and distribute this software for research purposes only is hereby granted, provided that ..." clause.
<Smerdyakov>
Demitar, what is "it"?
<async>
Smerdyakov: are you in soda right now?
<Smerdyakov>
async, no, but in 15 minutes I will be.
<monochrom>
"information wants to be free! entropy wants to increase!"
<async>
which room?
<Smerdyakov>
async, 310. The Programming Systems Seminar.
<async>
is there a way to remove characters after you've written them to stdin?
<monochrom>
Not if you don't buffer it.
<async>
ok
<monochrom>
If you buffer it and have access to the buffer you can try regretting it.
<monochrom>
It's like "how do I withdraw an email after I've sent it" hahahaha of course you're doomed!
<async>
by 'buffering' do you mean setting up an arbitrary buffer that i modify, and then i write it to stdin when its ready?
<async>
monochrom: yeah, and for news messages :)
<monochrom>
Sometimes the runtime has a buffer and lets you muck with it.
<monochrom>
But it's safest if you maintain your own buffer so you have full access and full guarantee.
<async>
i see
<async>
i'm trying to do a command history thing for the console
dxlvi has left #ocaml []
<monochrom>
Most consoles support a "delete key" or "backspace key". This does not remove anything from stdin. Rather, it removes things from the console.
<monochrom>
In fact it can be pretty ironic. The backspace key causes a backspace character to be *added* to stdin. The console, upon seeing the additional backspace key, responses by removing things in its own place.
<async>
i see
vezenchio has quit ["None of you understand. I'm not locked up in here with you. YOU are locked up in here with ME!"]
<monochrom>
In other words, console != stdin. Rather, stdin is the communication channel between your program and the console.
<monochrom>
If you find out what message to send (through stdin) to the console to tell it to remove things, you send that message. Then everyone is happy.
<monochrom>
or maybe it's stdout rather than stdin.
<async>
hehe
tnks has left #ocaml []
async has quit ["leaving"]
<pango>
what about using ledit... ftp://ftp.inria.fr/INRIA/Projects/cristal/Daniel.de_Rauglaudre/Tools/
tnks has joined #ocaml
mlh has joined #ocaml
<pango>
alias locaml='ledit -h ~/.ocaml_history -x ocaml'
monochrom has quit ["Don't talk to those who talk to themselves."]
async has joined #ocaml
<async>
is there a getch() equivalent for ocaml?
<async>
all the input_* functions don't process input instantaneously