emmanuelux has quit [Read error: Connection reset by peer]
emmanuelux has joined #ocaml
ulfdoz_ has joined #ocaml
ulfdoz has quit [Read error: Operation timed out]
ulfdoz_ is now known as ulfdoz
emmanuelux has quit [Read error: Connection reset by peer]
<thelema_>
hcarty: I'm working on hashtbl; I want the new interface but without dropping support for 3.12, so I have to pull the code from 4.00 into batteries
emmanuelux has joined #ocaml
phao has joined #ocaml
oriba_ has quit [Quit: oriba_]
cataska has quit [Quit: leaving]
<phao>
is it for k = 0 to 10 do ... done; or for k := 0 to 10 do ... done;
<phao>
the book I am reading insists in the second, but ocaml doesn't seem to accept it
<phao>
I built the memo function (it is working) and I wanna make the fib to use the table in its recursive calls
<phao>
because simply doing ((memo fib) 40) won't look at the table for fib (39) even if it's there
<phao>
let ff = memo fib;;
<phao>
ff 39;; ff 40;; (* this ff 40 will re-calculate ff 39*)
<phao>
but that code I pasted is invalid
<phao>
but... is there any way to get something like that done?
Sablier has joined #ocaml
<phao>
what I tried to do there is for rawfib use the memoized verion of itself...
<phao>
so that the table in memo is "utilized by" rawfib
ocp has joined #ocaml
<flux>
btw, that (fun x -> mfib x)-kind of style is redundant, plain mfib will do
<flux>
well, not in the second case :)
<phao>
thing is... I want that memo rawfib to be calculated only once
<phao>
rawfib, mfib, ... these things, I think, should be calculated only once
<flux>
phao, I think usually it is done by adding an additional argument to the recursive function
<flux>
which is the function it should call to recurse
<phao>
good!
<phao>
excelent idea
<flux>
I wonder though how that is actually done :)
<phao>
trying here
<flux>
it may need the use of an additional constructor because of recursive types
<flux>
(or use ocaml -rectypes to get around that but nobody uses that)
emmanuelux has quit [Remote host closed the connection]
<phao>
I'd need to do something like this
<phao>
let mfib = memo (rawfib mfib)
<phao>
heh
ftrvxmtrx has joined #ocaml
<phao>
yeah, the types are getting in the way
eikke has joined #ocaml
<phao>
I just did a (mfib mfib) here
<phao>
"the little schemer" came to mind, as well as Y
<phao>
I can't have the fixed point operator in a strongly typed language, right (like ML) ?
<flux>
you probably need some explicit polymorphism here, or worse, a record or recursive modules
<phao>
hmm
<phao>
I don't know how to use these
<phao>
I will postpone that
Submarine has joined #ocaml
Submarine has quit [Changing host]
Submarine has joined #ocaml
<flux>
well
<flux>
I found a solution
<flux>
almost, you need to work on that ;)
<flux>
type c = C of (c -> int -> int) let fib = let rec rawfib (c : c) = let C c' = c in function | 0 | 1 as i -> i | i -> c' c (i - 1) + c' c (i - 2) in rawfib (C (memo rawfib))
<flux>
it dies in the 'memo' function because it now memoizes rawfib's first argument
<flux>
which is a function
<flux>
it works if the last argument is: rawfib (C rawfib), but of course, it works slowly
BiDOrD has joined #ocaml
BiDOrD_ has quit [Ping timeout: 246 seconds]
<phao>
hmm, I get a Invalid_argument
<phao>
hmm
<flux>
your memo tries to compare functions. that doesn't work.
<phao>
yeah, because memoizes the 1st argument, which is a function
<phao>
you state types explicitly that often?
<phao>
like you did (c:c),
<phao>
types of arguments.
<flux>
not really, but it helped here to ensure the types properly :)
<phao>
ok
<flux>
it usually moves type errors closer to the origin of the error
<phao>
well
<phao>
I will just leave this be
<phao>
I think I'd have to do what you said, about using polymorphism
<phao>
flux, is it possible that this I wanna do is not possible here?
<phao>
(because of the type system)
<flux>
hmm, it may be that you need to lift the memoization table outside the memo-function
<flux>
the problem here is that to construct memoized function I need to access parameter c
<flux>
and if I have parameter c around and I create a table, the table is created many times
<flux>
with that intermediate () I get to construct the table separately
<flux>
(and still allowing 'memo' to be polymorphic)
<flux>
memo-function could probably deal with function that take themselves as first parameter by itself
ocp has quit [Quit: Leaving.]
<phao>
so that works?
<flux>
sure
avsm has quit [Read error: Connection reset by peer]
eni is now known as albacker
albacker has quit [Changing host]
albacker has joined #ocaml
albacker is now known as eni
eni has quit [Quit: .]
ankit9 has quit [Ping timeout: 256 seconds]
<phao>
that was compilcated =(
thomasga has joined #ocaml
<flux>
indeed :)
avsm has joined #ocaml
<phao>
it seems that making types explicit here is needed
<flux>
well, it works as well with type 'a c = C of ('a c -> 'a) let fib = let rec rawfib c = let C c' = c in function | 0 | 1 as i -> i | i -> c' c (i - 1) + c' c (i - 2) in let m = memo () in let v c = m (rawfib c) in v (C v) but I'm not sure if that can anymore be simplified.
<flux>
the main point is not to have infinite types
<flux>
infinite type = something that can be written out in finite time
<flux>
and to keep in mind that type a = b is not really a new type, but a type alias
zuymanto has joined #ocaml
<phao>
the trick with the functions receiving themselves is what I can't see clearly
<phao>
it's confusing, It's not obvious for me how that turns out to work
<mrvn>
blkid gibt doch die UUID vom inhalt von /dev/md0 aus, nicht die UUID von den Metadaten, oder?
<mrvn>
ups
silver has quit [Read error: Connection reset by peer]
wmeyer`` has joined #ocaml
hcarty has quit [Ping timeout: 252 seconds]
silver has joined #ocaml
hnrgrgr_ has joined #ocaml
hcarty has joined #ocaml
mrvn_ has joined #ocaml
adrien_ has joined #ocaml
dnm_ has joined #ocaml
wmeyer` has quit [Ping timeout: 260 seconds]
rwmjones has quit [Ping timeout: 260 seconds]
hnrgrgr has quit [Remote host closed the connection]
mrvn has quit [Remote host closed the connection]
adrien has quit [Ping timeout: 260 seconds]
testcocoon has quit [Ping timeout: 260 seconds]
dnm has quit [Remote host closed the connection]
rixed has quit [Ping timeout: 244 seconds]
rwmjones has joined #ocaml
rixed has joined #ocaml
testcocoon has joined #ocaml
fasta_ has joined #ocaml
fasta has quit [Ping timeout: 260 seconds]
zuymanto has quit [Quit: zuymanto]
beckerb has joined #ocaml
ankit9 has joined #ocaml
Hussaind has joined #ocaml
<phao>
flux, I can't let the ocaml system infer the types in that code, right?
<phao>
flux, I can't let the ocaml system infer the types in that code, right?
<phao>
ops
<phao>
sorry
<mfp>
(off-topic) any recommendations for plotting pretty graphs (i.e. beyond gnuplot)? gotta do some latency/rate graphs for my "billion random writes" benchmark
<phao>
mfp, a software?
<mfp>
well, yes
<phao>
idk if it helps, but I used libreoffice calc to plot graphs for me once... generated idk how many points, and gave to it
avsm has quit [Quit: Leaving.]
<mfp>
(my handwriting is write-only as far as other ppl are concerned ;)
<phao>
I think I wrote a program to generate 1000 points, and gave to libreoffice -- it did it very well
<phao>
heheh
<phao>
if this is for some work that is getting printed in a paper, then I think you could use libreoffice calc
<mfp>
hmm I'd prefer something that I can integrate in a Makefile
<phao>
hmm
<mfp>
also, I have maybe >2000000 data points or so in total
<phao>
ok
<mfp>
oops 2e5 rather
<mfp>
or maybe not, if I count all the percentile graphs for latency :)
<phao>
maybe libreoffice accepts command line options
<phao>
and can output the graph in an image file
<phao>
idk if I understood what you want though
<phao>
but idk if libreoffice accepts that... And honestly, I don't really think it's adequate hehe
<mfp>
definitely looks like something I can "script" :)
<Drakken>
right. You can look in thelema's bench/benchplot project on github for examples.
<mfp>
that sounds great, they should map quite directly to what I need
<Drakken>
bench/src/benchplot.ml
<mfp>
hmm that's a lot of code... I'll just compile and let it generate some plots :)
Yoric has joined #ocaml
<mfp>
benchplot.ml is a bit scary, but it boils down to ~40LOC per plot including all label + style options, which is acceptable
<mfp>
thanks a lot Drakken
<Drakken>
you bet :)
silver has quit [Read error: Connection reset by peer]
silver has joined #ocaml
Yoric has quit [Ping timeout: 265 seconds]
<phao>
flux, I think I understand the idea, but that type you put in there -- I don't even know what that means =)
<Drakken>
ha ha fib 4 = 3 :)
<phao>
?
<phao>
Drakken, did you look at the code?
<phao>
Drakken, I am having troubles understanding some things related to the type system
<orbitz>
phao: Is this the question you just asked in ##c?
<phao>
flux showed me a piece of code to solve a problem of mine, and that code only works if you explicitly state the types, and some very strange type stuff in there heheh
<phao>
orbitz, no no
<orbitz>
mfp: Did my memory leak fix in ocamlmq ever get back to you?
<orbitz>
phao: URL to code?
<phao>
orbitz, this is another doubt of mine =) I am trying to understand this code here:
<phao>
Drakken, that memo function is a little different... it generates a table, and it gives back you a funciton that takes f and its argument to lookup or compute by calling (f x)
avsm has joined #ocaml
<mrvn>
let fib = let t = Hashtbl.create 0 in Hashtbl.add t 0 1; Hashtbl.add t 1 1; let rec fib i = try Hashtbl.find t i with Not_found -> let v = (fib (i-2)) + (fib (i-1)) in Hashtbl.add t i v in v in fib
<Drakken>
there's nothing unusual about the memo function. it should use List.find
<phao>
mrvn, sure I understand there are simpler ways to do this
<orbitz>
phao: last thing i'd want to learn when starting ocaml is references side effects
<mrvn>
let fib = let t = Hashtbl.create 0 in Hashtbl.add t 0 1; Hashtbl.add t 1 1; let rec fib i = try Hashtbl.find t i with Not_found -> let v = (fib (i-2)) + (fib (i-1)) in Hashtbl.add t i v; v in fib I mean
<phao>
but I wanted to see, and want to understand, how to do it that way
strlen has quit [Ping timeout: 248 seconds]
strlen has joined #ocaml
<flux>
phao, do you use emacs, btw?
<flux>
or vi?
<mrvn>
a generic polymorphic memo function is hard.
<flux>
because both of those have code that can tell the types of expressions
<flux>
it can help a lot when trying to understand how types work in a piece of code.
<phao>
flux, none.. I use notepad++
<flux>
in emacs it's C-c C-t
<flux>
hmm
<flux>
maybe you could consider the ocaml eclipse plugin?
<phao>
I have emacs here -- I think...
<phao>
flux, I honestly don't think that it'd matter here...
<zorun>
flux: does it?
<phao>
the whole idea is that I wanna understand these things on my own
<phao>
(with some help hehe)
<zorun>
flux: C-c C-t doesn't seem to work with tuareg-mode
<phao>
flux, I guess I just don't know about the type system... but why is that let C c' = c is needed?
<phao>
why can't I just do (C c) c (i - 1) ?
<mfp>
orbitz: I don't remember that one (I do remember the fix involving corrupted frames due to a shared buffer, though), do you have a link to the diff?
<phao>
(C c) c (i - 1) + (C c) c (i - 2)
<phao>
I mean.
<orbitz>
mfp: one sec
<flux>
zorun, you need to have caml-types.el around for that to work
<flux>
zorun, also, you need to compile with -dtypes
<flux>
phao, well, C c isn't a function
<phao>
but won't (C c) construct a c from c?
<phao>
a value of type c from the value c I mean
<flux>
yes
<flux>
type c isn't a function type
<phao>
isn't it?
<flux>
it's a sum type
<flux>
like option
<phao>
sum type?
<phao>
I don't know what that is...
<flux>
you cannot do this either: (Some int_of_string) "42"
<flux>
sum type is like: type 'a option = Some of 'a | None
<flux>
but in this case we only have one constructor
<phao>
ahh.. I knew these by union types
<orbitz>
phao: tuples/records are product types and unions are sum types
<phao>
ok
<phao>
why does that let "makes" c a function then?
<phao>
ahh!!!
<phao>
it's pattern matching in there.
<phao>
and extracting the function...
<flux>
exactly
<orbitz>
yes
<phao>
now it makes more sense
<orbitz>
Since you c only has 1 ctor you can do it in the let
<phao>
ok
<phao>
It's problematic seeing stuff like this
<phao>
I don't wanna leave it before I understand at least some of it
<phao>
it's dangerous, it may take lots of time
<phao>
I think the catch here is thinking of that type... which I am really not used to
<phao>
(explicitly)
<mehdid>
rwmjones: concerning 6865790801a84e9ad94234e30da346b73381b232 in fedora-ocaml.git, those are merged into tools/objinfo.ml since 3.12.0.
<mehdid>
so there are not needed anymore
<mehdid>
*they
diego_diego has joined #ocaml
Tobu has quit [Quit: No Ping reply in 180 seconds.]
Tobu has joined #ocaml
diego_diego has quit [Quit: diego_diego]
diego_diego has joined #ocaml
diego_diego has quit [Client Quit]
<Drakken>
so... that C type is just a strange way of coding mutual recursion
<phao>
Drakken, I understood it as a way to pack/unpack the function
<phao>
it's a way to support "indirect" recursion actually
<Drakken>
right, because the function is a continuation from the other function. i.e. mutual recursion
<mrvn>
Drakken: it is a way around having a recursive type which would require -rectypes
<phao>
Drakken, I don't know how you call it
<phao>
I'd not say it's mutual recursion
<Drakken>
why do you need the type at all? there's rawfib and memo (), and they call each other recursively.
lin has joined #ocaml
<mrvn>
Drakken: the type of memo or rawfib would become recruisve
<Drakken>
I don't think so
<Drakken>
or rather, yes but you just define them together with let rec
<mrvn>
Drakken: that isn't the problem, the problem is that one argument of the function is the function itself. So the type becomes recursive with itself.
<Drakken>
you don't need that argument if the function is defined mutally with the other function.
<Drakken>
mutually
<mrvn>
Drakken: ok, true. But then your memo isn't generic anymore.
Yoric has joined #ocaml
<Drakken>
oh. I didn't realize that was the point.
<phao>
Drakken, it sounds really strange calling this thing mutual recursion
<phao>
the things rawfib is defined in terms of (its two parameters) are not defined in in terms of rawfib
<Drakken>
rawfib doesn't need two parameters if the memo doesn't need to be generic.
<phao>
ok
<phao>
then it goes back to what mrvn said
<Drakken>
fib looks in the memo table first, then calls rawfib. rawfib calls fib unless x = 0 or 1.
<Drakken>
That's mutual recursion.
oriba has joined #ocaml
<phao>
well, recursion has to do with the definitions
<phao>
the definition of rawfib is not in terms of itself, and the thigs it's defined in terms of are not defined in terms of rawfib
bzzbzz has joined #ocaml
<phao>
a parameter of rawfib, in that case, called rawfib
<phao>
hmm, mrvn suggested an implementation following the idea you have
<phao>
of mixing fib and "memo" into one
<phao>
that surely simplify everything, but I wanted them separately -- merely to see where it'd lead
<phao>
Drakken, maybe it's just me, but the code flux wrote is much more interesting
<Drakken>
okay
<phao>
doing it directly, as you did, is more efficient
<phao>
the direct approach is simpler, and less bureaucractic
<Drakken>
if you wanted the memo to be polymorphic, then fine, I didn't know that was a priority.
<Drakken>
I just didn't understand the code at first, and this was my way of trying to figure it out.
<phao>
Honestly, I didn't think in terms of that... flux started mentioned these details, which I honestly still don't understand
<phao>
I just wanted to know how I could have fib called the memoized version of itself in its body
<phao>
Drakken, I still am looking at the code, w/o sureness I know what it does =)
<ssbr>
Has anyone added typeclasses to ocaml?
<Drakken>
It looks like the recursive type replaces the mutual recursion in the simpler version.
<ssbr>
The lack of a polymorphic printing function dogs me every time I screw up :(
<Drakken>
it probably has a lot to do with ocaml's relative unpopularity too
<phao>
pretty much
<phao>
ssbr, I imagine open type should solve this
<ssbr>
phao: I don't know what that is. (Googling gives me fonts.)
<Drakken>
haskell and ocaml need to have a baby :)
<ssbr>
Drakken: yes please
<Hodapp>
Drakken: Why bother? It'd be even more obscure than both.
<phao>
ssbr, I am new to ocaml, but it's sort of a type that you can "extend"
<Drakken>
generic printing and (something like) typeclasses, but not the purity and monads
<ssbr>
Or laziness.
<ssbr>
(lazy + impure is just asking for problems)
<Drakken>
Hodapp everything is obscure at first ;)
<phao>
ssbr, with that you can make a polyprint, that initially takes int, then make a new polyprint that can accepts float and if the variable given isn't a float, you call the old one;; then one for string; then ... and then ...
<ssbr>
There's a lot of neat small pretty bits of haskell, like first class value constructors and all that. It's a very pretty language that works well with itself.
<ssbr>
phao: OK, that would be very nice
<ssbr>
I didn't know ocaml could do that
<ssbr>
Mmmm, those don't look quite right
<phao>
ssbr, I guess ocaml implementation does static linking to support stuff like that, for one
<ssbr>
phao: I'd want to pass in (print some_int), not (print (Integer some_int))
<phao>
the books gives a very similar to polyprint example
<phao>
it makes a to_string function
<phao>
Hmm...
<phao>
well yeah, got it
<ssbr>
or, yeah, to_string
sepp2k has joined #ocaml
<phao>
that to_string had that problem too
<phao>
you could only do to_string (Integer 3)
<phao>
for example
<Hodapp>
Drakken: Everything being obscure at first (which is not a given) does not imply that any of them are destined for eventual widespread use.
<ssbr>
phao: Yeah, that doesn't really save me the debugging overhead
<phao>
if it's for debugging purposes, it should be enough...
<Hodapp>
Drakken: However, feel free to develop a new language anyhow.
<ssbr>
not much different from print (Integer 4) and print (string_of_int 4)
<ssbr>
as far as debug printing is concerned, they're about the same :(
<ssbr>
Hodapp: I don't think people write languages to be used by everyone.
<phao>
ye
<ssbr>
If a language is useful for the author, that is sometimes enough.
<Hodapp>
ssbr: Some people do. Those languages however tend to suck.
<phao>
ssbr, look up java =)
<ssbr>
Like, if some OCamlized haskell happens to work as a GHC extension and interact with haskell code, then that's probably fine. It's plenty useful, because you get access to the whole haskell codebase
<phao>
there's also C# and Visual Basic
<phao>
I'd put javascript in the middle too
<ssbr>
phao: Hm, in reference to what?
<Hodapp>
ssbr: However, someone cited Ocaml's relative unpopularity as a reason for why someone should make a new language, and this is why I mentioned obscurity in the first place.
<phao>
ssbr, languages made for "everyone to use"
<ssbr>
Hodapp: I interpreted those as being two disconnected statements
<Hodapp>
phao: C# was a lame "Me too!" about Java, the way I see it.
<Drakken>
Hodapp was that someone me?
<ssbr>
phao: Well, C# and VB are pretty good actually.
<ssbr>
C# is very pleasant to program in, compared to most languages of that class. And VB is just C# with a worse syntax.
<phao>
ssbr, I wouldn't disagree, and I'd dare say the same for java and javascript -- but I never used any
<phao>
I just said they were "languages for the masses"
<Drakken>
I didn't say we should have a new language because ocaml is unpopular, I said we should have a new language because ocaml has features that suck (IMHO)
<phao>
Drakken, you could try out making this new language
<ssbr>
OCaml isn't really that unpopular.
<Drakken>
it doesn't dominate the software industry though.
<ssbr>
like, compared to C and whatever, OK, sure, but OCaml is pretty close to the top in the big picture :(
<phao>
hehe
<ssbr>
Drakken: sure, but it does have a pretty big presence in various kinds of research
<phao>
ssbr, have you ever done any scheme?
<ssbr>
phao: yes
<phao>
it's another one big in research... lots of papers have scheme code
<ssbr>
odd. TIOBE lists OCaml in the top 100 (latter 50), and "ML" as number 47
ski has joined #ocaml
<ssbr>
Oh, also "Lisp" as #15 and "Scheme" as #28. How terrible.
<Drakken>
latter 50 is pathetic. I can't believe the industry is dominated by script-kiddie languages and dinosaur OOP languages.
<ssbr>
Drakken: well, to be fair, Haskell, "ML", and F# are in the former 50
<phao>
that's because tiobe is a lot useful
<phao>
ssbr are you from brazil?
<ssbr>
phao: negative, I am a canadian
<djcoin>
Where did you see those figures ? (list as #15 etc. ?)
<ssbr>
TIOBE is a badly-architected but fun index of programming language popularity
osa1 has joined #ocaml
<phao>
Drakken, why can't you believe that?
<phao>
these languages have tons of useful libraries
<phao>
and they're used in schools
<phao>
I believe much of the languages people used are influenced by that.
<phao>
they wanna do, say , web programming, and see PHp that's easy to get something going and has tons of libraries; so they go for PHP
<Drakken>
they all suck
<Drakken>
ocaml would be way higher if it had generic printing
<phao>
Drakken, the languages suck, I agree, for example, that PHP sucks
<ssbr>
Drakken: I'm not so bought into OCaml-style type safety that I'd say anything with dynamic types is a sucky kiddie-scripting language
<phao>
well, C doesn't have generic printing =)
<phao>
it's high
<ssbr>
phao: C is that high largely because it is the common base for everything everywhere
<ssbr>
it's some kind of kooky, demonic lingua franca of the programming world
<Drakken>
C is a systems language
<phao>
whatever is the reason, it's not because of generic printing =)
<ssbr>
Drakken: systems programming is not as popular as C is
<ssbr>
not even close
<phao>
Drakken, there is an article by paul grahan about why languages get popular
<ssbr>
phao: generic printing is a usability concern that bites people.
<phao>
I think there's a lot of truth in that...
<phao>
Drakken, if I got it right, he believes C is popular because it was made by the authors for the authors; and because it could hack unix well
<Drakken>
yea
* Hodapp
<3 C
<phao>
Drakken, if you go to Paul Grahan website, you will find many articles, they're all interesting to read
<ssbr>
Hodapp: ewwwwwwwww
<Hodapp>
sometimes, I just need to go bash around memory and system calls directly.
<phao>
ssbr, I am not used to generic printing honestly
<ssbr>
Hodapp: take a look at ATS
<Hodapp>
and not pretend I'm in an OO language.
<Drakken>
phao I've read most of them
<Hodapp>
Paul Graham's articles are interesting
<phao>
ahh =)
silver has quit [Ping timeout: 244 seconds]
<mrvn>
ssbr: 90% of bugs are type errors
<Hodapp>
ssbr: I regularly use toolchains though where the only thing that's available might be C.
<phao>
Drakken, I believe libraries are as much (if not more) important than language design for many programmers
<ssbr>
Hodapp: after BitC died, I was like, "I want to learn something like BitC, but BitC is dead and also unpublished", and then I found ATS. It's pretty great, and fulfills a lot of the high-level promise of safe systems programming (although it goes about in a different way)
<ssbr>
(also ATS compiles to C)
<phao>
I mean, in your job, if you have a deadline, you won't wanna spend time building libraries
<phao>
it's just easier picking a language that has it already in it
<ssbr>
mrvn: that isn't a figure that is particularly convincing
<Hodapp>
ssbr: I will look at it, but I am still curious how well it can run on whatever weird toolchain I find myself using.
<phao>
and deal with the annoyances of the language -- because these are manageable
<ssbr>
mrvn: the issue is, how many type errors are caught by an OCaml-like type system that would not be caught otherwise? Is there a cost difference for the shared error-detection? What about that other 10%, does that constitute a disproportionate amount of the cost of debugging?
<mrvn>
ssbr: if you can detect and fix 90% of your bugs at the compile stage instead of having to run test suites that is a huge bonus.
<phao>
Drakken, for example, as annoying as it is, you can do for i from 0 to n <do something>
<ssbr>
mrvn: Maybe huge, maybe not
<phao>
instead of using some map fancy call
<mrvn>
ssbr: A lot of those 90% are cought by ocaml while C does not catch them.
<phao>
in a language that supports list very well
<phao>
and have high order procedures, etc
<ssbr>
mrvn: Oh, _C_, pff.
<mrvn>
ssbr: languages without compile time types at all are even worse
<ssbr>
comparing things to C is too easy. I thought you were talking about dynamically typed languages
<ssbr>
mrvn: I disagree. Unlike C, type errors are made visible -- even if they are delayed to runtime
<phao>
yeah
<ssbr>
also memory safety, oh jeez memory safety
<mrvn>
ssbr: dynamically typed languages will give you runtime errors. Which means some obvious type errors will be cought only years down the line by some poor user
<Hodapp>
mrvn: Are you aware of any empirical studies that have tried to determine with any degree of statistical accuracy the number of bugs in programs written in statically-typed languages vs. dynamically-typed?
<ssbr>
mrvn: Maybe.
<phao>
I sort of agree with mrvn
<ssbr>
mrvn: this is something that should be empirically studied, not reasoned about
<phao>
static typing helps a lot
<mrvn>
ssbr: ocaml can't (accidentally) segfault, no memory errors possible
<ssbr>
mrvn: I don't like ocaml because of beliefs about how hard it is to debug
<ssbr>
I don't really know
<Hodapp>
mrvn: I've looked and found incredibly scanty results, and mostly a lot of hand-waving.
<ssbr>
I like it because it is more pleasant to code in
<mrvn>
ssbr: I go by experience. The strict types in ocaml do help prevent bugs.
<Hodapp>
mrvn: The one that I did read found the opposite, but not in a statistically significant way.
<ssbr>
mrvn: anecdotal experience of other people is not something I can trust
<mrvn>
ssbr: work with it for a while
<ssbr>
mrvn: I've been working with it for weeks. I enjoy it.
<phao>
ssbr, ??
<ssbr>
I think I'd rather its type system were stronger.
<mrvn>
ssbr: isn't that enough reason to stick with it :))))
probst has joined #ocaml
<ssbr>
mrvn: eh, not really. I'm more productive with Python, for a number of reasons.
<mrvn>
ssbr: What do you mean stronger?
<ssbr>
mrvn: I like dependent types.
<mrvn>
ssbr: ocaml 4.0 will have GADTs
<ssbr>
that isn't what I mean no. Dependent types are what I mean. :(
<phao>
what are GADTs?
<phao>
generic ADT?
<mrvn>
ssbr: afaik most dependent types you can express with GADTs
<ssbr>
this type declaration (ATS) is a thing of beauty: fun {n:nat, x:type} array_get_elt(arr : array(x, n), idx : int n) -> x = ...
<ssbr>
I may have misremembered the syntax somewhat, and type might have to be t@ype sometimes, but hey
<mrvn>
phao: Generic or General or something Arithmetic Data Types
<sepp2k>
Generalized
<phao>
heh
<ssbr>
it means, "this function is defined for natural numbers 'n', and types 'x', as taking the parameters "arr": an array of 'x'es, of size n, and an index whose value is n"
<mrvn>
ssbr: the first part is just pattern matching on a record in a fun ...
<phao>
I imagine if function overloading would be a good idea here
<ssbr>
of course what I meant was to specify nat m < n, but whatever
<mrvn>
(in ocaml)
<ssbr>
mrvn: in ATS the stuff in {} are static values
<Hodapp>
ssbr: what do you (you specifically, not a hypothetical programmer) use ATS for?
<ssbr>
Hodapp: me? Nothing. I am considering writing a regular expression implementation in ATS.
<ssbr>
mostly its incompatibility with C is offputting. It's just shy of being good enough to replace C for library programming
<ssbr>
unfortunately all its pointers are void*
<ssbr>
(yes, this is actually my complaint.)
<mrvn>
ssbr: You can express compile time boundary checks for arrays in ocaml too.
<Hodapp>
ssbr: This is why I use C...
<ssbr>
Hodapp: sure, but I hate C
<ssbr>
Hodapp: too many terrible experienced
<ssbr>
people say the compiler warns you when you mess up. They are wrong.
<Hodapp>
the compiler warns in certain cases, but there are lots of ways to kill things.
<phao>
ssbr, what languages do you like?
<ssbr>
This one time, I malloc'd an array of size 0 because of a typo. Then I wrote 1024 entries into it
<ssbr>
then magically nothing went wrong. Instead, I mysteriously was having garbage output.
<ssbr>
That's odd -- why is that output garbage? Huh, it gets turned to garbage after I call that function. How could that-- oh, right, this is C"
<ssbr>
phao: ATS, OCaml, Python.
<ssbr>
(one of these is not like the others, eh?)
<ssbr>
mrvn: I'd be interested to hear more.
<ssbr>
mrvn: I don't know the power of OCaml's type system, so I can't really properly compare it to ATS.
<ssbr>
mrvn: OCaml's almost certainly isn't strong enough for handling safe memory use in ATS, but maybe it's good enough for practical applications?
<mrvn>
ssbr: ocaml has no buffer overflows, stack corruption, memory leaks or double frees normaly. You need to specifically use Obj.magic to do something dirty or call C code to get things to go bad.
<ssbr>
(ATS ends up deferring to an SMT solver for convenience, in ATS 2)
<Hodapp>
ssbr: Yeah, it is full of pitfalls like that.
<ssbr>
mrvn: Sure, of course.
<ssbr>
mrvn: but you were saying the type system could encode compile-time length checks
<mrvn>
ssbr: It can. It isn't pretty but it can.
<ssbr>
so like, I could define a function whose type is "an array, and a valid index into that array"
<ssbr>
mrvn: well, it isn't pretty in ATS either. but how much less pretty?
<ssbr>
eh. s/how much less pretty/how ugly?/
<mrvn>
ssbr: You can have a type "an array of size X and a index in X"
<ssbr>
mrvn: can I have functions that take arrays of variable size?
<mrvn>
Where "size X" is a type, so something like ONE | TWO | THREE ... or d1 d3 d7 Array.t for a size 137.
<ssbr>
Oh.
<ssbr>
mrvn: well. that isn't so different from ATS so far
<ssbr>
ATS has explicit compile-time values which can be, e.g., natural numbers or integers
<mrvn>
The logic to declare the type and the logic to declare indexs becomes rather ugly.
<ssbr>
Yeah...
probst has quit [Quit: probst]
<mrvn>
Doing it with a runtime check is trivial though.
<ssbr>
One of the desirable things is to have a nice way of expressing dependent types that is not too harsh
<ssbr>
mrvn: Sure. but ATS is meant to let you have the power of C, safely
<mrvn>
ssbr: Problem is that you need to do math with the types. E.g. a bsort needs to split the range of its index in two.
<ssbr>
people say, "I want to have the power to shoot myself in the foot", but they are liars. They want to shoot really close to their foot, even if that means they run the risk of shooting themselves. The idea is, well, what if we can let you shoot exactly anywhere anyone has wanted to shoot, and prevent you from hitting your foot?
<ssbr>
ATS doesn't hit that. In fact it's strictly impossible. But we can get really close...
<ssbr>
mrvn: the math can get _really_ ugly in ATS
<ssbr>
especially when pointers are involved
<ssbr>
anyway, uh, right, the point I was making
<ssbr>
compile-time boundary checks are quick way of advertising, "hey, you can, like C, avoid runtime checks for speed reasons -- but you can do it safely!"
<mrvn>
ssbr: last month I had an example that did compile time range checks for quicksort. Given a valid array and 0-size range the compiler then garanties that all the device&conquere stays inside the ranges so all array access can be done with Array.unsafe_* (without rnage checks).
<ssbr>
mrvn: very nice
<mrvn>
and quite hard to understand.
<ssbr>
in ATS it is not hard to understand :(
Kakadu has joined #ocaml
<ssbr>
Ah well. ATS and OCaml aren't even competitors. Nobody really does value-dependent types for application programming.
<mrvn>
well, in AST it is a compiler feature. In ocaml they did it with the existing type system.
<ssbr>
mrvn: Right.
<ssbr>
Well
<ssbr>
ATS is also strictly more powerful in some sense
<ssbr>
I just don't know what yet
<ssbr>
:(
<Kakadu>
Is there anybody experienced in crosscompling ocaml-sdl to arm?
<ssbr>
mrvn: I'm under the understanding that some properties of ATS lead it to be un-inferrable in some cases because of undecidability concerns
<mrvn>
Kakadu: I would use qemu-system-armel
<ssbr>
maybe I am wrong
<mrvn>
ssbr: quite probable.
<ssbr>
but if that's true it would imply ATS can do things with its type system ocaml can not, separately from just the UX of dependent types
<ssbr>
cannot*
<mrvn>
For me what you can do isn't important. Important is what you can do nicely.
<ssbr>
mrvn: then it might be desirable to get standard HM with special syntax, so that we get type inference everywhere
smondet has joined #ocaml
milosn has quit [Ping timeout: 244 seconds]
milosn has joined #ocaml
Hodapp has quit [Ping timeout: 244 seconds]
companion_cube has quit [Ping timeout: 244 seconds]
strlen has quit [Ping timeout: 244 seconds]
adrien_ has quit [Ping timeout: 244 seconds]
Hodapp has joined #ocaml
companion_cube has joined #ocaml
Reventlov has quit [Ping timeout: 244 seconds]
strlen has joined #ocaml
<Qrntz>
mfp, thanks, I'll try that
Reventlov has joined #ocaml
adrien has joined #ocaml
adrien has quit [Ping timeout: 244 seconds]
adrien has joined #ocaml
<wmeyer``>
morning
phao has quit [Quit: Not Here]
<Hodapp>
wow, I did not realize ML dated back to 1973
phao has joined #ocaml
snearch has joined #ocaml
djcoin has quit [Quit: WeeChat 0.3.2]
djcoin has joined #ocaml
oriba has quit [Quit: oriba]
<wmeyer``>
Hodapp: Correct. Robin Milner on Cambridge University started ML for LCF in around mid 70's
<wmeyer``>
Hodapp: Lisp is even older - 56. The thing was that none of the machines could handle that at this point
<wmeyer``>
that's the biggest problem why the industry went for Fortran, BCPL, and then C and etc. because it was efficient to write OS in these languages
<phao>
wmeyer``, the people seem to always choose the more practical language =)
<phao>
practical for the context, of course
<phao>
I guess, today, most people use languages just because other people use them, or because they were taught with those languages
<phao>
I mean, lots of people here where I study don't know very well why they use C++, they'll tell you tha they do because they started with it, and got used to it
<Hodapp>
wmeyer``: I was indeed well aware that Lisp is quite old. Kind of fascinating to read about, as it's often noted that Lisp and FORTRAN are the two oldest high-level languages still in use and they're rather different in paradigm
<wmeyer``>
Hodapp: yes
<wmeyer``>
Hodapp: If you add polymorphic type system to Lisp it immediately becomes ML however :-)
<Hodapp>
wmeyer``: Is ML homoiconic? Does it let you construct and evaluate code at runtime?
<wmeyer``>
Hodapp: No, is not homoiconic - code representation have different representaion than data - and it does not have "eval" primitive. Indeed the major difference in paradigm is that Lisp has powerful macro system - so it's more targetted to meta programming
<Hodapp>
wmeyer``: Seems to me it still has some key differences then :)
snearch has quit [Quit: Verlassend]
snearch has joined #ocaml
<phao>
Hodapp, well, you could build an eval
<phao>
however, I guess that would not be convenient
<wmeyer``>
phao: Eval is not that useful - perhaps embedding toplevel in OCaml runtime would be enough. I think the macro system makes the difference
<phao>
yeah
<wmeyer``>
Hodapp: yes, and all due to type system - you gain something to lose something
<wmeyer``>
Hodapp: but in my opinion type system is more useful :-)
<hongboz>
thelema_: I have a working version findlib
<hongboz>
for ocaml 4.0.0
phao has joined #ocaml
<djcoin>
wmeyer``: could you elaborate on type system being more powerful on macro system ? :)
<djcoin>
s/on/than
<phao>
djcoin, when I was on, he just said that he things the type system is more useful
<hongboz>
wmeyer``: I think type system should be exposed to programmers as a constraint language :-)
<phao>
thinks*
hongboz has quit [Quit: ERC Version 5.3 (IRC client for Emacs)]
<djcoin>
phao: yeat but how "more" useful ?
<djcoin>
For compilation check ?
<wmeyer``>
djcoin: It's not more powerful - it's rendundant in fact - in a presence of macro system. However the problem is that you need a type system to produce an industrial strenght code (for refactoring, reading purposes, that other can join)
<wmeyer``>
djcoin: it just produces more maintainable code
<phao>
djcoin, idk what he thinks, but I see it this way: it comes finished, and ready to use
<phao>
djcoin, as in, you could implement a type system with macros, afaik, but how long would that take?
<wmeyer``>
phao: not long, perhaps a day
<phao>
djcoin, many useful things lipers do with macros could be done without them anyway (see scheme users, they use much less macros than CLers)
<wmeyer``>
phao: that's the lisp course - basic ML type system is very simple
<phao>
wmeyer``, hard to believe, but as I was going to say
<wmeyer``>
phao: means *basic*
<phao>
it's hard for me to talk about something I am not used to
<wmeyer``>
phao: you just need unification - and traverse through your body of special function form implemented as macro - to verify if it type checks
Sablier has quit [Read error: Connection reset by peer]
dsheets has quit [Ping timeout: 244 seconds]
beckerb has quit [Quit: Konversation terminated!]
<wmeyer``>
phao: but once you have a type system - it's becomes a hurdle for macros
<phao>
I guess it does
<wmeyer``>
phao: that's why Camlp4 is much less powerful than classical Lisp macros - and much more complicated - because it's very hard to do
<wmeyer``>
phao: but you can use it or not
<phao>
maybe you could put the macro system to deal with the types for you
<wmeyer``>
imagine (define-typed (foo bar) (+ bar 43))
osa1 has quit [Quit: Konversation terminated!]
<phao>
sure
<wmeyer``>
phao: it's possible, but not easy and comes with overhead
<wmeyer``>
define-typed is just a macro
<wmeyer``>
that type checks before it calls proper define
dsheets has joined #ocaml
emmanuelux has quit [Remote host closed the connection]
<phao>
I wondered, once, how that could be done
<phao>
I imagined some way, but never tried
<phao>
I liked lisp most because of scheme -- when I actually took a CL book to read, I didn't like it so much
cago has quit [Quit: Leaving.]
<phao>
Scheme's continuation and procedures are really cool to use
<phao>
I think in terms of procedures, there are not many differences, except that it's alittle annoying having to do funcall in CL
<phao>
but other than that... not so different, I think
mika1 has quit [Quit: Leaving.]
<wmeyer``>
phao: Scheme is much better. Regarding funcall - well, CL has a legacy concept of separation between variable namespace and function namespace, so you need to convert back and forth
<wmeyer``>
phao: In Scheme there is just one environment
<wmeyer``>
phao: CL also comes with big bloat of library, Scheme suppose to be lean. CL has the CL style macros out of the box. Scheme has hygenic macros in standard, but every distribution comes with CL style macros anyway
emmanuelux has joined #ocaml
<ssbr>
wmeyer``: isn't define-syntax in one of the newer scheme standards, as an extension of CL-style defmacro?
<wmeyer``>
phao: and you are right, continuations are really cool in Scheme. Equiped with macrs you can do anything you want :-)
<ssbr>
where define-syntax lets you define a macro as a function that takes in and returns a syntax object, which is an S-expression with extra information attached
emmanuelux has quit [Remote host closed the connection]
<phao>
wmeyer``, the big library part, I'd not mind a useful one in scheme
<phao>
I badly can open files in standard scheme
<wmeyer``>
ssbr: unfortunately not, it's more limited version of defmacro, I think it deals implicitly with the scoping, and what you can call inside macros. Experts claim that there are much less powerful and harder to use than CL macros (but I am not an expert)
<phao>
ssbr, there are some people doing magic with syntax-rules and CPS
<phao>
I remember seeing some people talking about implementing defmacro in scheme using syntax-rules
<ssbr>
wmeyer``: I thought it let you break hygiene pretty cleanly
<ssbr>
I can test
ftrvxmtrx has quit [Quit: Leaving]
<ssbr>
wow. drracket does not work with xmonad at _ALL_
<ssbr>
oh, defmacro's signature is different, it takes the arguments of the expression, and not the whole expression
<wmeyer``>
ssbr: you are beating me down in Scheme :-) I trust you it's possible
<wmeyer``>
ssbr: but cumbersome
<ssbr>
wmeyer``: eh, my approach appears to have hygiene problems
<ssbr>
> (defmacro foo (n) (quote n))
<ssbr>
> (foo 2)
<ssbr>
reference to undefined identifier: n
<ssbr>
I did something wrong~~~
eikke has quit [Ping timeout: 246 seconds]
<ssbr>
oh, derp. That's just quoting.
<ssbr>
'me shakes head
svenl has quit [Ping timeout: 244 seconds]
<ssbr>
(defmacro foo (n) `(quote ,n)) . I am not used to writing this kind of macro
<ssbr>
wmeyer``: anyway, it should be enough to match common lisp
<ssbr>
AIUI they don't like defmacro because it loses too much information about the syntax, and because it doesn't have facilities for hygiene.
<wmeyer``>
ssbr: matter of taste
<wmeyer``>
i know some heavy lispers that do complain about hygenic macros
<ssbr>
wmeyer``: even if it's opt-in?
<wmeyer``>
ssbr: if they permit implementation of defmacro, then i think it's great because it gives choice
<ssbr>
wmeyer``: AIUI, R6RS permits implementation of defmacro
<wmeyer``>
ssbr: then first thing most people would do, is to just implement it, perhaps depends how much power you want :)
<ssbr>
bleh :(
<ssbr>
syntax-rules do almost everything anyone ever wants, and more easily, too
<ssbr>
it's like complaining about how terrible map is, and how we should all use fold_right instead
<ssbr>
mm, not even. map isn't useful enough
<wmeyer``>
ssbr: I agree, maybe having a chat with my coleague would give you an answer why he does not like defmacro, otherwise i can't myself talk about it
djcoin has quit [Quit: WeeChat 0.3.2]
<ssbr>
wmeyer``: does not like syntax-rules, you mean?
<wmeyer``>
yes
<wmeyer``>
sorry does not like syntax-rules yes
<ssbr>
it'd be entertaining
<wmeyer``>
ssbr: he is really hard lisper, and he was doing ocaml before too
<wmeyer``>
ssbr: he has his own lisp implementation
<ssbr>
is it Qi
<wmeyer``>
nope :-)
<wmeyer``>
it's not Dr Tarver
<wmeyer``>
it's not even released
<wmeyer``>
but has been with it for more than 5 years now
<ssbr>
that sounds unfortunate.
hongboz has joined #ocaml
<wmeyer``>
it is
<wmeyer``>
but that's Lisp Curse
eni has joined #ocaml
<ssbr>
Well, I am a fan of people making their own languages, but 5 years unpublished is a little iffy
<wmeyer``>
he has everything there what is needed
<ssbr>
it's like someone writing a novel in their basement for 5 years. It probably is going to be very "self-centred"
<wmeyer``>
already
<wmeyer``>
well there is some binary release, some while ago
<wmeyer``>
ssbr: but yes that's what lispers do
<wmeyer``>
that's why i think i personally prefer type system over macro system
<wmeyer``>
it's tempting to use macros
<ssbr>
I would like both.
<wmeyer``>
ssbr: ideally yes
<ssbr>
There is some research on that -- like the MetaML stuff
<wmeyer``>
ssbr: but that's runtime meta programming
<ssbr>
apparently you can type macros if they are syntax-rules style, but not if they are defmacro-style
<wmeyer``>
it's for a different puprose then extending syntax
<ssbr>
wmeyer``: why?
<ssbr>
also, I wonder if tuples would be less annoying with dependent types
<ssbr>
like, could one have the tuple type tuple([type1, type2, ..., typen]), I wonder? in some type system?
<ssbr>
er, wow that is irrelevant. you reminded me of that, is all
<wmeyer``>
because you can't change the grammar using MetaOCaml it's for partial evulation - but you can use combinators and compile them at runtime to more efficient form
<mrvn>
ssbr: with n being variable?
<wmeyer``>
ssbr: not really - dependent type system allows some sort of meta programming
<ssbr>
mrvn: Yeah
<mrvn>
ssbr: well, with t1=t2=..=tn it would be an array
<ssbr>
right
<mrvn>
you could have the index type dependent on the value and an universal array.
<mrvn>
index = 0 -> int | 1 -> float | 2 -> string ...
<mrvn>
ssbr: if one had a type ('a , ('c, 'd) as 'b) t = ... one could declare your tuple.
<mfp>
orbitz: one of the "billion write" benchmarks for the obigstore database I just released
<orbitz>
Ohhh swell!
<mrvn>
you've got to work on your units
<orbitz>
Pure ocaml?
<mfp>
this one represents 1e9 writes into 8192 hotspots with 50% update probability
<mfp>
mrvn: log scale and such?
thomasga has quit [Quit: Leaving.]
<mrvn>
mfp: using k/M/G
<mrvn>
mfp: drawing a standard deviation might help too
<mfp>
orbitz: it's got a bit of C++ to bind to leveldb
<mfp>
mrvn: the variability you can see there is caused by obigstore's throttling (to put it short, leveldb can sometimes accept writes faster than it can actually process them in a sustainable manner)
<mfp>
because the load generator keeps sending as much as it can
<mfp>
now, if the generation rate stays below the sustainable one, the actual insertion rate will remain pretty much constant
<ssbr>
Is there anything standard (like option) of the form type ('a,'b) either = Left of 'a | Right of 'b ?
<orbitz>
ssbr: No. I have my own prelude that has a Return.t with Success and Failure ctors
<ssbr>
Makes sense. Thanks.
<orbitz>
ssbr: And then like a functiont aht wraps up try/catch
hcarty has quit [Ping timeout: 252 seconds]
<ssbr>
clearly we need the error monad / deferreds
Xizor has quit []
<orbitz>
Deferres as in for IO?
<orbitz>
I'm looking ot async soon
tchell has quit [Ping timeout: 245 seconds]
mehitabel has quit [Ping timeout: 244 seconds]
<mfp>
orbitz: what sort of rates do you get in your Hashtbl-backed ocamlmq branch?
tchell has joined #ocaml
mehitabel has joined #ocaml
hcarty has joined #ocaml
<ssbr>
orbitz: deferreds are the same as error monads, AIUI
<ssbr>
they encode branching success/failure computations
<ssbr>
or something
<ssbr>
pipelines that can fail?
phao has quit [Quit: Not Here]
pangoafk is now known as pango
<orbitz>
mfp: I haven't actually pushed it to its limit. It does better than I need, at least.
osa1 has joined #ocaml
<orbitz>
mfp: I didn't switch to hashtable for any performance reason too, I just didn't have any use for persistence + needed to cut down on dependenceis
<mfp>
orbitz: this is the sequential write speed I'm getting on EC2 > http://i.imgur.com/1BPO8.png if I switch to an obigstore backend of persistence in ocamlmq, I could get a bit less than 1/2 of that
<mfp>
ic, if you were going for fewer deps this won't help you in any way :P
<orbitz>
Hehe
<orbitz>
I added a bunch of instrumetnation too, I don't know if that would be helpful to you
<orbitz>
I'm implementing a little web framework for fun that will be backed by ocamlmq too
<mfp>
hmm in the persistence-enabled branches I can get info about queued messages by querying the DB
<orbitz>
Like togglign debug on/off, looking at gc info
<mfp>
GC info could be useful
<orbitz>
Mostly I added it because I was trying to figure out hte memory leak and I was lost as to how to track it down
<orbitz>
You can adjust some gc settings on the fly too.
<mfp>
what I normally do is just add a SIGHUP handler that calls Gc.compact/full_major and dumps the stats to stderr
<orbitz>
Yeah, that's probably better
<mfp>
I wonder what happened to that request to instrument allocation in bytecode
<mfp>
IIRC the submitter claimed (Mottl?) it was possible to do it with no overhead when disabled
<mfp>
being able to take deltas would be very helpful when looking for leaks
<avsm>
i end up with a Gc.bracket function and pepper it everywhere. Something like 'let bracket fn a = let x = livewords () in fn a in let y = livewords () in print (y-x)
<avsm>
not the most elegant, but effective as a binary search
emmanuelux has quit [Remote host closed the connection]
emmanuelux has joined #ocaml
<ssbr>
Any recommended tools for unit testing ocaml code?
<mrvn>
ounit?
<Snark>
printf :-P
<ssbr>
Snark: har har
<ssbr>
rerunnable test cases is the goal :(
<ssbr>
mrvn: looks fine
<ssbr>
except the only tutorial is a video. Wowee
<ssbr>
ah well, simple enough though,
Snark has quit [Quit: Quitte]
robocop has joined #ocaml
Yoric has joined #ocaml
Yoric has quit [Client Quit]
<thelema_>
hongboz: Great. I see that there's a 1.3.2 release of findlib that should also fix things.
benozol has quit [Ping timeout: 245 seconds]
emmanuelux has quit [Remote host closed the connection]
benozol has joined #ocaml
emmanuelux has joined #ocaml
snearch has quit [Quit: Verlassend]
avsm has quit [Quit: Leaving.]
avsm has joined #ocaml
eikke has joined #ocaml
dsheets has quit [Quit: Leaving.]
dsheets has joined #ocaml
sepp2k1 has joined #ocaml
sepp2k has quit [Ping timeout: 260 seconds]
_andre has quit [Quit: leaving]
emmanuelux has quit [Read error: No route to host]
emmanuelux has joined #ocaml
Kakadu has quit [Quit: Konversation terminated!]
eni has joined #ocaml
cdidd has quit [Remote host closed the connection]
Sablier_ has joined #ocaml
Sablier has quit [Ping timeout: 248 seconds]
<wmeyer``>
thelema_: Please pull
<wmeyer``>
thelema_: It works quite OK, I was surprised how well. (META parsing on odb). It would be worth to dig all the packages that we can aproach with this. Majority of Makefile based packages are prone to it.
<ssbr>
I wonder how one would write a type-safe regular expression module? i.e. one that could do something like `let g1, g2 = groups (match (regexp "(a+)(b?)") "aaab") `
<ssbr>
I was thinking macros, but I'm not sure there is anything for that
<orbitz>
if Ocaml had type providrs, you could probably do it with that?
<wmeyer``>
you could if the regexp string was known during compilation
<ssbr>
wmeyer``: a pretty reasonable requirement for such an interface
<ssbr>
does camlp4 let you rewrite function calls in the lisp stype?
<ssbr>
Russ Cox is the author of RE2, the first mainstream linear-time regexp engine with the features of normal implementations (sans backrefs and assertions)
osa1_ has quit [Client Quit]
<ssbr>
Anyway, how would one write that typesafe regexp interface?
<ssbr>
it'd be pretty neat if one could get things like "(a)?" having an entry in the tuple of "string option" as well