<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?
<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
<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.
<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?
<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: