_shawnafk has quit [Read error: 104 (Connection reset by peer)]
_shawnafk has joined #ocaml
Kinners has left #ocaml []
mattam has quit [Operation timed out]
mattam has joined #ocaml
Xybot has joined #ocaml
Xybot has left #ocaml []
Nutssh has joined #ocaml
LittleDan has joined #ocaml
<LittleDan>
What's the rationale for OCaml having seperate type and object systems?
<Smerdyakov>
There is none, because that's not true. The object system is a subset of the type system.
<LittleDan>
Riastradh told me otherwise
<LittleDan>
but you're probably right
<Smerdyakov>
I doubt it. You probably misunderstood. (Or maybe he did ;)
<LittleDan>
wait, the object system is a subset of the type system? Oh, I knew that. But why aren't types objects?
<LittleDan>
instead of objects being types
<Smerdyakov>
That doesn't make any sense.
<Smerdyakov>
A type describes a value.
<Smerdyakov>
An object IS a value.
<LittleDan>
why isn't everything an object, instead of everything being a type?
<LittleDan>
I mean having a type
<Maddas>
err
<Smerdyakov>
Because that's not the OCaml philosophy.
<LittleDan>
oh
<LittleDan>
why not?
<Smerdyakov>
It's overly complex.
<LittleDan>
oh
<LittleDan>
ok
<Smerdyakov>
Objects involve a lot of semantic notions that are overkill for almost everything
<LittleDan>
like what?
<Smerdyakov>
Fields and methods
<LittleDan>
what makes them overkill?
<Smerdyakov>
You have to artificially choose to put all your functions into certain classes.
<LittleDan>
I feel like I'll become a troll if I say this, but doesn't static typing force you to put everything artificially into certain types?
<Maddas>
How so?
<LittleDan>
You can only use them with one type
<LittleDan>
It's been shown possible that that isn't necessary
<Maddas>
That isn't static typing per se
<LittleDan>
why not?
<Smerdyakov>
LittleDan, what's the problem with forcing you to have well-typed values?
<pattern>
nothing forces you to use just one type
<Maddas>
LittleDan: See type classes, for example.
<pattern>
in fact, ocaml comes with many different simple types and encourages you to create new types
<LittleDan>
but each function has to take a specific type, right?
<Smerdyakov>
Yes, which is very helpful in making sure your code does what you want.
<pattern>
one or more types, sometimes a general type, not necessarily a specific type
<Maddas>
LittleDan: Not necessarily a specific type, no.
<Maddas>
That's what you have parametric polymorphism for :)
<Maddas>
(And you can define your own types)
<LittleDan>
I guess I misinterpreted more of what Riastradh said. I asked him if operator overloading was possible (which I assumed could be implemented using parametric polymorphism) and he said no.
<Maddas>
LittleDan: You can't overload operators in O'Caml.
<Riastradh>
Perhaps you don't understand what parametric polymorphism is.
<LittleDan>
Is it completely different from generic functions?
<pattern>
but that doesn't mean you can't have an operator that works on a compound type
<Smerdyakov>
Parametric polymorphism is the same as generic functions, mostly.
<Riastradh>
Uh, no, not at all.
<Riastradh>
Generic functions are all about type dispatch. Parametric polymorphism is about 'I don't care what this type 'a is, and I don't destructure objects of the type 'a; all I care is that you're consistent with what type 'a is.'
<Smerdyakov>
Ah. I'm pretty sure that "generic functions" = "parametric polymorphism" in the world of static typing.
<Smerdyakov>
Or rather I've heard "generics" used with that meaning, and so I extended that to "generic functions."
<Riastradh>
'Generic function' refers to a function that dispatches at run-time on the types of its inputs.
<Smerdyakov>
Okeydokey.
<LittleDan>
So with parametric polymorphism, there is no way whatsoever to determine the type of your arguments?
<Riastradh>
No. That's the point.
<Smerdyakov>
There is no runtime type information in ML.
<pattern>
if you do something based on the type then it's no longer generic to all possible types
<LittleDan>
What can you do that's not based on the type?
<Smerdyakov>
Copy the value from place to place.
<Smerdyakov>
(in imperative terms :P)
<Maddas>
Or just pass it around
<pattern>
make a list of those values
<pattern>
or make a tuple
<LittleDan>
I get it; passing values around and making datastructures
<Maddas>
For example, yes. List.map and Array.map are common examples, I guess
<LittleDan>
But you can't have something that, say, takes integers or floats and adds them?
<Smerdyakov>
Correct
<pattern>
type intfloat = Int of int | Float of float;;
<pattern>
and then you can make something that adds them
<LittleDan>
but then how would you add them?
<Maddas>
pattern matching
<pattern>
you need to see if the function is passed arguments of Int or Float and then take the appropriate action
<Smerdyakov>
LittleDan, you can never get into a situation where you don't know if something is an int or a float, so it's a void question.
<Maddas>
What Smerdyakov said :)
<LittleDan>
What if you used that intfloat type and then tried to add them as if they were both ints, caught a potential error, and tried to add them as if they were both floats?
<Maddas>
Caught a potential error?
<pattern>
why would you get an error?
<Maddas>
What do you mean?
<LittleDan>
a type error? Does OCaml have them?
<pattern>
errors are not possible in ocaml ;)
<Maddas>
Not at run-time
<LittleDan>
oh
<Maddas>
That is the whole point
<pattern>
actually they are... exceptions are still possible
<Maddas>
If it compiles, it will not have type errors!
<Riastradh>
match (x,y) with (Int i, Float f) -> i + f (* that's not legal *)
<pattern>
match (x,y) with (Int i, Float f) -> (float_of_int i) +. f
<LittleDan>
Is type conversion possible in OCaml?
<pattern>
ocaml forces you to do explicit conversion
<Maddas>
LittleDan: Of course
<pattern>
instead of implicit conversion done by the language itself, like c
<Maddas>
But explicit only
<pattern>
yes, so that the programmer has to make the decision as to how to convert
<pattern>
floating point to integer conversion is a case in point, where the float can be truncated, rounded up, down, etc
<pattern>
you as the programmer should decide what kind of conversion is appropriate to your situation, not the compiler
<pattern>
the compiler is not smart enough to make the right decision in all cases
<LittleDan>
you can have dynamically typed languages that do that too
<pattern>
some languages do force one type of conversion on you
<pattern>
but that's not the ocaml way
<liralen>
little - sure, dynamically typed languages sometimes have strong typing.
<Maddas>
LittleDan: The explicit conversion is there to prevent type errors.
<Maddas>
If + would implicitly convert float to int, you would lose type interference, wouldn't you?
<pattern>
well, it wouldn't be an error if they were both one type
<LittleDan>
Maddas: I understand why, but other languages just don't have those type errors in the first place.
<whee>
I would just be a dork and add another token with camlp4 that would do the casting for you
<liralen>
little - what type errors do you have in mind, that other languages just don't have in the first place?
<pattern>
littledan, but those other languages might have programming errors as a result
<pattern>
for example, when a conversion is made implicitly and the programmer is not aware of it
<Maddas>
LittleDan: They do not have type interference.
<LittleDan>
liralen: for example 3.4 + 2.3, which I'm sure many beginner programmers make.
<pattern>
i think it took me all of five seconds to get used to using seperate arithmetic operators in ocaml
<Maddas>
LittleDan: So, is that any problem?
<pattern>
and ocaml will warn you if you make such a mistake
<Maddas>
The compiler tells it to them immediately
<liralen>
little - at least once, anyway, as they read the tutorial. After that they hopefully understand that O'Caml has arithmetic operators particular to floats,
<Maddas>
LittleDan: I think you are missing the point
<Maddas>
LittleDan: Type interference is not there to make life easy for the compiler, it's there to make life easy for the programmer.
<LittleDan>
Maddas: you mean that it will make bugs aparent at compile-time?
<Maddas>
Yes.
<pattern>
and that's a HUGE win
<pattern>
it's one of my very favorite things about ocaml
<pattern>
it makes programming so much more fun, and so much easier
<pattern>
because you're not going to be stuck scratching your head for hours trying to find some obscure bug
<pattern>
when the program compiles wihtout errors it's mostly bug free
<LittleDan>
what kinds of errors would remain?
<pattern>
most of the rest of the bugs that are left will be bugs of design
<liralen>
little - logical errors that don't violate the type system.
<pattern>
when you make incorrect design decisions
<pattern>
but those kinds of poor design decisoins are possible in any language
<pattern>
so you refactor and move on
<liralen>
let rec reverse l = match l with [] -> [] | (h::t) -> h;; (* woops *)
<liralen>
also, -> t;;
<Maddas>
Having your list the wrong way round. Using the wrong variable which accidentally has the same type. Things like that
<liralen>
the compiler would've caught the first example =)
Nutssh has left #ocaml []
<pattern>
yeah, those too :)
<pattern>
ok, so not just design bugs.. i take it back! :)
<pattern>
i've definitely had my code compile and the algorithm still be wrong
<pattern>
so algorithm design bugs also
<pattern>
still, the number of bugs that static typing absolutely prooves are impossible in your code is huge
<LittleDan>
What if you use an external tool to check for possible type errors?
<Maddas>
How?
<Maddas>
I don't understand
<LittleDan>
for Python (which I don't particularly like), there's PyChecker, which makes sure you don't use types weirdly.
<Maddas>
I never heard about it, but ok, so what if you use it?
<liralen>
little - and what does python do about code like: def foo(a,b): a + b
<liralen>
little - ?
<LittleDan>
liralen: Why not let that work? But if you then use that function on something where it shouldn't work, it alerts you.
<Maddas>
I don't understand
<liralen>
little - PyChecker can't know where you use that where it won't work, since you can apply it to anything at run-time.
<LittleDan>
say you use foo on two functions. It will alert you and raise an error.
<liralen>
little - PyChecker can't optimize that, either.
<LittleDan>
before runtime
<Maddas>
LittleDan: I think if you use O'Caml/Haskell (also has type interference) you will notice.
<liralen>
Little - in Python, def foo(a,b): a + b # can do *absolutely anything*
LittleDan has left #ocaml []
<Maddas>
uh.
LittleDan has joined #ocaml
<LittleDan>
sorry, what did you say?
<liralen>
I said: Little - in Python, def foo(a,b): a + b # can do *absolutely anything*
<Maddas>
03:24 < liralen> Little - in Python, def foo(a,b): a + b # can do *absolutely anything*
<Maddas>
(sorry, shouldn't have pasted)
<LittleDan>
I said, why not let it do anything, until you try something where you're adding two things where they shouldn't be added.
<liralen>
litle - anyway, that has little to do with why O'Caml's compiler does type inference and type checking rather than rely on the programmer to use an external tool and then trust whatever code that actually comes to it.
<Maddas>
LittleDan: That won't catch many errors.
<Maddas>
LittleDan: Or rather, it can miss many
<Maddas>
oh, wait, I misread.
<liralen>
little - PyChecker can notice that certain arguments to that function don't work, because it can look at the types of those arguments, but it can't do anything in general with that function's return.
<LittleDan>
Maddas: If you analyze the code that uses a library (as opposed to just the library itself), it catches most errors
<liralen>
also, woopsy:
<liralen>
def foo(a,b): return a + b
<Maddas>
LittleDan: Anyway, I think you are still missing the point.
<LittleDan>
liralen: It can trace what type it is.
<liralen>
What does that function return? Anything.
<LittleDan>
liralen: You analyze the usage of that function, not just the function itself.
<liralen>
little - not in general, you can't.
<LittleDan>
I mean you analyze a specific time using it
<liralen>
little - Python doesn't have the 'closed-world' mentality that O'Caml does.
<Maddas>
In Objective Caml, you *can't* have a run-time type error (without doing ugly things with the FFI et al).
<Maddas>
And in general you don't need to specify types explicitly, which is convenient.
<liralen>
little - anyway, if it helps you understand, putting the type inference in the compiler allows the compiler to make various optimizations.
buggs has quit [Read error: 60 (Operation timed out)]
<LittleDan>
liralen: I understand that, and OCaml is much faster than Python for that reason. That doesn't necessarily make it more bugfree overall.
<liralen>
little - er, yes it does. O'Caml necessarily lacks a certain class of bug. Python allows this class of bug.
<Maddas>
It does make it less error-prone, LittleDan.
<LittleDan>
but optimization has nothing to do with that
<Maddas>
We have already explained the purpose of the type system many times. Optimization is another benefit you get from it.
<LittleDan>
I konw
<LittleDan>
*know
<Maddas>
So what are you trying to say?
<LittleDan>
There still might be other bugs that increace with static typing
<Maddas>
What?
<Maddas>
Which bugs increase with static typing as opposed to dynamic typing? I wonder.
<liralen>
maddas - programs with design bugs and static typing have a harder time correcting those bugs at runtime.
<liralen>
please excuse my reference to programs 'having' static typing.
<Maddas>
liralen: I understood that as 'more bugs'
<liralen>
maddas - a curious understanding.
<Maddas>
Possibly. I am tired and will now go to bed.
<LittleDan>
forgetting to convert, although explicit and controlled conversion is still possible. Also some people think better with dynamic types (not everybody, this may just be a difference in opinion). And with implicit expectiations for what type to use (with type inference), it sometimes isn't immediately obvious with what you can and can't use. There are more than this.
<liralen>
little - anyway, you may benefit from some actually learning and playing with O'Caml and coming to your own conclusions as to how much its design helps you produce good programs.
<LittleDan>
liralen: I am
<LittleDan>
Does everyone in here think I'm a troll?
<liralen>
little - "some people think better with dynamic types" doesn't form a useful argument. Please don't use it in this context.
<LittleDan>
If you think in the paradigm that you're programming, you can be more productive.
<liralen>
little - so what?
<LittleDan>
Isn't that the purpose of programming, to be productive?
<liralen>
little - you don't gain any points for emitting irrelevent tautologies.
The-Fixer has quit ["Goodbye"]
<LittleDan>
why is that irrelavent, that you should program in the paradigm you feel most comfortable with?
The-Fixer has joined #ocaml
<LittleDan>
Obviously you feel most comfortable with static typing
<liralen>
little - and the two bugs that you mentioned -- forgetting to convert and getting confused about types -- will tend to show up at compile-time rather than run-time.
<liralen>
little - please don't make assumptions about what I feel comfortable with.
<LittleDan>
that doesn't make them not bugs just because you notice them.
<LittleDan>
You are arguing for static typing. You don't like it?
<liralen>
little - uh, hello? You have bugs whatever happens -- one system just lets you know when you compile your program.
<LittleDan>
you're not listening to what I'm saying
<liralen>
little - stop saying silly things, and stop talking about what I like or dislike.
<LittleDan>
in dynamically typed systems, many bugs aren't bugs and will just work completely
<LittleDan>
many of what would be bugs in statically typed systems
<LittleDan>
I'm not sure if I'm allowed to say this, but it seems like you don't want me to be here.
LittleDan has left #ocaml []
<liralen>
little - I have to go, but I have two points. One: an error that causes the compiler to stop and talk to you does not qualify as a 'bug'. Two: your assertion about dynamically typed systems does not hold, -- but nevermind.
<gl>
Was a poor troll.
<liralen>
I think he argued sincerely, for the most part.
* liralen
goes away.
buggs has joined #ocaml
liralen has quit ["screen"]
liralen has joined #ocaml
The-Fixer has quit [orwell.freenode.net irc.freenode.net]
Vjaz has quit [orwell.freenode.net irc.freenode.net]
Smerdyakov has quit [orwell.freenode.net irc.freenode.net]
srv has quit [orwell.freenode.net irc.freenode.net]
Smerdyakov has joined #ocaml
anpanman has quit [orwell.freenode.net irc.freenode.net]
liralen has quit [orwell.freenode.net irc.freenode.net]
pattern has quit [orwell.freenode.net irc.freenode.net]
rox has quit [orwell.freenode.net irc.freenode.net]
whee has quit [orwell.freenode.net irc.freenode.net]
_shawnafk has quit [orwell.freenode.net irc.freenode.net]
Banana[AFK] has quit [orwell.freenode.net irc.freenode.net]
lam has quit [orwell.freenode.net irc.freenode.net]
cmeme has quit [orwell.freenode.net irc.freenode.net]
smkl has quit [orwell.freenode.net irc.freenode.net]
Smerdyakov has quit [orwell.freenode.net irc.freenode.net]
Riastradh has quit [orwell.freenode.net irc.freenode.net]
Hipo has quit [orwell.freenode.net irc.freenode.net]
_shawnafk has joined #ocaml
lam has joined #ocaml
cmeme has joined #ocaml
Banana[AFK] has joined #ocaml
liralen has joined #ocaml
pattern has joined #ocaml
rox has joined #ocaml
whee has joined #ocaml
anpanman has joined #ocaml
Smerdyakov has joined #ocaml
Hipo has joined #ocaml
Riastradh has joined #ocaml
srv has joined #ocaml
Vjaz has joined #ocaml
smkl has joined #ocaml
Vjaz has quit [orwell.freenode.net irc.freenode.net]
srv has quit [orwell.freenode.net irc.freenode.net]
Vjaz has joined #ocaml
srv has joined #ocaml
whee has quit [orwell.freenode.net irc.freenode.net]
pattern has quit [orwell.freenode.net irc.freenode.net]
rox has quit [orwell.freenode.net irc.freenode.net]
liralen has quit [orwell.freenode.net irc.freenode.net]
liralen has joined #ocaml
pattern has joined #ocaml
rox has joined #ocaml
whee has joined #ocaml
smkl has quit [orwell.freenode.net irc.freenode.net]
smkl has joined #ocaml
Nutssh has joined #ocaml
Nutssh has left #ocaml []
Swynndla has joined #ocaml
drWorm has quit [Read error: 60 (Operation timed out)]
drWorm has joined #ocaml
The-Fixer has joined #ocaml
The-Fixer has quit [Client Quit]
The-Fixer has joined #ocaml
The-Fixer has quit [Remote closed the connection]
The-Fixer has joined #ocaml
Guillaumito has joined #ocaml
Guillaumito has left #ocaml []
Smerdy has joined #ocaml
Smerdyakov has quit [Read error: 110 (Connection timed out)]
Smerdy has quit [orwell.freenode.net irc.freenode.net]
anpanman has quit [orwell.freenode.net irc.freenode.net]
Riastradh has quit [orwell.freenode.net irc.freenode.net]
Hipo has quit [orwell.freenode.net irc.freenode.net]
Smerdy has joined #ocaml
anpanman has joined #ocaml
Hipo has joined #ocaml
Riastradh has joined #ocaml
<Swynndla>
I'm printing a list like this:
<Swynndla>
let rec print_list tab = match tab with
<Maddas>
I would write it as let print_string = List.iter (fun x -> print_char x; print_string " ");;
<Swynndla>
ahhhhhhhhhhhhh
<Swynndla>
much more elegant :)
<Swynndla>
hey ... does haskell have a cool graphics module like ocaml?
<Maddas>
(List|Array).iter, .map and .fold(r|l) functions are useful
<liralen>
Swynndla - yes, a number of them. Why don't you ask the Haskell people?
<Swynndla>
liralen, I want to finish a few things off before I get into Haskell
mimosa has joined #ocaml
<Swynndla>
but just can't help wondering
<Swynndla>
hey mimosa :)
<mimosa>
hi guy
<Swynndla>
Maddas, I've used List.map a few times ... and List.fold a couple of times
<Banana[AFK]>
hello people.
Banana[AFK] is now known as Banana
<Swynndla>
hey Banana :)
<Swynndla>
is Haskell as fast as ocaml?
<Banana>
from the point of view of a ocaml programmer I would say no.
<Swynndla>
:)
<Swynndla>
I mean does it run as fast ... ie ocaml runs nearly as fast as c
<Swynndla>
not how quick it is to code it
<mimosa>
it is not as fast as ocaml
<Swynndla>
ok
<mimosa>
it could be but the implementation is not really optimizing
<Swynndla>
is it statically typed with type inferencing (like ocaml)?
<Swynndla>
mimosa, yesterday I learned about tail recursion :)
<Banana>
Swynndla: statically typed yes.
<Banana>
i don't think there is type inference but i'm not sure.
<Swynndla>
ahhhhh ok
gim has joined #ocaml
<liralen>
swyn - yes, type inference.
<liralen>
swyn - also, GHC does a very good job of optimization -- except that it takes some time to do it.
<liralen>
swyn - again, the nice #Haskell people can tell you about that =)
<Swynndla>
:)
<Banana>
(and better than me apparently :D )
<Swynndla>
hehe
Smerdy has quit [Read error: 110 (Connection timed out)]
Kinners has joined #ocaml
<Banana>
bye.
Banana is now known as Banana[AFK]
<Swynndla>
well, at last I finished off my ocaml program using *no* for loops ... it's faster than before but C is still a little bit faster ... http://nopaste.snit.ch:8001/611
<pattern>
lists aren't always the most efficient solution
<pattern>
try your c program with linked lists as your main datastructure
<pattern>
i'm guessing you use arrays in c
<Swynndla>
yes I did
<pattern>
so you're comparing apples and oranges
<Swynndla>
I'll have to learn how to do that in c ... I don't know much about c yet ... I know perl better :P
<Swynndla>
true
<Swynndla>
but I did write an ocaml version using arrays .. and a for loop ... it was slower
<pattern>
interesting
<pattern>
well, i wouldn't worry about efficiency much when you're just starting to learn a language
<Swynndla>
although I wrote the array one a couple of weeks ago when I didn't know as much about ocaml .. perhaps I didn't write is efficiently
<Swynndla>
true
<pattern>
and the fact that ocaml gives you results close to c even when you are possibly using relatively inefficient methods should be heartening
<Swynndla>
yup :P
<pattern>
i'd concentrate on learning the language rather than trying to get maximum efficiency from it at this early stage in your leraning
<pattern>
learning
<Swynndla>
good point
<Swynndla>
BTW ... can ocaml execute a shell command (like 'date') and capture the result?
<Kinners>
yes, look at the unix module
<Swynndla>
oic thx
<Swynndla>
hey is my 'let rec myitns' fuction (at the bottom of my code) tail recursion?
<Swynndla>
I think it is
<Swynndla>
that is, I *think* it is?!
<pattern>
maybe Unix.open_process_in
<Kinners>
Swynndla: looks like it
<Swynndla>
cool
<Swynndla>
believe it or not, the function that I'm most proud of at the moment is this one:
<Swynndla>
let intlist_of_charlist =
<Swynndla>
List.map int_of_char
<Swynndla>
;;
<Swynndla>
as the "light went on" when I realized I didn't need fun i -> ... etc
<Swynndla>
:)
<Swynndla>
g2g ... bye all and thx for your help :P
Swynndla has quit ["Leaving"]
lus|wazze has joined #ocaml
wazze has quit [Read error: 110 (Connection timed out)]
_JusSx_ has joined #ocaml
<_JusSx_>
ls
Kinners has left #ocaml []
gim has quit [orwell.freenode.net irc.freenode.net]
smkl has quit [orwell.freenode.net irc.freenode.net]
gim has joined #ocaml
smkl has joined #ocaml
srv has quit [Read error: 110 (Connection timed out)]
lam has quit [Read error: 60 (Operation timed out)]
lus|wazze is now known as wazze
CoolPops has joined #ocaml
mimosa has quit ["J'ai fini."]
gim has quit []
srv has joined #ocaml
Nutssh has joined #ocaml
gim has joined #ocaml
Smerdyakov has joined #ocaml
_JusSx_ has quit ["No windows for this server"]
owll has joined #ocaml
owll has quit [Client Quit]
CoolPops has quit ["leaving"]
phubuh has quit [Remote closed the connection]
Nutssh has quit ["Client exiting"]
Smerdyakov has quit [Read error: 110 (Connection timed out)]
phubuh has joined #ocaml
The-Fixer has quit [Connection timed out]
The-Fixer has joined #ocaml
Herrchen has joined #ocaml
The-Fixer has quit ["Goodbye"]
The-Fixer has joined #ocaml
_JusSx_ has joined #ocaml
Banana[AFK] is now known as Banana
Nutssh has joined #ocaml
_JusSx_ has quit ["BitchX: ribbed for her pleasure!"]
_JusSx_ has joined #ocaml
Nutssh has quit ["Client exiting"]
The-Fixer has quit [Read error: 110 (Connection timed out)]
ejt has joined #ocaml
<ejt>
hi, I need to use unsigned 32 bit values, is there a module for doing this ?
<Banana>
yes.
<Banana>
Int32.
<ejt>
isn't that signed ?
<Banana>
yes.
<Banana>
you need unsigned 32bit ?
<ejt>
yep, I want to hold an inode number
<phubuh>
O'Caml doesn't come with an unsigned 32 bit type; it does come with Int64, however.
<Banana>
yeap you can use Int64.
<ejt>
that's an idea, thanks
<mellum>
Why not just use Int32?
<mellum>
The signed/unsigned difference usually does not matter.
<ejt>
mellum: until you print it out ?
<Banana>
yes you can handle just the printing with an int64.
<mellum>
But hey, I'd just use int.
<mellum>
The standard library does, too.
<ejt>
how do you do bit manipulations without an unsigned type ?
<mellum>
ejt: The question doesn't make sense.
<ejt>
hmmm, you're right Unix.stat just returns the inode in an int, I can't do better than that then
<ejt>
thx
<ejt>
and the modify time in a float =8o
<Banana>
ejt: by the way Int32 module comes with bitwise operation.
<ejt>
k
<ejt>
do these ignore the sign bit, or assume it's unsigned ?
<Banana>
they ignore the bit sign.
<mellum>
It simply doesn't matter for most operations. The beauty of two's complement.
<ejt>
Banana: thx
<Banana>
float in Ocaml are double precision (64 bits/iEEE 754).
<ejt>
I also see that st_size is an int; database files are going to be larger than 1G easily
<mellum>
ejt: use Unix.LargeFile if you care
<ejt>
ah, great, thanks
LittleDan has joined #ocaml
<LittleDan>
I'm not trying to start an argument. Does OCaml support anonymous functions?
CoolPops has joined #ocaml
<pattern>
littledan, yes
<LittleDan>
ok. thanks
LittleDan has left #ocaml []
<Banana>
whoo.
<Banana>
that was fast.
<ejt>
he just _had_ to know
<pattern>
i wonder if he knows what they are
<pattern>
or was just marking a checklist somewhere
<ejt>
maybe he's having an argument on another channel
<ejt>
is it possible to see what channels someone is on ?
<CoolPops>
I am currently attempting to learn a functional language and have looked at Erlang, Haskell and now Ocaml. I have went through (quickly) Introduction to the OCaml Programming Language tutorial (need to do it again). So that's my experience. One thing that is important to me is tcp sockets. I see many libs that require TCP but no reference to TCP functions anywhere. Where are they?
<pattern>
try /whois littledan
<ejt>
CoolPops: Unix
<CoolPops>
ejt: Ah! I was browsing throught the Ocaml manual and saw the page on the Unix library but didn't realize that it was broken down further... I did not click on "Module Unix: Unix system calls." ... sorry about that, it was a silly question.
<ejt>
I don't know if there's a higher level module that makes using sockets a bit easier
<pattern>
there are no silly questions
<Riastradh>
You unfortunately don't get anything as convenient as gen_tcp & gen_server with OCaml.
<pattern>
only silly question askers
<CoolPops>
pattern: is that similar to, Their is no such thing as bad dogs, only bad dog owners? :)
<pattern>
:)
<CoolPops>
ejt: once you use them a few times (the base) their not too hard. A few wrapper's and your good to go.
<ejt>
ejt: y, I would use them myself, but there again I have a copy of Stevens :)
<CoolPops>
ejt: I must admit coming from languages such as C and Ruby, these functional languages are pretty cool and pretty confusing at the same time.
<ejt>
CoolPops: it took me a lot of work to get to grips with Haskell
Etaoin has quit ["Client exiting"]
<CoolPops>
ejt: it seems to me that Haskell is a little bit easier than Ocaml, is that not true?
<ejt>
it's easy to see that it's elegant, harder to drop all the imperative algorithms
<CoolPops>
ejt: I have spent about 1 week with Erlang, 3 days with Haskel and about 6 hours so far with Ocaml.
<Riastradh>
Haskell will astonish you at times, but bother you to no end at other times.
<ejt>
CoolPops: so you understand Monads ? ;)
<CoolPops>
ejt: I understand that 1+1 is all three = 2.
<ejt>
as desk calculators go they're all quite similar
<CoolPops>
One of the things that made me think of Ocaml was a statement in the Haskell tutorial, (talking about speed of Haskell) "If you don't find this sufficient, I would suggest taking a look at the language O'Caml, which often outperforms even C++, yet also has many of the benefits of Haskell."
<pattern>
ocaml can also get by without monads
<ejt>
ocaml is probably a more pragmatic programming language
<ejt>
it uses imperative constructs when it needs
<ejt>
and yes it is impressively quick
<ejt>
on my machine it takes ~2 hours to build the ghc (haskell) tool chain, and 2 minutes to build the ocaml ones ... this suggests something to me
<mellum>
I don't know. For nearly all projects, language runtime efficiently isn't really important.
<CoolPops>
ejt: I don't know how long it took for me, but it was quite some time, and like you said ocaml almost nothing in comparison.
<CoolPops>
mellum: but why sacrafice it if it's not necessary?
<mellum>
CoolPops: depends on what you sacrify it for.
<CoolPops>
mellum: if Haskell has things that make it much better than OCaml, then I could see that statement, but if not...
<ejt>
mellum: it was Haskells memory usage that I got frustrated with
<Banana>
even the bytecode interpreter (aka VM) is fast and low meme requirement compared to others.
<mellum>
CoolPops: All I'm saying is that you should normally not base the decision for a language or against it on this criterion.
<mellum>
Unless you're writing an MPEG4 codec or something.
<CoolPops>
mellum: I'm brand new to functional languages, so I don't know what I'm sacraficing for what.
<Banana>
mellum is right or we would all choose ASM :)
<mellum>
But something like TCP networking you can do as well in Scheme.
<CoolPops>
if speed were the *only* consideration.
<CoolPops>
but if you have two equal languages, 1 2x as fast, use the one 2x as fast... that's all I am saying.
<CoolPops>
I don't know enough about Haskell or Ocaml to determine which is better for a given situation.
<Banana>
they are not equal... though.
<CoolPops>
Nor do I know enough about the differences. I'm a n00b.
<Banana>
Haskell is purely functionnal.
<CoolPops>
Banana: which is a statement I am still learning to understand.
<Banana>
that means you should'nt be able to do side effects.
<ejt>
the other major difference is that it is non-strict
<Banana>
no arrays no pointers, nothing that imply *inplace* modifications of structures.
<Banana>
(but such a langage wouldn't be usefull for everyday purpose).
<Banana>
like no printf ....
<Banana>
(which is a side effect).
<Banana>
so Haskell *hides* sides effect behind oppaque things called monads.
<ejt>
Banana: I disagree, Monads solve this nicely
<mattam>
and type classes too
<Banana>
that's what i was going to say.
<ejt>
y
<mattam>
:)
<Banana>
basicaly Haskell sees function that does side effects like function from a memory state to another memory state.
<Banana>
it's just a matter of point of view.
<CoolPops>
so what are the benefits of Ocaml?
<Banana>
ocaml allows you to use side effects in a more "intuitive" (aka like you use to do) way.
<Banana>
with arrays, printf, references....
<ejt>
speed, memory usage, more libraries
<Banana>
now a major diff between haskel and ocaml is evaluation strategy.
<ejt>
I don't agree with Banana, what he is saying is that imperative programming is more intuitive, which I disagree with
<Banana>
Haskell is uses Lazy evaluation.
<Banana>
ejt: I don't say that.
<mattam>
he used " "
<ejt>
< Banana> ocaml allows you to use side effects in a more "intuitive" (aka
<ejt>
like you use to do) way.
<Banana>
I say that it is more intuitive to use imperative constructions to do imperative programing.
<Banana>
what i was saying is "IF you want to use imperative features, then you can simply use them".
<ejt>
k
<Banana>
instead of using monads (which are elegant) but not that intuitive imho.
<ejt>
it's hard to say how much of that is due to your previous programming experience
<ejt>
anyway, I use them both
<CoolPops>
mindset is 90% of everything.
* CoolPops
doesn't understand monads yet.
<CoolPops>
for some reason Erlang seems to be the easiest for me to pick up on from the three.
<CoolPops>
that may be, however, because I spent the most time with it.
<mattam>
monads are a mathematical concept, so if you kown some mathematics (category theory in particular) it's probably more intuitive.
<Banana>
come on you have used Ocaml for 6 hours :)
<Maddas>
You don't need to limit yourself to one language, CoolPops
<CoolPops>
Maddas: no, but I would like to limit myself to learning 1 at a time :)
<Maddas>
Too late!
<Maddas>
:-)
<CoolPops>
Maddas: just trying to pick which one to get good at.
<Banana>
mattam: he he there is so much behind printf.... ;)
<ejt>
CoolPops: what sort of programs do you want to write ?
<mattam>
yeah, hacks
<CoolPops>
ejt: I deal with a few types. database systems, text processing, and web based (not why I am looking at functional langs).
<Maddas>
What are basic the properties of a set (as in those that the Set module creates)?
<CoolPops>
ejt: but to be honest, the real reason I am looking at functional languages is knowledge. I am pretty good at sequential, also object oriented now want to expand and learn functional...
<ejt>
then definitely explore the differences between the languages
<Banana>
Maddas: they are implemented as Balanced Binary trees.
<Maddas>
Banana: I know that, and that's all that I know :)
<Banana>
purely functionnal.
<Banana>
log(n) find.
<Maddas>
Are entries guaranteed to be unique?
<Banana>
what properties do you need ?
<Banana>
yes.
<Banana>
it's a set.
<Maddas>
Are they sorted?
<Maddas>
or necessarily sortable :-)
<Maddas>
ordered, I should say.
<CoolPops>
Work is done and I'm going home. Thanks for the help today.
<Banana>
you mean taking min in o(1) ?
CoolPops has quit ["cya."]
<Maddas>
Banana: No. Do the things stored in the set have to be ordered, does there need to be a compare function?
<mattam>
module Set: sig end
<mattam>
Sets over ordered types.module Set: sig end
<Banana>
yes
<Maddas>
hm
<Maddas>
Ok :)
<mattam>
its pretty clear
<Banana>
a total oredering.
<mellum>
Maddas: everything is comparable in Ocaml. There's a magic "<" operator.
<Maddas>
heh
<Banana>
(if you pass partial ordering..... it becomes an impredictible mess ;)
<Banana>
let's say everything of the same type is comparable. (just to be precise).
<Maddas>
I guess uniqueness is all I need, so a set should be fine.
Kinners has joined #ocaml
liralen has quit [Read error: 110 (Connection timed out)]
_JusSx_ has quit ["[BX] "got bitchx?""]
gim has quit [Read error: 104 (Connection reset by peer)]