descender has quit ["Why has elegance found so little following? Elegance has the disadvantage that hard work is needed to achieve it and a good e]
pango has quit [Remote closed the connection]
danly has quit ["Leaving"]
bmiller has quit [" "]
Mr_Awesome has joined #ocaml
sponge45 has joined #ocaml
pango_ has quit [Remote closed the connection]
pango_ has joined #ocaml
danly has joined #ocaml
Mr_Awesome has quit ["...and the Awesome level drops"]
fab_ has joined #ocaml
_fab has quit [Read error: 110 (Connection timed out)]
shawn has quit ["This computer has gone to sleep"]
mbishop has joined #ocaml
danly has quit [Remote closed the connection]
joshcryer has quit [Read error: 104 (Connection reset by peer)]
joshcryer has joined #ocaml
postalchris has quit [Read error: 113 (No route to host)]
sponge45 has quit ["zzzzzzzzzz"]
pango_ has quit [Remote closed the connection]
Smerdyakov has quit ["Leaving"]
yondalf has joined #ocaml
shawn has joined #ocaml
dark_light has quit [No route to host]
mbishop has quit [orwell.freenode.net irc.freenode.net]
Oatmeat|umn has quit [orwell.freenode.net irc.freenode.net]
jdev has quit [orwell.freenode.net irc.freenode.net]
eradman_ has quit [orwell.freenode.net irc.freenode.net]
batdog has quit [orwell.freenode.net irc.freenode.net]
mbishop has joined #ocaml
eradman_ has joined #ocaml
batdog has joined #ocaml
Oatmeat|umn has joined #ocaml
sponge45 has joined #ocaml
jdev has joined #ocaml
ikaros has quit [Read error: 110 (Connection timed out)]
ikaros has joined #ocaml
yondalf_ has joined #ocaml
yondalf_ has quit ["leaving"]
pango_ has joined #ocaml
yondalf has quit [Read error: 110 (Connection timed out)]
yondalf has joined #ocaml
jajs has joined #ocaml
llama32 has joined #ocaml
<llama32>
is there any reason i can't [practically] use a scheme/lisp-like type system on top of ocaml [or other members of the ml family?] using pattern matching? like if everything handles a type that's Int of int | String of string | List of mytype list | Function of (mytype list -> mytype) | ...? [i don't plan on using this in normal programs - im just wondering if lisp can be translated to ml]
<pango_>
well, that's basically what dynamically typed environments do internally (+ some amount of implicit coersions)
<llama32>
ml is great :)
yondalf has quit [Read error: 110 (Connection timed out)]
<llama32>
honestly, i don't know how people get by in Java, or worse still C, C++ and Objective C
<llama32>
hmm, interestingt
yondalf has joined #ocaml
<llama32>
type taco = Soup of int | Kebab of string;; <-- here, would "Soup 4" be represented in memory as a pointer to a pair [of machine-word-sized ints?] - the first element being say 0 for Soup or 1 for Kebab, the second being the 4 [or a pointer to a string] - or is this optimized?
<pango_>
optimized, how ?
<pango_>
there's some documentation on internal representation, on the same page as closures internal representation
<llama32>
well [this will be slower, but denser in memory] e.g. if you have only Soup or Kebab, this could be a bit at the end of the data - so 1010010101 = a Kebab, but 1010010100 = a Soup... this obviously wouldn't work when you have many more options, but many lisps and other dynamic languages do this
<llama32>
in fact apparently ocaml itself does this [sometimes?] to determine an immediate value [int, etc.] from a pointer for the garbage collection [but obviously not the type system]
<pango_>
both polymorphism and the garbage collector enforce some "uniformity" on data representation
<pango_>
so not every trick in data representation can be done without requiring much more complex (hence slow) algorithms to handle them
<pango_>
current representation is not that bad, before learning OCaml I wrote a Perl client for http://www.grenouille.com/ (a broadband tester are reporter), and the OCaml client used something like 4 times less memory ;)
<pango_>
s/tester are/tester and/
* llama32
wonders how java manages to eat up so much RAM
* llama32
also wonders why it eats up much more RAM on linux than on windows
sponge45 has quit ["zzzzzzzzzz"]
<pango_>
OCaml uses 1 bit tag to tell apart small enumerable values (ints, chars,...) from pointers... that's why ints are 31 bits on 32bits archs, or 63 bits on 64 bits archs...
yondalf has quit [Read error: 110 (Connection timed out)]
eradman_ has quit [orwell.freenode.net irc.freenode.net]
Oatmeat|umn has quit [orwell.freenode.net irc.freenode.net]
mbishop has quit [orwell.freenode.net irc.freenode.net]
batdog has quit [orwell.freenode.net irc.freenode.net]
mbishop has joined #ocaml
eradman_ has joined #ocaml
batdog has joined #ocaml
Oatmeat|umn has joined #ocaml
<pango_>
I think that's for Gc convenience, and that the "OCaml program" itself could very well work without such tag, relying only on static typing
pango_ has quit ["brb"]
<llama32>
pango_ smells [hehe, he'll never know]
eradman_ has quit [orwell.freenode.net irc.freenode.net]
Oatmeat|umn has quit [orwell.freenode.net irc.freenode.net]
mbishop has quit [orwell.freenode.net irc.freenode.net]
batdog has quit [orwell.freenode.net irc.freenode.net]
ppsmimou has quit [orwell.freenode.net irc.freenode.net]
jdev has quit [orwell.freenode.net irc.freenode.net]
fab_ has quit [orwell.freenode.net irc.freenode.net]
jacobian_ has quit [orwell.freenode.net irc.freenode.net]
triple_ has quit [orwell.freenode.net irc.freenode.net]
levi_home has quit [orwell.freenode.net irc.freenode.net]
DRMacIver has quit [orwell.freenode.net irc.freenode.net]
Oatmeat|umn has joined #ocaml
batdog has joined #ocaml
eradman_ has joined #ocaml
mbishop has joined #ocaml
jdev has joined #ocaml
fab_ has joined #ocaml
jacobian_ has joined #ocaml
triple_ has joined #ocaml
DRMacIver has joined #ocaml
levi_home has joined #ocaml
pango has joined #ocaml
ppsmimou has joined #ocaml
<llama32>
pango: do you still have that link handy? to the internal representations stuff? i've checked my history and browsed the caml website & google, but can't seem to find it
<cypher23>
pango, how would that work with static typing only?
Morphous has joined #ocaml
<pango>
how would that not work with static typing only ? types are known at compile time
<cypher23>
true. sorry, I was still in Ruby Mode
<pango>
and I think type is enough to tell whether internal representation will be a direct value or a pointer
Amorphous has quit [Read error: 110 (Connection timed out)]
dibblego has quit ["Leaving"]
Demitar has quit ["Ex-Chat"]
Demitar has joined #ocaml
jajs has quit [Read error: 54 (Connection reset by peer)]
jajs has joined #ocaml
Demitar_ has joined #ocaml
Demitar has quit [Read error: 104 (Connection reset by peer)]
fab_ has quit []
<llama32>
anyone know of a fairly efficient standard ml compiler that produces dynamically linked native executables [and allows libraries to be dynamically loaded at runtime]?
bluestorm has joined #ocaml
<zmdkrbou>
llama32: mlton is an efficient sml compiler (but i don't know about dyn. linked executables and so on)
<llama32>
afaik mlton is whole-program optimizing [which implies static linking]
<zmdkrbou>
dunno
<llama32>
hmm and it appears that SML/NJ is image-oriented [which would, i imagine, also imply static linking]
slipstream has joined #ocaml
Skal has quit [Remote closed the connection]
slipstream-- has quit [Read error: 110 (Connection timed out)]
llama33 has joined #ocaml
llama32 has quit [Read error: 110 (Connection timed out)]
yondalf has joined #ocaml
_fab has joined #ocaml
jajs has quit [Remote closed the connection]
descender has joined #ocaml
yondalf has quit [Remote closed the connection]
jajs has joined #ocaml
yondalf has joined #ocaml
b00t has joined #ocaml
yondalf_ has joined #ocaml
yondalf has quit [Connection timed out]
b00t has quit [Remote closed the connection]
yondalf_ has quit ["leaving"]
swater has joined #ocaml
batdog is now known as batdog|gone
Leonidas has joined #ocaml
swater has quit [Read error: 54 (Connection reset by peer)]
malc_ has joined #ocaml
llama33 has quit [Read error: 110 (Connection timed out)]
TaXules has quit [Remote closed the connection]
TaXules has joined #ocaml
Demitar has joined #ocaml
cmeme has quit [Excess Flood]
cmeme has joined #ocaml
swater has joined #ocaml
Smerdyakov has joined #ocaml
swater has quit [Remote closed the connection]
llama33 has joined #ocaml
pauldia has joined #ocaml
Smerdyakov has quit ["BBL"]
mpc has joined #ocaml
mpc has quit [Remote closed the connection]
mpc has joined #ocaml
Yorick has joined #ocaml
<llama33>
in what cases is partial application actually useful?
<llama33>
printf looks like an interesting example, but it's properties seem only to be a side-effect of strict typing
<Yorick>
llama33: it's quite often useful, if you mean partial application in general
<Yorick>
llama33: But I believe - other people may disagree - that the implicit partial application by specifying too few arguments to a function is only rarely so.
<llama33>
hmm
gunark has quit [orwell.freenode.net irc.freenode.net]
gunark has joined #ocaml
* llama33
just realised printf doesn't really seem to be a matter of partial evaluation, just similar to it in effect
<Yorick>
yes, printf is slightly magic.
<llama33>
yes it seems a bit complicated :s
* llama33
is wondering if partial evaluation is a feature worth putting in the lisp+ml-like language that currently exists only in his head
<Yorick>
It's much a question of syntax
<Yorick>
more so than semantics, actually.
* llama33
's imaginary language has multiple syntaxes, using lisp more as an intermediate representation
<Yorick>
lisp syntax (f a b c) allows variadic functions and also clearly marks what are the arguments to the function.
<Yorick>
In ocaml, if you see f a b c, you don't really know how many arguments are sent to f.
<llama33>
yeah, i have trouble understanding things like func1 a func2 b + c
<llama33>
it just doesn't clearly seperate anything
<Yorick>
ocaml does get some benefit from this, but it is clearly a trade-off - none is clearly superior in all ways
<llama33>
at least ocaml lets you write code looking pretty much like lisp anyway
<Yorick>
True, and the type checker will usually let you know what is wrong, although the errors can be cryptical.
<Yorick>
If you pass arguments as tuples instead, then both the syntax and semantics are more like other languages: f(a, b, c)
pauld has joined #ocaml
<mellum>
Yorick: it's unidiomatic, though, and much less efficient
<Yorick>
mellum: Really? Why?
<Yorick>
unidiomatic I know, but I don't see why there would be any difference in efficiency.
<pango>
less efficient for bytecode, because it (de)constructs the tuples
<Yorick>
of course, for a naive compiler. But there is no reason it could be made equally fast.
<Yorick>
s/could/could not/
<pango>
native compiler does the optimization
<Yorick>
And so it should.
<mellum>
Yorick: there is in fact no reason. It just doesn't happen for Ocaml.
<mellum>
And doing so would break compatibility, so it's not likely to happen.
<Yorick>
mellum: Exactly what would break compatibility?
<mellum>
Yorick: changing the argument passing conventions.
<Yorick>
mellum: Yes and no. As pango said, it already works well in this regard so there is no need to change.
<Yorick>
mellum: Also, it's only an ABI question - internal linkage can change any time.
<mellum>
Oh well, then the point that it is unidiomatic remains :)
<Yorick>
mellum: Certainly, but we, the users, decide what idiom we want to follow.
<bluestorm>
Yorick:
<bluestorm>
tuples are not as beautiful
<bluestorm>
you can't see the closure ^^
<bluestorm>
((f a b) c) is like (f a b c), you can't do the same with f(a,b,c)
<Yorick>
bluestorm: Where is the beauty?
<Yorick>
bluestorm: That you can't see how many arguments you are actually passing to the function?
<bluestorm>
Yorick: hum
<bluestorm>
if you want to see it, just add ( ) around
<bluestorm>
(f a b c) is pretty clear
<bluestorm>
but Yorick, you can pass any number of arguments you want (from 0 to the maximum number of arguments)
<bluestorm>
Yorick: this syntax is beautiful because it fit very well with the idea of closure
<bluestorm>
whereas the tuple syntax doesn't
<bluestorm>
if you don't like closures, you may prefer the tuple syntax. But i think closure are beautiful, and so this syntax looks nice
<Yorick>
bluestorm: I'm not sure what kind of closure you mean. Lexical variable closure is only distantly related.
<bluestorm>
hm
<bluestorm>
(i may use the wrong word for that)
<Yorick>
bluestorm: And no, you can't get variadic functions that way - each function is, by its type, defined to take a certain fixed number of argument that way.
<bluestorm>
let add2 = (+) 2 in
<zmdkrbou>
bluestorm: if you're thinking of all the stuff that goes with the function (environment etc.) then it's the right word
<bluestorm>
hm
<bluestorm>
Yorick: hm
<bluestorm>
it seems me the "->" notation for functional types show that it's transitive
<bluestorm>
if you have f : 'a -> 'b -> 'c
<zmdkrbou>
having functions as objects and not having partial evaluation seems stupid to me
<bluestorm>
f a is 'b -> 'c
<bluestorm>
and f a b is 'c
<Yorick>
bluestorm: You cannot define a function f, that when called (f a b) detects it has been called with those two arguments.
<bluestorm>
hm
<bluestorm>
what do you mean ?
<Yorick>
bluestorm: How do you count the number of arguments that a function has been passed? You cannot, unless you encapsulate them in some sort of data structure.
<bluestorm>
hm
<bluestorm>
but why should i detect it ?
<bluestorm>
the compiler know it for me
<bluestorm>
knows
<Yorick>
bluestorm: A variadic function is one that can accept a variable number of arguments. You can't do it that way.
<zmdkrbou>
Yorick: the problem is : you don't want variadic functions
<zmdkrbou>
at least in ml
<Yorick>
zmdkrbou: Please don't tell me what I want. Maybe you don't.
<bluestorm>
hm
<zmdkrbou>
when i use "you" i don't mean you in particular
<Yorick>
zmdkrbou: Then don't address me with "you" if you don't mean me.
<bluestorm>
ok, i just understood ^^
<bluestorm>
Yorick:
<zmdkrbou>
but variadic functions doesn't exist in lambda calculus afaik
<bluestorm>
can't you write f[a;b;c] ?
<Yorick>
zmdkrbou: Nor do functions that take more than one argument - but ML have those anyway.
<zmdkrbou>
Yorick: you can encode them
<zmdkrbou>
i don't think you can encode variadic functions
<Yorick>
bluestorm: Of course - that's a fair way of doing it.
<Yorick>
zmdkrbou: bluestorm just showed you how.
<bluestorm>
hm
<zmdkrbou>
Yorick: then a b and c have the same type .......
<zmdkrbou>
what a feature ! variadic functions (only for same type of arguments)
<bluestorm>
hm
<Yorick>
zmdkrbou: Right, so it is a limitation, unless you have some kind of subtyping system.
<bluestorm>
zmdkrbou:
<bluestorm>
hm, i see
<Yorick>
The ML convention of function application by juxtaposition is neat but perhaps the cost is greater than the benefits of doing so.
<zmdkrbou>
Yorick: i don't know what is the relationship beetwen subtyping and ML ... something with subtyping is maybe "out of ML", and if you want to do this out of ML, then you do what pleases you ...
<Yorick>
zmdkrbou: I'm not sure what you mean by that. ocaml already supports subtyping in some limited places, and it's perfectly possible to design an ML-like language with subtyping.
<zmdkrbou>
and which would allow full variadic functions ?
<Yorick>
zmdkrbou: That depends on what we mean by "ML-like".
<Yorick>
You could well argue that anything that is different from what ML does isn't ML-like, and then of course, only ML is ML-like.
<zmdkrbou>
dunno precisely ... lambda calculus with a sound type system i would say
<Yorick>
Syntax also matters. If I see "f a b c" in ML, I don't know how many arguments f really takes or is sent.
<zmdkrbou>
why should you care about that ?
<zmdkrbou>
if f has 3 arguments, then f a b is a perfectly valid function of one argument, that's all
<Yorick>
zmdkrbou: As a reader of the code, of course I care.
<zmdkrbou>
then there's no debate : you don't want partial evaluation in a language, while i do want it because i find it useful (and natural)
<Yorick>
zmdkrbou: I think we are talking about different things. I very much like partial evaluation and occasionally find it useful - but not often enough for it to merit a special syntax that makes the much more common case less practical.
<Yorick>
The common case is to call a function with all its arguments. Currying is _much_ less common.
<zmdkrbou>
depends on the coding style
<zmdkrbou>
having an uncurryfied call syntax is strange when you have higher-order functions, imo
<Yorick>
zmdkrbou: Why? Lots of languages do that perfectly well.
<zmdkrbou>
because let f x y = fun z -> bla is a function of 3 arguments, but if you wrote it like this, then you probably want it to be applied on 2 arguments first
<zmdkrbou>
i mean a function which returns a function should be partially applied
<Yorick>
zmdkrbou: Why? To make it harder to get proper diagnostics from the compiler?
<zmdkrbou>
because if g is the result of the partial application of f, you may want to use g later in the code
<zmdkrbou>
not at the same instant than f
<Yorick>
What's more elegant with (f a b c) compared to ((f a b) c) where in the latter case you see exactly what is going on
<Yorick>
Nothing prevents you from doing partial function application - it's just a matter of syntax.
<zmdkrbou>
it's perfectly equivalent to me ....
<Yorick>
zmdkrbou: How can you tell how many arguments f takes if you see a call to it as (f a b c)?
<Yorick>
You don't know - it could be 3, or 2 or 5 or anything else.
<Yorick>
So you don't know if the call is correct, which arguments go to f and which go somewhere else.
<zmdkrbou>
when i write functional code, i don't care about the arguments count of f
<zmdkrbou>
(and i have a look at the signature of a function before using it)
<Yorick>
The compiler cares, and will complain if you don't follow its rules.
<zmdkrbou>
if you don't give enough arguments, for example, then you'll have a type error
<Yorick>
Really? What type error, and where?
<zmdkrbou>
and when the compiler says "this is bla -> int while it should be int", it's not difficult to see the problem ...
pauldia has quit [Read error: 145 (Connection timed out)]
<bluestorm>
Yorick:
<bluestorm>
i think your code can support it
<Yorick>
zmdkrbou: You are making up excuses. Typically, the error message is both harder to decrypt _and_ indicating a source position not near the actual problem
<bluestorm>
i mean, the name of your values must show what's still a function and what isn't
<zmdkrbou>
for this example (calling a function with not enough arguments), i think the position and error message is ok
<zmdkrbou>
# let f x y = x + y ;;
<zmdkrbou>
val f : int -> int -> int = <fun>
<zmdkrbou>
# 2 + (f 3) ;;
<zmdkrbou>
This expression has type int -> int but is here used with type int
<zmdkrbou>
(with (f 3) underlined)
<zmdkrbou>
i would say : perfect.
<Yorick>
zmdkrbou: You are picking a way too easy example,.
<Yorick>
zmdkrbou: It's in the very complex cases that the problem shows up.
<zmdkrbou>
1/ if you're in the case of partial application, you can't escape the tricky part 2/ if you're calling the function with all arguments, it won't be more complicated than looking at the "wrong type" error : if there's an arrow, then you forgot an argument
<Yorick>
zmdkrbou: And no, your example is not perfect - it doesn't even say what the problem is.
<zmdkrbou>
the problem is that it doesn't have the right type :D
<zmdkrbou>
i mean it
<zmdkrbou>
it cannot be in the brain of the programmer and say "hey, this is not what you're program seems to be supposed to do man !"
<Yorick>
zmdkrbou: Exactly, because the language does not allow the programmer to tell the compiler what he wants to do.
<zmdkrbou>
hehe, you believe in the perfect language ? :)
<Yorick>
zmdkrbou: In your case, the programmer's problem was not a type error - that is the compiler's problem.
<zmdkrbou>
the programmer's problem is *NEVER* a type error
<zmdkrbou>
types are a way to express programmers problems
<Yorick>
zmdkrbou: A C compiler, for instance, would give a much better error message, saying right out that there is an argument missing.
<zmdkrbou>
C has low-level semantics ...
<cypher23>
Yorick, but that's only because C doesn't allow functions to be passed as arguments
malc_ has left #ocaml []
<Yorick>
cypher23: Nonsense. It's just a question of syntax. C allowes function arguments.
<mellum>
well, C does allow that. Only it does not allow currying.
<cypher23>
no, it allows passing a pointer to a function, which is a bit different
<Yorick>
cypher23: the only difference is that it doesn't have lexical closures, and that is not relevant to the discussion.
raspberry-lemon has joined #ocaml
<zmdkrbou>
you get much fewer error messages in C ...
<zmdkrbou>
but you get segfaults :p
<Yorick>
zmdkrbou: I used C only as an example of syntax that would allow a compiler to handle this case more gracefully. Of course C has lots of other problems.
<zmdkrbou>
i don't think it's a good example : to have the right error message, it is sufficient to force full application
<Yorick>
zmdkrbou: Can you rephrase that? I didn't quite understand.
<zmdkrbou>
i mean that you gave an example which of course shows how to get the "right" error message in this situation
<zmdkrbou>
because it's so simple
<cypher23>
Yorick, the difference is that C sees that you wanted to call a function with not enough arguments because it doesn't allow passing a (curried) function as an argument. in ocaml that is valid, as long as the types/signatures match
<zmdkrbou>
but this is trading a feature for a one-situation-error-message
<Yorick>
zmdkrbou: It's a very common situation, giving the wrong number of arguments to a function. Even more common is reading code and trying to understand it.
<cypher23>
For the C compiler this means that it knows exactly what you did wrong (not enough arguments), the ocaml compiler can't know it
<Yorick>
cypher23: Exactly. Syntactic currying considered harmful :)
<zmdkrbou>
it's such a common situation that you get to know instantly when the "int -> int instead of int"-like error messages mean "wrong number of arguments" ...
<Yorick>
Look, i like ML a lot and try to use it when I can, but I refuse making excuses for it when I see things that I consider worse than other languages. I'm not married to ML.
<zmdkrbou>
i don't care about your opinion of ML .....
<zmdkrbou>
i juste give my own :p
<zmdkrbou>
(so ok, let's keep our opinions and everything is fine)
<Yorick>
zmdkrbou: Of course. I'm not trying to reprogram you :)
<bluestorm>
Yorick:
<bluestorm>
what about labels ? ^^
<bluestorm>
ok, they can't do anything for the argument number, but they help you to strongly specifiy the meaning of each argument
<bluestorm>
so it's easier to know what's missing
<Yorick>
sorry, have to rush - cinema time :)
<Yorick>
nice talking to you. bye!
Yorick has quit ["Leaving"]
<cypher23>
oh, nice. google code search now supports ocaml as well (and a few more other languages as well)
Skal has joined #ocaml
llama33 has quit [Read error: 60 (Operation timed out)]
jajs has quit [Remote closed the connection]
_JusSx_ has quit [Client Quit]
cmeme has quit [Connection reset by peer]
cmeme has joined #ocaml
cmeme has quit [Read error: 131 (Connection reset by peer)]
cmeme has joined #ocaml
Skal has quit [Read error: 54 (Connection reset by peer)]
sponge45 has joined #ocaml
setog3 has joined #ocaml
<setog3>
hi
<sponge45>
hi
<setog3>
in ocaml in a rec function.. in a match how can I do action (modify some type) and return a liste ?
<sponge45>
I don't understand...
<setog3>
how can I for example print something, but don't return type unit, return a liste for example
<sponge45>
print_endline "something"; [1;2;3]
<sponge45>
It's all in the semicolon
revision17_ has quit [Read error: 104 (Connection reset by peer)]
<setog3>
yes thx
Smerdyakov has joined #ocaml
datrus has joined #ocaml
<datrus>
hello
<datrus>
does anyone know the name of a function to split a string into a list of substrings?
<datrus>
like python's string.split
<cypher23>
String.split?
<bluestorm>
Str modules does have that
<datrus>
ok, i found it
<bluestorm>
hm
<datrus>
do you mwan Str.split?
<datrus>
i was looking into String module
<bluestorm>
hm
<bluestorm>
i don't think String.split exists
<cypher23>
yes, it's Str.split. sorry
dibblego has joined #ocaml
descender has quit ["Why has elegance found so little following? Elegance has the disadvantage that hard work is needed to achieve it and a good e]