RE: [Caml-list] Infix function composition operator
A pipeline operator is usually preferred over function composition in impure languages like OCaml and F# due to the value restriction. For example, your example would be written in F# as: x | op1 | op2 | op3 | op4 | op5 This style is very common in F#, particularly when dealing with collections. Cheers, Jon. -Original Message- From: caml-list-boun...@yquem.inria.fr [mailto:caml-list- boun...@yquem.inria.fr] On Behalf Of m...@proof-technologies.com Sent: 10 November 2010 07:00 To: ymin...@gmail.com; ar...@noblesamurai.com Cc: caml-l...@inria.fr Subject: Re: [Caml-list] Infix function composition operator on 10/11/10 3:45 AM, ymin...@gmail.com wrote: This is probably a minority opinion, but I have written and read quite a lot of OCaml code over the years, and I've seen surprisingly few effective uses of the composition operator. Somehow, I usually find that code that avoids it is simpler and easier to read. I agree that using a composition operator can make the code obtuse, and so should not be overused. But it's incredibly useful for certain situations: 1) If you are performing a long chain of composed operations, it avoids nested bracketing piling up. For example: (op5 - op4 - op3 - op2 - op1) x Instead of: op5 (op4 (op3 (op2 (op1 x This sort of thing happens quite a lot in certain applications, e.g. in language processing, to get at subexpressions. 2) Creating an anonymous function to be passed as an argument, it avoids explicitly mentioning arguments of that function. This sort of thing can happen a lot in functional programming generally. For example: List.map (op2 - op1) xs Instead of: List.map (fun x - op2 (op1 x)) xs Mark Adams ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] MLbrot: Mandelbrot Set in OCaml
Hi, On Wed, Nov 10, 2010 at 12:57:05AM +0100, Goswin von Brederlow wrote: Guessing: Ah, yes, I already did that, I found that on the Web, I did not know it was called guessing. I loop with chunks 16, 8, 4, 2 and 1. Boundary Trace: Tesseracting: Both interesting indeed! Ok, I look at them! Thanks a lot! No. I mean like xaos does. When zooming in it keeps the computed pixels and only inserts new lines or rows where there are gaps. One effect of this is that in an animation the chaotic part of the image, where color for every pixel differs to the next, doesn't just flicker. I already do that. -- Daniel de Rauglaudre http://pauillac.inria.fr/~ddr/ ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Infix function composition operator
On 11/09/2010 09:19 PM, Arlen Christian Mart Cuss wrote: Hi all, I know this was asked at least 12 years ago[1], but is there any consensus or reason for there not being a compose function in standard OCaml, nor an infix operator? At the moment I tend to let compose or let (-) f g x = f (g x), but I wish I didn't have to! Batteries[1] includes such an operator in its Std module and its extension of Pervasives. The compose operator is is '-|', and the reverse compose operator is '|-' ((f |- g) x = g (f x)). It also provides the pipeline operator '|' and its converse application operator '**'. - Michael 1. http://batteries.forge.ocamlcore.org ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Infix function composition operator
On 10 Nov 2010, at 4:45, Yaron Minsky wrote: let ( |! ) x f = f x This is the same as F#'s pipe operator (|) which I find extremely useful because with it code reads the way it works, not backwards: 2 | tenfold | add 1 | double = 42 (ok, this is a ridiculous example, but you get the point). Regards. -DS ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Infix function composition operator
So how does value restriction affect things here? (excuse my lack of knowledge) One thing about using a pipeline like this is that it relies on '|' being left-associative (which it is due to OCaml's convention on operators that start with |). Mark. on 10/11/10 12:52 PM, Jon Harrop jonathandeanhar...@googlemail.com wrote: A pipeline operator is usually preferred over function composition in impure languages like OCaml and F# due to the value restriction. For example, your example would be written in F# as: x | op1 | op2 | op3 | op4 | op5 This style is very common in F#, particularly when dealing with collections. Cheers, Jon. -Original Message- From: caml-list-boun...@yquem.inria.fr [mailto:caml-list- boun...@yquem.inria.fr] On Behalf Of m...@proof-technologies.com Sent: 10 November 2010 07:00 To: ymin...@gmail.com; ar...@noblesamurai.com Cc: caml-l...@inria.fr Subject: Re: [Caml-list] Infix function composition operator on 10/11/10 3:45 AM, ymin...@gmail.com wrote: This is probably a minority opinion, but I have written and read quite a lot of OCaml code over the years, and I've seen surprisingly few effective uses of the composition operator. Somehow, I usually find that code that avoids it is simpler and easier to read. I agree that using a composition operator can make the code obtuse, and so should not be overused. But it's incredibly useful for certain situations: 1) If you are performing a long chain of composed operations, it avoids nested bracketing piling up. For example: (op5 - op4 - op3 - op2 - op1) x Instead of: op5 (op4 (op3 (op2 (op1 x This sort of thing happens quite a lot in certain applications, e.g. in language processing, to get at subexpressions. 2) Creating an anonymous function to be passed as an argument, it avoids explicitly mentioning arguments of that function. This sort of thing can happen a lot in functional programming generally. For example: List.map (op2 - op1) xs Instead of: List.map (fun x - op2 (op1 x)) xs Mark Adams ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
RE: [Caml-list] Infix function composition operator
In OCaml, the value restriction leads to non-generalized type variables ('_a
etc.) if you try to define functions like:
# let ( ) f g x = f(g x);;
val ( ) : ('a - 'b) - ('c - 'a) - 'c - 'b = fun
# let cons h t = h::t;;
val cons : 'a - 'a list - 'a list = fun
# cons cons;;
- : '_a - ('_a list - '_a list) list - ('_a list - '_a list) list = fun
This is a silly example but you are most likely to hit this problem in practice
in the context of parser combinators. Due to JIT compilation, F# cannot relax
the value restriction so that does not even compile.
In MLs, you usually want the eta-expanded form:
# let cons2 x = (cons cons) x;;
val cons2 : 'a - ('a list - 'a list) list - ('a list - 'a list) list =
fun
But a pipeline is prettier:
# let ( | ) x f = f x;;
val ( | ) : 'a - ('a - 'b) - 'b = fun
# let cons2 x = x | cons | cons;;
val cons2 : 'a - ('a list - 'a list) list - ('a list - 'a list) list =
fun
This is one advantage of Haskell over OCaml/F#. However, I don't see it as a
useful advantage in practice because parser combinators are so tedious during
development (they require constant attention as types evolve): you want code
generation like ocamlyacc or camlp4. OCaml is a very strong contender here, of
course.
Cheers,
Jon.
-Original Message-
From: m...@proof-technologies.com [mailto:m...@proof-technologies.com]
Sent: 10 November 2010 13:44
To: jonathandeanhar...@googlemail.com; ymin...@gmail.com;
ar...@noblesamurai.com
Cc: caml-l...@inria.fr
Subject: Re: [Caml-list] Infix function composition operator
So how does value restriction affect things here? (excuse my lack of
knowledge)
One thing about using a pipeline like this is that it relies on '|'
being
left-associative (which it is due to OCaml's convention on operators
that
start with |).
Mark.
on 10/11/10 12:52 PM, Jon Harrop jonathandeanhar...@googlemail.com
wrote:
A pipeline operator is usually preferred over function composition in
impure
languages like OCaml and F# due to the value restriction. For
example,
your
example would be written in F# as:
x | op1 | op2 | op3 | op4 | op5
This style is very common in F#, particularly when dealing with
collections.
Cheers,
Jon.
-Original Message-
From: caml-list-boun...@yquem.inria.fr [mailto:caml-list-
boun...@yquem.inria.fr] On Behalf Of m...@proof-technologies.com
Sent: 10 November 2010 07:00
To: ymin...@gmail.com; ar...@noblesamurai.com
Cc: caml-l...@inria.fr
Subject: Re: [Caml-list] Infix function composition operator
on 10/11/10 3:45 AM, ymin...@gmail.com wrote:
This is probably a minority opinion, but I have written and read
quite a
lot
of OCaml code over the years, and I've seen surprisingly few
effective
uses
of the composition operator. Somehow, I usually find that code
that
avoids
it is simpler and easier to read.
I agree that using a composition operator can make the code obtuse,
and
so
should not be overused. But it's incredibly useful for certain
situations:
1) If you are performing a long chain of composed operations, it
avoids
nested bracketing piling up.
For example:
(op5 - op4 - op3 - op2 - op1) x
Instead of:
op5 (op4 (op3 (op2 (op1 x
This sort of thing happens quite a lot in certain applications, e.g.
in
language processing, to get at subexpressions.
2) Creating an anonymous function to be passed as an argument, it
avoids
explicitly mentioning arguments of that function.
This sort of thing can happen a lot in functional programming
generally.
For example:
List.map (op2 - op1) xs
Instead of:
List.map (fun x - op2 (op1 x)) xs
Mark Adams
___
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
___
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Infix function composition operator
Fascinating! I do use parser combinators myself, and find myself having to
use the eta-expanded form, like you say. Thanks for that explanation.
Mark.
on 10/11/10 2:20 PM, Jon Harrop jonathandeanhar...@googlemail.com wrote:
In OCaml, the value restriction leads to non-generalized type variables
('_a
etc.) if you try to define functions like:
# let ( ) f g x = f(g x);;
val ( ) : ('a - 'b) - ('c - 'a) - 'c - 'b = fun
# let cons h t = h::t;;
val cons : 'a - 'a list - 'a list = fun
# cons cons;;
- : '_a - ('_a list - '_a list) list - ('_a list - '_a list) list =
fun
This is a silly example but you are most likely to hit this problem in
practice in the context of parser combinators. Due to JIT compilation, F#
cannot relax the value restriction so that does not even compile.
In MLs, you usually want the eta-expanded form:
# let cons2 x = (cons cons) x;;
val cons2 : 'a - ('a list - 'a list) list - ('a list - 'a list) list =
fun
But a pipeline is prettier:
# let ( | ) x f = f x;;
val ( | ) : 'a - ('a - 'b) - 'b = fun
# let cons2 x = x | cons | cons;;
val cons2 : 'a - ('a list - 'a list) list - ('a list - 'a list) list =
fun
This is one advantage of Haskell over OCaml/F#. However, I don't see it as
a
useful advantage in practice because parser combinators are so tedious
during development (they require constant attention as types evolve): you
want code generation like ocamlyacc or camlp4. OCaml is a very strong
contender here, of course.
Cheers,
Jon.
-Original Message-
From: m...@proof-technologies.com [mailto:m...@proof-technologies.com]
Sent: 10 November 2010 13:44
To: jonathandeanhar...@googlemail.com; ymin...@gmail.com;
ar...@noblesamurai.com
Cc: caml-l...@inria.fr
Subject: Re: [Caml-list] Infix function composition operator
So how does value restriction affect things here? (excuse my lack of
knowledge)
One thing about using a pipeline like this is that it relies on '|'
being
left-associative (which it is due to OCaml's convention on operators
that
start with |).
Mark.
___
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Causes for segfaults
Would you mind posting your code to see if other people can reproduce the problem? I can post the code ( http://scattered-thoughts.net/code/texsearch-0.4/ ) but unfortunately I can't post the (large) dataset that causes the segfault. I will see if I can persuade it to blow up on a randomly generated dataset and post the code for that. ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Infix function composition operator
On Wed, Nov 10, 2010 at 14:13 -, Jon Harrop wrote: However, I don't see it as a useful advantage in practice because parser combinators are so tedious during development (they require constant attention as types evolve): you want code generation like ocamlyacc or camlp4. OCaml is a very strong contender here, of course. Could you maybe elaborate a bit on what you find tedious with regard to evolving types in the context of parser combinators? In my parser code (using FParsec in F#) most types get inferred by the compiler and in the remaining instances the type annotations can hardly be called tedious. Actually, I find the types and the Visual Studio tooltips with the inferred types rather helpful for development. - Stephan Cheers, Jon. -Original Message- From: m...@proof-technologies.com [mailto:m...@proof-technologies.com] Sent: 10 November 2010 13:44 To: jonathandeanhar...@googlemail.com; ymin...@gmail.com; ar...@noblesamurai.com Cc: caml-l...@inria.fr Subject: Re: [Caml-list] Infix function composition operator So how does value restriction affect things here? (excuse my lack of knowledge) One thing about using a pipeline like this is that it relies on '|' being left-associative (which it is due to OCaml's convention on operators that start with |). Mark. on 10/11/10 12:52 PM, Jon Harropjonathandeanhar...@googlemail.com wrote: A pipeline operator is usually preferred over function composition in impure languages like OCaml and F# due to the value restriction. For example, your example would be written in F# as: x | op1 | op2 | op3 | op4 | op5 This style is very common in F#, particularly when dealing with collections. Cheers, Jon. -Original Message- From: caml-list-boun...@yquem.inria.fr [mailto:caml-list- boun...@yquem.inria.fr] On Behalf Of m...@proof-technologies.com Sent: 10 November 2010 07:00 To: ymin...@gmail.com; ar...@noblesamurai.com Cc: caml-l...@inria.fr Subject: Re: [Caml-list] Infix function composition operator on 10/11/10 3:45 AM, ymin...@gmail.com wrote: This is probably a minority opinion, but I have written and read quite a lot of OCaml code over the years, and I've seen surprisingly few effective uses of the composition operator. Somehow, I usually find that code that avoids it is simpler and easier to read. I agree that using a composition operator can make the code obtuse, and so should not be overused. But it's incredibly useful for certain situations: 1) If you are performing a long chain of composed operations, it avoids nested bracketing piling up. For example: (op5- op4- op3- op2- op1) x Instead of: op5 (op4 (op3 (op2 (op1 x This sort of thing happens quite a lot in certain applications, e.g. in language processing, to get at subexpressions. 2) Creating an anonymous function to be passed as an argument, it avoids explicitly mentioning arguments of that function. This sort of thing can happen a lot in functional programming generally. For example: List.map (op2- op1) xs Instead of: List.map (fun x - op2 (op1 x)) xs Mark Adams ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
RE: [Caml-list] Infix function composition operator
I am currently writing a concurrent server under contract in F#. Due to the poor performance of the default .NET serialization (over 170x slower than Marshal in OCaml!), I had to completely replace the serialization layer. Ideally, I would just write a script to compile my type definitions into serializers and deserializers over them. However, I haven't found time to do that yet so I am maintaining a set of combinators instead. They account for over 15% of the source code now. Every time I change a type (e.g. adding a field to a record type), I must update the combinators to reflect the changes. This is getting seriously tedious as the project is experimental and my types need to evolve rapidly. If I were using OCaml, Marshal would be easily fast enough and I wouldn't even need to update my type definitions by hand because I could use structural typing (polymorphic variants and objects). Unfortunately, this is not yet possible in F#. Another problem area has been the incrementality of garbage collection. OCaml is good in this respect among functional languages but still orders of magnitude behind the state-of-the-art. With enough care and attention, .NET can be almost as good as OCaml is ordinarily but .NET's worse cases are horrific: http://flyingfrogblog.blogspot.com/2010/10/can-you-repro-this-64-bit-net-gc-bug.html Cheers, Jon. -Original Message- From: caml-list-boun...@yquem.inria.fr [mailto:caml-list- boun...@yquem.inria.fr] On Behalf Of Stephan Tolksdorf Sent: 10 November 2010 16:11 To: caml-l...@inria.fr Subject: Re: [Caml-list] Infix function composition operator On Wed, Nov 10, 2010 at 14:13 -, Jon Harrop wrote: However, I don't see it as a useful advantage in practice because parser combinators are so tedious during development (they require constant attention as types evolve): you want code generation like ocamlyacc or camlp4. OCaml is a very strong contender here, of course. Could you maybe elaborate a bit on what you find tedious with regard to evolving types in the context of parser combinators? In my parser code (using FParsec in F#) most types get inferred by the compiler and in the remaining instances the type annotations can hardly be called tedious. Actually, I find the types and the Visual Studio tooltips with the inferred types rather helpful for development. - Stephan Cheers, Jon. -Original Message- From: m...@proof-technologies.com [mailto:m...@proof- technologies.com] Sent: 10 November 2010 13:44 To: jonathandeanhar...@googlemail.com; ymin...@gmail.com; ar...@noblesamurai.com Cc: caml-l...@inria.fr Subject: Re: [Caml-list] Infix function composition operator So how does value restriction affect things here? (excuse my lack of knowledge) One thing about using a pipeline like this is that it relies on '|' being left-associative (which it is due to OCaml's convention on operators that start with |). Mark. on 10/11/10 12:52 PM, Jon Harropjonathandeanhar...@googlemail.com wrote: A pipeline operator is usually preferred over function composition in impure languages like OCaml and F# due to the value restriction. For example, your example would be written in F# as: x | op1 | op2 | op3 | op4 | op5 This style is very common in F#, particularly when dealing with collections. Cheers, Jon. -Original Message- From: caml-list-boun...@yquem.inria.fr [mailto:caml-list- boun...@yquem.inria.fr] On Behalf Of m...@proof-technologies.com Sent: 10 November 2010 07:00 To: ymin...@gmail.com; ar...@noblesamurai.com Cc: caml-l...@inria.fr Subject: Re: [Caml-list] Infix function composition operator on 10/11/10 3:45 AM, ymin...@gmail.com wrote: This is probably a minority opinion, but I have written and read quite a lot of OCaml code over the years, and I've seen surprisingly few effective uses of the composition operator. Somehow, I usually find that code that avoids it is simpler and easier to read. I agree that using a composition operator can make the code obtuse, and so should not be overused. But it's incredibly useful for certain situations: 1) If you are performing a long chain of composed operations, it avoids nested bracketing piling up. For example: (op5- op4- op3- op2- op1) x Instead of: op5 (op4 (op3 (op2 (op1 x This sort of thing happens quite a lot in certain applications, e.g. in language processing, to get at subexpressions. 2) Creating an anonymous function to be passed as an argument, it avoids explicitly mentioning arguments of that function. This sort of thing can happen a lot in functional programming generally. For example: List.map (op2- op1) xs Instead of: List.map (fun x - op2 (op1 x)) xs Mark Adams ___ Caml-list mailing
Re: [Caml-list] Infix function composition operator
On Wed, Nov 10, 2010 at 17:41 -, Jon Harrop wrote: I had to completely replace the serialization layer. Ideally, I would just write a script to compile my type definitions into serializers and deserializers over them. However, I haven't found time to do that yet so I am maintaining a set of combinators instead. They account for over 15% of the source code now. Every time I change a type (e.g. adding a field to a record type), I must update the combinators to reflect the changes. This is getting seriously tedious as the project is experimental and my types need to evolve rapidly. Your problem here seems to be the absence of compile-time meta-programming facilities in F#, not the limitations of parser combinators. Using a parser generator tool like ocamlyacc (which you originally cited as a better technology) wouldn't make the parsing in your situation any easier, or am I missing something? In the case of your server application you could probably replace the compile-time meta-programming with some run-time reflection code generation. If you cache serializers and deserializers per type, performance should still be good. - Stephan -Original Message- From: caml-list-boun...@yquem.inria.fr [mailto:caml-list- boun...@yquem.inria.fr] On Behalf Of Stephan Tolksdorf Sent: 10 November 2010 16:11 To: caml-l...@inria.fr Subject: Re: [Caml-list] Infix function composition operator On Wed, Nov 10, 2010 at 14:13 -, Jon Harrop wrote: However, I don't see it as a useful advantage in practice because parser combinators are so tedious during development (they require constant attention as types evolve): you want code generation like ocamlyacc or camlp4. OCaml is a very strong contender here, of course. Could you maybe elaborate a bit on what you find tedious with regard to evolving types in the context of parser combinators? In my parser code (using FParsec in F#) most types get inferred by the compiler and in the remaining instances the type annotations can hardly be called tedious. Actually, I find the types and the Visual Studio tooltips with the inferred types rather helpful for development. - Stephan Cheers, Jon. -Original Message- From: m...@proof-technologies.com [mailto:m...@proof- technologies.com] Sent: 10 November 2010 13:44 To: jonathandeanhar...@googlemail.com; ymin...@gmail.com; ar...@noblesamurai.com Cc: caml-l...@inria.fr Subject: Re: [Caml-list] Infix function composition operator So how does value restriction affect things here? (excuse my lack of knowledge) One thing about using a pipeline like this is that it relies on '|' being left-associative (which it is due to OCaml's convention on operators that start with |). Mark. on 10/11/10 12:52 PM, Jon Harropjonathandeanhar...@googlemail.com wrote: A pipeline operator is usually preferred over function composition in impure languages like OCaml and F# due to the value restriction. For example, your example would be written in F# as: x | op1 | op2 | op3 | op4 | op5 This style is very common in F#, particularly when dealing with collections. Cheers, Jon. -Original Message- From: caml-list-boun...@yquem.inria.fr [mailto:caml-list- boun...@yquem.inria.fr] On Behalf Of m...@proof-technologies.com Sent: 10 November 2010 07:00 To: ymin...@gmail.com; ar...@noblesamurai.com Cc: caml-l...@inria.fr Subject: Re: [Caml-list] Infix function composition operator on 10/11/10 3:45 AM, ymin...@gmail.com wrote: This is probably a minority opinion, but I have written and read quite a lot of OCaml code over the years, and I've seen surprisingly few effective uses of the composition operator. Somehow, I usually find that code that avoids it is simpler and easier to read. I agree that using a composition operator can make the code obtuse, and so should not be overused. But it's incredibly useful for certain situations: 1) If you are performing a long chain of composed operations, it avoids nested bracketing piling up. For example: (op5- op4- op3- op2- op1) x Instead of: op5 (op4 (op3 (op2 (op1 x This sort of thing happens quite a lot in certain applications, e.g. in language processing, to get at subexpressions. 2) Creating an anonymous function to be passed as an argument, it avoids explicitly mentioning arguments of that function. This sort of thing can happen a lot in functional programming generally. For example: List.map (op2- op1) xs Instead of: List.map (fun x - op2 (op1 x)) xs Mark Adams ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs ___ Caml-list mailing list. Subscription management:
[Caml-list] ocamlclean : an OCaml bytecode cleaner (Was: (Announce) OCAPIC : OCaml for PIC18 microcontrollers)
Dear all, Shortly: ocamlclean is now available in a separate package so that you don't have to get the whole ocapic distribution just to try ocamlclean. More information: ocamlclean takes a bytecode executable (which are generally but not necessarily produced by ocamlc compiler) and reduces its size by eliminating some dead code. Dead code is discriminated statically. (It's impossible to eliminate all dead code, but in some cases it can reduce bytecode executables tremendously) It is meant to be compatible with standard bytecode such as produced by ocamlc. (DBUG section is currently not supported and is removed during the cleaning process. Other unsupported sections are left untouched.) Web site: http://www.algo-prog.info/ocaml_for_pic/ Developer: Benoît Vaugon -- Philippe Wang http://www-apr.lip6.fr/~pwang/ ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
[Caml-list] Average cost of the OCaml GC
Hi,
What is the average cost of the OCaml GC? I have a program that calls
'mark_slice' in 57% of the total execution time, and calls
'sweep_slice' in 21% of the total time, reported by Callgrind, which
is a profiling tool in Valgrind. 57% and 21% are the 'self cost' ---
the cost of the function itself ('Self Cost'), rather than the cost
including all called functions ('Inclusive Cost'). I guess
'mark_slice' and 'sweep_slice' are functions from OCaml GC. Are
these numbers normal?
My program calls both OCaml and C, which passes around C data types in
between. I also doubt if I defined the interface in an 'unefficient'
way that slows down the GC. Are there any rules in mind to make GC
work more efficiently?
Thanks.
--
Jianzhou
___
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] ocamlclean : an OCaml bytecode cleaner (Was: (Announce) OCAPIC : OCaml for PIC18 microcontrollers)
Hello, 2010/11/11 Philippe Wang philippe.w...@lip6.fr Shortly: ocamlclean is now available in a separate package so that you don't have to get the whole ocapic distribution just to try ocamlclean. More information: ocamlclean takes a bytecode executable (which are generally but not necessarily produced by ocamlc compiler) and reduces its size by eliminating some dead code. Dead code is discriminated statically. (It's impossible to eliminate all dead code, but in some cases it can reduce bytecode executables tremendously) It is meant to be compatible with standard bytecode such as produced by ocamlc. (DBUG section is currently not supported and is removed during the cleaning process. Other unsupported sections are left untouched.) Is ocamlclean compatible with dynamic loading? That is code potentially used by some unknown dynamically-loaded code must be kept. -- Julien ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
