<Zadeh>
I s'pose it's partly that it seems fairly specific and not general
<Zadeh>
mrvn: made anything cool in ocaml?
<mrvn>
working on a few things.
<mrvn>
mldonkey for example.
* Riastradh
is writing a game in OCaml.
docelic is now known as docelic|sleepo
<Zadeh>
oh yeah, why the double ;; ? :)
<Zadeh>
(Is there a FAQ? :)
<Riastradh>
; is already used.
Smerdyakov has joined #ocaml
PsionV has joined #ocaml
Smerdyakov has quit [Killed (NickServ (Nickname Enforcement))]
PsionV is now known as Smerdyakov
docelic|sleepo has quit [Excess Flood]
docelic|sleepo has joined #ocaml
noss has quit ["[x]chat"]
kirk has joined #ocaml
rhil_work is now known as rhil
lus|wazze has quit ["Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Univ]
Zadeh has quit [asimov.freenode.net irc.freenode.net]
smkl has quit [asimov.freenode.net irc.freenode.net]
Yurik has quit [asimov.freenode.net irc.freenode.net]
mrvn has quit [asimov.freenode.net irc.freenode.net]
Zadeh has joined #ocaml
smkl has joined #ocaml
Yurik has joined #ocaml
mrvn has joined #ocaml
Kinners has joined #ocaml
Smerdyakov has quit ["I explode."]
lament has joined #ocaml
reltuk has quit [Read error: 104 (Connection reset by peer)]
<mrvn>
Is there any way to make Printf.printf linebuffered except rewriteing it?
__DL__ has quit [No route to host]
__DL__ has joined #ocaml
Yurik has quit [Read error: 60 (Operation timed out)]
reltuk has joined #ocaml
Yurik has joined #ocaml
Kinners has left #ocaml []
wax has quit [Remote closed the connection]
wax has joined #ocaml
__DL__ has quit [Read error: 113 (No route to host)]
mattam has joined #ocaml
__DL__ has joined #ocaml
liyang has quit [Read error: 104 (Connection reset by peer)]
liyang has joined #ocaml
d-burp has joined #ocaml
d-burp is now known as d-bug
<async>
does anyone here use sourceforge?
<emu>
and will we admit to it?
lament has quit ["I AM NOT DELIGHTFULLY SAUCY"]
d-bug has quit []
docelic|sleepo is now known as docelic
rhil is now known as rhil_zzz
systems has joined #ocaml
systems has quit ["Client Exiting"]
d-bug has joined #ocaml
__DL__ has quit [Read error: 110 (Connection timed out)]
__DL__ has joined #ocaml
__DL__ has quit [Read error: 60 (Operation timed out)]
__DL__ has joined #ocaml
systems has joined #ocaml
docelic has quit [Read error: 110 (Connection timed out)]
mrvn_ has joined #ocaml
mrvn has quit [Read error: 60 (Operation timed out)]
systems has left #ocaml []
lus|wazze has joined #ocaml
__DL__ has quit [Read error: 110 (Connection timed out)]
__DL__ has joined #ocaml
mrvn_ is now known as mrvn
gene9 has joined #ocaml
docelic has joined #ocaml
Smerdyakov has joined #ocaml
vegai has joined #ocaml
<vegai>
I was wondering... is it possible to construct a generator function (like it is in eg. python)?
<Smerdyakov>
What's that?
<vegai>
ok, let me rephrase, of course it's *possible*
<vegai>
hmm, this might be a very imperative feature
<Smerdyakov>
Can you explain what it is/
<vegai>
Smerdyakov: it's a function that yields values, which means that the function is resumed when called the next time inside a loop -- instead of starting from top
<Smerdyakov>
Oh, commonly called an "iterator."
<vegai>
ah, yes
<Smerdyakov>
It's very easy to do in Caml just like you're used to, using imperative stuff.
<Smerdyakov>
The functional version is to return a new version of the iterator each time.
<Smerdyakov>
And the REALLY functional version is to use fold's instead!
<vegai>
I _did_ know them as iterators before, but then after learning it in python, I thought "generator" was the correct term ;P
<vegai>
ahh, fold sounds much better, indeed
<vegai>
I'd like to try stay away from useless imperativisms
<Smerdyakov>
Iterators are viewed as degenerate fold functions in the FP community. :-)
<vegai>
thank you
<vegai>
the culture change is quite difficult, when you've written programs in non-FP languages for some 20 years
<Smerdyakov>
Welllll, I switched after 13 years. =)
<Zadeh>
I started reading about ocaml because it looked like the notation my non-fp code evolved to independantly. ;)
<vegai>
ok, so I'm just 22, so "20 years" is an aggressive rounding =)
<Smerdyakov>
vegai, I'm 21, and 13 is quite correct. :)
<Zadeh>
hehe
<Smerdyakov>
I switched when I was 19, I think.
<vegai>
I think I was 5 when I wrote my first basic horror stories
<vegai>
...which of course means that I'm completely damaged as a programmer
<Smerdyakov>
I don't think kids these days get to learn real programming at 5.
<Smerdyakov>
They make web pages instead. :-(
<vegai>
if basic is real programming, I'll go kill myself now ;P
<Smerdyakov>
And maybe some day they learn to make PHP pages and content themselves at that forever.
* Zadeh
taught himself qbasic, 'cuz it was all his windows 3.1 system had.. until it eventually would crash when his programs got too big.
<Smerdyakov>
Zadeh, yes, limited availability was a nice shepherd.
<Zadeh>
and then, I learned x86 asm, because C was "too slow" my friends said
<Smerdyakov>
And those were the days when that was still correct, eh? :-)
<vegai>
I toyed with 6502 assembler somewhat
<vegai>
that was cute
<Zadeh>
barely
<Smerdyakov>
Zadeh, so do you fall into the category of "FP users" and not "FP implementors"?
<Zadeh>
Smerdyakov: I think so. But C++ doesn't make a very good FP language.
<vegai>
Zadeh: s/ FP// =)
<Smerdyakov>
Zadeh, you mean you develop a C++ compiler?
<Zadeh>
Smerdyakov: Nah, I do "FP" in C++.
<Zadeh>
actually, I started out one day trying to do my own C++ compiler
<vegai>
ah... yes. I also do "FP" in python
<Zadeh>
After a couple weeks of banging my head on the wall trying to get a simple parser working, I gave up
<Smerdyakov>
Oh. A disproportionate number of people in FP channels are language researchers and implementors, which is why I asked.
<Zadeh>
ahh
<Zadeh>
nope, I'm just a random user weirdo
<Zadeh>
hehe
<vegai>
Zadeh: we need guys like you. Go spread the word =)
<Smerdyakov>
It's easy to join the research club! You just need to go to grad school. =)
<Zadeh>
lol
<vegai>
but really, if it is wanted that this language succeeds, we need a lot more casual users than PhDs
<vegai>
I mean, look how haskell is doing
<Smerdyakov>
Haskell is kicking ass.
<Zadeh>
How's it doing?
<Smerdyakov>
There are people in #haskell using it professionally.
<vegai>
not well?
<Smerdyakov>
In industry
<vegai>
really? that's nice =)
<Zadeh>
Smerdyakov: So are you a grad student?
<Zadeh>
So far I've converted some simple C++ programs to ocaml and the speed difference isn't all that much, so I'm fairly impressed.
<Smerdyakov>
In the fall I will be.
<vegai>
Smerdyakov: I tend to judge the success of a programming language on how much good (free) software is available
<Smerdyakov>
vegai, count all the good free SML compilers and I guess it is doing pretty well. :D
<vegai>
of course, that's the only criterion, but an easy one
<vegai>
I mean, that's *not* the only criterion
<vegai>
Smerdyakov: =)
<Smerdyakov>
If you're interested in indoctrinating people in the ways of FP, check out #hprog. It's a community I've started/am trying to start for people who code for fun, and I think a lot are interested in language advocacy in general.
<Zadeh>
I tend to look for some important/substantial piece of widely used software written in it
<vegai>
no... I mean, we started a local organization(?) called "Friends of Artistic Programmers" some half a year ago here
<lus|wazze>
[15:36:39] <vegai> Smerdyakov: I tend to judge the success of a programming language on how much good (free) software is available <--- well if everyone used this criteria, wouldn't it be kinda of a self-fulfilling prophecy then`?
<Smerdyakov>
vegai, cooool.
<vegai>
lus|wazze: that's a way to judge the success _now_
<Smerdyakov>
vegai, did you stop it yet? =)
<mellum>
lus|wazze: it is, just look at the languages everybody uses nowadays.
<vegai>
Smerdyakov: well, we've been pretty silent, but that doesn't mean anything
<vegai>
aargh, seems like I can't write today
<vegai>
"Friends of Artistic Programming", of course
<Smerdyakov>
vegai, no web page?
<vegai>
Smerdyakov: not an international one
<vegai>
I should translate one
<vegai>
also, I think we oughta publish a bit before going more public
<vegai>
it's basically formed of a few undergrad and couple grad students (and one professor, I think)
<vegai>
lus|wazze: to continue... I don't mean that it implies anything about the quality of those languages
<Smerdyakov>
vegai, professor. Neat. :-) Must be young?
<vegai>
let me doublecheck that, I'm not sure. He's not very active
<Smerdyakov>
Well, I see no one has joined #hprog from here. Oh well. :-(
<vegai>
ah, sorry
docelic is now known as docelic|away
gene9 has quit [Read error: 104 (Connection reset by peer)]
gene9 has joined #ocaml
gene9 has quit [Read error: 104 (Connection reset by peer)]
Smerdyakov has quit ["Out to do some stuff"]
Bierher has joined #ocaml
<Bierher>
help
<Bierher>
help/
<Bierher>
help~~~[D
<Bierher>
q
<Bierher>
exit
<Bierher>
exit
<Bierher>
logout
Bierher has left #ocaml []
<mellum>
hehe
noss has joined #ocaml
d-bug has quit []
<kirk>
hahah
<kirk>
he looked pretty lost
<mrvn>
This function is applied to too manz arguments.
<mrvn>
# exit;;
<mrvn>
- : int -> 'a = <fun>
<mrvn>
Isn
<mrvn>
Isn't there a way to specify that a function never returns?
<lus|wazze>
<...> -> 'a, where 'a does not occur in <...>, IS the way the ocaml type system uses to specify that the function never returns
<lus|wazze>
why?
<mrvn>
It fits cause it magically returns whatver type is expected.
<mrvn>
But its not realy the same. 3 * 5 + (exit 0);; doesn't realy make much sense.
<lus|wazze>
yes it does
<lus|wazze>
exit just never returns the value to be added :)
<lus|wazze>
well you could alternatively narrow the type to a specific return type, like, say
<lus|wazze>
let exit : int -> unit = exit;;
<mrvn>
It never returns. Doesn't make sense to do anything with the return type so it shouldn't have any. But everything has one so 'a is the easy way out.
<lus|wazze>
well as i said you could also alternatively use unit as the return type
<lus|wazze>
which basically corresponds to using void functions in C for that purpose
<mrvn>
# let foo a = (exit a, exit a);;
<mrvn>
val foo : int -> unit * unit = <fun>
<lus|wazze>
but really 'a makes a lot of sense if you really think about what typing really means in ocaml
<mrvn>
C has a no-return hint for the compiler. Helps optimizing and avoiding missing return warningns.
<lus|wazze>
it just means there are no restrictions to its return type - that is, there is no reason why using exit's (say) return type as any type at all will ever lead to a type-clash
<lus|wazze>
which is exactly what the type 'a means -
<lus|wazze>
it means, that using this value as <any datatype at all> will never lead to a type clash
<lus|wazze>
which is true, of course, for exit
<lus|wazze>
because it never really returns a value
<mrvn>
typewise 'a makes perfect sense. It's just no realy getting the meaning accorss of a no-return function.
<lus|wazze>
well then what would?
<lus|wazze>
unit, probably
<mrvn>
no, no type would.
<mrvn>
ocaml doesn't have that concept.
<lus|wazze>
unit is basically that ... it is just a single value
<mrvn>
ibut exit has no value.
<lus|wazze>
hmm
<lus|wazze>
a datatype corresponding to the empty set
<lus|wazze>
that would probably work
<lus|wazze>
but why?
<mrvn>
no.
<lus|wazze>
what 'no'. yes
<mrvn>
woudln't work.
<lus|wazze>
a datatype corresponding to the empty set would signal just what you want
<lus|wazze>
it would mean that such a function could NEVER return a value
<mrvn>
you could build a list of empty sets.
<lus|wazze>
because there would be no valid return value
<lus|wazze>
umm
<lus|wazze>
no
<lus|wazze>
because the empty set contains no values...
<mrvn>
It would have to be a special case and probably wreck the type inference.
<lus|wazze>
that is, the type of lists of empty set members would be empty itself
<lus|wazze>
actually no
<lus|wazze>
wait a sec phone rings brb
<__DL__>
no, [] is into it
<lus|wazze>
hm thats truie
<lus|wazze>
true
<lus|wazze>
ok [] is the only list of , say, lets call that datatype nothing
<lus|wazze>
but you could still do no operation on the return value of a function returning nothing
<lus|wazze>
say the built-in type nothing would be defined as having no values
<lus|wazze>
so you could ONLY type functions which never return as returning nothing
<__DL__>
by the way, you could define such a type
<__DL__>
type nothing
<__DL__>
do the trick
<__DL__>
(but the compiler won't do anything to optimize it)
<lus|wazze>
# type nothing;;
<lus|wazze>
type nothing
<lus|wazze>
# let exit : int -> nothing = exit;;
<lus|wazze>
val exit : int -> nothing = <fun>
<lus|wazze>
there it is! :)
<lus|wazze>
so that oughta solve it mrvn, shouldn't it? :]
<__DL__>
by the way, if you look to the church rosser theorem, then the type int -> 'a is realy the good type for exist (and for raise also)
<lus|wazze>
thats what i was trying to explain
<lus|wazze>
ONLY a function which never really returns a value can have type <...> -> 'a where 'a does not appear in <...>
<lus|wazze>
[17:09:44] <lus|wazze> <...> -> 'a, where 'a does not occur in <...>, IS the way the ocaml type system uses to specify that the function never returns
<mrvn>
# let foo a = (exit a, exit a);;
<mrvn>
val foo : int -> nothing * nothing = <fun>
<__DL__>
(by the way, there is an exception to this rule :
<__DL__>
# input_value;;
<mrvn>
Doesn't change anything. Using exit's return value should not be possible.
<__DL__>
- : in_channel -> 'a = <fun>
<lus|wazze>
[17:29:46] <mrvn> Doesn't change anything. Using exit's return value should not be possible. <-- now that doesn't make any sense
<lus|wazze>
when you can't use exits return value you can't ever call exit at all
<__DL__>
mrvn : exit is (on a theorical point of view) the same than raise
<__DL__>
and you should be able to write : if y = 0 then raise Division_by_zero else x / y
<mrvn>
# exception Foo;;
<mrvn>
# let foo a = (raise Foo, raise Foo);;
<mrvn>
val foo : 'a -> 'b * 'c = <fun>
<mrvn>
That doesn't realy make sense.
<lus|wazze>
why not?
<mrvn>
same as exit, yes.
<__DL__>
the only way to have this is that raise have type exception -> 'a
<lus|wazze>
it constructs a pair, but while constructing the pair raises an exception ...
<lus|wazze>
like let foo a = (exit a, exit a);;
<lus|wazze>
constructs a pair, but while doing so, quits
<lus|wazze>
wheres the problem?
<lus|wazze>
you don't want to be able to quit / raise an exception?
<mrvn>
I do, but (exit 1, exit 1) seems wrong to me.
<lus|wazze>
because , in a functional language , at any point where you will want to raise an exception and / or quit you will at that point be constructing a value
<lus|wazze>
look , for instance , at _DL_'s example
<lus|wazze>
let divexn a b = if b == 0 then raise Division_by_zero else x / y;;
<lus|wazze>
that's a valid point at which to raise an exception, right?
<lus|wazze>
well
<lus|wazze>
then you can do , e.g., 2 + divexn 3 0
<lus|wazze>
you will again be raising an exception from within an expression, that is, while constructing a value
<mrvn>
I'm not debating that exit and raise should be forbidden.
<lus|wazze>
but you are, because in a functional sense when exit and raise are possible, they are possible WITHIN AN EXPRESSION - which seems to be what you are complaining about
<mrvn>
I'm just noting that using a never existing return value of exit seems odd.
<lus|wazze>
you have to get comfortable with the thought that in a functional language everything is an expression
<lus|wazze>
but it is not possible without?
<lus|wazze>
when you DON'T use the (never existing) return value of exit, YOU ARE NEVER EVEN CALLING IT IN THE FIRST PLACE
<mrvn>
I would have liked exit : int -| = <fun>
<mrvn>
or something showing its a no-return.
<lus|wazze>
but why?
<lus|wazze>
'a shows its a no-return, when 'a does not occur in the argument list ...
<__DL__>
returning a value is using it
<__DL__>
when you do and if the else, you return both value (depending of the test)
<mrvn>
or more usefull a int_of_string : string -> int |raises Error|
<lus|wazze>
one might also conceptualize it in a functional sense as returning a special value , which is part of EVERY datatype, which is then propagated upwards in the continuation chain until the computation terminates
<__DL__>
mrvn : this is a different thing, and an open function :
<__DL__>
open question I mean :
<__DL__>
let f g x = g x
<__DL__>
what would be the type of this for you (with your exception analisis)
<mrvn>
C++ has this feature optionally. If you specify what exceptions a function raises it can only raise those and any other exception from subfunctions are transformed to a general exception.
<lus|wazze>
of course why anyone would ever want that is another question ...
<mrvn>
f: ('a -> 'b |'c|) -> 'a -> 'b |'c|
<lus|wazze>
because an exception is inherently something that occurs UNEXPECTEDLY, thats why it is an exception in the first place
<mrvn>
lus|wazze: The compiler warns one about exceptions subfunctions throw that I don
<mrvn>
't handle or declare to keep throwing.
<__DL__>
yes, I thought so. The problem is that then the type system is not anymore computable.
<mrvn>
Very helfull in case one overlooks an exception.
<mrvn>
helpfull even.
<lus|wazze>
it spelled 'helpful'
<lus|wazze>
+s
<lus|wazze>
i think
<mrvn>
DL: I don't even want to start about exception type propagations in currified functions.
<lus|wazze>
well i just dont really see where your problem is in the first place
<lus|wazze>
using a generic type variable which does not occur in the argument list is, as was already mentioned, (usually, that is, not counting hacks like input_value) ONLY possible with functions that never return
<mrvn>
Well, I started thinking about it when I wanted to know what a function in a module throws on error.
<__DL__>
by the way, their is an exception anylis for ocaml, don't remeber where, but there is one.
<lus|wazze>
hm wanting to know what exceptions a function might throw IS a valid question but i don't really think it has anything to do with the fact that raise's / exit's return type is 'a :]
<mrvn>
raise X would have type NIL |X| and exit NIL |NIL|
<mrvn>
NIL specifying a non-return value.
<lus|wazze>
but why?
<mrvn>
NIL would not match anything but disapear in an if cluase for example.
<lus|wazze>
[17:46:25] <lus|wazze> but why?
<mrvn>
lus|wazze: The reason would be to prevent 1 + raise X but not 1+ if foo then rais X else 2
<lus|wazze>
you're just making the language more complicated, when there already is a perfectly simple solution
<lus|wazze>
... so and why would you want to prevent that?
<lus|wazze>
for example, in C++, would you want to prevent something like
<lus|wazze>
{ int x = 2 + y; float z = (float)(x * 3); throw blah; } ?
<lus|wazze>
just because the statements in front of the throw statement don't have any effect?
<mrvn>
Thats just a list of statements. perfectly valid.
<lus|wazze>
yes exactly and what i want you to get to understand that there is no such thing as a statement in ocaml
<lus|wazze>
ONLY expressions
<lus|wazze>
so 1 + <blah> is exactly the same thing as <foo> ; <blah> concerning the topic at hand
<mrvn>
but c++ knows that { throw blah; int x = 17 * acc(15,15);} never computes the accerman function.
<mrvn>
ocaml doesn't.
<lus|wazze>
does c++ also know that
<__DL__>
mrvn : who care ?
<lus|wazze>
{ int x = 17 * acc(15,15); throw blah; } never computes the ackermann function?
<mrvn>
lus|wazze: it does.
<mrvn>
Why wouldn't it compute it?
<mrvn>
It hopefully gets inlined and optimized away.
<lus|wazze>
i doubt the ackermann function as non-reducible recursive function will become inlined
<lus|wazze>
the compiler would have to realize that acc does not have any side-effects for it to optimize it away
<lus|wazze>
the same as in ocaml if you do
<lus|wazze>
acc 15 15 + raise Blah
<__DL__>
well, I don't beleive this whould change a lot of thing
<lus|wazze>
nothing, specifically
<mrvn>
lus|wazze: How would ocaml know the value is never used?
<lus|wazze>
because there is a raise statement executed throwing the result of the computation away?
<mrvn>
but raise is just a normal function
<mrvn>
returntype int in this case.
<__DL__>
by the way, the order of execution is not specified, so it is parfecly valid for caml to avaluate the raise Bla before computing acc 15 15
<lus|wazze>
actually the return type is 'a which is in this specific context narrowed to int
<mrvn>
thats what I ment.
<__DL__>
(and actually, it will compute the raise before the call to acc, but it is another question)
<mrvn>
Point is that from the type ocaml has no knowledge about raise aborting the computation.
<lus|wazze>
hmm
<lus|wazze>
actually that is true ONLY because of that ugly hack "input_value" existing
<mrvn>
One could of cause say its your own fault your shooting yourself in the leg.
<lus|wazze>
if i had any say in the matter i would remove that
<mrvn>
lus|wazze: marshaling and Obj use it too
<lus|wazze>
well and those special cases as well
<lus|wazze>
and then have the compiler take, as per the church-rosser theorem, that a function returning a type more generic than its arguments never returns
<mrvn>
well, one can allways just not write stupid code like 1+raise X but just raise X
<mrvn>
so for simplicity of type inference the current way is better :)
<mrvn>
One thing I realy miss is getting my hands on static type info of a value. Maybe you know a way to get that.
<thomas001>
another thing: what about support for 4 byte wide characters? like C's wchar_t
<noss>
are strings defined as octet arrays?
<karryall>
thomas001: same thing, not supported by the language but there are libraries doing unicode stuff
<karryall>
noss: yes
<thomas001>
thx again karryall
<noss>
isnt that a bit overspecified? character sequence is a more flexible definition.
<karryall>
what do you mean, what's the difference ?
<noss>
a character is not an octet. for all you know a character type could be 128bit, since we need that when the SETI project establishes contacts with alien planets.
<noss>
we could be known all over the galaxy as the race that had very flexibe strings and that taste good roasted.
<karryall>
ok
noss has quit ["[x]chat"]
kirk has quit [Read error: 104 (Connection reset by peer)]
<mrvn>
thomas001: because the cpu has to convert each float to double and back for each operation.