[Caml-list] Commercial Users of Functional Programming - Call For Presentations Reminder

[Grundy, Jim D]

Dear Fellow Camlers

Many of you use OCaml for commercial and open source applications, and as such 
you represent a vast repository of experience regarding the application and 
acceptance of functional programming in real-world.  I'd like to urge you to 
consider sharing it at the upcoming Commercial Users of Functional Programming 
workshop.

Kind regards

Jim Grundy


  Commercial Users of Functional Programming Workshop (CUFP) 2009



   Functional Programming As a Means, Not an End



   Call for Presentations



Sponsored by SIGPLAN

 Co-located with ICFP 2009



   Edinburgh, Scotland, 4 September 2009

 _



   Presentation proposals due 15 May 2009



   http://cufp.galois.com/2009/call.html

 _



   Functional languages have been under academic development for

   over 25 years, and remain fertile ground for programming

   language research. Recently, however, developers in industrial,

   governmental, and open-source projects have begun to use

   functional programming successfully in practical applications.

   In these settings, functional programming has often provided

   dramatic leverage, including whole new ways of thinking about

   the original problem.



   The goal of the CUFP workshop is to act as a voice for these

   users of functional programming. The workshop supports the

   increasing viability of functional programming in the

   commercial, governmental, and open-source space by providing a

   forum for professionals to share their experiences and ideas,

   whether those ideas are related to business, management, or

   engineering. The workshop is also designed to enable the

   formation and reinforcement of relationships that further the

   commercial use of functional programming. Providing user

   feedback to language designers and implementors is not a

   primary goal of the workshop, though it will be welcome if it

   occurs.



Speaking at CUFP



   If you use functional programming as a means, rather than as

   an end, we invite you to offer to give a talk at the workshop.

   Alternatively, if you know someone who would give a good talk,

   please nominate them!



   Talks are typically 25 minutes long, but can be shorter. They

   aim to inform participants about how functional programming

   played out in real-world applications, focusing especially on

   the re-usable lessons learned, or insights gained. Your talk

   does not need to be highly technical; for this audience,

   reflections on the commercial, management, or software

   engineering aspects are, if anything, more important. You do

   not need to submit a paper! Talks on the practical application

   of functional programming with a primarily technical focus may

   also be appropriate for the adjacent DEFUN 2009 event.



   If you are interested in offering a talk, or nominating someone

   to do so, send an e-mail to francesco(at)erlang-consulting(dot)com

   or  jim(dot)d(dot)grundy(at)intel(dot)com by 15 May 2009 with a

   short description of what you'd like to talk about or what you

   think your nominee should give a talk about. Such descriptions

   should be about one page long.



Program Plans



   CUFP 2009 will last a full day and feature a keynote presentation

   from Bryan O'Sullivan, co-author of Real World Haskell. The program

   will also include a mix of presentations and discussion sessions.

   Topics will range over a wide area, including:

 * Case studies of successful and unsuccessful uses of

   functional programming;

 * Business opportunities and risks from using functional languages;

 * Enablers for functional language use in a commercial setting;

 * Barriers to the adoption of functional languages, and

 * Mitigation strategies for overcoming limitations of

   functional programming.



   There will be no published proceedings, as the meeting is intended

   to be more a discussion forum than a technical interchange.



   This will be the sixth CUFP, for more information - including

   reports from attendees of previous events and video of recent

   talks - see the workshop web site: http://cufp.galois.com/

 _


___
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] Extending modules and signatures

[Ashish Agarwal]

> I think the real issue is inheritance.
Yes. Your example adds an extra complication by using references. Forgoing
that, I get around this within the current module system by defining a base
module B, which two other modules C an D "inherit", i.e. they just include
B. Module B has the common values and types needed by C and D. Only problem
with this is that I am forced to expose all the values and types in B to all
client code. It would help to restrict B's visibility to just C and D. No
big deal for internally used libraries; I just remember not to use B
elsewhere. However, it is not a good solution for libraries distributed to
others.


On Sun, Apr 19, 2009 at 8:06 PM, Martin Jambon
wrote:

> Ashish Agarwal wrote:
> >> The module type exists, it's just that it doesn't have a name.
> >
> > Right, thanks for the clarification.
> >
> >
> >> let x = (123, "abc")
> >> does not define "type x = int * string" either.
> >
> > True, but I think the expectations are different for module types. A
> > file a.ml  creates a module named A, and it seems natural
> > to expect a.mli to create a module type A. I find it inconsistent that
> > it does not.
> >
> > Further, if you wanted to name the above type, it is easy, just write
> > "type x = int * string". The corresponding solution to naming module
> > types is burdensome. You have to define it within another module,
> > introducing an unnecessary layer into your module hierarchy. Also that
> > doesn't help you when using somebody else's library.
> >
> > Having the compiler introduce module type names automatically from mli
> > files would be very helpful, and I don't see any disadvantages.
>
> OK, but I think the real issue is inheritance.  In order to truly extend an
> existing module, one needs to access the private items of the inherited
> module
> implementation.  In order to avoid messing up with the original module's
> global variables, the inherited "module" should be more like a functor that
> would create a fresh instance of the module each time it is instantiated,
> just
> like classes generate objects.
>
>
> I could imagine something like this:
>
> module class A :
> sig
>  val get_x : unit -> int
> end =
> struct
>  let x = ref 123
>  let get_x () = !x
> end
>
> module class B =
> struct
>  inherit A
>  let incr_x () = incr x
> end
>
> module B1 = new module B
> module B2 = new module B
> ;;
>
> B1.incr_x ();;
> - : unit = ()
> B1.get_x ();;
> - : int = 124
> B2.get_x ();;
> - : int = 123
>
>
> Module class implementations and signatures could be conveniently created
> as
> whole files using new file extensions, say .mc and .mci.  These would be
> like
> .ml files except that they would support module class inheritance and would
> be
> evaluated only when they are instantiated with "new module".
>
>
>
>
> Martin
>
> --
> http://mjambon.com/
>
___
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] Parallelized parsing

