From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id GAA09859; Sat, 31 Jan 2004 06:26:24 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id GAA09452 for ; Sat, 31 Jan 2004 06:26:22 +0100 (MET) Received: from herd.plethora.net (herd.plethora.net [205.166.146.1]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id i0V5QLP21911 for ; Sat, 31 Jan 2004 06:26:21 +0100 (MET) Received: from bhurt.plethora.net (bhurt.plethora.net [205.166.146.49]) by herd.plethora.net (8.11.6/8.10.1) with ESMTP id i0V5Q3Z09400; Fri, 30 Jan 2004 23:26:06 -0600 (CST) Date: Sat, 31 Jan 2004 00:29:25 -0600 (CST) From: Brian Hurt X-X-Sender: bhurt@localhost.localdomain To: skaller cc: Martin Berger , The Trade Subject: Re: [Caml-list] ocaml and concurrency In-Reply-To: <1075495504.23595.64.camel@localhost.localdomain> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 2004:99 theorist:01 theorist:01 currying:01 foo:01 ignoring:01 foo:01 uncurried:01 faked:01 haskell:01 state-:99 'g':01 abstraction:01 ocaml:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On 31 Jan 2004, skaller wrote: > On Fri, 2004-01-30 at 17:52, Brian Hurt wrote: > > On Fri, 30 Jan 2004, Martin Berger wrote: > > > > > > Perhaps because you're a type theorist? > > > > > > being a type theorist has many disadvantages ... > > > > > > > C not only *does* have function types, it has > > > > first class function values just like ML does. > > > > > > well, i'm not so sure about this for two reasons. > > > > Technically, he's correct. What C doesn't have is partial function > > application, > > If by that you mean currying .. well, of course C has that. > If a function returns a function which returns a function > you can curry exactly like in ML :-) Yuck. Yes, I suppose you could do that- but I say again, yuck. A simple function, which in Ocaml would have the type int -> int -> int ->int, would have the C prototype: ((int (*)(int)) (*)(int)) foo(int); Something reasonably, but not unheard of, complicated, like say: ('a -> 'b -> 'c) -> 'a array -> 'b array -> 'c array would be (ignoring the type safety issue): (((void **) (*)(void **))(*)(void **))foo(void * (*)(void *) (*)(void *)); That's like something out of a submission to the IOCCC. Not that the uncurried version is that much better: void ** foo(void * (*)(void *, void *), void **, void **); > > > which makes having functional types much less worthwhile- > > it's impossible for a function type to also contain state. > > Almost, but not quite true: > > int f(int x) { > static int y = x; > y = y + x; > return x; > } > > clearly does contain state.. the function isn't > re-entrant though (which means merely not > thread safe here since it manifestly isn't recursive). It's not only not re-entrant, it doesn't do what my example does. Here, I can have only one sum ever. My example allows to me have multiple different sums simultaneously- and adding to one doesn't add to the others. The C++ example kicking around that uses objects is more correct. Which is one way to do it in C- fake objects, and then used the faked objects to fake partial application. > > However it is true in Haskell and any purely > functional Ocaml code .. they really cannot contain > any state :-) No, even then they can contain state, they just can't change it. But it can be different from one partial application to another. A purely functional example: let logb base x = (log x)/.(log base);; let log10 = logb 10.;; let log2 = logb 2.;; let logn = logb (exp 1.);; Here I have three different functions- but all of them contain functional state- the base of logarithms I'm working in. > > Indeed, one can go further and say that ML functions > are a lie: if you consider: > > let f x = > let g y = y + x in g > in > let g1 = f 1 > and g2 = f 2 > > then the two g's are distinction functions, they're > NOT the 'g' defined in f, which in fact is NOT > a function at all, merely an abstraction (of course > g1 and g2 are functions .. :) f has a type int -> int -> int here, so f 1 has the type int -> int. Looks like a function to me. The question is: what is a function? -- "Usenet is like a herd of performing elephants with diarrhea -- massive, difficult to redirect, awe-inspiring, entertaining, and a source of mind-boggling amounts of excrement when you least expect it." - Gene Spafford Brian ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners