<whee>
it's nice because it has a bunch of things done ml style, and it's basically C so it's fast
<whee>
the region based memory management is also interesting
<mrvn>
Nothing C++ can't do with a proper compiler.
<pattern_>
mrvn, i was joking... of course any language is a legitimate choice for the contest
<whee>
well C++ brings along a lot of crap :P
<mrvn>
The only reason C has buffer overflows is that people are too lazy (or want more speed) to build in the checks into the compilers.
<Smerdyakov>
I want to see me work on the Cyclone compiler, if I go to Cornell. =)
<mrvn>
You can write an Ansi C++ compiler that does GC, checks arrays and pointers and all. Perfectly valid.
<whee>
ignoring the safety features, cyclone has nice things like pattern matching and array comprehensions and blah blah
<mrvn>
array comprehensions?
<whee>
yeah
<whee>
you can go and do something like int @{50}derf = new {for i < 50 : i**2};
<mrvn>
that sucks.
<whee>
plus it includes type inference
<whee>
well, almost entirely
<mrvn>
That realy does look unreadable. Just like perl
<whee>
some things can't be inferred at the moment, but it's still nice to have it on top of C
<pattern_>
perl is not unreadable
<mrvn>
I like the pattern matching part.
<pattern_>
perl gets an undeserved bad rap for that... i think it's perfectly readable
<mrvn>
and taged unions.
<mrvn>
pattern_: die if not dead;
<mrvn>
That construct alone is hell.
Kinners has joined #ocaml
<mrvn>
The if after the body for the if. *arrrgggghhhh*
<whee>
heh
<whee>
I don't mind reading perl, but I'd much rather be using something like python if I had a choice between perl, python, and ruby
<whee>
out of the interpted languages, anyway
<pattern_>
i don't know python or ruby
<mrvn>
You have like 10 page of cod you look through and try to understand why it gives some error and then, suddenly, you notice the "if" at the end and realize that this part gets skiped.
<whee>
parsing perl code must be fun
<pattern_>
and, right now, i find ocaml much harder to read than perl.... and it's infinately harder to learn, for me... of course, i expect to feel better about all this once i actually learn it
<mrvn>
whee: There are several constructs in perl which can meen multiple things. The compiler has to guess what you probably ment.
<pattern_>
i never had a problem with that
<pattern_>
just look in the manual if you're unsure of what the language you're writing should do
<mrvn>
pattern_: the point is it could do eigther of multiple things and all would be valid.
<whee>
I just view perl5 as a hackish language, I wouldn't want to write larger programs in it
<mrvn>
you have some code that does this, then you add some () for readability and it does something else. That is real fun.
<pattern_>
yes, it is hackish... i wouldn't call it's design elegant or well thought out... but it's easy to learn, easy to use, and easy to read (for me)... all three being quite the opposite of my experience with ocaml so far
<whee>
well, ocaml's a different beast than what you're used to
<mrvn>
perl is a langugage to write code. don't try to read or understand code :)
<pattern_>
perl's associated arrays were something i found particularly poor, as far as syntax goes... but the rest of it is nice, imo
<mrvn>
pattern matching in perl is fun. You can do some real nice exponential explosions with it.
<whee>
perl6 is something I'm going to definately look into, but that's just so I'm not behind
<mrvn>
match something like a 20 char string for hours on end.
<pattern_>
well, as long as we're bitching about readability... i've found a ton of ocaml code that is inexusably written, imo... virtually _no_ documentation, and variable names constantly consisting of a single character
<pattern_>
talk about unreadable!
<whee>
that's due to the programmer, not the language
<mrvn>
pattern_: which?
<pattern_>
i know this isn't a fault of the language itself... but it seems to be quite common for ocaml programs to be like taht
<mrvn>
And whats wrong with single letter bindings?
<pattern_>
mrvn, well, take the ocaml examples
<pattern_>
or take the libraries that come with the language
<whee>
which in particular?
<pattern_>
mrvn, there's nothing wrong with them for a little bit of code, but when your whole program is made up of them there's something wrong... especially when combined with a lack of documentation
<mrvn>
All the user directed libraries have docs:
<mrvn>
val set : 'a array -> int -> 'a -> unit
<mrvn>
Array.set a n x modifies array a in place, replacing element number n with x.
<mrvn>
Raise Invalid_argument "Array.set" if n is outside the range 0 to Array.length a - 1. You can also write a.(n) <- x instead of Array.set a n x.
<mrvn>
Stuff like that.
<pattern_>
whee, i can give you plenty of examples... gimme a second
<whee>
and all the libraries are parsable with ocamldoc
<mrvn>
My docs even have highliting for stuff that changed recently.
<pattern_>
x1, x2, n, l ? what the hell are those?
<pattern_>
yes, it is common
<whee>
n is common for use as integers, x* as elements, l* as lists
<mrvn>
val sort : ('a -> 'a -> int) -> 'a list -> 'a list
<mrvn>
Sort a list in increasing order according to a comparison function. The comparison function must return 0 if it arguments compare as equal, a positive integer if the first is greater, and a negative integer if the first is smaller
<mrvn>
(see Array.sort for a complete specification).
<mrvn>
For example, Pervasives.compare is a suitable comparison function. The resulting list is sorted in increasing order. List.sort is guaranteed to run in constant heap space (in addition to the size of the result list) and logarithmic stack space.
<mrvn>
The current implementation uses Merge Sort. It runs in constant heap space and logarithmic stack space.
<pattern_>
i like to write code with _informative_ labels like "input" "output", at least...
<whee>
I mean, it's not like these are named "kjdfs" and "jfkdf"
<whee>
these _are_ informative
<whee>
there's nothing more to know than that they're two lists
<mrvn>
pattern_: the functionality is documented.
<pattern_>
i'm sure if you dig in to the code you can figure out what each part means, but you shouldn't have to dig in to it... you should be able to glance at a comment and see what that section of code is for
<whee>
with an algorithm like mergesort the variable names aren't that important
<mrvn>
pattern_: n is usually and int, some counter or something.
<mrvn>
pattern_: l is usually a list
<mrvn>
cmp a comparison function
<pattern_>
and key variables should be crystal clear... the only excusable short variable names, imo, are local, temporary variables... and few and far between, if possible
<mrvn>
h/t for head and tail
<mrvn>
or x::xs
<whee>
what do you suggest that they're named?
<whee>
heh
<whee>
I mean, n and l are really not that important in one function call
<mrvn>
pattern_: your n and l are temporary local names.
<pattern_>
whee, i'd have to analyze the code before i can give you an answer to that
<whee>
this looks like a common implementation of mergesort with a couple optimization cases
<mrvn>
pattern_: another rule in variable names: accu is used to accumulate results when transforming stuff into tail-recursive form.
<pattern_>
mrvn, i know there are many temporary variables there... but, taken as a whole, the effect is a goobledygook that is only matched by complex regex's in perl
<mrvn>
pattern_: You get used to look at the useage of the variables rather than the names.
<pattern_>
in regex's too, if you know how to interpret them, they're decyphrable.. and they're concise, and you don't really need to say "\newline", because everyone knows that "\n" means that... but get a huge regex, and try to parse through that by hand... it's a bitch
<pattern_>
that's why commenting and informative variable names are key
<mrvn>
variables like n, l, i, j, x, xs are perfectly clear to me.
<mrvn>
Maybe its just practice or a different way of thinking.
<whee>
I even use one letter bindings all over the place
<mrvn>
Just try to read formal lambda calculus code where all variables are named s', s'', s''', s'''', ...
<pattern_>
x1 x2 l2 s1 s2 ? they're only decyphrable in the _context_ of the code they're in... that means that to see what the code is processing you have to get your hands dirty in the implementation, and spend time decyphring it
<whee>
sometimes you're just writing higher level functions where the actual meaning of these variables is unimportant, and so are the variable names
<mrvn>
pattern_: no, you look at the type.
<whee>
it's the manipulation of them that matters, not what they are
rc51 has joined #ocaml
<mrvn>
pattern_: It would be great if you could hover over a variable name with the mouse in xemacs and it would tell you the type of the variable.
<Kinners>
pattern_: the meaning of x1, x2, ... are first element of list, second element of list, ... using longer names would be cumbersome
<pattern_>
and x and xs in the context of x::xs ? x is the head of the pattern and xs is the rest, but the head of what? tail of what? what exactly is being processed here? you can't tell, especially if it's in the middle of a hundred lines of similarly uncommented code, like the list.ml excerpt
<pattern_>
kinners, head of which list?
<mrvn>
pattern_: of a list, any list
<pattern_>
exactly!
<whee>
well, being in list.ml, probably a list
<whee>
heh
<mrvn>
the one matched against
<mrvn>
an 'a list
<pattern_>
you don't know which list it's talking about... following that code is a nightmare
<pattern_>
mrvn, yes, the one matched against... but what is the purpose of matching it there?
<Kinners>
rec sort n l .. match n, l with ... 2, x1 :: x2 :: _ -> ... that's perfectly clear
<pattern_>
no comments and poor choice of variable names make this indecyphrable unless you go deep in to the code
<mrvn>
pattern_: there are only ever 2 lists in the code.
<mrvn>
l1 and l2 or s1 and s2 for them being sorted.
<whee>
the documentation in list.mli make it clear as to what it does
<mrvn>
Ok, s1 and s2 is not quite clear without parsing the s1 = rev_sort n1 l i
<mrvn>
-i
<whee>
then from there it's just getting familiar with the algorithm
<pattern_>
kinners, that may well be perfectly clear... but i didn't say that small bits of uncommented code, with short variable names was indecyphrable, but long pieces of code that were uncommented with poor choice of variable names certainly are
<whee>
but these aren't poor choices of variable names
<whee>
I can take a random line with variables, and tell you what they likely represent
<whee>
which is just as good as a variable name like the_head_of_the_first_List_which_is_partially_sorted
<mrvn>
pattern_: The thing is that the function is documented to do merge_sort. Merge sort is a rather simple and short algorithm and needs no further explanation here.
<whee>
heh
<pattern_>
whee, yes you can, by looking at it and _analyzing_ it.. but you shouldn't need to analyze the code when looking at it to figure out what it does... that's what comments are for
<mrvn>
pattern_: Your not realy supposed to read the code anyway without knowing what merge sort is.
<whee>
pattern: check list.mli
<whee>
that tells you what it does
<whee>
knowing how it does it is a matter of understanding the algorithm
<pattern_>
i did look at the list.mli
<whee>
there's plenty of documentation on what a merge sort is, it's not worth clutting up the code with it
<pattern_>
it tells you what the whole code is _for_ and how you use it.. but that doesn't document the implementation, and that's what i'm talking about
<mrvn>
pattern_: what would be a better name for any of the variables?
<pattern_>
whee, the merge sort is just a simple example... ocaml code seems to be littered with this poor style
<pattern_>
again, not a fault of the language, but a vice all too common to ocaml programmers, as far as i can see
<whee>
which would make it not poor style :P
<pattern_>
what would make it not poor style?
<mrvn>
pattern_: Tell us a better name. Otherwise I will assumeits just you not yet being familiar with the nameing conventions.
<pattern_>
that it's common not to comment your code?
<whee>
it's common not to comment code which is obvious in function
<pattern_>
that it's common to choose short variable names?
<pattern_>
whee, what is the function of this code:
<pattern_>
let n2 = n - n1 in
<pattern_>
let l2 = chop n1 l in
<pattern_>
don't describe what it does, but what is it for?
<mrvn>
pattern_: it splits the list into two lists
<pattern_>
and what is it used for?
<whee>
for sorting?
<whee>
heh
<pattern_>
you have to look in to the rest of the code, don't you?
<mrvn>
merge sort.
<mrvn>
sort first half, sort second half, megre both
<pattern_>
you wouldn't know that if i hadn't already shown you where it came from
<whee>
so what do you suggest those two lines be changed to?
<pattern_>
i can grab some random lines from another piece of ocaml code if you like
<mrvn>
pattern_: Of cause not. It could mean anything without context
<pattern_>
whee, i suggest some comments
<whee>
like?
<pattern_>
well, i'd have to analyze the code myself to find out
<whee>
should every line be able to stand on its own?
<mrvn>
(* lets do mergesort here *) :)
<whee>
let x = 3 (*this is the number 3, which is used to implement a timer (we're in the timer module here, and the timer module does a lot of things, like scheduling, and signals) *)
<pattern_>
i'm not saying that every little bit of obvious code should be documented... but in what, 65 lines that i pasted there, there isn't a single comment
<mrvn>
pattern_: your line is from "let rec sort n l", which is merge sort. What else should it do but merge sort?
<mrvn>
pattern_: There realy is not a single line there that needs a comment.
<pattern_>
i disagree
<pattern_>
i guess we should leave it at that
<mrvn>
then tell us a comment for some line.
<pattern_>
but, when hearing about how unreadable perl is, it's always going to compare unfavorably to ocaml, in my eyes... just because of the poor programming style that i see to be so common... that's just my oppinion, and it may change as i get to know the language better
<mrvn>
pattern_: as if perl would have more comments :)
<pattern_>
generally, yes... and more descriptive variable names too
<mrvn>
like $_, $1, $2, $3...
<mrvn>
very descriptive.
<pattern_>
that's only used in regex's
<mrvn>
or just not passing a paramter and then its automagically $_
<pattern_>
and i always assign $_ to a more descriptive variable name right away, and use that
<Riastradh>
$_, $&, $!, $", $', et cetera...all of those are used in just regexps?
<mrvn>
Riastradh: $_ is the last return value.
<pattern_>
i comment when using those special variable names
<Riastradh>
Yes, I know.
<mrvn>
That allows for some realy nasty code.
* Riastradh
knows a thing or two about Perl, and that those don't involve regexps.
<Riastradh>
Or at least most of them don't.
<pattern_>
for example: "# turn off newlines"
<mrvn>
I know $_, whats the rest of those?
<Riastradh>
$! is the last error.
<Riastradh>
I don't remember about the rest of them, but I'm fairly certain they don't have to do with regexps.
<pattern_>
riastradh, <mrvn> like $_, $1, $2, $3... <--- that's what i was commenting at, and three out of four of those variables _do_ deal with regex's
<mrvn>
pattern_: arent $1, $2, $3,... the arguments passed to a function too?
<Riastradh>
No, they're regexp matches.
<whee>
I think that's somewhere in @_
<pattern_>
no, you're thinking of shell
<Riastradh>
$x where x is a positive integer are arguments to a shell script.
<whee>
and this is why I don't like perl
<whee>
hehh
<whee>
I would hate writing anything in a language where it feels like everything, even function arguments, was hacked on
<pattern_>
yes, @_ is the argument array, which i always match like so: ($name, $date, $time) = @_ <--- perfectly readable
<mrvn>
pattern_: most people don't.
<pattern_>
"x a b s1 l" is not
<mrvn>
Noone said you couldn't write readable code.
<pattern_>
i plan to write readable ocaml code
<pattern_>
...go against the grain :)
<mrvn>
pattern_: Thats perfectly readable.
<mrvn>
x is applied the agruments a b s1 and l.
<pattern_>
yeah, but what do those arguments mean?
<mrvn>
Without context I would say two things, probably ints, the first string and a list.
<pattern_>
is l a list of dates or times or what?
<mrvn>
pattern_: an 'a list.
<pattern_>
yes, context is necessary unless you have comments and good variable name choices
<pattern_>
that is my whole point
<mrvn>
pattern_: doesn't matter what it is and most likely its not clear.
<pattern_>
anyway, enough flaming
<pattern_>
i think you see my point, even though you may not agree
<pattern_>
and vice-versa
<mrvn>
pattern_: Get used to abstract code where you only have an abstract knowledge of variables, like l being an 'a list. Who cares what 'a is.
<mrvn>
pattern_: I see your point, but not your example.
<pattern_>
ok
<pattern_>
let's leave it at that, then
<mrvn>
I find ocaml very well documented.
<pattern_>
and i don't
<mrvn>
I practically learned all of ocaml just from the docs within days.
<pattern_>
that may change, though, as i said... as i get to know the language better and get more experience in reading other people's code
<mrvn>
probably
<mrvn>
pattern_: If in doubt just ask your friendly neighbourhood ocaml runtime.
<pattern_>
"syntax error"
<pattern_>
not very descriptive
<pattern_>
:(
<mrvn>
it highlights the part thats wrong.
<pattern_>
not always
<mrvn>
or gives the character position
<pattern_>
nope
<pattern_>
not always a reliable one, anyway
<whee>
show me a case where it doesn't
<pattern_>
sure
<pattern_>
brb
<mrvn>
whee: adding an extra ; at the end of a toplevel "let"
<mrvn>
That syntax error gets detected 2 lets down the road.
<whee>
eh?
<Kinners>
if you use the camlp4 parser instead you can get better messages
<mrvn>
let a = 1; let b = 2 _let_ c = 3
<mrvn>
Syntax error
<whee>
that must explain why I never get odd messages, I'm always going through camlp4
<whee>
mrvn: in the toplevel loop?
<mrvn>
The let b isn't toplevel anymore so it expects an "in" before the next let.
<whee>
oh, now I see what you're saying
<mrvn>
ocaml could be more descriptive here saying that it expected an identifier or "in"
<whee>
# let a = 3; let b = 2 let c = 5
<whee>
^^^
<whee>
Parse error: 'and' or 'in' expected (in [expr])
<mrvn>
But after a few of these errors you just know to check for it.
<Kinners>
that's a problem with using LALR parsers instead of hand made recursive decent ones I think
<mrvn>
How do you use camlp4 prser?
<Kinners>
in the top level you can do #load "camlp4o.cma";;
<mrvn>
and in makefiles?
<whee>
or run "ocaml camlp4o.cma"
<Kinners>
or camlp4r.cma for the other syntax?
<steele>
is there a camlp4 parser for the old syntax?
<palomer>
when does an else block end? like if i have let () = if something then something else something in something
<mrvn>
palomer: with the end of the statement
<palomer>
is the in a continuation of something or does it scope the let ()
<whee>
what he said
<whee>
heh
<mrvn>
then and else have no implicit begin/end
<palomer>
so how do I know if an in belongs to the else or the parent let?
<mrvn>
if true then 1 else 2;3 ===> 3
<mrvn>
palomer: in allways belongs to the last in
<mrvn>
last let
<mrvn>
and let has an implicit begin than end with the in
<palomer>
let () = if true then 1 else let fudge = 5 in bar fudge;;
<mrvn>
palomer: only top level lets have no in
<whee>
hrmfm
<mrvn>
Scary, I think my xterm dissapear on me sometimes.
<whee>
it's hiding from something. perhaps you should have a talk with it :)
xxd_ has quit ["EOF"]
foxen5 has quit [Read error: 110 (Connection timed out)]
xxd has joined #ocaml
<palomer>
hrmfm
<whee>
meh, I'm still having problems using streams for parsing
<palomer>
streams are fun!
<palomer>
hrm, today I got hired by a computer engineering student to implement a toking ring network in C++
<palomer>
any clues at what I should charge him?
<whee>
I really should be able to pull this off, it can't be much different than parser combinators
<whee>
.. nuts. heh
<whee>
I can't figure out what basic idea I'm getting wrong :\
<emu>
$1000000
<whee>
heh
<emu>
so you're doing his hw?
<async>
anyone want to help me with my hw? :)
<whee>
well, that was interesting
<whee>
did a rewrite of this stream parser and it just magically works
<whee>
hah,
<whee>
I'm incredibly amazed that this actually parses correctly
palomer has quit [Remote closed the connection]
<whee>
well, almost :\
<whee>
noone has streams experience? heh
<mrvn>
I looked at it and then decided to just read in my input file as char list, convert it to token list and then to AST.
<whee>
having the dumbest problem with getting it to skip over things that don't matter
<mrvn>
If you create a stream of a function, is it ever called twice on the same value?
<whee>
no
<mrvn>
and if it called in order?
<whee>
yes, it's called in order
<mrvn>
basically: does Stream.from (fun i -> read_char ()) work?
<whee>
perhaps
<whee>
heh
<mrvn>
I gave up on streams because they have no unput function, not even for a single char.
<whee>
there's functional streams, which don't remove what you take off
foxen5 has joined #ocaml
<whee>
but I guess you're expected to use npeek in that case
<mrvn>
But I guess it can be done with peek instead.
<whee>
hhrrrrrmf, this is really confusing.
<whee>
trying to get a parser that will return a value of type t if the next item on the stream matches some list of chars; if nothing matches, it'll ttry the next value in the stream
<whee>
but it's just raising an Error exception and I can't figure it out :\
<whee>
insanely confusing. hurf
<mrvn>
I have to transform a minimax search from the simple recursive form into an continuation based form.
<whee>
heh
<whee>
the same exact thing I'm doing is in the camlp4 implementation somewhere, but it won't wofk :|
<pattern_>
the difference in clarity is like night and day, imo
<mrvn>
Thats more comment than code.
<pattern_>
and that's just a random perl snippet that came up first in a google search for: perl "merge sort"
<mrvn>
Also its horibly wrong
<mrvn>
# Shift the left array over by 1 to the right to make room for the
<mrvn>
# smaller value
<pattern_>
i'm not arguing correctness, just clarity
<mrvn>
You never do that. That makes it O(n^2)
<mrvn>
or worse
<pattern_>
just commenting and variable naming style
<mrvn>
n^2 log n
<pattern_>
you can't sidetrack me! :P
<pattern_>
and i'm not saying every piece of code has to be that heavily documented... obviously that code was for tutorial purposes
<mrvn>
The only thing that might be better is using left and right for the boder index.
<mrvn>
Thats somewhat clearer than 1 and 2
<pattern_>
but if you look at it in contrast to that 65 lines of completely uncommented ocaml code that i pasted a link to earlier the difference is pretty plain
<pattern_>
# Store the right index value that needs to be brought to the front
<pattern_>
my $tmp = $array_ref->;[$right_index];
<mrvn>
Yes, I can read the ocaml code and the perl is just unintelligable bunch of comments.
<pattern_>
now, without that comment, how are you going to know why the right index value is being stored?
<mrvn>
Might be increased by the font.
<pattern_>
you have to be intimately familiar with the algorithm or analyze the code
<pattern_>
you should not have to do so
<pattern_>
what is going on should be plain from the comments and variable names
<mrvn>
pattern_: yes you should.
<pattern_>
well, maybe you _should_ be familiar with any code before you even look at it, but i don't think that's realistic
<mrvn>
Something as common as merge sort should not start to explain merge sort inside the code.
<mrvn>
Thats what books on algorithms are for.
<pattern_>
when i look at code i don't want to spend an hour figuring out what it does or how it does it
<mrvn>
You should only comment on stuff thats out of the ordinary and on the interfaces.
<mrvn>
In my code the commenting is usualy the debug output I commented out:)
<mrvn>
Not the best style.
<pattern_>
comments in the interfaces should be for people _using_ your function, not trying to maintain it or understand how it works
polin8_ has joined #ocaml
polin8_ has quit [Client Quit]
Kinners has left #ocaml []
systems has joined #ocaml
systems has left #ocaml []
mellum has quit [Read error: 60 (Operation timed out)]
Kinners has joined #ocaml
mellum has joined #ocaml
<mellum>
hi
<Kinners>
hi mellum
pattern_ has quit [Remote closed the connection]
pattern_ has joined #ocaml
docelic|sleepo is now known as docelic
Kinners has left #ocaml []
musasabi has joined #ocaml
rox|geboren is now known as rox
<mellum>
Bah. "not" really should be a keyword and not a function.
derfy has joined #ocaml
pattern_ has quit [calvino.freenode.net irc.freenode.net]
docelic has quit [calvino.freenode.net irc.freenode.net]
Riastradh has quit [calvino.freenode.net irc.freenode.net]
Rhaaw has quit [calvino.freenode.net irc.freenode.net]
rox has quit [calvino.freenode.net irc.freenode.net]
Riastradh has joined #ocaml
docelic has joined #ocaml
rox has joined #ocaml
mattam_ has joined #ocaml
pattern_ has joined #ocaml
Rhaaw has joined #ocaml
mattam has quit [Read error: 110 (Connection timed out)]
palomer has joined #ocaml
TimFreeman has joined #ocaml
TimFreeman has left #ocaml []
mrvn_ has joined #ocaml
mrvn has quit [Read error: 110 (Connection timed out)]
foxen5 has quit [Read error: 104 (Connection reset by peer)]
foxen5 has joined #ocaml
<whee>
meh I tell you
TachYon has joined #ocaml
<whee>
my interpreter is somehow incorrect ;\
palomer has quit [Remote closed the connection]
rc51 has quit [Remote closed the connection]
TachYon has quit [Remote closed the connection]
systems has joined #ocaml
systems has quit ["Client Exiting"]
derfy has left #ocaml []
docelic is now known as docelic|sleepo
TrOn has quit [Read error: 60 (Operation timed out)]