[Jon Harrop]

On Tuesday 21 April 2009 08:19:33 you wrote:
> On Mon, Apr 20, 2009 at 23:15, Jon Harrop  wrote:
> > For example, Mathematica syntax for nested lists of integers looks like:
> >
> >  {{{1, 2}}, {{3, 4}, {4, 5}}, ..}
> >
> > and there are obvious divide-and-conquer approaches to lexing and parsing
> > that grammar. You can recursively subdivide the string (e.g. memory
> > mapped from a file) to build a tree of where the tokens { , and } appear
> > by index and then recursively convert the tree into an AST.
> >
> > What other grammars can be lexed and/or parsed efficiently in parallel?
>
> Is it of any use? The overhead of parsing a single file in parallel is
> so high that you won't have any speedup, especially compared to the
> much simpler approach of parsing *several* files in parallel.

I'm seeing near-linear speedups parsing nested Mathematica lists in F# using 
the algorithms I described. Moreover, dumping large quantities of data from 
Mathematica in that format is much easier than dividing it into separate 
files because there is no clear break in the tree.

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e

___
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] Parallelized parsing

[Jon Harrop]

On Tuesday 21 April 2009 01:52:40 Yitzhak Mandelbaum wrote:
> Some good places to start are here:
> ...

Wow! Thanks for the link fest. :-)

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e

___
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] Polymorphism problem

[Mauricio Fernandez]

On Mon, Apr 20, 2009 at 09:44:54PM -0400, Eliot Handelman wrote:
> Consider this:
> 
> type 'a x = { x_v : 'a }
> 
> and 'a y = { y_x : int kind;
>  y_arr : 'a array
> }
> and 'a kind =
> X of 'a x
>   | Y of 'a y
> 
> 
> I'd like to write a function _getter_ that's polymorphic over kind. This
> doesn't work, getting int kind -> int:
> 
> let rec getter = function
> X x -> x.x_v
>   | Y y -> y.y_arr.(getter y.y_x)
>
> which seems surprising to me since getter y.y_x is an intermediate
> value that's never returned. Is this just a limitation of the type system or
> does this result make sense?

The above function requires polymorphic recursion, which OCaml doesn't support
directly. There are several ways to encode it, though, one involving recursive
modules and another rank-2 polymorphism:

# module rec M : sig val getter : 'a kind -> 'a end = struct
  let getter = function
X x -> x.x_v
  | Y y -> y.y_arr.(M.getter y.y_x)
  end;;
module rec M : sig val getter : 'a kind -> 'a end
# M.getter;;
- : 'a kind -> 'a = 

# type get = { get : 'a. 'a kind -> 'a };;
type get = { get : 'a. 'a kind -> 'a; }
# let rec get = { get = function X x -> x.x_v | Y y -> y.y_arr.(get.get y.y_x) 
};;
val get : get = {get = }
# let getter = get.get;;
val getter : 'a kind -> 'a = 

-- 
Mauricio Fernandez  -   http://eigenclass.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] Parallelized parsing

[David MENTRE]

Hello Jon,

On Mon, Apr 20, 2009 at 23:15, Jon Harrop  wrote:
> For example, Mathematica syntax for nested lists of integers looks like:
>
>  {{{1, 2}}, {{3, 4}, {4, 5}}, ..}
>
> and there are obvious divide-and-conquer approaches to lexing and parsing that
> grammar. You can recursively subdivide the string (e.g. memory mapped from a
> file) to build a tree of where the tokens { , and } appear by index and then
> recursively convert the tree into an AST.
>
> What other grammars can be lexed and/or parsed efficiently in parallel?

Is it of any use? The overhead of parsing a single file in parallel is
so high that you won't have any speedup, especially compared to the
much simpler approach of parsing *several* files in parallel.

It reminds me of parallel approaches used for 3D movies: a lot of
research has been done to parallelize the rendering of a single
picture[1] while companies like Pixar are using a much simpler
approach in real life: render a whole picture per computer or core.

And don't forget the Amdahl's law :
  http://en.wikipedia.org/wiki/Amdahl%27s_law
Where is your real bottleneck?

Yours,
david

[1] Hopefully, some of those algorithms have brought speedup in
serialized setting, i.e. on a single core or computer, for example by
optimizing cache use.

___
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