blueshoe has quit [Read error: 104 (Connection reset by peer)]
DiabloEMN has quit [Remote closed the connection]
jbm____ has joined #ocaml
<jbm____>
anybody mind helping a newbie with a mostly-implementation conceptual hurdle?
<pattern>
just ask
<jbm____>
i'm trying to build a parse tree out of a string containing words and parens
<jbm____>
so i've got type tree_struct = { mutable name : string; mutable children : tree_struct list; mutable parent : tree_struct };;
<jbm____>
problem being: i can't bootstrap the thing =)
<jbm____>
if i make .parent a 'tree_struct optional', it complains in assignment code, and i can't find any documentation on how to make a self-referencing declaration
blueshoe has joined #ocaml
<mattam>
parent has to be optional
<Riastradh>
jbm____ (you really like underscores, don't you?), how are you assigning parent?
<jbm____>
Riastradh: well, i'm not, that's the problem
<Riastradh>
...um, what do you mean by 'it complains in assignment code,' then?
<jbm____>
I tried setting it to the expression-name-thingy ("variable") i was currently defining
<jbm____>
that didn't work. And i can't not-assign it
<jbm____>
Riastradh: the underscores are because every last normal nick i use is taken on here, and i'm not on often enough to reg a new one =)
<Riastradh>
What about just 'jbm?'
<jbm____>
most definitely taken
<Riastradh>
No.
<jbm____>
if you /nick jbm, you'll get a message from the nickserv bot, whatever its name is
<Riastradh>
Yes, but that's all you'll get.
<Riastradh>
The guy hasn't connected in nineteen weeks.
<jbm____>
how do you check that, may i ask? i haven't really IRCed in about 5 years =)
<Riastradh>
/msg NickServ info jbm
<jbm____>
hrm. dankesehr
jbm____ is now known as jbm
<jbm>
i seem to recall dalnet having a nickserv that would get all pissy if you weren't the person in question
<Riastradh>
Now, what do you mean by 'I tried setting it to the variable that I was currently defining?'
<jbm>
let root_node = { string = "__ROOT__" ; children = [] ; parent = root_node } ;;
<Riastradh>
...uh.
<jbm>
yah, i know. i don't have any better ideas at this point
<Riastradh>
First, you can't evaluate root_node before its value is created.
<Riastradh>
Second, what's the type of root_node?
<jbm>
type tree_struct = { mutable name : string ; mutable children : tree_struct list ; mutable parent : tree_struct } ;;
<Riastradh>
(or what should the type be, anyways)
<jbm>
(sorry, the root_node ... string = should be root_node ... name =)
<Riastradh>
What happened to the option?
<jbm>
oh, this is without the option
<jbm>
with the option, i get problems in the parse fun
<Riastradh>
You know how option works, right?
<jbm>
maybe i should explain the problem to see how you would solve it
<jbm>
yah, kind of
<Riastradh>
Define [['a option]].
<jbm>
it allows the use of None as a value by creating a new "wrapper" type of sort
<jbm>
ok, sorry, i really don't understand that line
<Riastradh>
(the [[]] is just a notation I use for delimiting code in conversation text)
<jbm>
ah, ok
<jbm>
'a option is something like [[type 'a option = None | Value of 'a]]
<Riastradh>
[[Some of 'a]], not [[Value of 'a]].
<jbm>
ah, yes, sorry
<jbm>
Oh. hrm.
<Riastradh>
How is the parse function using the parent field?
<jbm>
Please excuse the embarrasing newbie feel of it all. I've spent years in C, only to be reduced to a bad-statement-emitting newb again.
<jbm>
It's a terrible amalgamation of the OCaml book's BASIC lexer and my own terrible code.
<Riastradh>
You apply child_add to the parent field of one of those tree records. child_add assigns a field of the tree record that is passed to it -- but what you passed is what's in the parent field, which is of type [[tree_struct option]], not just tree_struct --.
<jbm>
Arg.
<jbm>
That makes a hell of a lot of sense, thank you
<jbm>
so i should wrap all code that touches [[.parent]] with a [[match None -> (*something*) | Some p -> (* work with p *)]], and it seems sane otherwise?
<Riastradh>
I haven't looked very closely at the code, but yes, that's what you'd want to do.
<jbm>
Yah, the tree-building is b0rked at the moment, i think, but i've been beating my head against the bootstrapping problem for a while.
<jbm>
Thank you so very much; there's a lot of changes between this and my trusty C. It's been rough going, but i really like the language overall.
<blueshoe>
So what is ?strong typing??As best as we can tell,this is a meaningless phrase,and people often use it in a nonsensical fashion.To some it seems to mean ?The language has a type checker?. To others it means ?The language is sound?(that is,the type checker and run-time system are related)...
<Riastradh>
'Strongly typed' means 'unchecked type errors do not occur.'
<Riastradh>
(regardless of whether checking is done statically or dynamically)
<blueshoe>
To most,it seems to just mean,"A language like Pascal,C or Java,related in a way I can"t quite make precise". For amusement, when someone mentions the phrase "strongly typed"at a cocktail party,ask them to define it,then sit back and watch them squirm.
<blueshoe>
And please, don?t use the term yourself unless you want to sound poorly- trained and ignorant. Use the terminology of this course instead.
<blueshoe>
hehe
rox has quit [Read error: 110 (Connection timed out)]
<blueshoe>
You will sometimes see people refer to the lack of mutation as "referential transparency", as in "Haskell is referentially transparent" (and, by extension, languages like Java, C++, Scheme and ML are not).
Nutssh has joined #ocaml
<blueshoe>
It's a great phrase to use at cocktail party and it makes Haskell sound very impressive, but please understand that its use in this manner verges on the nonsensical.
<blueshoe>
hmm... i wonder how many other sacred cows he's going to attempt to slaughter
<Riastradh>
What terminology do they want you to use to mean 'unchecked errors due to type mismatches can't occur?'
<Nutssh>
What are you talking about, sounds interesting.
<blueshoe>
riastradh, i dunno.. haven't got to that yet
<Riastradh>
Nutssh, Shriram Krishnamurthi is making quibbles about the terms 'strongly typed' and 'referentially transparent.'
<Nutssh>
Interesting! And damn. :( I have to grade the class on automata theory right now. :/
<blueshoe>
riastradh, "type soundness" might be the term he prefers
<Riastradh>
What term does he prefer to mean that for every input to a function there is only one possible output?
<blueshoe>
"...In particular, we would like to know that the type system did indeed abstract over values: that running the type checker **correctly predicted** (up to the limits of the abstraction) what the program would do."
Hipo has quit [Read error: 104 (Connection reset by peer)]
Hipo has joined #ocaml
<blueshoe>
"...Type soundness is, then, really a claim that the type system and run-time system (as represented by the semantics) are in sync. The type system erects certain abstractions, and the theorem states that the run-time system mirrors those abstractions. Most modern languages, like ML and Java, have this flavor."
<blueshoe>
"In contract, C and C++ **do not have sound type systems.**"
<Nutssh>
Query: Ocaml has no special form like call/cc, but I believe that ocaml does?
<blueshoe>
nutssh, is that a deliberate contradiction?
<Nutssh>
Lol. change that second ocaml to sml-nj.
<blueshoe>
the answer is: i don't know... maybe someone else here might... or maybe #sml?
<Riastradh>
Nutssh, yes, SML/NJ has call/cc.
<Nutssh>
Thanks.
<blueshoe>
riastradh, also "type saftey" is the other term he prefers... "...the property that no primitive operation is ever applied to values of the wrong type"
<blueshoe>
i always thought strong typing was kind of synonymous with type safety
<Nutssh>
I've heard arguments that lisp is type-safe, in that you can't do illegal things. It may raise an exception or an error, but that is defined behavior that may be later caught.
<Nutssh>
I think it is somewhat compelling.
<blueshoe>
which? lisp or the type safety terminology over using "static typing"?
<Riastradh>
Static versus dynamic and strong/safe/sound versus weak/unsafe/unsound are orthogonal.
<blueshoe>
ah
<Riastradh>
C is statically and weakly/unsafely/unsoundly typed.
<Riastradh>
Scheme is dynamically and strongly/safely/soundly typed.
<Riastradh>
ML and Haskell are statically and strongly/safely/soundly typed.
<Nutssh>
Ah. I see how I misread that line.
<blueshoe>
err.. yeah, i meant "strongly typed" in my last query
<blueshoe>
that's the term this guy abhors.. but he doesn't make a case for why
<blueshoe>
he just says it's vague
<Riastradh>
It's not vague. It's just often misused.
<Nutssh>
Strong (static/compile-time)seems like it should imply type safety. But type safety should imply nothing about strong (static/compile-time) typing.
<cleverdra>
Nutssh - please do not equate 'strong' with 'static' typing.
<Riastradh>
Nutssh, count up five messages of mine, not including this one, and please repeat it.
<Nutssh>
<Riastradh> Static versus dynamic and strong/safe/sound versus weak/unsafe/unsound are orthogonal.
<Riastradh>
Now eliminate all the 'versus x' clauses and repeat it again.
<cleverdra>
Nutssh - you miscounted.
<Riastradh>
cleverdra, no, he didn't.
<cleverdra>
oh, indeed.
<Nutssh>
I need to be less sloppy.
<Riastradh>
Nutssh, remove each occurance of 'versus x' in that message and repeat it.
<cleverdra>
Nutssh - indeed.
<blueshoe>
cleverdra is a real programmer, he counts from 0
<blueshoe>
;)
<Nutssh>
The claim that strong and static are orthogonal.
<cleverdra>
Nutssh - yes, they have nothing to do with each other.
<Riastradh>
You know what 'orthogonal' means, right?
<Nutssh>
Yes, I know what they mean. I've had this pointed out to me before, too.
<cleverdra>
Common Lisp has strong dynamic typing -- and certain CL systems actually perform a great deal of optimization and type inference.
<Nutssh>
*nods* I've used the python compiler -- I liked that property.
<Riastradh>
Perl has four types: scalar, array, hash, and function.
<Riastradh>
Perl is _very_ statically typed.
<Riastradh>
You have to annotate every variable with its type, either with $, @, %, or \&.
<blueshoe>
well, ok, then.. if you don't distinguish between integer and string values then i guess you can call it one type
<Riastradh>
Can't distinguish 'em in Perl, as far as I know.
<blueshoe>
in fact, by that reasoning you could use just one type for everything and call yourself "statically typed", right? ;)
<jbm>
Riastradh: unquoted strings get their own type, but it's all fuzzily defined (designed by a linguist)
<jbm>
blueshoe: yes, i would say brainf*ck is pretty statically-typed =P
<Nutssh>
perl has lists and hashes.
<blueshoe>
perl -e '$foo="bar";$foo++;'
<blueshoe>
that's so nice, don't you think?
<jbm>
blueshoo: should return "bas"
<jbm>
blueshoe: you're really missing the whole concept of type as an abstract
<blueshoe>
how so?
<cleverdra>
blueshoe - (let ((foo "bar")) (set! foo 666) (display foo)), for your earlier example.
<jbm>
blueshoe: just because you have a weird bastardized int-slash-string type doesn't mean you're using it as two types
<blueshoe>
# let foo = "bar";;
<blueshoe>
val foo : string = "bar"
<blueshoe>
# foo + 1;;
<blueshoe>
This expression has type string but is here used with type int
<blueshoe>
now, that's what i like :)
<jbm>
hey, i'm a C guy. I like my typecasting. But Perl's dynamic typing has some really handy (hackish, typically) uses
<blueshoe>
jbm, but i just did use it as two types
<cleverdra>
(let ((foo "bar")) (+ foo 1)) will produce a similar error.
<blueshoe>
yes, i can see the hackish uses of this
<cleverdra>
jbm - Perl in general lends itself to hackery -- please don't confuse that with dynamic typing.
<blueshoe>
but it also makes your code more succeptible to errors (like if you forget that $foo is a string)
<jbm>
cleverdra: i'm referring to the rampant implicit stringification
<cleverdra>
jbm - it doesn't have 'rampant implicit stringification', it has 'string/number equivalency' in one 'scalar' type.
<Nutssh>
Perhaps a different example from perl? print ("0" eq "00") ; print "\n" ; print ("0" == "00") ; print "\n";
<jbm>
cleverdra: i'm referring to scalar module references
<cleverdra>
Yes, one uses the scalar as a string and one uses the scalar as a number. So what?
* jbm
passes out the Abstract Algebra textbooks
<blueshoe>
cleverdra, so you can easily confuse strings and numbers... that doesn't sound like perl has it's types straight, no matter that it chooses to call them "one type"
<cleverdra>
Imagine an O'Caml where everything operated on string_or_number types.
<jbm>
cleverdra: no, thanks. i do appreciate the static typing =)
<cleverdra>
jbm - sigh, this has nothing to do with static typing.
<jbm>
cleverdra: err, slip a "between ints and strings" in there
<cleverdra>
huh, OK.
<blueshoe>
cleverdra, it is possible to make such types in ocaml, but it doesn't encourage confusing types... if you want to do that then it'll be intentional (and a dangerous practice, imo)
<Riastradh>
The point is that numbers and strings are the same thing in Perl, regardless of whether it's considered statically or dynamically typed. (It happens to be statically typed.)
<Riastradh>
s/are the same thing/are of the same type/1
<cleverdra>
blueshoe - yes, Perl encourages many possibly unlikable practices.
<cleverdra>
blueshoe - such as using regular expressions and creating regular-expression-parsable formats instead of building a proper parser.
<blueshoe>
i did say i appreciated the hackish uses of perl
<jbm>
Riastradh: hrm. yah, perl is statically typed, but it has enough implicit stuff that makes it feel dynamic to me
<blueshoe>
in fact, i like perl (not completely, but overall)
<blueshoe>
still, i like strong typing
<jbm>
Riastradh: what would you call the way perl does stringification of various things at random times?
<cleverdra>
yes, me too =) I also like dynamic typing.
<blueshoe>
and you can't have that if you think numbers and strings are the same type
<Riastradh>
Everyone likes strong typing.
<blueshoe>
err.. i meant safe typing
<Riastradh>
No one likes obscure errors caused by type mismatches.
<jbm>
Mostly because we're all willing to say "hey, wow, i screw up," i think =)
<cleverdra>
blueshoe - sure you can -- adding an int_or_string type to O'Caml won't destroy its strong typing =)
<blueshoe>
riastradh, the creators of perl evidentally do
<blueshoe>
it won't?
<cleverdra>
blueshoe - your string_eq and int_eq operators will still whine at compiletime if you pass other than a string_or_int at them.
<blueshoe>
how about an "everything" type?
<cleverdra>
also, 'to'.
<cleverdra>
blueshoe - please don't confuse 'int_or_string' with 'everything'.
<blueshoe>
that'd defeat the purpose of the type system, no?
<cleverdra>
blueshoe - but an 'everything' type works well to think of dynamic typing systems.
<blueshoe>
therefore you are circumventing it by adding such polymorphous types
<jbm>
cleverdra: i would argue that a lack of type system is still a strong type system, so long as everything is a bag-o-bytes
<blueshoe>
and so perl did by using one type for both strings and numbers
<cleverdra>
-- except that dynamic type systems typically allow runtime extension of the type system.
<cleverdra>
jbm - sure, but so what?
<jbm>
cleverdra: dynamic type systems typically do implicit casting between types to allow comparison and whatnot, right?
<cleverdra>
jbm - that hardly defines a useful type system.
<Riastradh>
'Implicit casting?'
<jbm>
cleverdra: you're obviously not a systems programmer ;^P
<cleverdra>
jbm - no, dynamic type systems do not typically do that.
<cleverdra>
jbm - please don't make offensive remarks.
<Nutssh>
jbm: I don't think so, as Riastradh reminded me earlier:
<jbm>
cleverdra: hey, i said you weren't =)
<Nutssh>
<Riastradh> Static versus dynamic and strong/safe/sound versus weak/unsafe/unsound are orthogonal.
<cleverdra>
jbm - putting a smiley on "You obviously don't know what you're talking about." doesn't make it less rude, OK?
<jbm>
cleverdra: that's not what i implied at all. i was saying that systems programmers don't typically care about more than bytes
<jbm>
cleverdra: sorry if it was misconstrued
<cleverdra>
jbm - no, they always care about more than bytes -- even when their type systems do not directly support these notions.
<Nutssh>
I don't see how to avoid ill-formed operations on bagobytes.
<cleverdra>
jbm - see Forth stack comments =)
<jbm>
cleverdra: oh, heh, i missed those
<jbm>
so anyway. now that i'm done offending people, i'm back to being slightly confused
<jbm>
i suppose i should google around before wasting time with questions about dynamic typing systems, though
<jbm>
i'm used to dynamic systems doing weird things like overloading "+" to mean concatenation as well as addition
<cleverdra>
yes, Arc wants to do that.
<jbm>
so [[(string s) + (int i)]] would wind up being "si"
<cleverdra>
You can define such operations in CLOS, if you really want to.
<jbm>
to me, that sounds like implicit type promotion
<jbm>
but apparently i'm way off in left field and i didn't even know it. what am i missing?
<Nutssh>
jbm: dynamic/static is orthogonal to strong/weak
<cleverdra>
jbm - but take a look at Common Lisp or Erlang before you dismiss dynamic typing as an artifact of Perl and Python craziness =)
<jbm>
cleverdra: i've used (what i thought was) dynamic typing in C# (stop lauging at me ;^)
<cleverdra>
I don't know anything at all about C#, sorry.
<Nutssh>
Java is dynamic typing --- you can cast to Object and back at any time. But it is strong in that it will catch illegal casts. Lisp is the same way.
<jbm>
cleverdra: well, the bits i was using are in C++ as well. Basically, you can define methods for a class that promote it to a different class
<cleverdra>
well, er, I know that Microsoft defined it and that it has something to do with .NET and that .NET supposedly has its goal as a 'universal VM' for various languages to compile to.
<jbm>
cleverdra: they do really neat things with the universal VM. you should look into it sometime, it's quite clever. Very not-MS feeling.
<cleverdra>
Nutssh - no, Java has static rather than dynamic typing.
<cleverdra>
Nutssh - Object bizareness aside.
* cleverdra
shudders.
<Nutssh>
cleverdra: ? An Object can contain any non-primitive, the actual type is checked concretely at runtime.
<cleverdra>
Nutssh - and if you define an 'everything' type in O'Caml and program exclusively with it, you still don't get a language with 'dynamic typing' =) -- but I agree that we talk about edge cases, here.
<Riastradh>
cleverdra, sure you're using dynamic typing. The constructor is the dynamic type.
<Nutssh>
Can you define an everything type in ocaml?
<Riastradh>
No.
<jbm>
much as i enjoy this discussion, i need to actually do the homework i was kludging together to help me with
jbm has quit ["Client exiting"]
<cleverdra>
Nutssh - you can define a type with constructors for every type in O'Caml -- but nothing to stop someone else from defining a new type which it doesn't include.
<Nutssh>
What about functional types?
<cleverdra>
Nutssh - I don't know what you mean when you say that, sorry.
<Nutssh>
Assume you use the language ocaml with only functions and ints. can you declare a datatype that can contain all ints and all functions (including higher order) on int
<cleverdra>
ah. My bad =)
<Nutssh>
datatype IntFuns = Int of int | IntFun of int -> int | Foo of (int -> int) -> int | ...
blueshoe has quit [Read error: 104 (Connection reset by peer)]
<blueshoe>
teratorn, not concatenation, arithmetic
<cleverdra>
teratorn - no, that doesn't work.
<teratorn>
huh, what?
<Maddas>
teratorn: and "foobar" - "bar" gives you "foo"?
<cleverdra>
'foo' . 'bar' eq 'foobar'
<blueshoe>
teratorn, yes, my example was an evil use, but it's the only one i can think of that would half way legitimise allowing arithmetic opperations on strings
<Maddas>
So what would "foo" * "bar" do? :)
<teratorn>
Maddas: no of course not
<teratorn>
Maddas: explode!
<blueshoe>
and, since it's evil, it shouldn't have been in the language in the first place
<cleverdra>
Maddas - don't confuse teratorn with someone very knowledgable about Perl.
<cleverdra>
also, (sp).
<Maddas>
blueshoe: Perl would be very unpractical without many evil things
<teratorn>
notice i same *some* functions.
<Maddas>
The point of it is to be practical, I'm not claiming it's very elegant/type-safe/whatever
<Maddas>
and sure the type system does allow doing broken things, but incrementing strings is not one of those things :)
<blueshoe>
my point is that this is a feature only useful in corner cases, and thus the practicality is limited and the price you pay (mistakes when you forget that $foo is a string and increment) is too great
<cleverdra>
for (my $i = $f . 'a' x 5; -e $i; $i++) { frobnicate_file $i }
<teratorn>
blueshoe: it is ridiculous, of course.
<cleverdra>
given a $f eq 'foo' or such and many 'fooaaaaa' 'fooaaaab' 'fooabcde' files.
<blueshoe>
ptewy
<blueshoe>
it would not be hard to do that without allowing arithmetic operations on strings
<Maddas>
yes, but it would be less practical
<Maddas>
Perl has a lot of things which would not be hard to do otherwise
<cleverdra>
blueshoe - bah, you can do damage in any language by forgetting things -- languages differ only in how much information they demand you consider at any time. Perl demands quite a bit, relatively: you need to consider list versus a scalar context, and integer versus string application of a scalar, and so on.
<blueshoe>
cleverdra, but when i forget what type one of my identifiers is and use it incorrectly ocaml reminds me
<blueshoe>
which is really, really nice
<Maddas>
yes, because it has a very different type system
<cleverdra>
$|++; where $| has such magic that it only ever has a value of 0 or 1 -- meaning that you actually want to do '$| = 1' most of the time, however idiomatic the alternative at the start of a program.
<cleverdra>
blueshoe - O'Caml allows you to forget about certain things, sure.
<cleverdra>
blueshoe - it allows you to think more of your program. It also requires you to type a great deal more if you ever want to deal with the bizarre example I just posited, of the 'fooaaaaa' files.
<blueshoe>
i don't think you'd need a "great deal more"
<Maddas>
cleverdra: You type more in most cases
<blueshoe>
and it's a corner case
<cleverdra>
blueshoe - in general, Perl will allow you to express succintly a hackish solution for a huge domain of problems -- and it demands a lot of you for that.
<blueshoe>
but bugs aren't a corner case
<blueshoe>
bugs happen all the time
<blueshoe>
and that's where a safe type system helps a lot
<Maddas>
blueshoe: You type more for most common things
<cleverdra>
blueshoe - bugs don't matter in a one-shot program.
<cleverdra>
blueshoe - because you don't have any, because you have the entire program in your mind when you write it, you test it quickly, and then you use it. Simple as that.
<blueshoe>
one shot programs have a way of growing and persisting beyond their intended hackish use
* teratorn
thinks about pasting a link to Bruce Eckel's blog
<cleverdra>
blueshoe - hence the added discipline required of a Perl programmer to know *when to stop*.
<blueshoe>
when to stop using perl ;)
<Maddas>
blueshoe: every language has something some other doesn't
<blueshoe>
that was a joke, btw
<Maddas>
I could just as well make ocaml seem silly by pasting random one-liners and asking you to do that in O'Caml
<blueshoe>
i'd be interested
<Maddas>
It's not hard to find something a language lacks
<Maddas>
ok
<blueshoe>
not a dare, i'm just curious
<cleverdra>
sigh.
<blueshoe>
as i'm an ocaml beginner
<Maddas>
a dict client, for example :)
<cleverdra>
perl -penis filename
<cleverdra>
Write a program that does that in less time, in O'Caml.
<cleverdra>
(preferably, one that implements a language that takes such argumenst as will allow you to invoke it in exactly this manner and function -- but nevermind)
<blueshoe>
ooops, i misread that
<Maddas>
I still think you are missing the point, though, blueshoe
<blueshoe>
i read it as: <Maddas> I could just as well make ocaml seem silly by pasting random one-liners [in Ocaml] and asking you [not] to do that in O'Caml (because it is bad practice)
<Maddas>
err, ok
<blueshoe>
not as what you actually said
<blueshoe>
and i am interested in things that ocaml did wrong
<Maddas>
You don't need to do anything wrong
<Maddas>
There is no perfect language
<Maddas>
You will always lack something in some way
<blueshoe>
yes, of course
<Maddas>
So just saying "X sucks because it doesn't have Y" is quite pointless
<blueshoe>
but if there was something glaringly bad in ocaml, i'm curious to hear of it
<cleverdra>
very few languages have Forth's KEY EKEY KEY? , for instance.
<cleverdra>
blueshoe - well, no 'eval' =)
<Maddas>
no call/cc
<Maddas>
no typeclasses :)
<cleverdra>
no logical variables!
<Maddas>
there is quite surely some reason that those aren't there, though
<cleverdra>
and I find O'Caml's one-dimensional control-flow a sore strain on my imagination.
<blueshoe>
i've read it is possible to do some sort of eval in ocaml
<blueshoe>
i think we've had that discussion before, though
<Maddas>
blueshoe: sure, everything is possible in some way in a turing complete language :)
<teratorn>
cleverdra: as opposed to..? mozart, erlang?
<Maddas>
(e.g. typeclasses -- IIRC -- aren't there because you can't interfere types completely with them)
<cleverdra>
teratorn - huh? With regards to what?
<Maddas>
call/cc might be not there for efficiency reasons, what do I know
<blueshoe>
"When I was a BASIC programmer, I thought line numbers, goto, structured loops and assignment were indispensible. Then I became a C programmer, abandoned line numbers, and convinced myself typecasting and function pointers were indispensible..."
<teratorn>
cleverdra: I think i misunderstood you
<blueshoe>
"Then I became a C++ programmer, abandoned typecasting and and became convinced overloading and classes were indispensible. Then I became a Haskell programmer, and abandoned function pointers, classes, goto, assignment and structured loops..."
<blueshoe>
"Then I became a Generic Haskell programmer and abandoned overloading (type classes)."
<cleverdra>
Maddas - probably more because people don't write languages just to see how many useful features they can throw into it =)
<Maddas>
cleverdra: for example, yes :)
<cleverdra>
teratorn - misunderstood me when?
<blueshoe>
abandoned type classes! i don't know what they are, but that sounds like heresy :)
<cleverdra>
teratorn - ah. Referring to befunge, of course!
<Maddas>
blueshoe: I don't like arguing with somebody who doesn't know anything about the subject :)
<Maddas>
(I don't know much at all, either, of course)
<cleverdra>
teratorn - without my four-dimensional control-flow on a 10x10x10x10 cube with multithreading and time-travel, I don't know what I'd do.
<blueshoe>
maddas, well, i wasn't arguing about typeclasses... hope you didn't read it as that
<blueshoe>
just reminded me of that amusing quote
<Maddas>
no, I'm just being grumpy :)
<teratorn>
cleverdra: yeah sounds lovely :D
<cleverdra>
the time travel has some lossage, unfortunate, due to befunge's general inability to command the flow of time outside itself.
<cleverdra>
also, unfortunately.
<cleverdra>
an implementation detail, I suppose -- many people rely on distinct befunge-time and outside-befunge-time
<blueshoe>
so what are type classes? call/cc?
<Maddas>
Cool things
<Maddas>
:-)
<Maddas>
(or very evil things, depending on which side you are on)
<blueshoe>
any good, dummbed-down references online i could take a look at that don't require knowing lisp?
<cleverdra>
blueshoe - see 'Learn Scheme in Fixnum Days' for a nice enough call/cc tutorial (but you may want to run through the rest of the tutorial, and get a Scheme, just to understand it)
<blueshoe>
or scheme :)
<Maddas>
blueshoe: I doubt it
<Maddas>
What language would you want as an example?
<blueshoe>
i don't want a language example
<blueshoe>
i just want a conceptual overview
<blueshoe>
and why they're useful
<Maddas>
I think it's a bit hard to grasp why something is useful without examples :-)
<cleverdra>
blueshoe - no, seriously, just expend an hour on a well-written (widely-mirrored) example and a scheme. You don't have to learn the language, just understand call/cc.
<Maddas>
call/cc lets you implement lots of things, e.g. coroutines
<cleverdra>
e.g., an OO system.
<blueshoe>
so how is that different from using the and construct in ocaml?
<blueshoe>
or a private helper function, rather
<cleverdra>
I created an OO system accidently in one Scheme program, trying to work on a program. I didn't *use* it, of course, I just noticed that I'd created the bloody thing and that I'd, therefore, gone way too far off the deep end of design for a simple problem.
<blueshoe>
and i do intend to learn scheme, eventually
<Maddas>
blueshoe: This is why I don't think the concepts without examples are too useful
<Maddas>
You'll just think "I can do something like that, too"
<Maddas>
blueshoe: ask Riastradh about uses of call/cc, I don't know enough. I just tried to fully understand it and failed
<blueshoe>
i think the problem is rather that some concepts are hard to explain without getting in to the nitty-gritty of a specific language implementation
<Maddas>
I don't think so
<cleverdra>
You can also create a simple enough cooperative multitasking with call/cc -- a generalization of coroutines.
<cleverdra>
blueshoe - no, call/cc has nothing at all to do with 'the nitty-gritty of a specific language implementation'
<Maddas>
But many people find it hard thinking in terms of what their own language doesn't have
<blueshoe>
hmm
<cleverdra>
blueshoe - but see the Sapir-Whorf Hypothesis.
<blueshoe>
i know it
<Maddas>
which is actually the whole point I learnt O'Caml and am learning Haskell -- to get a different view on things :)
<blueshoe>
yes, it certainly does do that
<blueshoe>
but i still have faith in explanations that don't necessarily require you to know the language in question (or even languages like it)
<Maddas>
You don't need to know the language
<Maddas>
you probably will just not understand too much of it otherwise :-)
<blueshoe>
i just think that most programmers are good at programming, not explaining
<Maddas>
call/cc is not language specific
<Maddas>
SML has call/cc too
<cleverdra>
blueshoe - a bit like learning mumble-musicalsomethingorother-mumble without wanting to learn the terms that musically-oriented people use to describe it, I think.
<Maddas>
blueshoe: heh, I think most programmers are not very good at programming, but that's just me :)
<Maddas>
cleverdra: Yeah
<blueshoe>
maddas, yeah, that was going to be an asside in my own comment, but i ommited it for brevity's sake
<Maddas>
blueshoe: Most places will explain it even without knowing Scheme, I guess
<blueshoe>
preching to the converted and all that ;)
<Maddas>
but I doubt you'll be able to see how it works from the examples
<Maddas>
It lets you build a lot of your own things, and showing that without actually building anything is a bit silly, I'd say
<cleverdra>
blueshoe - think of how you'd describe glue to someone, maybe?
<Maddas>
cleverdra: or having a rich type system to a C programmer, maybe
<blueshoe>
well, i would start like this: "lets say you wanted to perform this function, you'd go about doing it in your pathetic little language like so and would get lost in horrible complexity, but if you had call/cc you could simply ___"
<Maddas>
blueshoe: yes, and there follows the code example :)
<cleverdra>
"It forms a milky paste that you can apply to two surfaces to, after some time and (thus) drying, bind them. We used to (?) kill horses for it. Some people snort its fumes to enjoy the sensation of brain damage happening. You can make sculptures out of it by forming it and then let it dry against an adhesive-resistant surface. It smells bad. It comes in many forms -- such as 'cardboard paper to cardboard paper' and 'buttcheek to buttcheek' and 'rip flesh o
<Maddas>
I think the definition of call/cc is quite abstract and hard to understand without exmaples
<Maddas>
cleverdra: doesn't sound very useful!
<cleverdra>
"Unlike the One Ring, people generally use it to bind things in the light -- because such as the sun will speed the drying."
<blueshoe>
i think it is possible to describe the advantages of a rich type system to a c programmer.. you would go in to examples, of course, but they could be c examples or examples a c programemr could understand without knowing say, ml
<Maddas>
blueshoe: I don't see you being very convincing without using examples of the rich type system
<Maddas>
The whole point of it is being useful, after all, and showing that something is useful without showing how is not easy :)
<Maddas>
(except for trivial cases, of course)
<blueshoe>
cleverdra, your example of glue is too general... of course there are things that you might have trouble explaining to people because their way of thinking is inherently limited (like describing color to a blind person), but i am not at all convinced that programming language features fall in to this category
ita has joined #ocaml
<ita>
hi
<ita>
(et salut tout le monde pour ceux qui parlent francais :)
<cleverdra>
blueshoe - please don't call them 'programming language features'
<Maddas>
blueshoe: call/cc is VERY general
<cleverdra>
ita - oh, sure, only greet the french-speakers.
<Maddas>
cleverdra: he said 'hi' =)
<ita>
cleverdra: i've said "hi" first :)
<cleverdra>
ita - je ne pas parle francais, but je parle francais to the extend that I read that as "and hello to the world of french-speaking people"
<blueshoe>
maddas, well, you might not be convincing, if the c programmer did not believe that such things were possible, but i think you could get them to understand what a rich type system was and what it's advantages would be, even were it (hypothetically) not possible
* cleverdra
doesn't remember what horrible insult 'hi' refers to in French, but will look it up!
<Maddas>
blueshoe: Sure, but he could easily make you look ridiculous
<cleverdra>
(also, 'extent')
<Maddas>
Since you are not allowed to use examples, and he will say "I'd do this like that"
<blueshoe>
heh
<Maddas>
How will you do it? No wait, don't use any code I don't understand
<blueshoe>
well, once i do understand call/cc i'll come back and explain it in terms even an ocaml programmer can understand ;)
rox has joined #ocaml
<blueshoe>
mark my words... mark my words!
<Maddas>
blueshoe: the problem isn't understanding it, I think, the problem is showing it's useful
<cleverdra>
blueshoe - I suspect that programmers as a class fall on the 'physical' side of learning and thinking, meaning that they work better dealing with manipulating 'physical' mental constructs -- hence the difficultly you'll have with getting, say, me to tell you about call/cc in a way that other than 'Here, go read this tutorial and then use what you learned to write these programs, and then tell me what you think of that.'
<Maddas>
Yeah
<blueshoe>
that's a good point
<Maddas>
It's hard thinking in terms of something that you don't know -- e.g. things only languages that you don't know have
<Maddas>
Which is what I'm trying to say the whole time :-)
<cleverdra>
blueshoe - so even if you come up with that wonderful explanation, most programmers will ignore you until they bother to fiddle with it themselves.
<blueshoe>
a lot of time i do understand stuff better by playing with it
<cleverdra>
blueshoe - after which, sure, they'll know exactly what you mean =)
<Maddas>
cleverdra: A rich type system, for example!
<Maddas>
or something
* Maddas
mutters
<blueshoe>
ok, i suppose you have a point there
<blueshoe>
buuuut... that doesn't mean that someone who's really good at explaing stuff couldn't do it
<Maddas>
no
<Maddas>
he could certainly do it, sure
Swynndla has joined #ocaml
<Maddas>
but you would certainly doubt its usefulness
<blueshoe>
maybe
<Maddas>
blueshoe: that's why I think knowing more languages makes you a better programmer
<cleverdra>
blueshoe - the author of 'Learn Scheme in Fixnum Days' did a pretty good job of explaining call/cc, I thought =)
<blueshoe>
but at least i might understand why other people thought it might be useful
<Maddas>
I don't know, I rarely see that happen in reality
<blueshoe>
clevedra, cool, thank you... i will look that up
<blueshoe>
yeah, it is rare
<Maddas>
That's why you don't see many things a lanugage lacks before you go beyond it :)
<cleverdra>
anyway, I couldn't find that nifty Mercury example of typeclasses -- it came in the form a programming challenge, asking people to write a 'connect 4' game using a provided typeclass to represent connect4 players.
<Maddas>
How is Mercury?
<Maddas>
Can you recommend learning it?
<cleverdra>
but typeclasses, basically, describe a set of types in terms of what functions act on them.
<Maddas>
It is often compared to a Java interface
<blueshoe>
but isn't what a module signature is like?
<blueshoe>
like a java interface
<blueshoe>
(though i don't know java or any other oo lang)
<cleverdra>
blueshoe - maybe like a Java interface, but not like type classses.
<cleverdra>
I don't know Java interfaces all that well, myself.
<Maddas>
Me neither, I only know they are often compared to it :-)
<blueshoe>
hmm
<cleverdra>
(except that classes can subscribe to them, and functions that apply to all of an interface can act on objects of such classes)
<cleverdra>
Quite a bit like type classes!
<blueshoe>
so type classes are an oo feature?
<Maddas>
I don't think so
<Maddas>
But they certainly let you do oo-like things
<cleverdra>
Haskell, for instance, has an Eq typeclass that describes all types for which (=) makes sense.
<blueshoe>
i'd be interested to hear them compared and contrasted with oo and modules
<Maddas>
and a Num typeclass with which you can do arithmetic
<blueshoe>
ahh, that's interesting
<cleverdra>
You can define a String type and then subscribe your String type to the Eq typeclass, defining (=) of Strings at the same time.
<Maddas>
or you can define a Tree class and define (=) for a tree, for example :)
<Maddas>
If your type has those things, you can make it an instance of a Num typeclass
<cleverdra>
well, you define the instance and the functions at the same time.
<blueshoe>
so typeclasses let you say that an method that acts on a particular datastructure is functionally equivalent to other methods acting on different data structures?
<Maddas>
Yes, true
<cleverdra>
hence all these distinct functions named (=) =)
<Maddas>
What do you mean with method?
<Maddas>
As in the OO-term 'method', or just as in 'function'?
<blueshoe>
function
<blueshoe>
subroutine
<cleverdra>
blueshoe - no, typeclasses allow you to write, say, a quicksort that applies to any type that subscribes to the Ord typeclass.
<blueshoe>
algorithm
<ita>
is that possible to write a compiler that can parse data like a command-line interpreter ?
<Maddas>
I'd say they just let you abstract more
<Maddas>
for example what cleverdra said :-)
<blueshoe>
cleverdra sounds cool :)
<ita>
i've seen the "basic" compiler example in the caml book, wonder if i can transform it into a vi-like editor
<cleverdra>
blueshoe - but the Mercury example had a nifty 'player' typeclass that it defined (without any code -- a programming challenge) that cleared everything up for me. Sorry that I couldn't find it.
<cleverdra>
also, not 'connect4'. battleship.
<blueshoe>
well, that haskell example you posted a link to makes sense
<blueshoe>
"if we want to make something a Num, then we'd have to implement those functions."
<blueshoe>
so to belong to a typeclass your object has to implement those methods
<Maddas>
Yes
<Maddas>
and you have to declare it as a member, of course
<blueshoe>
right
<Maddas>
(an 'instance', in Haskell)
<blueshoe>
makes sense
<Maddas>
the definitions of those methods and the declaration are one thing, of course.
<cleverdra>
and such a declaration incorporates the function definitions.
<blueshoe>
so why doesn't ocaml have this feature?
<Maddas>
declaration as an instance
<Maddas>
blueshoe: o'caml doesn't have every good feature!
<blueshoe>
didn't you say there was some reason, though?
<Maddas>
I think it's partly because you lose a bit of type interference
<blueshoe>
something philosophical, maybe?
<blueshoe>
ah
<Maddas>
if I understood mattam correctly
<cleverdra>
blueshoe - O'Caml chooses to have a magic (=) instead, as SML has an (=)-with-exceptions.
<blueshoe>
so it's just a technical implementation issue... not that they thought typeclasses were a bad idea
<Maddas>
blueshoe: Most things that are missing are probably 'implementation issues'
<Maddas>
You just can't have everything :-)
<blueshoe>
well, some languages seem not to know better
<Maddas>
heh
<blueshoe>
and others are pedantic
<blueshoe>
(pythons mandatory whitespace)
<Maddas>
pedantic?
<cleverdra>
for instance, I don't have any strong-typing in my 4-dimensional-control-flow time-travelling multithreaded hypercube with befunge, darn it all.
* Maddas
pats cleverdra
<Maddas>
Just wait, just wait!
<blueshoe>
well, the time travel feature excludes strong typing
<cleverdra>
well, that and the self-modification.
<cleverdra>
strong-typing would certainly have to work very hard with befunge to guarantee that I'll never... well, I can't think of any particularly way that I could violate befunge's type system.
<blueshoe>
and everyone knows that hypercubes turn in to mellowcubes at the first hint of typing
<blueshoe>
or worse, in to stuckupsquares
<cleverdra>
You can have n-dimensional control flow, of course -- but I have a hard time wrapping my head around such structures. Sigh -- and I suspect niggling implementation issues holding me back, since I want my 10x10x10x10 hypercube to fit neatly within a static 10000-byte space (well, er, but time-travelling confuses things. hm.)
<cleverdra>
but anyway, please take a moment to consider camlp4.
<blueshoe>
10000-bytes? why i, as a struggling phd student, implemented a 20x20x20x20 hypercube in 10000-bits one caffine frenzied night
<blueshoe>
please see my thesis
<blueshoe>
granted, the flow control only worked in the reverse-timeflow dimension, which is why i'm here, but it was darn righteous hack that will be written about in 50 years time, i can assure you
<Maddas>
heh
<cleverdra>
blueshoe - I'll keep an eye out for it!
<blueshoe>
just don't lose the flux capacitor!
<blueshoe>
it's the most important part
<cleverdra>
yeah, you don't want to get lost in a time-travelling hypercube.
* Maddas
ponders
<Maddas>
Sounds like fun!
<Maddas>
Anyway, time to go, bye!
<cleverdra>
Maddas - bye =)
<blueshoe>
see you
smklsmkl is now known as smkl
<blueshoe>
looking at this scheme example from "teach yourself scheme in fixnum days", i think call/cc could be explained in ocaml terms
<blueshoe>
also, didn't one of you say that sml had it?
Nutssh has joined #ocaml
<blueshoe>
that means it's close enough to ocaml to be explained in ocaml terms
<blueshoe>
same with that haskell example, which was close enough to ocaml/sml
<blueshoe>
the haskell example of typeclasses
<blueshoe>
call/cc replaces its argument by the continuation that it was called from, and its own continuation is likewise replaced by the continuation of its parent
<blueshoe>
or something
__DL__ has joined #ocaml
blueshoe has quit [Read error: 104 (Connection reset by peer)]
Nutssh has quit ["Client exiting"]
Nutssh has joined #ocaml
<Maddas>
blueshoe: yes
<Maddas>
But you can't demonstrate examples of it in O'Caml because O'Caml doesn't have it :-)
<det>
Maddas: he left
<Maddas>
oh, ok. My proxy's backlog doesn't display that :)
<det>
dircproxy ?
<Maddas>
exactly
<Maddas>
I know, you can configure it to
<Nutssh>
Interesting piece of software. I didn't know it existed.
blueshoe has joined #ocaml
<Maddas>
blueshoe: yes, but you can't demonstrate examples of iti n O'Caml because O'Caml/ doesn't have it :)
<Maddas>
s./..
<det>
blueshoe: SML doesnt have call/cc it is just that popular implementations do (SML/NJ, MLton)
<blueshoe>
you can demonstrate it in ocaml, and say "imagine if this operation were legal"
<blueshoe>
det, close enough
<Maddas>
blueshoe: well, if you count pseudo-O'Caml as O'Caml
<Maddas>
I guess that's a question of definition
<blueshoe>
yes, pseudo-ocaml
<Maddas>
hm, it's not even pseudo, it's just a lack of implementation
<Nutssh>
See the map example on page 8 for the first bit of wierdness.
<Nutssh>
Lol.
<blueshoe>
that is weird, because i don't see what it is they're mapping
<blueshoe>
oh
<blueshoe>
i see
<det>
I believe I remember that you need something else in addition to call/cc to simulate mutable state
<blueshoe>
they map a function that takes an argument, which happens to be 1 the first time around, and once its bound to one that function will always evaluate to 1
<det>
references or something
<blueshoe>
and then it just applies that to the rest of the list
<blueshoe>
this looks like an entry to the obfuscated lisp contest or something
<blueshoe>
not that i know list
<blueshoe>
p
<blueshoe>
but still
<blueshoe>
i'd hope to write clearer code
<blueshoe>
i guess it could be useful in some weird circumstances, though
<Nutssh>
Well, that does supply inspiration though. Imagine what you could do in an obfuscated scheme context. Assume that you allow 'eval'.
<blueshoe>
heh
<blueshoe>
LISP: Lost In Supurfluous Parenthesis
<Nutssh>
Ya know, that could be a very cool contest, or at least frightning. I suspect that scheme writers could really outdo c writers in obfuscated code.
<blueshoe>
then maybe there should be an International Obfuscated Code Contest
<blueshoe>
where any language can apply :)
<blueshoe>
except maybe languages which were designed for the purpose of obfuscatoin, as that's cheating
<Nutssh>
Have to restrict somewhat, one of a half-dozen languages.
<blueshoe>
well, they'd have to be languages that all the judges knew
<__DL__>
Well, one can translate unlambda directly into lisp, so...
<Nutssh>
C, Java, C++, drscheme, ocaml, gforth,
<blueshoe>
finding capable and willing judges would be the hard part
<blueshoe>
speaking of contests, i read someone's suggestion that there should be a mini-icfp, perhaps run monthly
<blueshoe>
i think that'd be cool
<blueshoe>
but, again, finding judges willing to put in the effort/commitment would be the hard part
<Nutssh>
Put them all up online. Whichever one gets a reasonable explanation put up last, wins?
<blueshoe>
you could actually have people vote
<blueshoe>
though electronic voting systems aren't all that trustable
<blueshoe>
as i'm sure i don't have to tell anyone here
<blueshoe>
but for something like this, why not?
<blueshoe>
also, there used to be a 'programming for fun competion' on advogato or kuro5hin... what ever happened to that? there hasn't been one in a while, has there?
<Nutssh>
Programming is work? I do like the idea of who can post a program that survives the longest without being explained.
<cleverdra>
My program: qqqh+h+h99h+h+hqqq
<blueshoe>
oh, that's easy!
<cleverdra>
blueshoe - sure, but did I write it for the buggy implementation or to the standard?
<blueshoe>
if you have to ask you don't deserve to know
<blueshoe>
;)
<Nutssh>
Is that a palidromic programming language?
<blueshoe>
madamiamadam
<blueshoe>
a man, a plan, a canal: panama
<blueshoe>
those are the only ones i know
<blueshoe>
but they don't compile!
<cleverdra>
Nutssh - no.
<Nutssh>
:) Ok.
<blueshoe>
malboogle?
<cleverdra>
It produces, IIFC, 3006 lines of output.
<cleverdra>
oops, sorry, 5976
<blueshoe>
99 bottles of beer on the wall?
<cleverdra>
huh? How many lines do you suppose such a song would have? What an absurd notion!
<cleverdra>
If we have, at a guess, 5 lines to each verse (including verse-seperator) of that song, we'd still only have 495 lines of input.
<blueshoe>
yes, once you made me actually apply thought to my joke this was crystal clear
<cleverdra>
What programming language do *you* use, where 496==4976 returns true?
<cleverdra>
{ 496 eq 4976 } in Perl does not even return true. Bah!
<Nutssh>
*whew* I just found that URL from googling a two year old message I wrote. For a moment I wondered if I'd littered google with obscenities.
<Maddas>
haha
<cleverdra>
Clearly my program does something more profound than a *99 bottles of beer program* in a language as intentionally difficult as *malbolge*.
<blueshoe>
indeed
<cleverdra>
5976 lines of output, baby. Let's see the LOC/LOO ratio for that one, eh?
<blueshoe>
or perhaps you are trying to deliberately mislead us
<cleverdra>
Oh, I see, you don't care about my program at all -- you care about my character.
<cleverdra>
Well I've had enough mud slinging for tonight!
<blueshoe>
is that what it prints out?
<cleverdra>
blueshoe - 99 bottles of beer? No. Its output obviously could not possibly consist of a '99 bottles of beer' song.
<blueshoe>
no, your character
<blueshoe>
:)
<cleverdra>
well, depends on the character.
Maddas has left #ocaml []
<cleverdra>
but before I go to bed: that program prints *two* 99 bottles of beer songs -- and more. It has 6 quines of itself, 6 'Hello, world!'s, and it increments an accumulator (at compiletime, in certain implementations).
<blueshoe>
oooooooh
<blueshoe>
sexy
<cleverdra>
Surely a masterpiece -- that it defines a palindrome only underlines my incredible skill.
<blueshoe>
i am sure that in the misearable annals of the earth! you shall be duly enshrined
<cleverdra>
Indeed!
<cleverdra>
but beware: the standard for this language and the one implementation differ significantly. Don't trust the implementation, even if someone *did* write it in O'Caml.
* cleverdra
goes to bed.
<blueshoe>
night, cleverdra
<blueshoe>
recursive dreams
<Nutssh>
Night too.
<blueshoe>
night nutssh
Nutssh has quit ["Client exiting"]
The-Fixer has quit ["Goodbye"]
__DL__ has quit [Remote closed the connection]
__DL__ has joined #ocaml
mimosa has joined #ocaml
The-Fixer has joined #ocaml
Banana[Home] is now known as Banana
blueshoe has quit [Read error: 104 (Connection reset by peer)]
vect has quit [Nick collision from services.]
vect has joined #ocaml
buggs|afk is now known as buggs
karryall has joined #ocaml
Kinners has joined #ocaml
karryall has quit ["."]
wazze has quit ["Learning about how the end letters on French words are just becoming more and more silent, I conclude that one day the French]
blueshoe has joined #ocaml
karryall has joined #ocaml
blueshoe has quit [Read error: 104 (Connection reset by peer)]
Kinners has left #ocaml []
blueshoe has joined #ocaml
cmeme has joined #ocaml
cjohnson has joined #ocaml
blueshoe has quit [Read error: 104 (Connection reset by peer)]
cjohnson has quit ["Drawn beyond the lines of reason"]
tomasso has joined #ocaml
ggik has joined #ocaml
ggik has left #ocaml []
ggik has joined #ocaml
ggik has left #ocaml []
blueshoe has joined #ocaml
blueshoe has quit [Read error: 104 (Connection reset by peer)]
karryall has quit ["home"]
gim_ has joined #ocaml
Smerdyakov has joined #ocaml
Smerdyakov has quit ["class"]
vect is now known as gl
giedi has joined #ocaml
cjohnson has joined #ocaml
blueshoe has joined #ocaml
owll has joined #ocaml
blueshoe has quit [Read error: 104 (Connection reset by peer)]
owll has quit [Client Quit]
mattam_ has joined #ocaml
mattam has quit [Read error: 110 (Connection timed out)]
blueshoe has joined #ocaml
mattam_ is now known as mattam
blueshoe has quit [Read error: 104 (Connection reset by peer)]
Nutssh has joined #ocaml
Nutssh has quit ["Client exiting"]
reltuk has joined #ocaml
giedi has quit [Remote closed the connection]
gl has quit ["BitchX-1.0c20cvs -- just do it."]
gl has joined #ocaml
<gl>
yooo
buggs^z has joined #ocaml
Smerdyakov has joined #ocaml
Nutssh has joined #ocaml
buggs has quit [Connection timed out]
wazze has joined #ocaml
__DL__ has quit [Read error: 110 (Connection timed out)]
__DL__ has joined #ocaml
gim_ has quit ["dodo"]
Nomme has quit [Read error: 104 (Connection reset by peer)]