sponge45 changed the topic of #ocaml to: Discussions about the OCaml programming language | http://caml.inria.fr/
pango has joined #ocaml
smimou has quit ["bli"]
b00t has joined #ocaml
love-pingoo has quit ["Connection reset by pear"]
lmbdwr_ has joined #ocaml
lmbdwr has quit [Read error: 110 (Connection timed out)]
lmbdwr_ has quit [Read error: 110 (Connection timed out)]
romanoffi has joined #ocaml
danly has quit [Read error: 110 (Connection timed out)]
smimp has joined #ocaml
smimp has quit ["leaving"]
smimp has joined #ocaml
smimp has quit [Client Quit]
lmbdwr has joined #ocaml
mbishop has quit [Remote closed the connection]
ikaros has quit [Read error: 110 (Connection timed out)]
ikaros has joined #ocaml
stevan_ has joined #ocaml
Ringo47 has joined #ocaml
stevan has quit [Read error: 113 (No route to host)]
danly has joined #ocaml
bzzbzz has quit ["leaving"]
romanoffi has left #ocaml []
delamon has joined #ocaml
stevan__ has joined #ocaml
stevan_ has quit [Read error: 113 (No route to host)]
slowriot has quit []
pango has quit [Remote closed the connection]
mbishop has joined #ocaml
jlouis has quit ["Leaving"]
_velco has joined #ocaml
petchema has joined #ocaml
petchema is now known as pango
pango has quit [Client Quit]
Ringo47 has left #ocaml []
slipstream-- has joined #ocaml
slipstream has quit [Read error: 110 (Connection timed out)]
Mr_Awesome has quit ["and the Awesome Level drops"]
love-pingoo has joined #ocaml
velco has joined #ocaml
love-pingoo has quit ["Connection reset by pear"]
delamon has quit [Read error: 110 (Connection timed out)]
ppsmimou has joined #ocaml
asmanian has joined #ocaml
lmbdwr_ has joined #ocaml
lmbdwr has quit [Read error: 110 (Connection timed out)]
bebui_ is now known as julien
lmbdwr_ is now known as lmbdwr
love-pingoo has joined #ocaml
lmbdwr has quit [Read error: 104 (Connection reset by peer)]
lmbdwr has joined #ocaml
johnnowak has quit []
zmdkrbou has quit [Read error: 104 (Connection reset by peer)]
ikaros has quit [Remote closed the connection]
ikaros has joined #ocaml
b00t has quit [Client Quit]
metaperl has quit [Client Quit]
eradman has joined #ocaml
ikaros has quit ["Leaving"]
ikaros has joined #ocaml
ikaros has quit [Client Quit]
slipstream has joined #ocaml
slipstream-- has quit [Read error: 110 (Connection timed out)]
mpc has quit []
Smirnov has joined #ocaml
<Smirnov>
how to get ocaml to beta reduce functions without side effects at compile time?
<Smirnov>
like say using templates and specializations in C++?
<haelix>
Smirnov: Can you describe what you have in mind in C++
<haelix>
I'll do my best at translating in Ocaml
<haelix>
but
<haelix>
off hand
mpc has joined #ocaml
<haelix>
Ocaml is not too gifted for compile time manipulations (camlp4 (a syntax-tree level preprocessor) or metaocaml ("multistage compilation extension for ocaml) might be the way to go)
<velco>
oh, I haven't noticed this, lemme take a look.
<haelix>
velco: basically, that's parsing a string of 1 and 0 as a binary number, and computing int int value at compile time
<velco>
why must one use integer template parameter, instead of ordinary function parameter >?
<Smirnov>
actually from the compiler point of view its a unsigned long ;)
<haelix>
velco: beacuse that way
<Smirnov>
velco: i am not an expert in C++, i got this from a book about template metaprogramming
<haelix>
the computation is made by the c++ typing system
<haelix>
(implicit template instantiation)
<velco>
yes, and otherwise it would be does by the compiler optimizer, so ?
<velco>
s/does/done/
<haelix>
and that will ensure the result is available before the program is run
<haelix>
yes
<haelix>
you'd have to make foolish expectation on the optimiser behavior
<Smirnov>
hehe
<velco>
not at all
<velco>
becausde the meaning of the program does not change.
<mattam>
it's just constant propagation
<velco>
yes
<haelix>
that I do not disagree with
<haelix>
what I mean by "foolish" is "unreliable"
<mattam>
but there are more complicated examples where C++ templates hackery don't correspond to anything in ocaml
<haelix>
will ocamlopt optimise the computation away ?
<velco>
there;s nothing in the OCaml languagem which prevents it.
<mattam>
well, if the function applied is also inlined that may be the case
<haelix>
evrything is in the "may"
<mattam>
indeed
<velco>
why are you sure the C++ implementation does it at compile time ?
<mattam>
it does not do textual replacement as c++ does everytime
<velco>
it's exaclty tha unreliable.
<haelix>
no it's not :)
<haelix>
basically,
<velco>
why are you assuming at all there's C++ compiler and not C++ interpretet ?
<mattam>
c++ templates are not much more than intelligent macros, so camlp4 could easily emulate them
<haelix>
velco: something like "the standard requires that all programs underwent a thorough checking of their types,
<velco>
there's no real need, becauseML is polymorphic
<haelix>
tra la la
<haelix>
template instantiation
<haelix>
I'm bored enough to read through the 1000+ pages, thoug )
<mattam>
yep, and specialization is left to the compiler :)
<velco>
what compiler?
<mattam>
ocamlopt
<velco>
you said certain optimization were unrealiable and you still assume a compiler ?
<mattam>
i said that ?
<velco>
not you )
<haelix>
velco: this is not an optimisation, per se
<velco>
isn;t it unreliable to assume a compiler ?
<haelix>
it is rather leveraging the (complex) C++ type system
<haelix>
to have it perform computations at compile time
<velco>
i.e. just as unreliable as to assume random dumbness of implementatios ?
<velco>
no,
<velco>
it performs "computations at compile time" after instantiation.
<velco>
i.e.
<velco>
it works on plain, non-polymorphic funcsions.
<velco>
well, mostly.
<haelix>
who is "it" ?
<velco>
well, certain template parameters mayb be constant folded during instantiation.
<velco>
the compiler.
<velco>
but I suppose this is not the interesting casem right ?
<haelix>
well
<velco>
but rather the interesting case is compile-time computations performed on template bodies, right ?
<haelix>
I don't know what you mean by non polymorphic functions
<haelix>
but the key things in C++ compile time arithmetic
smimp has joined #ocaml
<haelix>
is that an integer can be a compile time type parameter
<haelix>
C++ won't do much on template bodies themselves
<haelix>
template metaprogramming is rather clumsy and limited, if you ask me
<velco>
what?
<haelix>
more over, implementations are slow and takes up gigabytes to perform simple things
<velco>
granted.
<velco>
becase instantiation results in monomorphic functions.
<velco>
which I was trying to explain to Smirnov before.
<haelix>
sorry, I didn't mean to stop you from explaining
<velco>
besides, template instantiation does not deserve to be called "metaprogramming", as it is extremely limited form of manipulating programs.
<velco>
haelix: I was refering to a talk in another channel.
<haelix>
whily you're at it... would you mind to explain, evne briefly, what (poly|mono)morphic functions are ?
<haelix>
ok
<haelix>
I'm not in the club :)
<velco>
polymorphic function is one, which can have parameters of many types.
<velco>
classic example: list length function.
<velco>
it can compute list length no matter what are the types of the elements of the list.
<velco>
which in ML is a polymorphic functions, in C++ are N template instantiations.
<Smirnov>
the standard requires templates to be done at compile time, it also requires constant expressions of constants to be evaluated at compile time
<velco>
(granted C++ allows certain forms of polymorphism based on sub-typing)
<Smirnov>
haelix: hes just talking about 'a, 'b, etc
<velco>
heh
<velco>
Smirnov: yes, 'a 'b which is typename A, typename B in C++ :)
mpc has quit []
<Smirnov>
sure if you want
<velco>
Smirnov: wrt. constants in template parameters
<velco>
Smirnov: consider a ML type, where certain 'a , 'b designate types, which have only one element - certain constant
<Smirnov>
wrt?
<velco>
Smirnov: you can replace any expression of these types, with the one and only member of the type, i..e the said constant
<Smirnov>
you can, but thats not going to help you to statically evaluate the expression
<velco>
Smirnov: and you could remove the types from the type definition
<Smirnov>
whereas in C++ burying a constant value in a type, *would* let you get that value at compile time
<velco>
Smirnov: partial evaluation is left to the compiler, I'm talking about expresive power of the type systems.
<Smirnov>
but i already know that. i implemented type unification before, type inferencing is nothing new to me
<velco>
thus, we have established that it's only syntactic sugar to have non-type template parameters.
<velco>
by describing a mechanoc procedure for eliminating them.
<Smirnov>
semantically the evaluation happens at *COMPILE* time not RUN time
<haelix>
no subclassing relation between A, B, list<A> and list<B>
<haelix>
actually
<velco>
haelix: now write that in ocaml.
<haelix>
length would work with any time with an "int size()" method
<Smirnov>
no problem let length x = List.size x
<velco>
haelix: and you will see that in ocaml yuo have one function, whereas in C++ you have two instantiations.
<haelix>
you're delving into implementation considerations, here
<haelix>
who knows what ocamlopt will do under the hood ?
<haelix>
besides
<velco>
i.e. in ML you wil have one polymorphic function, in C++ you will have two monoymorphic functions
<haelix>
C++ compilers are allowed (and even encouraged :)
<haelix>
to factor out similar code
<haelix>
(similar at the assembly level)
<Smirnov>
really, i dont remember ML spec to say you are required to have 1 polymorphic function
<velco>
haelix: from the C++ standard it *follows* there are two instantiations.
<haelix>
the whole "instantion" thing you say C++ is plagued with is a specification model
<haelix>
from an implementor point of view, though
<velco>
Smirnov: do you remmeber C++ standard saying the compiler is required not to insert empty loops in the code at random places ?
<haelix>
(and to feed the troll a bit more)
<haelix>
C++ will have a harder time factoring the generated instantiation together, given that there's leeway to provide alternate implementaion of length
<haelix>
(specialisations)
<haelix>
whereas, in Ocaml... sorry you're out of luck
<velco>
what?
<velco>
what prevents the compiler from doin partial evaluation ?
<haelix>
now, give me in ocaml a length function that works equally well for strings and lists:
<haelix>
obviously here, you need to have two implementaions (at the machine code level)
<velco>
haelix: you mix polymorphism with identifier obverloading.
<haelix>
well
<haelix>
I lack identifier overloading in ocaml
<haelix>
s/lack/miss/
<mattam>
you certainly do
<velco>
haelix: why must I use the same names for list and string length ?
<haelix>
you don't have too
<velco>
this strikes me as a rather arbitrary requirement.
<haelix>
ok
<Smirnov>
thats to determine which one to use statically
<velco>
so your example in ML would still look like one polymorphic functions and another string function.
<haelix>
let's forget about overloading
<velco>
mind you, you *wrote* the stirng function by youself
<Smirnov>
what is this whole argument about again, we already established the answer to my original question?
<haelix>
Well
<haelix>
it's about the repsective merits of Ocaml and C++
<velco>
Smirnov: the whole argument was me noting that C++ has a patricularly stupid way to implementa parametric polymorphism.
* haelix
caught trollin
<velco>
Smirnov: rather
<Smirnov>
that doesnt strike me as a particularly useful argument
<velco>
it was me wondering
<mattam>
well, it's simply adhoc, not parametric :)
<velco>
why are you so exceted by C++ "metaprogramming"
<Smirnov>
the only thing i miss in ocaml is overloading
<Smirnov>
ok, its cause you can evaluate a boatload of expressions statically
<velco>
mattam: well, templates can be though of as parametric types
<mattam>
they're not exciting in this case...
<Smirnov>
dunno, i havent seen much of static evaluation before so
lmbdwr has quit [Read error: 110 (Connection timed out)]
<haelix>
Speaking of metaprogramming:
lmbdwr has joined #ocaml
<haelix>
I only have a misty idea of how lisp does metaprogramming
<haelix>
how does metaocaml metaprogramming compares to it ?
<velco>
well, speaking of C++ type system is sort of moot, since its only informally described.
* Smirnov
has been lisp-deprived :(
<flux->
smirnov, I think most of the cases when in c++ you use metaprogramming to evaluate constants at compile time is not because of performance, but because of the fact that consts can be used in more places than non-consts, in c++
<Smirnov>
every language should have 'match' ;)
<flux->
but, I too miss the lack of overloading in ocaml
<haelix>
and the fact that adding an external tool in the buildchain that would spare us the harrass of template computations is bothersome, too
<flux->
it sometimes makes me wonder what good is type inference, if I need to spell out 'String.length' and String.that all over the code
<velco>
don't you always know what types you have ?
<velco>
hmm, apparently not.
<flux->
I do
<flux->
and I need to tell that to the compiler
<flux->
again and again..
<haelix>
noone here to enlighten us on the reason why this is not Hindley-Milner friendly ?
<flux->
I cannot just 'open' the module, because of String.length List.length
<flux->
(+and)
<velco>
yeah
<Smirnov>
why cant you just do "foo".length anyways
<Smirnov>
it can already tell its a string!
<velco>
can't you "rename" the modules, similar to Haskell ``import qualified Data.List as L"
<flux->
yes
<flux->
and locally too
<flux->
which is nice
<flux->
let module L = List in ..
<flux->
and I do that time to time
<flux->
but some cases of 'do some arithmetic with a custom data type' can produce quite verbose code
<flux->
A.div (A.add (A.sub a b) c)
<velco>
bug Xavier Leroy to to impement typeclases
<velco>
:)
<flux->
:-)
<flux->
there was actually an ocaml-fork that allowed 'generic' functions
<mattam>
what's the type of "let size = length" if length is overloaded ?
<flux->
the name escapes me..
<flux->
someone must remember? it provides one answer for that question.
<hcarty>
flux-: Creating a new operator could be handy too, in that case
<flux->
hcarty, true
<hcarty>
flux-: GCaml, perhaps? It's on the wikipedia page...
<flux->
yes, GCaml
<flux->
and I've used that too. a nice way of doing that is to define a separate module that defines the operators, so the code can either 'open' it or not
<hcarty>
I'm still in the learning stages with OCaml, and every 100 lines of code or so flip between loving and hating it :-)
<flux->
it makes me feel the same, still: 'why do I need to tell the compiler I'm summing two floats together'
<mattam>
that's the only thing you need to tell him, ever
<mattam>
tell it even
<velco>
as opposed to litering the code with thousands of type annotations.
<flux->
yes, it's a tradeoff, which can be sitestepped with some type systems
<velco>
I find `a +. b'' easier than ``float a, b; a + b''
<flux->
dunno
<flux->
you need to write the definition only once
<flux->
whereas in each step you will be telling again the types of the operands
<hcarty>
OCaml does have the benefit of never (as far as I know) losing precision (float to int) accidentally
<flux->
the types of subexpressions will be 'inferred' even in c
<velco>
no.
<flux->
yeah, I don't miss the implicit type conversions, atleast not to that direction
<velco>
the types of the whole expression will be inferred from the types of the subexpressions in C
<velco>
not the types of the subexpressions.
<velco>
it works only "bottom-op" in C/C++/etc
<velco>
bottom-up
<flux->
I don't think we're in disagreement there
<love-pingoo>
when I work mostly on floats I define let (+) a b = a +. b
<love-pingoo>
see you
love-pingoo has quit ["Leaving"]
<flux->
there's also the pa_openin, which would allow open FloatArith in a + b
<flux->
(assuming you first write the module)
<flux->
too bad tuareg's auto-indentation breaks with it :-)
<hcarty>
That could allow for some confusion - redefine (+) and (+.) to switch them around
<flux->
well, you are expected to be slightly aware atleast of the types of the bindings, I don't think the open would be confusing
<flux->
(especially in the context of my example: maybe if you used the mechanism for a larger piece of code)
<flux->
camlp4-tutorial had an example of a new keyword FLOAT, which allowed let a = FLOAT 5.0 + 4.0
<Smirnov>
how would u do type x = Bool of bool | Int of int;; in C++ and then match if it was a Bool or Int?
<flux->
with an union_
<flux->
?
<flux->
or do you mean if there was a match-keyword in c++?
<Smirnov>
well, i want to do a match, there is no match with unions
<flux->
there is no match in c++, period.
<velco>
Smirnov: struct s { int tag; union { int x; float y; } };
<Smirnov>
yes... so how would i do the equivalent
<flux->
whathesai
<flux->
d
<velco>
Smirnov: switch (p->tag_ { ... }
<Smirnov>
velco: thats what i thought, seems hackish
<velco>
Smirnov: this is how its under the hood in ML too :)
<Smirnov>
yeah but i dig the sugar
<velco>
(AFAIK)
<haelix>
Smirnov: better use an enum for tag
<haelix>
that way, you get warnings (with gcc) for missing case in switches
<Smirnov>
ok
<Smirnov>
thats not so bad i suppose
<Smirnov>
any idea how you would do that in C#?
<haelix>
huh
<haelix>
with an inheritance hierarchy, I suppose :)
<Smirnov>
nooooooo :-\
<haelix>
(I like c#, from what I've seen and done with it, it's perhaps the best C ever made, but on this particular bit, I have no clue)
<Smirnov>
dang i need to write an interpreter in C# and the last one i wrote was in ocaml and used a loooot of matches ;)
<Smirnov>
except you would need to make all the FieldOffset a different size and put an enum first
<Smirnov>
hm, C# unions cant contain any reference types? that sucks, how are you supposed to do type x = MyTuple of (string * int list * bool)
<Smirnov>
the good news is, CLS-compliant types are guaranteed to have a byte size
<Smirnov>
i guess you could do a switch on the type of an object at runtime, but that seems..uh..slow
mpc has joined #ocaml
<smimp>
i'm trying to learn the language, whats a good path to go.. i've been reading through practical ocaml, but it seems to assume some familiarity with the language that i don't have
<smimp>
i don't care
<smimp>
eek.. wrong window.. sry
<smimp>
about the i don't care
<haelix>
smimp: if you have some afmiliarity with C