foobarquux changed the topic of #ocaml to: www.ocaml.org
graydon has joined #ocaml
jao has joined #ocaml
jao has quit [carter.openprojects.net irc.openprojects.net]
mellum has quit [carter.openprojects.net irc.openprojects.net]
jemfinch has quit [carter.openprojects.net irc.openprojects.net]
Taaus has quit [carter.openprojects.net irc.openprojects.net]
mellum has joined #ocaml
jemfinch has joined #ocaml
Taaus has joined #ocaml
jemfinch has quit [carter.openprojects.net irc.openprojects.net]
Taaus has quit [carter.openprojects.net irc.openprojects.net]
mellum has quit [carter.openprojects.net irc.openprojects.net]
mellum has joined #ocaml
jemfinch has joined #ocaml
Taaus has joined #ocaml
jao has joined #ocaml
jemfinch has quit [carter.openprojects.net irc.openprojects.net]
Taaus has quit [carter.openprojects.net irc.openprojects.net]
mellum has quit [carter.openprojects.net irc.openprojects.net]
Taaus has joined #ocaml
jemfinch has joined #ocaml
mellum has joined #ocaml
mellum has quit [carter.openprojects.net irc.openprojects.net]
jemfinch has quit [carter.openprojects.net irc.openprojects.net]
Taaus has quit [carter.openprojects.net irc.openprojects.net]
smkl has quit [carter.openprojects.net irc.openprojects.net]
gl has quit [carter.openprojects.net irc.openprojects.net]
jao has quit [carter.openprojects.net irc.openprojects.net]
mellum has joined #ocaml
jemfinch has joined #ocaml
Taaus has joined #ocaml
jao has joined #ocaml
smkl has joined #ocaml
gl has joined #ocaml
jemfinch has quit [carter.openprojects.net irc.openprojects.net]
mellum has quit [carter.openprojects.net irc.openprojects.net]
Taaus has quit [carter.openprojects.net irc.openprojects.net]
mellum has joined #ocaml
jemfinch has joined #ocaml
Taaus has joined #ocaml
jao has quit [carter.openprojects.net irc.openprojects.net]
jao has joined #ocaml
jao has quit [carter.openprojects.net irc.openprojects.net]
jao has joined #ocaml
graydon has quit [Remote closed the connection]
awwaiid has joined #ocaml
jao has quit [Read error: 113 (No route to host)]
mellum has quit [Read error: 110 (Connection timed out)]
jjl has joined #ocaml
<jjl>
hi..
<Taaus>
Hey :)
<jemfinch>
howdy
* jemfinch
is being tempted by SML.
<Taaus>
jemfinch: Really? How come? :)
<jjl>
use the sml camlp4 thing :)
<jemfinch>
mostly because (a) it seems slightly safer than O'Caml, (b) it's standardized, and (c) it has first-class continuations.
<Taaus>
I see.
<jemfinch>
the last is the biggest, of course.
<Taaus>
Of course :)
<jjl>
I'm a bit of a newcomer - what does c mean exactly?
<jemfinch>
jjl: I can't quite tell you for sure. It's something you'll really have to research (I can't tell you more than is available on the internet, since I've not yet used them)
<jjl>
heh. fair enough
<Taaus>
I'm not sure I quite see how (b) is an advantage... And alas, I can't tell if (a) is true, or not :)
<jemfinch>
(b) isn't much of an advantage, but the academic community likes that SML has several implementations (not just one) and even more that it's fully and rigorously defined.
<jjl>
I did have to change some code between 3.02 and 3.04, so I can see that b might be an advantage from that point of view
<jemfinch>
and because of that, it seems more research gets done with SML.
<jemfinch>
(a) seems that way because SML seems less focused on polymorphism (for instance, it has, *somewhere* (no in the initial environment) a function that does what "compare" does, but the compiler gives a warning when it's used)
<Taaus>
Ah.
<jemfinch>
also, for instance, it uses options instead of exceptions a lot.
<jemfinch>
for instance, in Bool.fromString, it returns a bool option, rather than a bool.
<jemfinch>
thus, it returns SOME bool when the string represents a valid bool, and NONE when it doesn't...instead of what O'Caml does, which is return a bool directly, but raise an exception on a conversion failure.
<jemfinch>
such a scheme is slightly safer in that it's *impossible* for a programmer to ignore the failure condition (he has to match the option to get the return value)
<Taaus>
Ah.
<jjl>
but slightly less efficient? it seems ocaml is geared to being efficient
<jemfinch>
yeah, matching on the option would be slightly less efficient than just calling the function.
<jemfinch>
but more efficient than putting the function in a try...with block.
<jemfinch>
(since a try...with block needs to setjmp and whatnot)
<jjl>
is it? I didn't know that.. oh, yeah I see
<jemfinch>
jjl: in the whole grand scheme of O'Caml constructs, try...with are probably one of the most expensive.
<Taaus>
SML has its own disadvantages, though.
<jemfinch>
Taaus: what are they?
<Taaus>
Well, just let me grab 'ML for the working programmer'
<jemfinch>
:)
* jemfinch
is reading "A critique of SML" at the moment.
<Taaus>
jemfinch: '+' and '*' being overloaded, for instance :)
<jemfinch>
(a) and (b), though, pale in comparison to the ability to finally be able to play around with real continuations.
<jemfinch>
Taaus: well, that's an advantage or a disadvantage.
<jemfinch>
depending on how you feel about that...
<Taaus>
Well, it does mean you have to specify the type of some functions...
<jemfinch>
unless you're happy with the default.
<Taaus>
I.e. 'fun square x = x*x;' won't go.
<jemfinch>
it will, actually -- it'll be int -> int.
<Taaus>
jemfinch: Not according to my book.
<jemfinch>
(that changed from SML 90 to SML 97)
<jemfinch>
Taaus: I think that book uses SML 90, and that's one of the things they changed.
<Taaus>
You mean the supposedly 'standard' ML changed? I smell a rat.
<jemfinch>
well, it has to be updated, of course. Standards can change, the point, however, is that they exist, in a form other than implementation, to be coded by anyone.
<jemfinch>
does sml have the .ml .mli distinction that O'Caml does?
<Taaus>
Dunno.
<jemfinch>
I haven't seen anything like that...
<jemfinch>
but if it does, declaring the types for functions wouldn't be a big deal at all, since I always do that anyway in the .mli file.
<jemfinch>
I only see .sml files, though.
<jjl>
I dont recall coming across anything like .mli when I was using mosml
<jjl>
it was only for very simple stuff though :)
<Taaus>
I just wish I could get the O'Caml GUI/graphics stuff working... :/
* jemfinch
doesn't like doing GUI stuff :)
<jjl>
I've only used the GL bindings for graphics
<Taaus>
Well, me neither... But I kinda have to ;)
<Taaus>
For my pet adventure game project (not in O'Caml, though :)
<Taaus>
jemfinch: Are you going to release the sources of that IRC bot, BTW?
<jemfinch>
Taaus: when I get a chance to finish the rewrite.
<jemfinch>
it's just a bunch of ugly code :)
<Taaus>
Ah.
<jemfinch>
a mish-mash of libraries translated from other languages, etc.
<Taaus>
:/
<jemfinch>
let's see...it relies on my translated python modules, my interpreted languge "ast," my translated cdb database system, my little set of utility functions (seems every ocaml programmer has one) and a lot of other stuff :)
<Taaus>
Right...
<Taaus>
Maybe I'd be better off rolling my own IRC bot, then ;)
<jemfinch>
oh, are you planning to write an irc bot?
<Taaus>
Well, I've been toying with the idea...
<jemfinch>
well, by all means, feel free to have the code.
* jemfinch
can zip it up any time you need it, just don't expect too much :)
<Taaus>
Originally I wanted to do it in Perl or Ruby, or something, but there are a couple of security issues involved...
* jemfinch
has written an irc bot in Python, too.
<jemfinch>
ew, Ruby.
<Taaus>
You don't like Ruby?
<jemfinch>
it has no real use, IMO.
<Taaus>
Eeeh?
<Taaus>
Do elaborate.
<jemfinch>
well, it's really not superior to other languages.
<jemfinch>
The syntax is less readable and natural as Python's, but less useful for quick hacks like Perl's is useful for.
<jemfinch>
the implementation in C is horrid.
<Taaus>
Less readable? That's very subjective, Mr. Python programmer...
<Taaus>
:)
<jemfinch>
it has fewer libraries, fewer users, and a slower development cycle than Python or Perl.
<jemfinch>
it's not faster than either Python or Perl (regardless of the claims of Matz, which simply don't hold up to reality)
<jemfinch>
it doesn't have first-class functions.
<Taaus>
Heh, fewer libs and fewer users aren't problems with the language...
<Taaus>
(And neither is implementation, BTW.. But I digress..)
<jemfinch>
when considering single (or practically single) implementation languages, they do.
<jemfinch>
if you just want to consider the language itself, it's obviously inferior to Python.
<jemfinch>
it doesn't have as many features, its syntax is by far less intuitive...
<Taaus>
Right... Obviously... Right...
<jemfinch>
coroutines?
<jemfinch>
generic iteration?
<jemfinch>
first class functions?
<Taaus>
Heh, well... I guess every language has its advocates...
<jemfinch>
I'm more of an anti-advocate, actually :)
<jemfinch>
what are you reasons for liking Ruby?
<Taaus>
You sure don't come across as one...
<jemfinch>
(I mean, rather than advocating things, I generally just denigrate the things I don't like :))
<Taaus>
Well, I think Ruby code is very readable... And I'd give it a couple of points for consistency ;)
<jemfinch>
Have you read Python code? You'll find that in nearly every circumstance, it's more consistent than Ruby code.
<jemfinch>
Ruby still has a lot of the evil syntactical sugar that leads to useless variability in code.
<Taaus>
Umm.. I think we're talking about different kinds of consistency...
<jemfinch>
(it's certainly better than Perl in that regard, of course, but it's not superior to Python)
<Taaus>
Really? Do tell?
<jemfinch>
for instance, in Ruby, can you not put a condition before *or* after the code to execute based on it?
<Taaus>
Dunno.
<Taaus>
Haven't tried :)
<jemfinch>
"do_stuff() if" ... or "if (...) do_stuff"
<Taaus>
Oh, right.
<Taaus>
Yeah, I think you can do that.
<Taaus>
How is that a bad thing?
<jemfinch>
it means that code has an extra way to be inconsistent.
<jemfinch>
it detracts from readability because you have to be aware of both types of conditions, and you have to be ready to read both...
<Taaus>
Well, it's the programmers fault if the code is inconsistent, IMO..
<jemfinch>
and where one programmer might use one form, another programmer might use another form -- and both will have more trouble reading the other's code because he would've done it differently.
<jemfinch>
that's the thing -- it doesn't help anything, but it makes it harder to read others' code.
<jjl>
isn't that equally, if not more true of perl though?
<jemfinch>
jjl: oh, it's far more true of Perl.
<Taaus>
Umm... Well, I don't agree... It's obvious what each of those two constructs do...
<jemfinch>
Ruby's better than Perl in that regard, by a lot, but it's not Python.
<Taaus>
Perl... Don't get me started :)
<Taaus>
Write-only coding... :/
<jemfinch>
Taaus: it is obvious what those constructs do, sure -- but the fact that there are two to choose from means that programmers will still write code in varying ways.
<Taaus>
jemfinch: Yeah, but you wouldn't use 'do_stuff() if' for a large block of code... Not if your head was screwed on properly, anyway ;)
<jemfinch>
Taaus: that's one of the biggest problems -- too often programmers with their heads screwed on properly need to maintain the code of programmers with heads that were slightly less tightly attached...
<jemfinch>
in Python, the damage those programmers with their heads unscrewed can do is minimized.
<jemfinch>
And even good programmers will sometimes choose different idioms than other good programmers, and it all makes the code less consistent and harder to read.
<jemfinch>
Python's syntax is much more like english than Ruby's -- even if you don't know Python right now, you can check out /usr/local/lib/python<version> and read the code, and I'll bet you'll be able to understand it with no difficulties whatsoever.
<jemfinch>
I can't do the same thing with Ruby, though -- it's just not as natural for a programmer to read.
<Taaus>
Heh, aiming for English syntax isn't neccesarily a good thing, IMO...
<jemfinch>
I'm not talking about Perl's kind of "it's like a natural language!" BS.
<jemfinch>
I'm just saying, if, say, you want to iterate over a list, you say "for element in list: ..."
<jemfinch>
or for lines in a file (this requires 2.2 and its new iterators) "for line in file_object: ..."
<Taaus>
File.open("foo.bar").each { |line| print line }
<Taaus>
:)
<jemfinch>
that's far less natural/intuitive.
<Taaus>
To you, maybe...
<jemfinch>
I really doubt anyone can argue that "File.open("foo.bar").each { |line| print line }" is more naturally readable than the Python version:
<jemfinch>
for line in open("foo.bar"):
<jemfinch>
print line
<Taaus>
Well, what would it look like if you wanted to print linenumbers as well? :)
<jemfinch>
i = 1
<jemfinch>
for line in open("foo.bar"):
<jemfinch>
print i, ": " + line
<jemfinch>
i += 1
<jemfinch>
<Taaus>
File.open("foo.bar").each_with_index { |line, index| print index +":" + line }
<Taaus>
(If memory serves...)
<jemfinch>
I still think it's hard to argue that the Ruby version is more readable.
<Taaus>
Well, you would, wouldn't you? ;)
<jemfinch>
aside from pure language considerations, though, there's really no reason, implementation-wise, to choose Ruby over Python.
<jemfinch>
it's slower, it has fewer libraries, it has fewer users, its implementation is much worse coded (and thus harder to modify for your needs) and it doesn't get useful new features added nearly as often.
<jemfinch>
it doesn't compile to bytecode, so it can't cache compiled source files.
<jemfinch>
Ruby is just looking for a niche that's already filled *very* well by Python.
<Taaus>
Umm... It does compile to bytecode... And you can even save the bytecode... There's no guarantee it'll work between versions, though.
<jemfinch>
you'll also note that no large project has been written in Ruby, whereas numerous large projects (some as large as 140,000 lines of code) have been written in Python.
<jemfinch>
no, it doesn't compile to bytecode.
<jemfinch>
it directly evaluates the syntax tree.
<Taaus>
Hmm...
<jemfinch>
they want to make 2.0 compile to bytecode, but at the moment, that's vaporware.
<jemfinch>
the reason I know all this is that while I was implementing my language in O'Caml, I was reading lots of implementations of interpreters (since I have no formal training in CS whatsoever and needed all the help I could get)
<jemfinch>
check out eval.c in the Ruby source distribution if you don't believe me :)
<Taaus>
Heh, I stay as far away from C as I possibly can.
<jemfinch>
me too :)
<jemfinch>
but all these languages are written in C :)
* jemfinch
read a lot of Lua, Python, Ruby, Tcl, etc.
<Taaus>
And I truly don't care if you're right or not... I haven't had a use for bytecode compilation yet :)
<jemfinch>
well, for scaleability, it's something that's really good to have.
<jemfinch>
I mean, who wants to relex and reparse 140,000 lines of code every time you start a program?
<Taaus>
Umm.. I dunno..
<jemfinch>
and once you get into optimization of the abstract syntax tree, that's when bytecode compilers really come in useful.
<Taaus>
Was that a rhetorical question? ;)
<jemfinch>
my problem with Ruby isn't as much that it's a *bad* language (it's better than a lot of other ones -- Perl, Tcl, etc.) just that it's inferior in every way to Python, and thus not useful, IMO.
<jemfinch>
I just don't like to see people using Ruby when they could be doing even better using Python.
<Taaus>
Well, my problem with Ruby is that @ means instance variable... To my poor Perl-affected brain, I keep seeing 'array this, array that' ;)
<jemfinch>
it's just another example of where Ruby introduces strange, unnatural syntax :)
<Taaus>
Well, it's only unnatural because I was subjected to Perl first...
<jemfinch>
in Python, for an instance variable, you'll generally use "self."
<Taaus>
(And because I don't program that much in Ruby..)
<jemfinch>
it's unnatural because there's nothing inherent in the symbol "@" that means "this is an instance variable"
<jemfinch>
whereas in Python, a reference to an attribute of the "self" object is very obviously an instance variable.
<Taaus>
Heh, you'd probably have a field day with AGAST (the scripting language I'm using for my adventure game.) It has a couple of really nasty inconsistencies ;)
<jemfinch>
hehe :)
<Taaus>
But a lot of that is due to the fact that 90% (or more) of the community aren't programmers...
<Taaus>
I see a lot of nasty AGAST code...
jjl25_ has joined #ocaml
jjl25_ is now known as jjl_
<Taaus>
wb jjl
jjl has quit [Read error: 104 (Connection reset by peer)]
jjl_ is now known as jjl
<jjl>
bah.. my network card died
<Taaus>
:/
smklsmkl has joined #ocaml
smkl has quit [Read error: 104 (Connection reset by peer)]
graydon has joined #ocaml
jjl has quit ["Client Exiting"]
smklsmkl is now known as smkl
<awwaiid>
just give me back my { and } and python would be just fine. I've had way too many corrupted files to go for that white-space-sensitive stuff.
<jemfinch>
corrupted files?
* jemfinch
has never had that problem.
<jemfinch>
I'm quite fond of the lack of braces and indentation based syntax in Python.
<jemfinch>
I think it leads to much more consistency and readability.
<awwaiid>
Oh its definately infrequent. Maybe it wouldn't be a problem these days... mostly having to do with floppies and bad M$->unix converters.
<jemfinch>
the only problem is that it castrates lambdas.
<awwaiid>
castrates lambdas? I think I'm going to have to quote you :)
<awwaiid>
I didn't even know python had lambdas.
<awwaiid>
my bitter angst at the lack of {}'s has kept me away.
<awwaiid>
Its irrational, I know.
<jemfinch>
:)
<jemfinch>
a lot of people's bitter angst at the lack of braces keeps them away :)
<jemfinch>
but I've honestly never seen someone program in Python for a few weeks and then quit because of the whitespace indentation.
<jemfinch>
it's something most people really grow to love.
<awwaiid>
who knows. maybe one day I'll try again :)
* jemfinch
used to use Python.
<jemfinch>
I don't anymore because I suppose I'm just not good enough a programmer to write correct code in a language that does so little compile-time checking.
<awwaiid>
haha
<awwaiid>
yes... ocaml and the like have spoiled me too. I went to write something in (*sudder*) c++ the other day and it seemed to drag on and on and on because of the stupidest errors.
<graydon>
jemfinch: if you write _really_ assertion-heavy code, with a "test" mode in every function where it doesn't really "do" what it meant to, you can get by in a no-static-checks sort of language. but it's tedious and annoying.
<jemfinch>
graydon: yeah, and even then you won't get the same assurances you get with static typing.
<jemfinch>
you won't get the 100% code coverage analysis that strict compilation provides, or the ability to refactor without fear of breaking the program.
<graydon>
jemfinch: oh, I know, I really don't enjoy working that way. just that it's possible. I get forced to do it sometimes (writing python, perl, sh, C, or something)
<jemfinch>
graydon: if you have any examples of that kind of code in Python that you're free to release, I'd be interested in seeing what it looks like.
* jemfinch
can feel himself being converted to SML.
<jemfinch>
so why do you use O'Caml instead of SML?
<graydon>
better standard tools. camlp4 in particular :)
<jemfinch>
do you use camlp4?
<graydon>
definitely. it is imho the most useful part of ocaml.
<graydon>
or at least the distinguishing part. the compiler and standard libraries help an awful lot too :)
<jemfinch>
what do you use it for?
<graydon>
camlp4 lets you make up a notation for whatever problem you're working on. it's like (defmacro...) for ML.
<jemfinch>
it seems to require a whole lot more knowledge of ML and parsing stuff than defmacro does, though.
<graydon>
a little, but the results are really really useful.
<graydon>
especially since, well, if you happen to already _have_ some domain language kicking around
<graydon>
you can teach camlp4 how to transform it directly into ocaml
<graydon>
which gives you an optimizing compiler for free
<graydon>
imho very handy
<jemfinch>
so this interpreter I've written in O'Caml, I could get camlp4 to just translate that into O'Caml?
<graydon>
possibly. it depends on the language, but yes, it's quite possible.
<jemfinch>
hmm.
<jemfinch>
camlp4 always just seemed too hard to learn for me.
<graydon>
I've embedded several languages into ocaml with it so far, and am quite satisfied.
<graydon>
it takes some learning. it's definitely harder than (defmacro...) :)
<graydon>
basically you have 3 options with camlp4:
<graydon>
(1) you extend the syntax of caml "transparently", which means trying to interface an extension into the main ocaml grammar.
<graydon>
(2) you add a "quotation expander", which lets users jot down values in new notations, surrounded in <:foo< ..... >> quote blocks.
<graydon>
(3) you redefine the entire grammar from scratch, for translating "pure" language foo input into ocaml.
<jemfinch>
how hard is 3?
<graydon>
3 is not too bad, since you can use a simpler grammar than ocaml's, and just transform it into a subset of ocaml, to feed into the ocaml compiler.
<graydon>
2 is also not too bad, for the same reason.
* jemfinch
wouldn't mind an s-exp based syntax for O'Caml.
<graydon>
1 varies. it can be easy or it can be hard, depending on whether your extension interacts well with other parts of ocaml's grammar
<jemfinch>
then you could you could just write defmacro itself :)
<graydon>
there's already a sexp camlp4 module, in camlp4/ets/pa_lisp.cmo, I think.
<jemfinch>
it's ugly, and O'Caml shines through way too much.
<jemfinch>
I mean something that would make O'Caml look much more like Lisp...not like parenthesized O'Caml :)
<graydon>
well, it depends how much insight you want to give the translation module into the semantics of the translatee.
* jemfinch
goes back to doing laundry and translating Greek.