naufraghi has quit [Read error: 104 (Connection reset by peer)]
Yoric[DT] has joined #ocaml
<Yoric[DT]>
hi
alexyk has quit []
OChameau has joined #ocaml
comglz has joined #ocaml
naufraghi has joined #ocaml
naufraghi_ has quit [Read error: 113 (No route to host)]
gim has quit []
alexyk has joined #ocaml
naufraghi has quit []
gim has joined #ocaml
hkBst has joined #ocaml
Yoric[DT] has quit ["Ex-Chat"]
yangsx has quit [Read error: 110 (Connection timed out)]
comglz has quit ["Lost terminal"]
alexyk has quit []
yminsky_ has joined #ocaml
al-maisan has joined #ocaml
<al-maisan>
Hello there!
bluestorm has joined #ocaml
<al-maisan>
quick question : how do I match for whitespace using Str.regexp ?
<bluestorm>
[ \t\n] ?
<al-maisan>
Ah, cool, didn't know you can use '\t' in ocaml .. thanks!
bluestorm has quit [Remote closed the connection]
LordMetroid has joined #ocaml
lordmetroid_ has joined #ocaml
lordmetroid__ has joined #ocaml
lordmetroid__ has quit [Client Quit]
lordmetroid__ has joined #ocaml
LordMetroid has quit [Read error: 110 (Connection timed out)]
lordmetroid_ has quit [Connection timed out]
lordmetroid__ is now known as LordMetroid
eelte has joined #ocaml
coucou747 has quit [Read error: 113 (No route to host)]
Mr_Awesome has joined #ocaml
Yoric[DT] has joined #ocaml
<Yoric[DT]>
hi
ChristopheT has joined #ocaml
eelte has quit [Read error: 113 (No route to host)]
eelte has joined #ocaml
bluestorm has joined #ocaml
struk_atwork has joined #ocaml
yminsky_ has quit []
ygrek has joined #ocaml
rodge has quit [Read error: 110 (Connection timed out)]
ikaros has quit [Read error: 110 (Connection timed out)]
ikaros has joined #ocaml
RobertFischer has joined #ocaml
Yoric_ has joined #ocaml
evn has joined #ocaml
al-maisan has quit ["Leaving."]
rodge has joined #ocaml
Yoric[DT] has quit [Read error: 110 (Connection timed out)]
postalchris has joined #ocaml
flux has quit [Operation timed out]
flux has joined #ocaml
Linktim has joined #ocaml
sirius6b has joined #ocaml
RobertFischer has left #ocaml []
ulfdoz_ has joined #ocaml
Demitar has joined #ocaml
Linktim_ has joined #ocaml
coucou747 has joined #ocaml
ulfdoz has quit [Connection reset by peer]
LordMetroid has quit ["Leaving"]
filp has quit ["Bye"]
RobertFischer has joined #ocaml
Linktim- has joined #ocaml
eelte has quit [Read error: 113 (No route to host)]
Linktim has quit [Read error: 110 (Connection timed out)]
ikaros has quit [leguin.freenode.net irc.freenode.net]
TychoBrahe has quit [leguin.freenode.net irc.freenode.net]
mbishop has quit [leguin.freenode.net irc.freenode.net]
Ugarte has quit [leguin.freenode.net irc.freenode.net]
cmeme has quit [leguin.freenode.net irc.freenode.net]
olegfink has quit [leguin.freenode.net irc.freenode.net]
r0bby has quit [leguin.freenode.net irc.freenode.net]
ikaros has joined #ocaml
TychoBrahe has joined #ocaml
mbishop has joined #ocaml
cmeme has joined #ocaml
Ugarte has joined #ocaml
r0bby has joined #ocaml
olegfink has joined #ocaml
netx has quit [Read error: 110 (Connection timed out)]
Snark_ has joined #ocaml
Linktim_ has quit [Read error: 110 (Connection timed out)]
Snark_ is now known as Snark
jonafan_ is now known as jonafan
Yoric_ has quit ["Ex-Chat"]
<hcarty>
bluestorm: http://ocaml.pastewith.us/77 -- This would be, I think, the most useful way to use a pa_float-like syntax
<hcarty>
It is just pa_opening (or pa_scope) with the pa_float syntax
jonafan is now known as iowalinuxboy
<hcarty>
Nesting should be cleaner and easier to understand this way
iowalinuxboy is now known as iowalinuxdude
<hcarty>
s/pa_opening/pa_openin/
iowalinuxdude is now known as jonafan
<hcarty>
So Float.(1.0 + 2.0) = open Float in 1.0 + 2.0 = Float.(+) 1.0 2.0 iff Float.(+) is defined. So operators can be whatever you want.
OChameau has quit ["Leaving"]
Waleee has joined #ocaml
hehe has joined #ocaml
hehe has left #ocaml []
<flux>
I suppose I could try that out with some fp-arithmetic-heavy code
<sirius6b>
How would you truncate whitespaces from the beginning and ending of the string?
<hcarty>
sirius6b: I'd use the OCaml PCRE bindings. Str should also be able to help you out.
<hcarty>
flux: I haven't done any tests. But the proliferation of operators in Jane St.'s core lib made this seem useful.
<hcarty>
I previously extended pa_float to work with any library, so (+) mapped to Foo.add, (-) to Foo.sub and so on.
<hcarty>
I think the approach I just pasted is more generally useful as it does not restrict you to specific operators or names
<hcarty>
I think open ... in is probably still useful. But I think this syntax more than Zheng Li's Module @ ... as I think it is easier for me to reason where the context begins and ends
<hcarty>
If I knew enough camlp4 to write my own rather than just hacking up others' code, I would base this on pa_openin and maybe avoid the code duplication.
<hcarty>
I don't know that that is possible though
Yoric[DT] has joined #ocaml
filp has joined #ocaml
<hcarty>
This Module.() syntax seems to open up some simpler options as well, though I imagine the performance hit may start to add up if it is used too much - f List.(hd l) List.(tl l)
<bluestorm>
hcarty: so "Module.(...)" instead of "open Module in (...)" ?
<bluestorm>
why not
postalchris has quit [Read error: 110 (Connection timed out)]
<bluestorm>
i'm not sure the syntaxic gain is that obvious, but in this domain, small things matters
coucou747 has quit ["bye ca veut dire tchao en anglais"]
* Yoric[DT]
agrees.
<bluestorm>
and the transformation being done is much more easy to understand / reason about, as you said
coucou747 has joined #ocaml
<bluestorm>
now you need modules with syntax sugar (and here comes Numeric :-' )
<bluestorm>
+ic
<orbitz>
IMO M.(..) makes more since because it looks more like a peice of ocde where as open Foo looks like I'm importnat a module, but i'm new, just my thoughts
<orbitz>
importinga module*
<Yoric[DT]>
bluestorm: I was reasoning along the same lines.
<Yoric[DT]>
Numeric + open...in... (or, better, this extension) will be great.
<bluestorm>
Yoric[DT]: the problem is that hcarty will probably want integer-like operators (+ and not +/ +. +:, etc.), wich i'm not sure is the best choice without his syntax
<hcarty>
bluestorm: and Yoric[DT] : I'm happy with whatever variety of operators and functions
<bluestorm>
+. *. are ok ?
<Yoric[DT]>
bluestorm: pretty easy to convert one into the other anyway.
<hcarty>
Foo.add and Foo.(+) could be the same functions
<hcarty>
bluestorm: The plus to open .. in or Module.( .. ) is that the operators could be whatever is appropriate for the module
<bluestorm>
hcarty: i think people using eg. a Int64 module don't want it to rebind (+) on opening
<hcarty>
That is a good point, and a reason I'm not sure this is the best way to go
<bluestorm>
they would tolerate +/ (Num) or +. (float) but they probably don't want to overwrite integer operators, if they use a global open (and are unaware of your extension)
<Yoric[DT]>
bluestorm: just make it a module called Int64.Rebind
<Yoric[DT]>
(or WithInt64)
<bluestorm>
:p i was considering something like that
<bluestorm>
and his extension would open the submodule silently ?
<Yoric[DT]>
Not necessarily silently.
<Yoric[DT]>
WithInt64.(bla)
<bluestorm>
ah
<bluestorm>
so a specific syntaxextension-friendly module in the lib ?
<hcarty>
Since it nests, maybe it wouldn't be so bad Int64.(4L + 5L + of_int Integer.(6 + 3))
<Yoric[DT]>
bluestorm: that's the idea
<bluestorm>
hcarty: the problem is, the library designer should care about the people unaware of your extension
<hcarty>
bluestorm: Indeed
<bluestorm>
hcarty: i don't think they can design the "generic" Int64 module with (+) as operator
<bluestorm>
because people using "open Int64" would cry
<bluestorm>
Yoric[DT]'s idea is to provide a specific module for that
postalchris has joined #ocaml
<Yoric[DT]>
Which is actually what I'm already doing in Batteries Included.
<Yoric[DT]>
(although I'm using (+.) for the moment)
<hcarty>
Yes, a different operator may be best
<hcarty>
Or +/ even, since it's already used in one module?
<hcarty>
Int64.(4L +/ 5L +/ of_int (6 + 3))
* orbitz
thinks that will be cumbersome and unattractive to a large audience
rhar has joined #ocaml
rhar has quit [Read error: 104 (Connection reset by peer)]
<orbitz>
if you are gunna try to make it easier to write mathematicale xpressiosn with other modules, go the full mile.
<Yoric[DT]>
How so ?
evn has left #ocaml []
<hcarty>
There is the pa_float' method of (+) -> Module.add
<hcarty>
But by just using a module's operators, it allows (+) to mean whatever is appropriate in context
<bluestorm>
hmm
<bluestorm>
why couldn't you provide to the user a way to change the operator -> function ?
alexyk has joined #ocaml
<hcarty>
bluestorm: That would be ideal, or better if the library had a way to specify that
<hcarty>
Is it possible to do with camlp4?
jules_ has joined #ocaml
<bluestorm>
i think so
<bluestorm>
you could expose a rebinding-function
<bluestorm>
that an additionnal .cmo, inserted by the user at camlp4-time, could use
<bluestorm>
a bit like what type-conv does if you see
<bluestorm>
you can add code that use the type-conv registration mechanism to add new type processors
<hcarty>
module Int64 = WithInt64 in code which uses the extension (or just wants to operators) may be an easy way to get around all of this. Having the extra library to maintain may be a pain? Or maybe not.
<bluestorm>
btw hcarty
<bluestorm>
i think your fresh () function is unnecessary
<hcarty>
bluestorm: Could it just be a constant string?
<bluestorm>
i think so
<hcarty>
I simply hacked at pa
<bluestorm>
yes
<hcarty>
pa_opening and used the match from pa_float
<hcarty>
ack, s/pa_opening/pa_float/
<bluestorm>
i've asked Yoric[DT] and alain frisch about that actually, and it *seems* there is no risk of binding conflict
<Yoric[DT]>
As usual, trust Alain Frisch better than me.
<bluestorm>
hm
<bluestorm>
actually he mostly said "Ha ? Maybe."
ulfdoz has quit [Remote closed the connection]
ulfdoz has joined #ocaml
<hcarty>
modules are not recursive by default, correct?
<hcarty>
That's the only place I would see it being an issue
<hcarty>
But even then maybe not
<bluestorm>
they are not
<flux>
hm, open Foo in .. doesn't require parenthesis, does it? I've tried the syntax extension in functions such as: let foo a = open String in ..rest..of..the..function.. - requiring parenthesis would in that situation in my opinion be less convenient
<bluestorm>
it doesn't
<flux>
however for arithmetic operations (embdded in expressions) and such I can see the syntactic value in Foo.(expr) would be convenient. perhaps better than (open Foo in expr)
<flux>
but if I had to choose, I'd take open in; but that's just personal preference ;)
<bluestorm>
yes, especially when considering nested openin
<bluestorm>
flux: i think we could provide both
<hcarty>
flux: I think they could exist harmoniously
sirius6b has quit ["Ухожу"]
<hcarty>
Yoric[DT]: I also have some extra functions for Bigarray (which I also offered thelema) if you are interested for Batteries. I need to take the time to pack it up though.
<Yoric[DT]>
thanks
<Yoric[DT]>
My hope is that thelema and I will end-up sharing a common codebase in the end, though.
<hcarty>
That would certainly be preferable
Linktim- has quit [Read error: 110 (Connection timed out)]
comglz has joined #ocaml
jules_ has quit ["Leaving"]
Mr_Awesome has quit [Read error: 110 (Connection timed out)]
jlouis has joined #ocaml
rodge has quit [Read error: 110 (Connection timed out)]
rodge has joined #ocaml
ygrek has quit [Remote closed the connection]
ygrek has joined #ocaml
Choupinou has joined #ocaml
TychoBrahe has quit [Read error: 110 (Connection timed out)]
Choupinou is now known as TychoBrahe
<flux>
hmm.. I think this is the first time I'm contemplating using the Obj-module..
<bluestorm>
:p
<bluestorm>
i've used it some days ago
<flux>
I have a bunch of objects I want to interactively connect to each other, and the objects can do that only if they are type-compatible, in which case they can interact efficiently
<bluestorm>
to implement a ... setcdr :-'
<flux>
now that's just evil!
<flux>
for tail-recursive algorithms without the reversion step?
<bluestorm>
yes
<flux>
hm, with linear types that too could be safe ;)
<jonafan>
soooo
<jonafan>
how do you make a programming language
ygrek has quit [Remote closed the connection]
<bluestorm>
flux: the extlib method is safe
<flux>
that's only slightly less general than question "how does one program"
<jonafan>
it seems like it'd be pretty easy to make an interpreter, but compilers??
<bluestorm>
(.. i think)
<flux>
bluestorm, yes, but because they've been carefully thought out, the compiler didn't help much in ensuring their safety..
<bluestorm>
as they provide only an 'a unsafe_list -> l'a ist function
<bluestorm>
but in this case, i think the extlib method was unsuited
<flux>
a public one?
<flux>
I mean, just using that requires to take some precautions
<flux>
such as: don't mutate the original list after the conversion..
<bluestorm>
hm
<flux>
or does it work by copying?
<bluestorm>
you're right
<bluestorm>
(... and linear types would help with that too)
<flux>
jonafan, there are several books on the topic. however, I don't recall any, as it has been some time since I've dealt with the topic.
<bluestorm>
so it's unsafe actually :p
<bluestorm>
but they could provide a by-copying method
<jonafan>
would you start by making an interpreter?
<bluestorm>
jonafan: there is a "moderne compiler implementation with ML" wich is said to be good
<bluestorm>
jonafan: yes
<jonafan>
yeah.. probably reading books woul dbe good
<flux>
well, atleast writing interpreter would be much simpler, and would probably provide some insight into the problem domain
<bluestorm>
btw, some people have worked on ways to transform an interpreter into a mostly-compiler through multi-stage evaluation
<bluestorm>
see MetaOcaml
<jonafan>
wow
<jonafan>
these computers are going to be self aware soon
ChristopheT has quit [Remote closed the connection]
<flux>
is metaocaml still moving forward?
<flux>
atleast I believe they have some natdynlink support, so they're in sync with 3.10.x..
<flux>
(but there's no such release on their web pages, I suppose you need to get it from cvs)
Snark has quit ["Ex-Chat"]
<hcarty>
MetaOCaml, OCamlP3l and JoCaml all seem very interesting and unfortunately they all seem to have very uncertain futures
alexyk has quit [Read error: 110 (Connection timed out)]
<hcarty>
flux: Where is the MetaOCaml CVS?
<flux>
I don't think I found it, only read about it :)
<hcarty>
Ah, ok
alexyk has joined #ocaml
alexyk has quit [Client Quit]
RobertFischer has joined #ocaml
<RobertFischer>
mn
<hcarty>
bluestorm and Yoric[DT] : What do you think of having Foo and Foo.Infix (or something similar) then have Foo.( ... ) open both Foo and Foo.Infix in ( ... )?
<bluestorm>
not bad, the problem is that you can't know at camlp4-time if Foo.Infix is defined
<bluestorm>
so that would result in an error for Infix-unaware modules
<Yoric[DT]>
I agree with bluestorm.
<Yoric[DT]>
It hurts the generality of your extension.
<bluestorm>
hcarty: i think that a simple openin + an user-refinable rewriting table would be the best thing to do so far
<Yoric[DT]>
I would have Foo.( ... ) be the same thing as open Foo in ...
<Yoric[DT]>
and then I'd rely on the module writer for providing operators in Foo.
<bluestorm>
so you could implement the obvious rewriting ( (+.) -> (+), etc. ), and let the user desactivate them and add more for a specific module of his
<hcarty>
Good points
<hcarty>
I am uncertain if rewriting is a good idea - just using operators and functions in the given module would provide a more consistent approach
olleolleolle has joined #ocaml
<hcarty>
A user would not have to think of what to use inside of Foo.( ... ) and what to use outside of it
<hcarty>
s/and/vs/
<bluestorm>
that could come as a separate extension anyway, but i think a slight dose of rewriting could be helpful
<Yoric[DT]>
How so ?
<bluestorm>
hm
RobertFischer has quit []
<bluestorm>
the main point of the extension hcarty used as a base was to write Float(1 + n) instead of 1. +. n
<bluestorm>
Float.(...), sorry
spanish_mathish has joined #ocaml
<bluestorm>
it would make sense to allow for a per-module table saying "rebind that infix to that function", eg. (+) -> (+.) in Float
RobertFischer has joined #ocaml
erg has quit [Remote closed the connection]
<hcarty>
bluestorm: Is there a way to make that happen automatically when Foo is linked and pa_context (or whatever it should be called) is used, using ocamlfind/ocamlbuild/etc?
erg has joined #ocaml
<bluestorm>
you mean, define the Foo-related translation table inside the Foo module ?
<hcarty>
Something like that, yes. Or a foo.context findlib entry, kind of like foo.syntax is used in some modules.
<bluestorm>
the simplest way would be to make that happen at camlp4-time
<bluestorm>
say, i wrote a context_foo.cmo that is loaded with the camlp4 modules after pa_context.cmo
<bluestorm>
and that update the table for the Foo module
<hcarty>
Ok, that makes sense. And for modules with no entry in the replacement table everything stays as-is?
<bluestorm>
it could be possible to place them directly in the preprocessed code, but surely more difficult and probably less powerful (you would have to parse the data and do ugly things with them)
<spanish_mathish>
does ocaml TCO?
<bluestorm>
yes
<bluestorm>
(i assume you mean "support tail call optimization")
olleolleolle has left #ocaml []
<jlouis>
the only thing to be aware of is the introduction of try ... handle which may kill TCO
<bluestorm>
hm
<bluestorm>
in my opinion, it's more something like "try .. with count as a post-call action" (wich is quite natural) than a magic/strange thing
Mr_Awesome has joined #ocaml
RobertFischer has left #ocaml []
evn has joined #ocaml
filp has quit ["Bye"]
smimou has quit ["bli"]
alexyk has joined #ocaml
Mr_Awesome has quit ["aunt jemima is the devil!"]
Mr_Awesome has joined #ocaml
ikaros has quit ["segfault"]
postalchris has quit ["Leaving."]
hkBst has quit ["Konversation terminated!"]
coucou747 has quit ["bye ca veut dire tchao en anglais"]
nuncanada has joined #ocaml
alexyk has quit []
evn_ has joined #ocaml
bluestorm has quit [Read error: 113 (No route to host)]
Yoric[DT] has quit ["Ex-Chat"]
r0bby has quit [Connection timed out]
palomer has joined #ocaml
<palomer>
is it possible to get a stack trace when using lablgtk?
<tsuyoshi>
I don't see why not
yangsx has joined #ocaml
comglz has quit ["goude naille te"]
<orbitz>
why woudl stack traces depend on lablgtk?