mbishop changed the topic of #ocaml to: Discussions about the OCaml programming language | http://caml.inria.fr/ | Grab Ocaml 3.10.0 from http://caml.inria.fr/ocaml/release.html (featuring new camlp4 and more!)
<Jeff_123> ok thanks I'll check it out
<Jeff_123> well, not with cvs :P
<Jeff_123> cool! It's right where you said
nuncanada has joined #ocaml
smimou has joined #ocaml
<hcarty> I don't know the syntax to actually /use/ the extension :-) But I was poking through the source the other day and noticed that
<Jeff_123> if you do a search for camlp4oof there's a post by john harrop giving a simple example
<hcarty> Jeff_123: Cool, thanks
l_a_m_ has joined #ocaml
bebui has quit [Remote closed the connection]
bebui has joined #ocaml
ita has quit [Remote closed the connection]
<hcarty> Ah, I remember seeing that. I was hoping for something like [1..100]
l_a_m has quit [Read error: 110 (Connection timed out)]
<Jeff_123> ya it's not quite as feature complete as eg haskell or python's list comprehensions
<Jeff_123> if I could figure out how camlp4 works maybe I could extend it further
<hcarty> Sdflow is a nice library for some similar things, without needing camlp4
<hcarty> But some other simple extras would be nice
<Jeff_123> I want to learn camlp4 for lots of reasons though
<Jeff_123> anyone know of some secret camlp4 3.10 tutorial?
smimou has quit ["bli"]
buluca has quit [Read error: 113 (No route to host)]
jeffwheeler has joined #ocaml
<jeffwheeler> I'm interested in learning a bit more about OCaml; I've gone through much of the tutorial at ocaml-tutorial.org, but was wondering if there were any other beginner's resources?
yminsky has joined #ocaml
yminsky has quit []
nuncanada has quit ["Leaving"]
<hcarty> jeffwheeler: http://wiki.cocan.org/training has some more links
Zolaa is now known as Zola
<jeffwheeler> hcarty: thanks
sergez has joined #ocaml
ikaros has quit [Read error: 110 (Connection timed out)]
ikaros has joined #ocaml
kelaouch1 has joined #ocaml
jeffwheeler has quit [Remote closed the connection]
kelaouchi has quit [Read error: 110 (Connection timed out)]
david_koontz has quit []
ikaros_ has joined #ocaml
ikaros has quit [Read error: 110 (Connection timed out)]
<Jeff_123> hell, i'd pay for an online course that taught camlp4 comprehensively
sergez has quit [Read error: 110 (Connection timed out)]
mordaunt has joined #ocaml
mordaunt has quit [Read error: 104 (Connection reset by peer)]
<pango> there is http://martin.jambon.free.fr/extend-ocaml-syntax.html, but I don't know how well it applies to ocaml 3.10 too
jeffwheeler has joined #ocaml
<jeffwheeler> Is there a way to verify that a function is using tail-recursion?
<jeffwheeler> From what I can find, most simply input a very large number and watch for a stack overflow.
rayno has quit [Connection timed out]
rayno has joined #ocaml
<tsuyoshi> I haven't had any trouble telling just by looking at a function
<jeffwheeler> As I said a few hours ago in this channel, I'm pretty new to OCaml, and I'm just looking for a way to verify.
<tsuyoshi> there isn't.. if you're trying to figure it out, you could paste the code for uys and we could look at it and explain whether it is or not
<pango> tail recursivity is a property of calls, not functions, so you may have to tail recursive and non tail recursive calls to the same function (within its definition)
<pango> (well, within its definition, or otherwise)
<jeffwheeler> hmm; let me show you what I'm playing with
<jeffwheeler> (I couldn't find an official pastebin for this room: is there one?)
<jeffwheeler> It seems to work alright, but I'm not sure it's the best way to implement it.
<jeffwheeler> I _think_ it's tail-recursive because it does not appear to overflow on large numbers.
<tsuyoshi> it is tail recursive
<pango> it is... (but its complexity is O(n^2) )
<tsuyoshi> essentially, when you return the result of a call, you're making a tail call
<pango> because List.length complexity is O(n)
<jeffwheeler> pango: oh, I hadn't considered that; it's a linked list.
<jeffwheeler> And it's singly-linked, correct? Because there is no way to add to the end.
<pango> it's the simplest way to create immutable lists
<pango> interestingly, you're passing n around, but it's never modified... as is, you could remove the parameter, and use count everywhere
<pango> or put it to better use, to avoid using List.length :)
<jeffwheeler> Yeah, I just was able to remove the List.length; was about to share.
<jeffwheeler> but I hadn't considered that method
seafood_ has quit []
netx has quit ["Leaving"]
<pango> looks ok... and should be faster for large arguments
<jeffwheeler> thanks a lot for your help; I'd been playing with that for a while. I'm totally new to a lot of these concepts, but I have been programming other things like Python for the web for a while.
<pango> (that said, ints will quickly overflow)
<pango> using Big_ints: http://pastebin.be/6892
<jeffwheeler> pango: appreciate the example; definitely learning some things from it
<pango> it needs to be linked against the Nums module to work (ocamlc nums.cma, ocamlopt nums.cmxa, ocaml nums.cma, or #load "nums.cma" ;; in toplevel)
<jeffwheeler> yeah, I'm playing with doing a similar things with the ounit library at the moment; unit testing seems like it makes a killer combo with functional languages
<pango> static typing and rich type system also allow to avoid whole classes of bugs
<jeffwheeler> thanks a lot for the help; I'm gonna go get some sleep
<pango> np
jeffwheeler has quit []
Onyxyte has joined #ocaml
seafood_ has joined #ocaml
Yoric[DT] has joined #ocaml
bhall has quit ["Lost terminal"]
netx has joined #ocaml
ttamttam has joined #ocaml
Yoric[DT] has quit ["Ex-Chat"]
desp has joined #ocaml
<desp> hello
<desp> how would you write the Y fixed point combinator in OCaml?
<desp> I found Oleg's treatise on the subject, http://okmij.org/ftp/ML/fixpoints.ml
<desp> but I'm wondering if there isn't a simpler way
<desp> specifically, the simplest way that does not use built-in recursion support (let rec, or recursion through use of modules)
<desp> although the Wrap/unwrap method isn't too bad...
seafood_ has quit []
apastinen has joined #ocaml
apastinen has quit ["leaving"]
apastinen has joined #ocaml
marmottine_ has joined #ocaml
filp has joined #ocaml
m3ga has joined #ocaml
Jeff_123 has quit ["Quit"]
sergez has joined #ocaml
<flux> this looks fun: http://conway.rutgers.edu/~ccshan/wiki/blog/posts/MultipleQ/ - multiple-question forms that are constructed from the code that Lazy.forces values when it needs them
smimou has joined #ocaml
Abo-Marwan has quit [Remote closed the connection]
screwt8 has quit [Remote closed the connection]
screwt8 has joined #ocaml
<desp> flux: it's very nice.
<m3ga> oooo, very nice!
<desp> any ideas about a fixed point combinator in OCaml, though?
<flux> nope. the ones in the .ml look what I would think of, too
<desp> mhm
<tsuyoshi> hmm.. I need gconf bindings
<tsuyoshi> and a deb for pgocaml
<tsuyoshi> there was an itp back in 2002..
<tsuyoshi> but it's not in wnpp
<flux> what are you going to write?
Abo-Marwan has joined #ocaml
<tsuyoshi> still working on a fundraising database
<tsuyoshi> got a lot of it working with postgresql-ocaml
<tsuyoshi> but I'm getting sick of the way I'm interfacing with sql
<flux> :)
<tsuyoshi> actually I'm getting sick of sql
<flux> I wonder if pgocaml will help much
<rwmjones> tsuyoshi, you are or aren't using pg'ocaml?
<flux> you're still writing sql?
<tsuyoshi> rwmjones: I want to convert my existing code to use pgocaml
<flux> and have the non-composability issues..
<tsuyoshi> flux: what do you mean still writing sql?
<tsuyoshi> is there a better way?
<flux> well, the things that for example LINQ or Python SQLAlchemy etc use
<flux> (right? I haven't really looked at them ;-))
<tsuyoshi> never heard of those
<flux> but the point is that you construct queries from selects and projections etc
<flux> there was discussion about those things some time back
<flux> and I actually also have a defunct idea, but it doesn't work or even provide static guarantees: http://www.modeemi.cs.tut.fi/~flux/software/ocaml-sql/
<tsuyoshi> the biggest annoyance (aside from sql being a pain to optimize) is nulls
<tsuyoshi> pgocaml should be able to tell if a query result can have nulls or not
<flux> I also have an idea to make that work, should simplify it quote a lot.. just provide labels to the fields after all stages.
<flux> which should remove all ambiguities
<tsuyoshi> right now when I compile I get 200 warnings about partial matches
<tsuyoshi> because I put all the query results into option string arrays
<tsuyoshi> so I have like
<tsuyoshi> let [|Some foo; Some bar|] = Sql.get1 "select foo, bar from quux"
<flux> I do that on case-by-case basis
<flux> and do match .. with | [|
<flux> ..with Some x :: Some y :: z :: Some foo :: [] -> .. | _ -> failwith "Argh"
<tsuyoshi> ehh.. that is too wordy
<flux> I like your idea is using different functions for different data arity
<flux> s/is/of/
<flux> or is that for that purpose?-)
<flux> what does get1 mean?
<tsuyoshi> yeah.. I have Sql.get, which puts all the rows into an extlib enum
<tsuyoshi> Sql.get1 raises an error if there's more than one row
<flux> in my present code I make queries like this: trydb db ~expect:[Pg.Tuples_ok] (prepare_with "select * from foo where a=?0 and time>=?1" [0, db_of_str "hello"; 1, db_of_time time]) (fun r -> r#get_all_lst)
<tsuyoshi> hrm.. how does pgocaml do this
<flux> so if I expect one row the last (fun ..) can actually be replaced with something like get_one
<tsuyoshi> ah, I have another fucntion Sql.run which expects no tuples
<tsuyoshi> so I can get rid of the ~expect argument too
<flux> I guess I could refactor those a bit..
<tsuyoshi> I'm really disliking sql though.. when you get into using lots of tables it gets ugly
<tsuyoshi> I started getting 500 line queries.. and I tried to split them into smaller views
<flux> 500 line queries, huh
<flux> what are you querying for?-)
<tsuyoshi> but then the postgres optimizer doesn't optimize very well when the complicated part is hidden behind views
<flux> is that true even nowadays?
rayno has quit [Connection timed out]
<tsuyoshi> actually I'm not sure.. since I'm still using 7.4
<tsuyoshi> I should upgrade
<flux> you definitely should.
<tsuyoshi> but still.. when it gets above a dozen tables in one query, it switches to the genetic optimizer
<flux> atleast I've discovered that it's not a good idea to write abstractions as functions, because that will prevent the optimization
<tsuyoshi> and the genetic optimizer just plain sucks
<flux> :)
<flux> perhaps you can share your worries with #postgresql, I've seen those guys being helpful
<tsuyoshi> and then I have to de-view the query, because I have to make the joins explicit
<flux> well, if the queries were composable, that would be quite a simple change in the querying code
<tsuyoshi> and the whole schema thing is just awful
<tsuyoshi> composable?
<tsuyoshi> hmm.. yes
<tsuyoshi> I just can't help thinking the problem is not with postgresql per se, but that they are using a query language which really isn't that great
<flux> on reddit discussions I've read about at least one nice (nicer?) query language, developed by IBM I think.. the name escapes me, though. it was very structured.
<tsuyoshi> it's tough for me to write a query that is both fast and readable
<flux> instead of the "plain english"-approach of sql
<flux> however, as sql is now the hottest query language around, the other languages aren't really being developed
<tsuyoshi> I wonder if it would be better with a new query language to compile to sql, or to add a new parser to postgres
<flux> I think both: first stage 1 (even though it is complex), then perhaps stage 2
<flux> stage 1 would be usable with more sql backends
<flux> and stage 2 only if it really gives something..
<flux> the stage 2 query language could be extended with hints (like 'I expect only a few rows, I expect query size ~ 10% of database table size')
Yoric[DT] has joined #ocaml
<Yoric[DT]> hi
Tetsuo has joined #ocaml
<tsuyoshi> oh, there wasn't an itp for pgocaml
<tsuyoshi> I will package it then
* Yoric[DT] returns debugging his parser.
<flux> yoric[dt], how's it going?
<Yoric[DT]> Tired, too much nightly debugging.
<Yoric[DT]> But otherwise, fine.
<Yoric[DT]> It's progressing.
* Yoric[DT] is also a bit low on morale with the current situation of French universities.
<flux> what situation?
<Yoric[DT]> Essentially, the government has passed a law that turns French universities into businesses.
<Yoric[DT]> Not exactly privatized them, but the spirit's there.
<tsuyoshi> they have to turn a profit?
<Yoric[DT]> They are expected to make money on their own.
<Yoric[DT]> The law doesn't say that they have to make profit, but the law makes it possible.
<Yoric[DT]> And the law also makes the university need to find private investments.
<Yoric[DT]> Which, to my mind, sounds like stock-holders in everything but name.
<Yoric[DT]> Although the universities remain nominally public.
<flux> so they will get no money from the government?
<flux> or they do, just not as much as they used to?
<Yoric[DT]> Not specified.
<Yoric[DT]> The government may decide each year if/how much money they give.
<Yoric[DT]> In particular, our Beloved President declared essentially that there would be no money for Letters.
<Yoric[DT]> Because, you know, humanities are useless.
desp has left #ocaml []
<tsuyoshi> that sounds kind of crazy
<tsuyoshi> especially in france.. paris is like the world capital of literature
<Yoric[DT]> Our Beloved President is a caricature of Margaret Thatcher thinking he's Napoleon.
<Yoric[DT]> And I actually believe that last sentence.
seafood_ has joined #ocaml
<tsuyoshi> ooh.. no kerberos or ssl in pgocaml
<tsuyoshi> I need kerberos at least
<tsuyoshi> guess I'll have to look into adding that
<tsuyoshi> so can the president of france do whatever he wants? doesn't he have to get things through the legislature?
<Yoric[DT]> Usually, yes.
<Yoric[DT]> But he has such an overwhelming majority that it doesn't matter for the moment.
<Yoric[DT]> (that is, in both parliaments)
seafood_ has quit [Client Quit]
<tsuyoshi> oh, that's too bad
<Yoric[DT]> Given time, parts of that majority will split away, but it's only 6 months into his presidency, so they stick together.
<Yoric[DT]> And they have a very thatcherian agenda.
<asmanur> Yoric[DT]: in what university are you teaching ?
<Yoric[DT]> Orléans.
<asmanur> ok
<Yoric[DT]> Why ?
Winterstream_ has joined #ocaml
* Yoric[DT] hopes asmanur is not RG :)
<Winterstream_> Hi everyone.
<Yoric[DT]> hi
<asmanur> just to know, maybe you could be in the town i live, but no :]
<Winterstream_> Is it possible to obtain the name of an algebraic type in Ocaml?
<Yoric[DT]> (for non-French, RG = Renseignements Généraux = the part of police in charge of watching political activists)
<Yoric[DT]> asmanur: where are you ?
<asmanur> Dijon
<asmanur> it's pretty far :p
<Yoric[DT]> Winterstream_: what do you mean ?
<Winterstream_> If one matches a var n to a type Node, is there function f, so that (f n) will produce "Node"
<Winterstream_> ?
<Yoric[DT]> a type Node ?
<Yoric[DT]> You want a function returning a type ?
<Yoric[DT]> Oh, sorry, a string.
<Winterstream_> For a type
<Yoric[DT]> Not that I know.
|Catch22| has quit [Read error: 104 (Connection reset by peer)]
* Yoric[DT] isn't sure he understands the question.
<Yoric[DT]> Is node a type or a type constructor ?
<Yoric[DT]> Is Node a type or a type constructor ?
<Winterstream_> Sorry; I should explain better...
<Winterstream_> As far as I know, Ocaml doesn't have a symbol type, right? But one pretty much gets the same functionality by using algebraic data types.
Mr_Awesome has quit ["aunt jemima is the devil!"]
<Winterstream_> Now, in Common LISP, one has a function to convert symbol names to strings and vice versa. Erlang has something similar (something like atom_to_string and string_to_atom)
<Yoric[DT]> "symbol" as in "free algebra upon a symbol alphabet" ?
<Winterstream_> No...
<Yoric[DT]> Chances are that the answer to your question is "no", but I'd like to be sure I understand first :)
<Winterstream_> Like 'this-is-a-lisp-symbol
<Yoric[DT]> "symbol" as in "any identifier" ?
<Winterstream_> It's just a constant whose name can be converted to a string and vice versa
<Yoric[DT]> er...ok
<Yoric[DT]> But your symbols live in different types, do they ?
<Winterstream_> In a softly typed language like Erlang, it's the only way to store "type" information...
<Yoric[DT]> Ok.
<Winterstream_> {my_type, 1, 2, 3}
<Winterstream_> my_type isn't a type name...
* Yoric[DT] is slowly remembering Erlang.
<Winterstream_> it's just a label
<Yoric[DT]> ok
<Winterstream_> One could use...
hkBst has joined #ocaml
<Winterstream_> {"my_type", 1, 2, 3}
<Yoric[DT]> Now, why do you need conversions to strings or from strings ?
<Winterstream_> but strings are not that efficient
<Yoric[DT]> ok
<Winterstream_> Well, I'm writing my own little Erlang-like general-purpose IPC mechanism...
<Winterstream_> One of its data types is an "atom" type (which matches what I described above)
<Winterstream_> When one send an Ocaml data type
<Winterstream_> I would like to be able to serialize the name of the data type as an atom
<Yoric[DT]> Ok.
<Winterstream_> So, if we have a data type Node(1, 2, 3), I would like it to serialize to (Node, 1, 2, 3)
<Yoric[DT]> Firstly, are you sure that one of the already-available serialization mechanisms are not appropriate for you ?
<Yoric[DT]> s/one/none/
<Winterstream_> My system is meant to be used by any language
<Yoric[DT]> ok
<Winterstream_> So I've designed a very simple encoding scheme
<Yoric[DT]> Secondly, do you want to be able to send any kind of value ?
<Winterstream_> It's really basic
<Winterstream_> Well, within reason
<Yoric[DT]> Or just a subset defined by you ?
<Winterstream_> It will be possible to define specialized serializers...
<Winterstream_> But mostly it's simple
<Winterstream_> lists, tuples
<Winterstream_> numbers, strings, atoms
<Winterstream_> Not even all numbers - just ints
<Yoric[DT]> Basically, you want to send trivial S-Expressions.
<Yoric[DT]> Is that it ?
<Winterstream_> More or less
<Yoric[DT]> There's an S-Expression library for OCaml supporting serialization/deserialization.
<Winterstream_> It's somewhat similar to Joe Armstrong's UBF
<Winterstream_> Oh yeah, Janet Capital's one?
<Yoric[DT]> I think so.
<Winterstream_> (hmm, I can't quite remember their name)
<Yoric[DT]> I haven't tried it.
<Winterstream_> Jane Street
<Winterstream_> I'll check it out
* Yoric[DT] is reading UBF.
<Winterstream_> Thanks for reminding me
<Yoric[DT]> Basically, writing a UBF serializer/deserializer looks rather trivial.
<Winterstream_> Yeah.
<Winterstream_> That's the point...
<Winterstream_> because...
<Winterstream_> Well, I'd rather not make it absolutely general
<Yoric[DT]> But no, out-of-the-box, you have no support for turning types into readable tags and vice-versa.
<Winterstream_> Since Erlang does just fine with such simplicity
<Yoric[DT]> Still, it's just one line of pattern-matching.
<Winterstream_> I am so bad at OCaml...
<Winterstream_> But I've decided to write the process spawning process in Ocaml ;)
<Yoric[DT]> :)
<Winterstream_> To improve my OCaml knowledge
<Yoric[DT]> match my_tree with
<Winterstream_> and because it's rock solid
<Winterstream_> and fast
buluca has joined #ocaml
<Winterstream_> What I would like to be able to do, is something like:
<Yoric[DT]> | Struct some_list = "Struct {"^List.map some_list ^"}"
<Winterstream_> send(Node(a, b, c))
<Winterstream_> and send should do the work
<Yoric[DT]> An element of vocabulary : from the point of view of OCaml, all the elements of UBF would be inhabitants of the same type.
<Yoric[DT]> They would just use different constructors.
<Yoric[DT]> (a constructor being essentially a statically-typed atom)
<Winterstream_> yes
<Winterstream_> But I would like to make it more convenient for the programmer...
<Winterstream_> When my process receives data
<Winterstream_> It should construct a proper OCaml type
<Winterstream_> which is ready for normal pattern matching
<Winterstream_> So...
<Winterstream_> [1, 2, 3] in my encoding, should create the equivalent OCaml list
<Winterstream_> Oh wait
<Winterstream_> I just realized
<Winterstream_> I can't just do that...
<Winterstream_> Of course
<Winterstream_> Because the type of the match
<Winterstream_> must be the same
<Winterstream_> Whether the incoming data is a string
<Winterstream_> or an int
<Winterstream_> So you are right
<Winterstream_> I must use a type constructor
<Winterstream_> :/
<Yoric[DT]> (technically, you may use polymorphic variants, but, well, that's an advanced topic)
<Winterstream_> I have read about them a little bit
<Winterstream_> Maybe I should just use something simple for the beginning
<Yoric[DT]> Probably.
<Yoric[DT]> You can always rework it at a later stage.
m3ga has quit ["disappearing into the sunset"]
<Winterstream_> True
<Winterstream_> Thanks Yoric[DT]
<Yoric[DT]> A pleasure.
rogo has quit [Read error: 110 (Connection timed out)]
smimou has quit ["bli"]
JoshGraham has joined #ocaml
seafood_ has joined #ocaml
<JohnnyL> nsfw
rwmjones has quit [Read error: 113 (No route to host)]
rwmjones has joined #ocaml
rayno has joined #ocaml
JoshGraham has left #ocaml []
screwt8 has quit [Read error: 104 (Connection reset by peer)]
Abo-Marwan has quit [Read error: 104 (Connection reset by peer)]
Abo-Marwan has joined #ocaml
Tetsuo has quit [Remote closed the connection]
piggybox has joined #ocaml
screwt8 has joined #ocaml
Yoric[DT] has quit ["Ex-Chat"]
munga has joined #ocaml
seafood_ has quit []
rayno has quit [Connection timed out]
munga has quit ["Ex-Chat"]
pango has quit [Remote closed the connection]
pango has joined #ocaml
filp has quit ["Bye"]
CRathman has joined #ocaml
filp has joined #ocaml
filp has quit [Client Quit]
piggybox has quit ["Leaving"]
CRathman has quit ["ChatZilla 0.9.79 [Firefox 2.0.0.9/2007102514]"]
ttamttam has left #ocaml []
Ogedei has joined #ocaml
Tov_enst has quit ["Ex-Chat"]
gunark has quit [Read error: 104 (Connection reset by peer)]
filp has joined #ocaml
buluca has quit [Read error: 113 (No route to host)]
ttamttam has joined #ocaml
screwt8 has quit [Read error: 104 (Connection reset by peer)]
Abo-Marwan has quit [Read error: 104 (Connection reset by peer)]
|Catch22| has joined #ocaml
ita has joined #ocaml
bluestorm has joined #ocaml
Tetsuo has joined #ocaml
Yoric[DT] has joined #ocaml
bluestorm has quit ["Konversation terminated!"]
<Yoric[DT]> hi
<ita>
Onyxyte has quit ["Be back later."]
rayno has joined #ocaml
bhall has joined #ocaml
buluca has joined #ocaml
screwt8 has joined #ocaml
Jeff_123 has joined #ocaml
Abo-Marwan has joined #ocaml
<ttamttam> ouille
<ita> ttamttam: et path le chemin ..
Mr_Awesome has joined #ocaml
smimou has joined #ocaml
buluca has quit [Read error: 113 (No route to host)]
<Yoric[DT]> ?
ttamttam has left #ocaml []
ita has quit ["Hasta luego!"]
ertai has joined #ocaml
buluca has joined #ocaml
Ogedei has quit ["ERC Version 5.0.4 $Revision: 1.726.2.19 $ (IRC client for Emacs)"]
filp has quit ["Bye"]
david_koontz has joined #ocaml
hkBst has quit ["Konversation terminated!"]
romanoffi has left #ocaml []
marmottine_ has quit ["Quitte"]
screwt8 has quit [Read error: 104 (Connection reset by peer)]
Abo-Marwan has quit [Read error: 104 (Connection reset by peer)]
screwt879 has joined #ocaml
Abo-Marwan105 has joined #ocaml
ertai has quit [Read error: 110 (Connection timed out)]
JohnnyL has left #ocaml []
Mr_Awesome has quit ["aunt jemima is the devil!"]
buluca has quit [Read error: 113 (No route to host)]