Snrrrub has quit [Read error: 104 (Connection reset by peer)]
patraic has quit ["Leaving"]
dabd has quit ["using sirc version 2.211+KSIRC/1.3.12"]
hasone has quit [Read error: 110 (Connection timed out)]
hasone has joined #ocaml
jlouis has quit ["leaving"]
jlouis has joined #ocaml
dibblego has joined #ocaml
sgnb` has quit [Read error: 104 (Connection reset by peer)]
sgnb` has joined #ocaml
sgnb` has quit [Read error: 104 (Connection reset by peer)]
coucou747 has quit [Read error: 104 (Connection reset by peer)]
sgnb` has joined #ocaml
thelema has quit [Read error: 110 (Connection timed out)]
yminsky has quit [Read error: 110 (Connection timed out)]
hkBst has quit ["Konversation terminated!"]
ecc has quit ["leaving"]
alexyk has joined #ocaml
<alexyk>
hi -- how do I declare ocaml functions before ocaml infers the type itself? I try to feed the inferred type line back but it's flagged at val
<alexyk>
I want to do Haskell-type declarations first before defining the body
delamarche has quit []
yminsky has joined #ocaml
<alexyk>
hi yaron!
<alexyk>
repeating newbie question -- how do I declare a function before its definition, not in a module sig?
<thermoplyae>
why would you want to?
<thermoplyae>
and how about something like 'let f : int -> int = function x -> x + 2'
seafood_ has joined #ocaml
<alexyk>
um, I was getting errors from ocaml and had to type-declare all parameters
<alexyk>
then I get the location of the error better
<alexyk>
tehn I thought I still don't specify the result which is auto-inferred
<alexyk>
then I thought that Haskell has a clear way to declare the type first
<alexyk>
so the line val f: int->int which ocaml spits out, and you can include in a module sig, is invalid at the same level as the f itself, right?
<thermoplyae>
right
<thermoplyae>
but even in a module you can explicitly type things the way i demonstrated above
<thermoplyae>
and i'm pretty sure there's no sleeker way to do it. 'let f (x:int) = x+2' can be somewhat shorter if you don't need to restrict the return type
<thermoplyae>
but, inconveniently, brb. good luck
<alexyk>
kk, thx!
<alexyk>
another question on loading libraries -- for findlib, do you always have to start with #use "topfind" in every script? I included that into my~/ .ocamlinit so I don't have to retype it when invoking ocaml in a shell, but if I do scripting with it via #! it's not loaded...
middayc has quit []
<hcarty>
alexyk: The ocaml executable does differentiate between interactive and non-interactive sessions, so it may only use ~/.ocamlinit when the session in interactive
<hcarty>
Also, if you are doing much script-like work with OCaml then it may be worth looking in to ocamlscript - it does some trickery to compile scripts to native code
<alexyk>
ok thx
evn_ has joined #ocaml
brooksbp has joined #ocaml
netx has quit [Read error: 104 (Connection reset by peer)]
alexyk has quit [Read error: 104 (Connection reset by peer)]
alexyk has joined #ocaml
Mr_Awesome has joined #ocaml
jlouis has quit [Read error: 110 (Connection timed out)]
alexyk has quit []
hasone has quit [Read error: 110 (Connection timed out)]
hasone has joined #ocaml
thelema has joined #ocaml
alexyk has joined #ocaml
<alexyk>
greetings -- which paste do folks use here?
<alexyk>
why is it flagged at let p0 = lcs xs ys on ys as too many parameters?
<thelema>
alexyk: when I take that pastebin and paste it into my ocaml toplevel, it works fine.
<thelema>
alexyk: style-wise, I don't like putting code after "in" (let..in), I either put the in on its own line or put it at the end of a one-line let.
catch22 has joined #ocaml
|Catch22| has quit [Read error: 104 (Connection reset by peer)]
<alexyk>
thelema: interesting...
<alexyk>
I probably have something wrong still lingering in my toplevel
<alexyk>
so when do we use let .. and .. versus let .. in ?
<alexyk>
when they're independent?
<thelema>
when you don't need to sequence the bindings...
<thelema>
yes
<alexyk>
and do I need begin..;..end around things sequenced with semicolon?
<thelema>
sometimes
<alexyk>
like when? :)
alexyk has quit []
<thelema>
if/then
__suri has quit [Read error: 104 (Connection reset by peer)]
__suri has joined #ocaml
alexyk has joined #ocaml
katz has quit ["Leaving."]
evn_ has quit []
seafood__ has joined #ocaml
seafood_ has quit [Connection timed out]
alexyk has quit [Read error: 104 (Connection reset by peer)]
alexyk has joined #ocaml
alexyk has quit [Client Quit]
olleolleolle has joined #ocaml
thermoplyae has quit ["daddy's in space"]
seafood__ has quit []
olleolleolle has quit []
coucou747 has joined #ocaml
katz has joined #ocaml
sgnb` has quit [Read error: 104 (Connection reset by peer)]
catch22 has quit []
brooksbp has quit [Read error: 104 (Connection reset by peer)]
ttamttam has joined #ocaml
seafood_ has joined #ocaml
olleolleolle has joined #ocaml
ttamtta1 has joined #ocaml
ben__ has joined #ocaml
Yoric[DT] has joined #ocaml
seafood_ has quit [Read error: 110 (Connection timed out)]
<Yoric[DT]>
hi
<ben__>
Hiya.
ben__ is now known as ziph
<ziph>
What's the best way to have a location attached to each node of an AST?
<Yoric[DT]>
In Camlp4 or your own AST ?
<Yoric[DT]>
If it's Camlp4, it's built-in.
ttamttam has quit [Read error: 110 (Connection timed out)]
<Yoric[DT]>
If it's your own AST, take a look at the following thread:
<Yoric[DT]>
(and consider implementing that with Camlp4, I'm probably going to do it at some point).
<Yoric[DT]>
s/Camlp4/type-conv
patraic has joined #ocaml
<ziph>
Hmm, ta, the news article looks like it'll do the trick. I'll have to play with Camlp4, it seems to be a common answer to my questions. ;)
ygrek has joined #ocaml
<Yoric[DT]>
ziph: actually, type-conv should be easier than Camlp4 for that task.
* Yoric[DT]
did the trick using Camlp4, but will convert it to type-conv whenever he finds time.
<Yoric[DT]>
Maybe today.
<Yoric[DT]>
Well, gottarun.
<Yoric[DT]>
Cheers
Yoric[DT] has quit ["Ex-Chat"]
goalieca has quit [Remote closed the connection]
thelema has quit [Read error: 110 (Connection timed out)]
l_a_m has joined #ocaml
xd has joined #ocaml
seafood_ has joined #ocaml
ziph has quit []
hkBst has joined #ocaml
munga has joined #ocaml
OChameau has joined #ocaml
ben__ has joined #ocaml
Tetsuo has joined #ocaml
ben__ is now known as ziph
middayc has joined #ocaml
ygrek has quit [Remote closed the connection]
seafood_ has quit []
seafood_ has joined #ocaml
middayc_ has joined #ocaml
ygrek has joined #ocaml
middayc has quit [Read error: 110 (Connection timed out)]
middayc_ has quit []
middayc has joined #ocaml
seafood__ has joined #ocaml
ttamtta1 has left #ocaml []
seafood___ has joined #ocaml
seafood___ has quit []
letrec has joined #ocaml
seafood_ has quit [Read error: 110 (Connection timed out)]
seafood__ has quit [Read error: 110 (Connection timed out)]
<letrec>
Hey! Is there an equivallent of List.assoc using structural equality?
<flux>
assoc uses structural equality
<flux>
it's assq that uses physical equality
<letrec>
What's the difference between compare and (=) ?
<flux>
compare returns an integer which is 0, less than 0 or greater than 0
<letrec>
Look, it must be different, because when I use List.assoc my algorithm doesn't work (when I rewrite assoc using =, then it works fine)
<flux>
hm
<flux>
simple test:
<flux>
in let a = "hello" in List.assoc "hello" [a, "a"] -> works
<flux>
in let a = "hello" in List.assq "hello" [a, "a"] -> doesn't work
<flux>
whops, that 'in' shouldn't be at the beginning of line
<flux>
(and the latter you can fix by doing List.assq a)
<flux>
what if you replace List.assoc with: let assoc k l = snd (List.find (fun (a, b) -> a = k) l)
<flux>
(or (\fst _ = k) for those discussing whether pa_hole.ml is useful or not ;))
<letrec>
Ok, I'll investigate then. Thanks.
<flux>
maybe by accident you have two elements with the same key?
<letrec>
The definition of x=y is (compare x y)=0, right?
<flux>
those are equivalent, yes
ecc has joined #ocaml
<letrec>
Another thing. Is there an equivallent of Haskell show in ocaml? Because I'm writing stuff like let regStr r = match r with EAX->"EAX"|EBX->"EBX"|... It is boring. How can I do?
<flux>
there are language extensions similar to haskell's 'deriving'
<flux>
I haven't tried them out, but I suppose they can be found from caml humps
<flux>
they will provide you automatically with printing and parsing functions for data types
<letrec>
Sounds good. Do you happen to know the name of this extension?
<flux>
according to its bug tracking system it hasn't been ported to 3.10.x; it still might be, though
<letrec>
Thx. I'll see if I can use them, as it is never nice to use (potentially unmaintained) extension to a language...
<letrec>
Note: this could be added to ocaml core language/library? Ocaml needs to have knowledge of the internal structure of algebraic types (structural equality uses this), so adding this feature should be easy. Anyway, not a big deal for now.
olleolleolle has left #ocaml []
evn_ has joined #ocaml
<flux>
it could be added, but it is very unlikely it would be added
<letrec>
Why not -- from my naive viewpoint, this is a very useful feature. I like reflexion.
<hcarty>
All of these interesting new camlp4 extensions make related toplevel problems even more unfortunate
<flux>
letrec, there is a desire to keep the core language small
<evn_>
which toplevel problems
<flux>
there are loads of useful extensions, were they all integrated into the standard distribution, the perceived language size would be very big
<hcarty>
evn_: Using camlp4 in a toplevel breaks the #use "foo.ml";; command
<hcarty>
It will work once, but following uses give an I/O error
<evn_>
oh, did not realize that
<flux>
hcarty, is there a bug open?
<evn_>
mainly cause i haven't managed to get camlp4 to work in a toplevel properly
<evn_>
but i'm a noob
<hcarty>
flux: I submitted one a week or few ago
<flux>
hcarty, has there been any response?
<letrec>
flux: ok, I see. At least, my own perception of the language is that it is small. There are a lot of official libraries, and this is good.
<hcarty>
flux: None yet
bongy has joined #ocaml
<letrec>
Why can I declare something like: type cfl = Cfl of int*cfl ?? It cannot be used, so why does the type checker accept it?
<flux>
is that really an issue?-)
<hcarty>
flux: I was wrong regarding the toplevel bug report. It has been marked as acknowledged
<hcarty>
So it will hopefully be fixed in 3.11 or sooner...
<pango>
let rec x = Clf (42, x)
<ziph>
Noob question warning: How do I force the type of a function? (Not a functions argument)
<ziph>
(One being defined in a let ...)
<hcarty>
ziph: let f x : int = ... But that can only make a function type more specific, it will not override the type inference completely
<hcarty>
# let f x : int = x;;
<hcarty>
val f : int -> int = <fun>
<ziph>
Ah, I'm too tired, it didn't occur to me that I don't need to force the return value type.
bluestorm has joined #ocaml
<ziph>
By not override you mean it will not override conflicting rules?
<flux>
he means:
<flux>
# let f x : 'a = x + 1;;
<flux>
val f : int -> int = <fun>
<hcarty>
Yes, what flux said :-)
<ziph>
Yup. I'm trying to make the compiler tell me how it decided the type of a function (and got it wrong)
<flux>
what kind of functions do you have if the compiler gets the type wrong?-o
<flux>
objects?
<letrec>
Maybe that works: let f x = let y = x in ( y:int) ?
<flux>
or polymorphic variants.. I suppose those are the only two options.
<ziph>
It just tells me that local expression should be a predicate, not a predicate_record.
<ziph>
(predicate is a union, predicate_record.node is a predicate)
<ziph>
I should point out this is F# so that you can make fun of me. ;)
<flux>
unless F# is different from ocaml on that point (which it might be?), it is very doubtful the compiler gets it wrong..
<ziph>
Yeah, it is something I've done wrong.
<flux>
a more likely candiate would be a mistake elsewhere in the code :)
<flux>
for example on another branch you are returning a value of another type
<ziph>
Is the return type ever inferred from a calling function?
<flux>
I suppose it is for local functions
<ziph>
i.e. will "let (a : int) = my_fun 23" infer the return type of my_fun?
<flux>
my_fun could be called from other sites too
<flux>
infact from other modules too
<flux>
my_fun by itself will be as general as possible
Tetsuo has quit ["Leaving"]
<ziph>
Oh, found it.
<ziph>
It is a fairly large recursive function and one of the calls expected it to return "predicate".
<ziph>
Hindley–Milner can't be made maximum-likelyhood? ;)
<bluestorm>
it's not so easy actually
<ziph>
Is there any pattern to the type the compiler assumes is the "correct" one when it reports a conflict?
<bluestorm>
"pattern" ?
thelema has joined #ocaml
<flux>
doesn't it usually assume the first inferred type to be the expected one?
<flux>
atleast that has been my experience
<ziph>
That's what I was wondering; it seems to work that way.
<letrec>
I'm writing a recursion on trees, and the main recursion function is of return type (string*expr list) list*((expr*expr) list). Very boring to handle when it comes to construct the return expression, but I need all the information. Any better way of doing this kind of things?
<ziph>
Keep a single list of a union and split it in to the two lists later?
<ziph>
(e.g. type list_contents = A string * expr | B expr * expr)
<thelema>
A = string * expr list
<ziph>
Oops, ta.
<ziph>
:)
|Catch22| has joined #ocaml
* thelema
wonders what information gets carried by this structure...
<ziph>
I just made assumptions. ;)
<letrec>
thelema: ok, here it is. That's a control flow graph. (string*expr list) list is a list of labels and associated conditions for the jump. The second part is a dag (direct acyclic graph), that contains which expression is stored where (this 'where' is also an expression as it can go to memory). The length of the different lists is not related.
<letrec>
As you recurse in the initial tree, you may add an element in the dag, or add/update a label and its associated conditions if it is a jump.
<thelema>
Alternative 2: use a pair of local accumulators, and do dag := node :: !dag
hasone_ has joined #ocaml
<thelema>
and another function [let update str expr = find str's entry and update it]
<thelema>
and don't pass these around as a pair, simply do the update, and at the very end, construct your pair out of them.
<letrec>
Having a local reference sounds actually like a good idea.
<thelema>
I ended up doing this tranformation recently and it seems to have made my code easier to follow.
hasone has quit [Read error: 110 (Connection timed out)]
hasone_ is now known as hasone
<letrec>
But initially value for dag will be ref []. (with no type). Where do I provide the type?
<thelema>
let it get inferred.
RobertFischer has joined #ocaml
<letrec>
Wow, ocaml doesn't need the type when creating the reference?
<thelema>
nope.
<RobertFischer>
Heheh.
<RobertFischer>
I love wandering into #ocaml and seeing someone impressed by its awesomeness. :)
<thelema>
:)
<letrec>
:)
<letrec>
thelema: when you update dag by dag:= !dag @ ... , is a new object created, or does ocaml reuse the old one?
<letrec>
(e.g. is there an object copy)?
<flux>
letrec, you want to use ::, which will construct a list from head and tail; tail will be reused
<flux>
I suppose with @ would share the old list too
<RobertFischer>
letrec: Don't worry too much about when new objects are or aren't created.
<thelema>
flux: @ makes new nodes, but uses the old data in the nodes.
<thelema>
flux: :: keeps even the nodes.
<RobertFischer>
You should be relying on immutability most of the time, so whether it's new or a copy doesn't matter. And ocaml will be fast, even with object burn.
<letrec>
RobertFischer: just asking, to see whether ocaml is REALLY awesome :)
<RobertFischer>
The OOP mantra of "allocation is slow" needs to be etched out of your brain.
<RobertFischer>
Well, which way is more awesome?
<flux>
thelema, one would be able to construct a @ that shares the nodes of the right list.. is that a performance optimization not doing it?
<ziph>
Wouldn't "1 @ my_list" suck on a list with a few million elements? :)
<thelema>
flux: the right list always gets shared.
<thelema>
I'm only talking about the left list.
<thelema>
ziph: yes, append is expensive.
<RobertFischer>
"left_list :: right_list" will add one new node to right_list, which is the entire list of left_list, right?
<thelema>
RobertFischer: :: adds a new element to the head of the list
<RobertFischer>
Right.
<RobertFischer>
That's what I was trying to get at.
<RobertFischer>
We're in agreement -- I think I just had trouble expressing it. :)
<ziph>
:: = cons
<ziph>
;)
<thelema>
ziph: sorry, I think I answered incorrectly -- [1] @ my_list is a prepend, and is basically the same as 1 :: my_list
<ziph>
thelma, yeah, I stuffed up too.
<thelema>
ziph: the hard part is my_list @ [1]
<ziph>
my_list @ [1] is what i meant.
<thelema>
The last node's 'next' pointer has to change to point to the [1], but if we do this, we have to make a new node because of immutability, or we have to throw away all our sharing.
<ziph>
Implement a local optimisation for non-escaping values? ;)
<thelema>
ziph: non-escaping values?
<ziph>
Values never passed out of scope..
<ziph>
I was being silly though, I think the real answer is resizable arrays or dequeues. ;)
<letrec>
RobertFischer: as I'm writing kind of compiler, I need to care about the algorithms implementation I'm afraid. But anyway, I'm already amazed by ocaml don't worry: in 2 days, I've been able to write most of the compiler middle-end!! Not a single segmentation fault :)
<thelema>
hmm.. if you want that, maybe a 'a mut_list type will suit better, allowing mutation, but requiring copying for many operations.
<thelema>
letrec: try to use :: instead of @ whenever you can.
<ziph>
And don
<letrec>
thelema: ok, will do. But the boring restriction is that :: only works at the beginning of the list.
<ziph>
And don't forget the List.rev if it matters to you. :)
<thelema>
letrec: you could generate the list backwards and then List.rev it at the end.
<ziph>
Or just pretend your list starts at the end.
<letrec>
So to use List.rev and :: is better because it allows tail recursion?
<thelema>
no, because each :: operation is O(1) instead of @ at O(n)
<ziph>
List.rev is usually very fast in any functional language.
<letrec>
List.rev is O(n) I think?
<thelema>
yes, but you do it only once at the end.
<ziph>
Only baaad implementations wouldn't be. ;)
<ziph>
:: is useful building your AST too if you want to flatten lists.
* thelema
tried to reverse a list faster then O(n), but when the result led to a O(n) sorting algorithm, knew he had made a mistake.
<bluestorm>
letrec:
<flux>
yeah, a mistake indeed, did you happen to solve the halting problem too, accidentally?-)
<bluestorm>
if you were only talinkg about the syntaxic heaviness of big product types (tuples)
<bluestorm>
have you looked at records ?
pango has quit [Remote closed the connection]
<letrec>
Let's imagine that at the beginning of a list, you put a pointer to the last element. Adding to the beginning or and would be O(1). Looks easy, why is that not done like that?
<ziph>
You have an O(n) sorting algorithm using only an ordering? :)
<letrec>
(adding to the beginning or the end I mean)
<bluestorm>
letrec: you have to reverse every pointer
<bluestorm>
not only the first one
<ziph>
letrec, you could do it with a doubly linked list, but then you lose pointer sharing.
<letrec>
I'm not talking about reverse, but about :: to be used in array :: element.
<flux>
what about ropes? I haven't taken a look (I really should..), but they supposedly are functional and have good append complexity
<bluestorm>
letrec:
<bluestorm>
you can't do what you suggest
<bluestorm>
because that would change the "array" list
<thelema>
letrec: assume you have a list n = [3]. If you prepend an element to it, you can have n2 = 5 :: n, and the value of n hasn't changed. But if you do [n3 = magical_append 5 n], n now points to a 2 element list.
<bluestorm>
you could do that actually
<bluestorm>
but it's unsafe
<flux>
maybe if ocaml had matching with view, lists wouldn't need to be the main data structure - and infact I think there's an extension around to do that
<thelema>
flux: ropes are pretty good, and give you immutable vectors with good prepend/append, etc.
<letrec>
bluestorm: sorry, I wanted to say list :: element.
<bluestorm>
of course
<bluestorm>
but still
<bluestorm>
if you change one of the *list* pointers, you mutate an immutable data structure
<bluestorm>
wich is not kind of you
dwmw2_gone is now known as dwmw2_AVF
<thelema>
prepend doesn't involve mutation - just make a new node and point it at the head of your old list.
pango has joined #ocaml
<thelema>
any other change either requires mutation or will require copying.
<letrec>
bluestorm: Oh, yes, indeed, was out of my mind. When you have e :: l, you create a new data, but the old one is still there untouched. Hence immutability. Didn't see it that way :)
<bluestorm>
it's actually possible to mutate lists with some Obj machinery
<bluestorm>
but you should not do that unless you can prove that your algorithm is globally safe
<thelema>
bluestorm: extlib has a tail-recursive version of List.map and fold_right and others that does this magic.
<bluestorm>
e.g. you can code an in-place "rev" function, that mutate lists that way, but doesn't change anything to the parameters
<bluestorm>
(observationally safe)
<thelema>
bluestorm: in place rev that doesn't change its parameters?
<letrec>
bluestorm, thelema: of course, it makes sense. I won't use Obj.magic for now anyway :)
<thelema>
doesn't in place mean that it changes the input?
<letrec>
Thx
<flux>
thelema, but they don't actually mutate anything to an external viewer
<thelema>
flux: correct, the output ist just gets built through a series of appends, and then Obj.magic'ed into an immutable list.
<bluestorm>
hm
Illocution has quit ["Lost terminal"]
Illocution has joined #ocaml
<bluestorm>
actually it seems that the in-place rev in not pure
<bluestorm>
just that it doesn't matter in the context in wich he uses it
Morphous_ has joined #ocaml
* thelema
concurs
kotarak has joined #ocaml
<RobertFischer>
I really encourage people to make sure that the particular segment/algorithm is slow in Ocaml before you spend any time trying to "improve" it. There's a lot of surprising performance characteristics of Ocaml, particularly if you're coming from an imperative/OO world.
<RobertFischer>
Get some benchmarks around it and prove it out.
<RobertFischer>
And then get some benchmarks around your new algorithm and see if it's actually faster, or if it just seems like it should be faster.
* RobertFischer
has burnt a lot of time implementing new and exciting ways to make Ocaml slower.
<bluestorm>
:p
<thelema>
heh.
Morphous has quit [Read error: 110 (Connection timed out)]
<RobertFischer>
And, if you do the experiments, and you don't know why it's slower, ask the mailing list. It'll probably be an interesting conversation.
<RobertFischer>
:)
marmottine has joined #ocaml
<letrec>
As I'll have tree matching algorithm, I'll find it slow, don't worry :) The real question will be what to blame -- ocaml or the heuristics I'm using? Of course, I'll be blaming ocaml first, that's part of the game :)
<letrec>
s/what to blame/what is to blame/
<neale>
"what to blame" works too
<neale>
well, in American English anyway.
<flux>
letrec, but then you get a chance to familiarize yourself with the profiling tools ;)
<letrec>
neale: thx, I'm not a native English speaker so I get lost.
<neale>
letrec: Don't worry about it; I am a native English speaker and I get lost too.
<neale>
English is a lovely mix of French and Danish, two of the craziest languages in Europe.
<neale>
At least it doesn't have much Basque influence.
Linktim has joined #ocaml
<neale>
Personally I'm pulling for Spanish as the next "global language". It has phonetic spelling *and* lots of words that rhyme!
<letrec>
Strange, because I'm a French native speaker and it doesn't help at ALL for English.
<neale>
Learning French helped my English a lot.
<neale>
Except now I always misspell ceiling.
<bluestorm>
letrec:
<bluestorm>
you shouldn't say that
<thelema>
neale: you mean "learning grammar helped my English a lot"
<bluestorm>
french is a big asset concerning english vocabulary
<letrec>
Except for words like 'entrepreneur', which are not of much help anyway.
<neale>
yes, vocabulary.
<bluestorm>
letrec: hm
<neale>
English grammar didn't seem to be affected much by Guillaume le Conquerant.
* neale
shakes his Saxon fist in the air.
<RobertFischer>
American English r0xx0rz.
<bluestorm>
letrec: i think you're slightly wrong there, actually a lot of english words have latin roots
<ziph>
Doing anything with the language part of your brain probably helps anything else rattling around in there. :)
<neale>
I think if English were your second language the grammar would seem rather bizarre.
<neale>
Unless your first were something Germanic.
<neale>
well, even then probably.
<letrec>
bluestorm: I'd say French helps, but then it gives you prejudices that are difficult to break. I lived in Germany for some years, and my German is very very clean -- if you compare to my English (I'm living in the UK).
<ziph>
Question: why does a pen have a gender? ;)
<RobertFischer>
Yeah, not having genders is one thing I love about English.
<bluestorm>
letrec: haha, i'd be happy if german vocabulary had more latin roots :p
<neale>
ziph: well at least it's masculine. Unlike "sword".
<ziph>
:)
<ziph>
I find that the Spanish speakers I hang about don't even understand the question.
<neale>
That would be the Sapir-Whorf hypothesis.
<bluestorm>
neale: is "sword" feminine ?
<neale>
bluestorm: it is in latin :)
<kotarak>
it's neutral in german
<neale>
hm, maybe it is neuter in Latin.
<neale>
I just remember that it *wasn't* masculine.
<neale>
I supposed scabbard isn't feminine either.
<bluestorm>
i actually fail to see "sword" as a latin word
<ziph>
Doesn't that kind of thing upset feminists? ;)
<neale>
ziph: depends on the feminist I'm sure.
<ziph>
Or is France free of them? ;)
<bluestorm>
hm
<bluestorm>
what should upset them : sword being feminine or not ?
<ziph>
Gender for verbs would be fun.
<neale>
ziph: check out Swahili sometime.
<bluestorm>
i guess feminists are mostly concerned with people
<neale>
It doesn't have verb gender but it has something like 11 or 13 classes for nouns.
<neale>
and all nouns can be in all classes.
<ziph>
neale: looks like they invented hungarian notation.
<neale>
haha
<neale>
possibly!
<bluestorm>
about latin, "spatha" actually is feminine, comes from greek (sphatè, feminine), and gave the latin word (spada / espada, épée)
<ziph>
This is a bit off topic, but is this the nicest way to do this:
<ziph>
match check_types lhs, check_types rhs with
<ziph>
| lhs_type, rhs_type when lhs_type = rhs_type -> lhs_type
<bluestorm>
haha
<bluestorm>
maybe ten minute ago i was considering a "nonlinear patterns" syntaxic extension
<neale>
ziph: it doesn't look un-nice
<bluestorm>
ziph: it's quite nice actually
<bluestorm>
it might actually looks nicer with shorter names
<neale>
"a" and "b" would work
munga has quit ["Leaving"]
evn_ has quit []
<thelema>
neale: as a speaker of swahili, I have to point out that nouns stay in one class (maybe 2, if you cound singular and plural as different classes)
Linktim has quit [Read error: 110 (Connection timed out)]
<neale>
whoa you speak swahili?
<thelema>
yup. 2 years living in Tanzania.
<neale>
Where I live I feel lucky when I meet a French speaker
<neale>
that's awesome
<neale>
I've always wanted to learn an African language, but my odds aren't good.
<neale>
thelema: isn't there stuff you have to do to nouns depending on to whom you are speaking?
<thelema>
you could join the Peace Corps - I went that way.
<neale>
I don't think my 2-year-old daughter would want to come along.
<neale>
well, actually, she might.
<RobertFischer>
thelema: What'd you think of Peace Corps?
<thelema>
neale: in swahili? not that I can think of. In Japanese, yes.
<neale>
Well I've only ever read about Swahili so I don't know much.
<thelema>
RobertFischer: they've become very protective of their volunteers (putting unnecessary restrictions on us to keep us safe), but I approve of the program strongly.
<neale>
there have been a few highly-publicized instances of Peace Corps volunteers getting into some Really Bad Stuff.
<neale>
A friend of mine was in Honduras for two years with the Peace Corps. She had a good experience and it rubbed off on everyone she knows, Honduras doesn't seem scary any more.
<neale>
Also she brought me this awesome hammock made out of scrap material from athletic shorts.
<RobertFischer>
thelema: Do they accept volunteers in their 20s?
<neale>
all in all a net win for everybody.
<thelema>
neale: there are different greetings for different classes of people, but the same exists in english - one doesn't greet the CEO of your company "Whazzup, Dude?"
<RobertFischer>
thelema: And I kinda appreciate the effort to keep them safe, y'know.
<neale>
thelema: one might, once or twice.
<thelema>
RobertFischer: they accept people of any age. As long as you have no dependents, and if married you have to go together.
<thelema>
neale: once. Only once.
<RobertFischer>
thelema and neale: Unless you're in a really awesome dot-com start-up. :)
<thelema>
RobertFischer: granted.
<neale>
You could probably get away with it a few times at an insurance company if you did it right.
<neale>
the first time would get a quizzical glance
<neale>
the second time might elicit a question
<RobertFischer>
neale: Career brinksmanship.
<RobertFischer>
neale: That's ballsy.
<neale>
It just depends on how dedicated you are to saying "whazzup dude" to the CEO.
<ziph>
Did Office Space make the rounds in Europe? :)
<neale>
unfortunately it was region-encoded for the moon :<
<ziph>
:)
<neale>
I take it that it's bedtime in France right now.
<ziph>
I live in a country that makes region coding illegal. ;)
<RobertFischer>
ziph: What country is that?
<neale>
ziph: It's illegal in my country to prevent fair use, but they do it anyway.
<RobertFischer>
That's friggin' AWESOME.
<ziph>
Australia.
<RobertFischer>
neale: It's not illegal to prevent fair use. It's just not legal to sue someone over it.
<ziph>
The iPhone is also likely to be illegal here.
<neale>
RobertFischer: Maybe I live in Russia!
<RobertFischer>
ziph: Did you guys oust that cheap Bush knock-off?
<ziph>
RobertFischer: The left and right in Australia aren't quite the same as the US.
<RobertFischer>
neale: You have a point. If you're in the US, though, that's the case. My paralegal wife and I bicker over this stuff all the time.
<RobertFischer>
ziph: Enlighten me. :)
<bluestorm>
ziph: left in america ? what's that ? :-'
<ziph>
The left-wing party is very, very unionised. They aren't just affiliated with the unions, they are the unions. ;)
<ziph>
And they're also actually left-wing.
<RobertFischer>
bluestorm: That's where the corporations take all your money and they raise your taxes, too.
<RobertFischer>
bluestorm: The right is where they corporations take all your money, but at least they don't tax you, first.
* RobertFischer
should have shut up about six lines ago.
<bluestorm>
:p
<ziph>
The right taxes you, they're just smarter about not doing it to the rich and not being obvious about it. ;)
<bluestorm>
i guess that from an american point of view
<bluestorm>
european political life must be really bizarre
<bluestorm>
the inverse being quite true too
<ziph>
But in Australia most public service is not politicised at all. We have an independent, federal voting commission for instance.
<RobertFischer>
ziph: We used to have independent things.
<ziph>
Like parks and public roads? ;)
<RobertFischer>
ziph: It was nice.
<ziph>
The state left parties are actually the worst offenders for private roads here. :)
<ziph>
They're also largely responsible for the property price boom by restricting land supply. (Which is a retarded thing to be doing in in country where most of the land is uninhabited)
<ziph>
If I've parsed a grammar that has parenthesis for forcing associativity, are there any nice tricks for going from AST -> tokens and figuring out where to put parenthesis back in without having to basically match the grammar productions back over the AST?
<ziph>
E.g. "A and (B or C)" has the AST (and A (or B C)), so just going "Or a b -> (print a) ^ " or " ^ (print b)" isn't correct.
<bluestorm>
hm
<bluestorm>
i've done that partially right a few times
<bluestorm>
and it was always ugly :p
<ziph>
:)
<ziph>
At the moment I have something that looks like a recursive descent parser only over the AST. :)
<bluestorm>
you could e.g. send back the non-parenthesized string + a boolean describing the need for parenthesis
<bluestorm>
hmm
<bluestorm>
if the only case where you don't need parenthesis is the single variable
<bluestorm>
you could only use a special case for that
<bluestorm>
(Alt+F2, emacs)
<ziph>
"A and B and C" doesn't need them.
<bluestorm>
hm
<bluestorm>
if you want to consider "and" as a n-ary operator
<bluestorm>
then you shouldn't use a binary tree imho
<bluestorm>
And of prop list would be more appropriate for that kind of considerations
<ziph>
"or" also has different precedence.
<bluestorm>
and it has the very nice side effect that you don't need True and False anymore, And [] and Or [] ftw
<ziph>
I'm thinking maybe each AST node type could be assigned an precedence number, but my mind is a bit muddy at the moment.
<ziph>
The language has more than just "and" and "or", too.
<ziph>
an = a
<ziph>
Then when your precedence lowers when writing out a production you know you need a parenthesis. But I was hoping there might be a common technique so I didn't have to think hard enough to convince myself it was correct. ;)
<thelema>
ziph: maybe generate it with parentheses and go over in a second pass and try to remove unneeded ones.
<neale>
does this channel have a preferred pastebin?
<ziph>
thelma, how would you decide which ones were unneeded?
<thelema>
simple pattern matching? (Z) -> Z
<thelema>
hmm, no...
<thelema>
not enough to capture order of operations...
<ziph>
I considered preserving them in the AST, but this goes Text -> AST -> "Byte Code" -> AST -> Text
<thelema>
do you have a "level" function that gives you an int for each operator?
<thelema>
if so, you could add parentheses when level(subterm) < level(term)
<ziph>
thelema: That's the way I was thinking, but apart from seeming intuitively correct I wasn't sure. :)
delamarche has joined #ocaml
<neale>
why does tuareg-mode have so much trouble with comments
<thelema>
neale: lazy update
<neale>
The thing that gets my goat is when I try to word-wrap a commented section, it throws asterisks all over the place.
<neale>
caml-mode seems better.
goalieca has joined #ocaml
<letrec>
Is some kind of syntaxic sugar such as the $ in Haskell? f $ g x <==> f (g x) ? Would help.
<thelema>
neale: many people like the vertical line of *'s as a border of the comment.
OChameau has quit ["Leaving"]
<bluestorm>
letrec:
<thelema>
letrec: no such sugar exists in standard ocaml
<bluestorm>
let (^<) f x = f x
<letrec>
bluestorm: nice trick :)
<neale>
thelema: no it throws asterisks *outside* of the comment block
<RobertFischer>
What's the point of $ as syntactic sugar?
<bluestorm>
RobertFischer: removing parens
<RobertFischer>
Are parens really that evil?
<bluestorm>
depends on your taste
<neale>
I sort of like the parens version personally
<thelema>
neale: really? ick.
<bluestorm>
RobertFischer: i use let (>^) x f = f x too
<bluestorm>
wich is sometimes very nice
<neale>
Haskell looks like gibberish to me
<RobertFischer>
I'd rather read h( f( g x ) ) ), or (better yet) let g1 = g x in let f1 = f g1 in, assuming that my function names are more than one character or the thing I'm applying it to is more than "x".
<RobertFischer>
Makes it easier to refactor later.
<thelema>
no, you can have a simple ocaml wrapper around your C call that takes care of the stashing.
<neale>
yeah
<neale>
actually, yeah.
<neale>
that would make life a lot simpler
* thelema
writes in C as little as possible.
<neale>
I'm still getting comfortable with the "OCaml way"
<neale>
I've really ever done native language bindings for Python and an esoteric language called ColdC.
<neale>
s/really/only/
<neale>
thelema: thanks for showing me the light :)
thermoplyae has joined #ocaml
<thelema>
:)
<neale>
you think it's okay to provide a C layer that could cause a segmentation fault?
<thelema>
document that it needs to be used within a certain context, and I'd say 'no problem'
<neale>
I guess the "obj" module isn't any worse.
<thelema>
(* DANGER DANGER: Do not use without callback-stashing wrapper *)
<neale>
if I did it write I could have it just tuck away whatever you pass it, be it a continuation or an int
<neale>
that seems like the Right Thing
<neale>
s/write/right/
<thelema>
no, if you do that, when it pulls the value back out, it won't know what the type is.
<neale>
can't I just coerce it?
<neale>
I get one word of "user data"
<thelema>
if you stash an int and a callback, how can you make sure not to call the int as a callback?
<neale>
so couldn't I tuck away a pointer to the value?
<neale>
thelema: functors!
<neale>
let me code up the .mli file and paste it somewhere
<neale>
I may totally off my nut
<thelema>
the ocaml way is to tag the values i.e. a variant type.
<thelema>
you could write code that would take either all callbacks, or all ints, but to mix them...
<neale>
but aren't they all just values?
<thelema>
when you get passed a value, how can you know whether it's an integer or a pointer to a function?
<thelema>
and if the second, how can you find out what the parameters of the function are?
Yoric[DT] has joined #ocaml
<thelema>
the reason that teh C bindings work is that the types on the ocaml side are specified, and you use that knowledge to deconstruct the values on the C side.
<thelema>
But you can't store that typing information inside a value.
<Yoric[DT]>
'evening
<thelema>
it gets erased on runtime.
<thelema>
Yoric[DT]: you joined us to say good night?
<Yoric[DT]>
thelema: well, I joined you, looked at the time and realized it was perhaps a better idea to greet the presents by wishing them a pleasant evening than by wishing them a pleasant afternoon or morning.
<thelema>
Yoric[DT]: don't you usually say good night and sign off around this time?
<Yoric[DT]>
By the way, now that I'm on-line, does anyone know what's a "type manifest" ?
<Yoric[DT]>
thelema: usually a few hours later.
<Yoric[DT]>
I often end my teaching-day around this time, put on my mask and resume my career as a researcher vigilante.
<kotarak>
maybe the "int a; char *p;" stuff at the start of a C function?
ttamttam has left #ocaml []
<bluestorm>
Yoric[DT]: where you not working on statical analysis of javascript ?
<Yoric[DT]>
I was.
<bluestorm>
i've seen something related recently
<bluestorm>
on the mailing-list, probably
<Yoric[DT]>
And then my research director decided I should work on statical analysis of C instead.
<Yoric[DT]>
Yeah, JSure.
<Yoric[DT]>
I've sent them an e-mail a few months ago and I haven't received any answer.
olleolleolle has quit []
<thelema>
Yoric[DT]: I'd stop waiting for an answer.
<Yoric[DT]>
Sounds like a plan.
<Yoric[DT]>
Unfortunately, I'm now under deadline constraints, so I'll wait until I've finished my static analysis of C before resuming with JS.
<neale>
thelema: yeah but see, if I use a functor to make the whole module work with only one type, then I've nicely skirted the problem of not knowing what a thing is on the C side
<neale>
I just take whatever I'm given, and then return it, and the type system does the work of knowing what sort of thing it is.
<neale>
note: I do not plan to actually call the callbacks from C
<flux>
neale, how are you then supporting epoll? simply by returning events?
<bluestorm>
couldn't you use polymorphic functions instead ?
<neale>
bluestorm: I guess you could as long as your program only ever uses one type
<flux>
neale, hm?
<bluestorm>
hm ?
<bluestorm>
:D
<flux>
btw, can you really have multiple epolls running?
<neale>
like, what if I wanted to have int events and (unit -> unit) events in the same program, wouldn't polymorphic functions prevent that?
<neale>
flux: yeah, sure
<flux>
neale, they wouldn't
<neale>
flux: not simultaneously, obviously
<flux>
neale, not even in separate threads?
<neale>
flux: okay mister pedantic
<flux>
:)
<flux>
neale, one hint, if you haven't yet found it: in your ocaml_poll_wait, you want to call a couple of functions before and after you enter the wait function
<neale>
oh?
<flux>
I can't remember the names, though, but if you don't do that, threading won't work
<neale>
Oh, right, probably to release some sort of lock
<neale>
then re-grab it
<neale>
bluestorm: re polymorphic functions, what do you have in mind?
<bluestorm>
hm
<neale>
external ctl : t -> op -> Unix.file_descr -> (event_list * 'a) -> unit
<neale>
external wait : t -> int -> (event_list * a) list
<neale>
something like that?
<neale>
I think the problem here is just making sure that both 'a are the same type, and there's no way to do that outside a functor AFAIK
middayc_ has joined #ocaml
<flux>
maybe more like external : ctl : 'a t -> op .. .. * 'a) ..
<neale>
ah!
<bluestorm>
hm
<bluestorm>
i'd have tried to attach type information to your "t" type
<neale>
I hadn't considered that
<neale>
yes, I suppose that would work
<flux>
neale, the function to call before wait: enter_blocking_section(); and after: leave_blocking_section();
<neale>
flux: cool, thanks
<bluestorm>
btw
<bluestorm>
is there an elegant way to get "weak" types ('_a) for free ?
<flux>
for free?
<bluestorm>
hm
<bluestorm>
sometimes you'd like to get weak types
<bluestorm>
when the compiler infer polymorphic types
<thelema>
why?
<bluestorm>
hm
<bluestorm>
i was doing some marshalling stuff
<thelema>
why not just specify what type you want?
<bluestorm>
and i wanted to create something like handle : unit -> '_a marshalling_handler
<thelema>
that's what you'll get when you go and use the function.
<bluestorm>
(a handler being a stateful thing (in my case an output channel) being passed to functions)
<neale>
Wouldn't that just be
<bluestorm>
thelema: actually something like (open_out "foo") just gives you a plain polymorphic type
<neale>
handle : unit -> Weak marshalling_handler?
<neale>
er
<neale>
handle : unit -> Weak 'a marshalling_handler
<neale>
I mean
<thelema>
neale: those weak reference types are different from weak polymorphic types.
<neale>
handle : unit -> Weak.t ('a marshalling_handler)
<neale>
ohhhhhhhh
<neale>
sorry, noob
<thelema>
n/p
<bluestorm>
no problem :p
<neale>
I still wrote it wrong anyway
<bluestorm>
thelema: let create_handler file = open_out file returns a 'a handler
<bluestorm>
when i'd like a '_a handler, to ensure only one type is ever marshalled to that file
<thelema>
but this allows the user to 'handle' and int and then a string, etc.
<thelema>
gotcha. hmmm... what if you specify '_a as signature?
<bluestorm>
hm
<bluestorm>
let's try ^^
<flux>
won't work.
olleolleolle has joined #ocaml
<bluestorm>
The type variable name '_a is not allowed in programs :p
<thelema>
feh.
<bluestorm>
the solution i used
<thelema>
functors?
<bluestorm>
is to pass a dummy ('a option ref), being (ref None), along with the channel
<bluestorm>
let create_handler file = ref None, open_out ...
patraic has quit [Remote closed the connection]
middayc has quit [Read error: 113 (No route to host)]
<thelema>
that's an evil trick.
<flux>
ref () is better?-)
<bluestorm>
hm
<bluestorm>
i'm not sure ref () will generate weak types
<thelema>
flux: ref () won't weak-ify the type.
<flux>
ah
middayc_ has quit []
<thelema>
bluestorm: and you're looking for a better solution?
<bluestorm>
hm, yes
<flux>
hmm
<thelema>
Using a functor makes a more heavy-weight solution, but it seems to me the 'right way' to make sure these functions work on one type.
middayc has joined #ocaml
<flux>
ocamlc -i outputs stuff with _b
<flux>
but you still can't actually enter such a signature
<flux>
the plain interface description might not give the idea how to really use them. well, perhaps it will for you :).
<neale>
wow my mind is blown
<neale>
so the big difference here is that the kernel keeps the "user data" around
<neale>
(for epoll)
<flux>
neale, are you calling caml_register_global_root?
<neale>
no, what does that do?
<neale>
oh wait I heard about that somewhere and was told it was wildly inefficient for large data sets, which is what I'll have.
<flux>
oh, wait, you already stored the data in ocaml?
<flux>
not in C?
<neale>
flux: that's what I'm thinking I'll have to do.
<flux>
(or: not only in C)
<neale>
I'll say "you pass in whatever you want but just make sure you keep a reference to it somewhere"
<neale>
and then provide a nice wrapper which uses the Set module to do just that
<flux>
I think I read the same discussion and xavier had an opposing opinion. however, there still were cases that could be optimized, it might even be implemented in near future..
<neale>
flux: another problem is *unregistering* the globals
<neale>
because at some point (maybe frequently) they will be deleted
<flux>
neale, it is?
<thelema>
neale: it's possible caml_register_global_root will have an efficient dual implementation in the near future.
<flux>
I think maybe me and thelema have a crystal ball of the same make?-)
<thelema>
flux: we read the same thread on caml-list
evn_ has joined #ocaml
<flux>
I should perhaps subscribe, I've only followed caml weekly
<neale>
huh.
<neale>
looks like caml_register_global_root is the community-approved way to do this.
<neale>
I'm still not super-duper happy about it though, is there a way to unregister?
<flux>
caml_remove_global_root :)
<neale>
but then I need to keep track of my junk
<thelema>
neale: how many values do you expect to register at a time?
<neale>
thelema: I need to be able to handle up to MAX_INT/2
<bluestorm>
flux: i've suscribed very recently
<bluestorm>
and found it interesting so far
<neale>
actually, no, MAX_INT
<neale>
so on a 64-bit machine, a whole lot.
<bluestorm>
then caml_registor_global_root is probably not an option
<neale>
no.
<bluestorm>
on every value, at least
<thelema>
how can you have that many channels?
<neale>
I think I prefer the warning that you must keep a reference, and using Set to manage them in the provided wrapper.
<neale>
thelema: let's say you are google...
<thelema>
then you divide up the problem and run parts of the problem on different machines.
<flux>
neale, note that ocaml can also move stuff around; heap compaction
smimou has quit ["bli"]
<flux>
neale, so you need to be careful about how you hold on to user-provided data..
<neale>
I mean probably google will not use my silly little wrapper, but I'm not in favor of placing arbitrary restrictions if there's a design option where I don't have to.
<thelema>
just holding max_int refs on a 64-bit machine seems ludicrous.
<neale>
flux: oh my.
<flux>
neale, you could disable heap compaction (lablgtk does if
<flux>
it AFAIK), but that's a hacky way to go about it
<neale>
yes.
<neale>
what a bummer!
<thelema>
would epoll even work if you gave it 2^63 values?
<neale>
theoretically
<neale>
dangit
<neale>
I'm going to have to make do with ints aren't I.
<flux>
without caml_register_global_root, that's one option
<neale>
lame.
<neale>
It would have been so neato to pass in continuations.
<flux>
oh, I was thinking rather having a map from integers to ocaml values
<neale>
yeah, sure
<neale>
it's not *terribly* lame
<neale>
it's just an extra lookup step that C doesn't have to do.
<RobertFischer>
neale: Where do you want to pass continuations? On the other side of a epoll?
<flux>
neale, if it's a resizable array, the lookup would be very fast
<neale>
yeah I want to create lots of curried handler functions and pass those in, so that when epoll returns I can just run the continuation it returns
<bluestorm>
and deletion is quite easy to handle, if the values know their own index in the array
<RobertFischer>
Use JoCaml. :)
<flux>
does JoCaml use (e)poll?-)
* RobertFischer
is in love.
<RobertFischer>
JoCaml has everything that Ocaml has.
<RobertFischer>
Plus concurrent awesomeness.
<flux>
robertfischer, so you've written something with it?
<RobertFischer>
flux: Mainly little proofs-of-concepts. I'm following along with the manual right now.
<neale>
I think I'll just use ints.
<neale>
I'm sure I'm not the only person writing an OCaml program who knows 255 files isn't enough but doesn't want to depend of libevent.
<flux>
I don't think the libevent ocaml even work, unless they've been updated recently
<flux>
+bindings for
<neale>
it compiled for me
<flux>
gc-issues
<neale>
but it seemed like I was going to have all this extra cruft floating around in RAM if I used it
<flux>
but maybe they are fixed, I've sent patches to the author
<neale>
okay, gotta go donate blood.
<neale>
thanks for the tips
<flux>
happy bleeding!
evn_ has quit []
l_a_m has quit [Remote closed the connection]
coucou747 has quit ["bye ca veut dire tchao en anglais"]