RE: [Caml-list] F#

RE: [Caml-list] F#

[Don Syme]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2330 bytes --]

And I'm even more grateful to Xavier and the team for doing such a great job with OCaml over the years, and for providing a solid core language, an excellent runtime system and the very interesting set of langauge features they've added to the core.  Core Caml provides a great starting point for work of all kinds: I used it in my PhD thesis, for example, as the term language for a theorem prover.
 
I chose to implement a core Caml compiler for .NET partly to test out generics, but also because I want to be able to program against .NET libraries using the language I love to program in, and reuse the libraries and techniques I've developed.  I guess it's possible I'll get a bit of flak from the Caml community about F#.  Being at Microsoft Research I presume I'll be writing a fair bit of .NET code sooner or late, and personally I'd rather do that in Caml/F# than C#... I hope the Caml community won't mind me making that opportunity available to others via the public release of F#.
 
Cheers,
Don
 

	-----Original Message----- 
	From: Xavier Leroy [mailto:xavier.leroy@inria.fr] 
	Sent: Sat 08.06.2002 18:01 
	To: Vincent Foley 
	Cc: OCaml Mailing list 
	Subject: Re: [Caml-list] F#
	
	

	> http://research.microsoft.com/projects/ilx/fsharp.htm
	>
	> F# is a .NET language based on the core of OCaml.  It can use the .NET
	> libraries and interact with C#.  What do you guys think?
	
	I think that Don Syme and his Microsoft Cambridge colleagues did a
	great job with adding parametric polymorphism to the .NET framework --
	something that was initially overlooked in .NET --, and I'm very happy
	that they chose core Caml to demonstrate this extension in action.
	
	By the way, for those of you who are in the Paris area: Don Syme will
	give a talk on F# at INRIA Rocquencourt on the morning of June 14th,
	and everyone is welcome to attend.  E-mail me privately for more info.
	
	- Xavier Leroy
	-------------------
	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
	

N‹§²æìr¸›zf¢•Æ¦–X¬¶·ª¹ë-ŠzâiúÀ­Èb½ë!¶Ú\x7fýƦ–)뉧ë\x06è+zš+¶Èm¶Ÿÿq©¥Šzâiúÿn)ÿq©¥nè,\x14\x04!¶Ú\x7fýƦ–)뉧ëüP\x10ü\x17 ŠyÞ®Éb²Øm¶Ÿÿ‚º.¦Ìš†Š\x1c¢o஋©þ‡\x1ašVÞ‚)çz»

O'Caml, JVM, and .NET (was Re: [Caml-list] F#)

[Brian Smith]

I have looked over the archives and I have seen there has been a fair 
amount of discussion on compiling O'Caml to JVM bytecode or the .NET 
intermediate language. The primary advantage cited seems to be reuse of 
.NET and J2SE/J2EE libraries. People have said that compiling O'Caml to 
JVM/.NET is difficult because of mismatches in the .NET/JVM object model 
and the O'Caml object model.

But, would it be easier to reuse Java libraries by:
   * extending the O'Caml runtime to be able to interpret JVM bytecodes
     (i.e. be able to dynamically link to *.class and *.jar files), or
   * cross-compiling JVM bytecode into O'Caml bytecode, or
   * compiling Java source code into O'Caml bytecode

Similar questions apply for .NET, of course.

I would like to do more programming in O'Caml but it is sometimes 
difficult to choose O'Caml over Java when there are _so_ many libraries 
available for Java, with more added seemingly every day.

Thanks,
Brian

Don Syme wrote:
 > I chose to implement a core Caml compiler for .NET partly to test out
 > generics, but also because I want to be able to program against .NET
 > libraries using the language I love to program in, and reuse the
 > libraries and techniques I've developed.  I guess it's possible I'll
 > get a bit of flak from the Caml community about F#.

-------------------
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

Re: [Caml-list] F#

[skaller]

On Thu, 2007-03-08 at 12:54 -0500, Brian Hurt wrote:
> Roland Zumkeller wrote:
> 
> > Wasn't there a more or less good reason for OCaml *not* to support
> > operator overloading?
> >
> Yes.  Ocaml has modules and functors.  IMHO, any time you thing "boy, 
> it'd be really nice to use operator overloading here", you should use a 
> module and a functor instead.

Unfortunately you often cant do that easily:

* functors don't scale to separate compilation

* separate compilation doesn't support inter-unit recursion

* functors have a huge book-keeping overhead
(I mean syntactic overhead, not performance overhead)

* functors are hard to combine

The first two issues are implementation problems rather than
intrinsic to the language in the abstract.

The book-keeping problem is a consequence of the fine grained
control functors provide, compared with say Haskell typeclasses.

The combination problem is best characterized by an expert.

A lot of the time you want a data functor, not a module
functor, and higher order data functors (functorial
polymorphism) aren't available in Ocaml.

For example if you have some container you just want
to fold over it, which means you want a polyadic fold.
Module functors help *define* a fold which is polymorphic
over signature arguments, but don't provide polyadic usage.

Although the mechanism used in C++ is unsound, C++ 
does provide polyadic programming, and in that sense
is way ahead of Ocaml and Haskell. Despite the unsoundness,
generics in C++ usually 'just work anyhow'.

However .. and Harrop "interactive" crowd note .. functors
do provide one advantage. Because of the mandatory
book-keeping they're amenable to use of a Form based GUI/IDE
to assist in definition:

	Functor Hashtbl
	key		| <instantiating type here>
	compare         | < defn here>
	hash            | <defn here>


[That's supposed to be a form where the signature is listed in
a column format, and the programmer just fills in the
definitions]

I would probably hate that BUT it would sure help noobs learn
to use first order functors.

In fact you could use a little cheat .. and call them 
static classes, and tell people it's an Ocaml kind of OO .. 
(Haskell does this little cheat .. it makes typeclasses
very easy to explain to OO people).


-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] F#

[Brian Hurt]

Roland Zumkeller wrote:

> Wasn't there a more or less good reason for OCaml *not* to support
> operator overloading?
>
Yes.  Ocaml has modules and functors.  IMHO, any time you thing "boy, 
it'd be really nice to use operator overloading here", you should use a 
module and a functor instead.

I have a long post on this topic comming soon, but for now:
1) Functors state up front what operators need to be provided to the 
code.  This is less of a problem with purely numeric code, but I've yet 
to see a language that allowed operator overloading and then exercised 
the restraint and kept them only on numeric types.  At which point, 
having it stated in the .mli file what operators are needed, and having 
it checked that you're actually providing them, is nice.

2) Functors allow for more flexible semantics as to what operations need 
to be provided, so operations that aren't obviously operators can be 
required as well- for example, Newton's method likes having an "equals 
within epsilon" function, or norm operation, neither of which are really 
operators.

3) Functors allow for more types- for example, if you're doing Newton's 
method on complex numbers, the type of an epsilon, or the type of a 
norm, is not a complex number, but instead just a real.  Or if you're 
doing Newton's method on vectors, the type of the derivitive is a 
matrix.  These are easy to express this with functors, hard to do with 
operator overloading.

4) Functors make it easier to swap in alternate implementations of 
various operations.  For example, doing Newton's method on vectors, you 
end up needing to calculate b/A, where A is a matrix and b a vector.  
This is easy enough to translate as solving Ax=b, you standard linear 
system.  It's nice to be able to switch out which linear system solver 
you want to use with functors, rather harder with operator overloading.

Brian

Re: [Caml-list] F#

[Roland Zumkeller]

Wasn't there a more or less good reason for OCaml *not* to support
operator overloading?

-- 
http://www.lix.polytechnique.fr/~zumkeller/

Re: [Caml-list] F#

[Jon Harrop]

On Thursday 08 March 2007 14:41, Robert Fischer wrote:
> > However, operator overloading (i.e. overloading symbols) makes numerical
> > code so much easier to read that it is worth sacrificing some inference
> > for it.
>
> Unless, of course, you like to know what it is you're actually doing.

As overloads are statically resolved in F#, you just hover the mouse to find 
out which overload is being used. So you know immediately what the code is 
actually doing.

> I highly suggest checking out the Programmer-to-Programmer book on C# and
> their conversation about operator overloading.  They do a nice job
> documenting just why it's such a dangerous tool in the toolbox.

Well, I've spent the past few months writing F# code full time and I can 
definitely say that this aspect of F# is better. Of course, you'll have to 
read F# for Scientists to find out why. ;-)

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

RE: [Caml-list] F#

[Robert Fischer]

> However, operator overloading (i.e. overloading symbols) makes numerical code 
> so much easier to read that it is worth sacrificing some inference for it.
>

Unless, of course, you like to know what it is you're actually doing.

It's bad enough trying to figure out what "+" means in an overloaded environment with nominal typing.  With duck typing, it's a mess, and it's a mess that both you and the compiler have to work hard to figure out.

I highly suggest checking out the Programmer-to-Programmer book on C# and their conversation about operator overloading.  They do a nice job documenting just why it's such a dangerous tool in the toolbox.

~~ Robert.

Re: [Caml-list] F#

[Jon Harrop]

On Thursday 08 March 2007 02:12, Erik de Castro Lopo wrote:
> I'm mainly a Linux guy so the chances of me getting up close and personal
> with F# are exactly zero :-).

Actually the F# compiler and tools are freely available and run under Mono (on 
Linux). I've had a little play with C# from Mono and was really impressed, 
but I haven't tried F# from Mono yet.

> However, I am interested in hearing about 
> the differences between F# and Ocaml wrt operator overloading. Care to
> clue me (and everyone else) in?

I can try. Basically, overloading is very popular in languages like C++ and 
C#. Programmers even overload functions and constructors in those languages.

General overloading doesn't sit well with type inference because the code no 
longer conveys a sufficient amount of type information to resolve the 
overload and infer all of the types. So general overloading is bad for type 
inferred languages like F# and .NET APIs that use overloading make for uglier 
F# code that uses them.

However, operator overloading (i.e. overloading symbols) makes numerical code 
so much easier to read that it is worth sacrificing some inference for it.

The arithmetic operators default to int:

> let add a b = a + b;;
val add : int -> int -> int

So you keep OCaml compatibility. But the operators can be applied to floats:

> 1.1 + 2.2;;
val it : float = 3.3

SML provides the same capability up to this point but F# allows the 
overloading to be extended. It already works for vectors:

> let a = vector [1.; 2.; 3.] and b = vector [2.; 3.; 4.];;
val a : vector
val b : vector
> a + b;;
val it : vector = [3.; 5.; 7.]

and you can even extend it to work on your own types by augmenting the type 
constructor with static member functions:

> type expr =
    | Int of int
    | Add of expr * expr
    | Mul of expr * expr with
    static member ( + ) (f, g) = Add(f, g)
    static member ( * ) (f, g) = Mul(f, g)
  end;;

Then you can even use + to add symbolic expressions:

> Int 3 + Int 4;;
val it : expr = Int 3 + Int 4

However, the operator must always be statically resolved, so the code is 
always fast because it doesn't incur run-time dispatch.

That's the basic idea. There are some subtlties, like is the type of 
+ 'a->'a->'a or 'a->'b->'c?

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

RE: [Caml-list] F#

[Don Syme]

[ Chris - I've moved this to the F# discussion list, bcc'd to caml-list.
I don't want to clog caml-list with F#-specific discussions.... :-) ]

> >F# programs compiled for V1 of the CLR use the type "object" for all 
> >values of variable (i.e. 'a) type.  This is simple erasure.
> 
> Huh.  I must not understand the issues, because I thought it was
harder 
> than this.  If you can just make 'a into objects, why were people 
> complaining that it's hard to make it work?  (Xavier called your work
a 
> tour de force, and I thought I'd learn something by trying to
understand 
> why.  But, I'm a relative beginner, and the research papers dive in
deep 
> pretty quick.  :)

Compiling to object works for ML because it has no runtime type
information, but you run into problems like those described in the last
email.  It is also less efficient in some circumstances than direct
support for PP in a virtual machine (an array of objects is more
expensive than an array of integers for example). 

Hence we have been adding support for PP directly to the CLR and the
intermediary language of the CLR.   It was this work Xavier was
referring to.  See http://research.microsoft.com/projects/clrgen for an
overview.  

> Also, what are the dlls that are installed?  When you say "compiled
for V1 
> of the CLR", does that mean you have a bytecode file that will run
anywhere 
> (like Java), or does it need the extension dlls to be installed?

There are a couple of small runtime DLLs.  These would need to be
installed in the same directory as your application if using F# for
server-side programming, or as part of your downloaded code if writing
client-side.  If I were to do web-site stuff with F# I would focus on
writing computational code in F# and using front-end builders in C# or
VB.  But I'll admit I haven't tried this out and it obviously depends on
your app.  You may be able to do the whole lot in F# if there isn't much
on the front end.  I'll give it a go and add a sample to the
distribution...

> Requiring people to install dlls is not quite as nice, but 
> still might be better than rewriting my app in java.

You would just have to make the DLLs part of your app, i.e. take a copy
of them and stuff them in the same directory as your .EXE.  The client
doesn't have to register them as a different package.  But please the
currently licence says you can only redistribute the DLLs for
non-commercial purposes - there may be flexibility in this if needed. 

I'd like to get rid of the DLLs to make this a little cleaner, and do
away with the legal hassles as well.  The DLLs only contain little type
definitions (pairs, tuples, lists, "ref", etc.) which get shared across
interoperating applications.   But if you are just writing small
applications then the types may as well get statically linked into your
application code, as you don't care about cross-language working in this
situation.  Static linking still offers a sensible deployment model,
especially when the "bulk" of the libraries (i.e. the .NET libraries)
get shared.

Cheers,
Don

-------------------
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

Re: [Caml-list] F#

[Michael Vanier]

My mail reader can't make any sense of this.  Anyone care to tell me what
it is?

Mike

> Date: Sun, 9 Jun 2002 05:26:56 -0700
> From: "Don Syme" <dsyme@microsoft.com>
> 
> DQo+IEkgd2FzIHVuZGVyIHRoZSBpbXByZXNzaW9uIHRoYXQgdGhlIENMUiBhcyBpdCdzIGN1cnJl
> bnRseSBzaGlwcGVkIGNvdWxkIG5vdA0KPiBkbyBwYXJhbWV0cmljIHBvbHltb3JwaGlzbS4gIFtY
> YXZpZXIncyBwb3N0IGZyb20gbGFzdCB5ZWFyIGxpc3Rpbmcgd2hhdA0KPiBpc24ndCBzdXBwb3J0
> ZWQgaXMgaGVyZTogIGh0dHA6Ly9jYW1sLmlucmlhLmZyL2FyY2hpdmVzLzIwMDEwMi9tc2cwMDE5
> MC5odG1sXQ0KDQpGIyBwcm9ncmFtcyBjb21waWxlZCBmb3IgVjEgb2YgdGhlIENMUiB1c2UgdGhl
> IHR5cGUgIm9iamVjdCIgZm9yIGFsbCB2YWx1ZXMgb2YgdmFyaWFibGUgKGkuZS4gJ2EpIHR5cGUu
> ICBUaGlzIGlzIHNpbXBsZSBlcmFzdXJlLiAgSXQgaXMgYW4gT0sgd2F5IHRvIGltcGxlbWVudCBQ
> UCAoaXQncyBob3cgR0ogZG9lcyBpdCkgLSB0aGVyZSBhcmUgYSBmZXcgcHJvYmxlbXMsIGUuZy4g
> dHlwZSBkaXN0aW5jdGlvbnMgZ2V0IGxvc3QgaW4gdGhlIElMIHNvIGludGVyb3AgaXMgbm90IHF1
> aXRlIGhvdyB5b3UgbWlnaHQgd2FudCBpdCwgYW5kIGl0J3Mgbm90IHRoZSBtb2RlbCB3ZSB1bHRp
> bWF0ZWx5IHdhbnRlZCBmb3IgQyMgYmVjYXVzZSBvZiBwZXJmb3JtYW5jZSBhbmQgcnVudGltZS10
> eXBlIHJlYXNvbnMgKHdlIHdvdWxkIGxpa2UgYW4gb2JqZWN0J3MgZnVsbCB0eXBlIHRvIGJlIHZp
> c2libGUgYXQgcnVudGltZSwgZS5nLiBmb3IgcmVmbGVjdGlvbiwganVzdCBhcyBpdCBpcyBmb3Ig
> YXJyYXkgdHlwZXMgZm9yIHRoZSBKVk0gYW5kIENMUikuICANCg0KUHJvYmFibHkgdGhlIG1vc3Qg
> aXJyaXRhdGluZyB0aGluZyBhYm91dCB1c2luZyBlcmFzdXJlIGZvciBGIyBpcyB0aGF0IGl0IGZv
> cmNlcyB0aGUgdHJlYXRtZW50IG9mIGFycmF5cyB0byBiZSBzbGlnaHRseSBub24tdW5pZm9ybS4g
> IEYjLXdoZW4tY29tcGlsaW5nLWZvci1WMS1vZi10aGUtQ0xSIHN1cHBvcnRzIHR3byBmYW1pbGll
> cyBvZiBhcnJheSB0eXBlczogdHJ1bHkgcGFyYW1ldHJpYyBhcnJheXMgb2YgdGhlIGZvcm0gIidh
> IGFycmF5IiAgYW5kIGEgZmFtaWx5IG9mIC5ORVQgYXJyYXkgdHlwZXMgIidhW10iLiAgSW4gdGhl
> IGZvcm1lciAgYXJlIGFsd2F5cyBjb21waWxlZCBhcyAib2JqZWN0W10iLCBoZW5jZSwgZm9yIGV4
> YW1wbGUsIGJ5dGUgYXJyYXlzIHdvbid0IGhhdmUgdGhlIHJlcHJlc2VudGF0aW9uIHlvdSBtaWdo
> dCBleHBlY3QuICBJbiB0aGUgbGF0dGVyICdhIGlzIGVmZmVjdGl2ZWx5IGEgd2VhayB0eXBlIHZh
> cmlhYmxlIGFuZCBtdXN0IGFsd2F5cyBiZSBrbm93biBhdCBjb21waWxlIHRpbWUsIGkuZS4geW91
> IGNhbid0IGdlbmVyYWxpemUgb3ZlciB2YXJpYWJsZXMgdXNlZCBpbiBfW10gdHlwZXMuICBUaGUg
> Zm9ybWVyIGFyZSBmb3IgcG9seW1vcnBoaWMgcHJvZ3JhbW1pbmcgb3ZlciBhcnJheXMgd2hlcmUg
> eW91IGRvbid0IGNhcmUgYWJvdXQgaW50ZXJvcCAoZS5nLiB3aGVuIHlvdSdyZSB3cml0aW5nIG5l
> dyBkYXRhIHN0cnVjdHVyZXMgbGlrZSBoYXNoIHRhYmxlcyBidWlsdCB1c2luZyBhcnJheXMpLiAg
> VGhlIGxhdHRlciBhcmUgZm9yIHdoZW4geW91IG5lZWQgdG8gYnVpbGQgb3IgYWNjZXNzIGNvbXBv
> bmVudHMgdGhhdCB0cmFuc2FjdCAuTkVUIGFycmF5IHR5cGVzIChpLmUuIGludFtdIGluIEYjIGlz
> IGd1YXJhbnRlZWQgdG8gYmUgaWRlbnRpY2FsIHRvIEMjJ3MgaW50W10gdHlwZSkuICBGIyBzdXBw
> b3J0cyB0aGUgbGF0dGVyIGJ5IGlubGluaW5nIGFsbCBjb2RlIHRoYXQgbWFuaXB1bGF0ZXMgX1td
> IHR5cGVzLiAgSXQgc3RyaWtlcyBtZSB0aGF0IGl0J3MgcG9zc2libGUgdGhhdCBHSiBjb3VsZCBo
> YXZlIG1hZGUgdGhpcyBkaXN0aW5jdGlvbiBhcyB3ZWxsIChhcyBmYXIgYXMgSSBrbm93IHlvdSBj
> YW4ndCBjdXJyZW50bHkgd3JpdGUgYW55IGNvZGUgaW4gR0ogdGhhdCBwb2x5bW9ycGhpY2FsbHkg
> bWFuaXB1bGF0ZXMgYXJyYXkgdHlwZXMsIGUuZy4gY3JlYXRlcyBuZXcgYXJyYXlzIC0gdGhleSBj
> b3VsZCBoYXZlIGFsbG93ZWQgdGhpcyBidXQgZm9yY2VkIGFsbCBzb3VyY2UtbGFuZ3VhZ2UgY29t
> cGlsZXJzIHRvIGlubGluZSBhbGwgc3VjaCBjb2RlKS4NCg0KPiBQUy4gIFdoeSBGIz8gIFRoZSBs
> YXN0IHRoaW5nIHdlIG5lZWQgYXJlIG1vcmUgc3ltYm9saWMgY2hhcmFjdGVycyBpbiBvdXINCj4g
> bGFuZ3VhZ2UgbmFtZXMhICA6KSAgV2hhdCB3YXMgd3Jvbmcgd2l0aCBjYW1sLm5ldCwganVzdCB0
> aGUgY29tcGF0aWJpbGl0eQ0KPiBpc3N1ZXM/DQoNCkkgY29uY2x1ZGVkIHRoYXQgaXQgd2Fzbid0
> IHJlYWxseSBhcHByb3ByaWF0ZSBmb3IgTWljcm9zb2Z0IFJzZWFyY2ggdG8gcmVsZWFzZSBhbnl0
> aGluZyB3aXRoIHRoZSBuYW1lICJDYW1sIiBpbiBpdCAtIHRoYXQgaXMgdXAgdG8gdGhlIElOUklB
> IHRlYW0uICBBbHNvIHRoZSBsYW5ndWFnZSBpc24ndCBleGFjdGx5IE9DYW1sIG9yIENhbWwtbGln
> aHQsIGVzcGVjaWFsbHkgYmVjYXVzZSBvZiBpbW11dGFibGUgc3RyaW5ncywgYXMgd2VsbCBhcyB0
> aGUgZXh0ZW5zaW9ucyBsaWtlIHRoZSBvbmUgYWJvdmUuICBBcyBmb3IgRiMsIHdlbGwgaXQgZ2F2
> ZSB0aGUgLy4gY3Jvd2QgYSBnb29kIGNoYW5jZSB0byBjcmFjayBzb21lIHByZXR0eSBnb29kIGpv
> a2VzLCB0aGUgYmVzdCBvZiB3aGljaCB3YXMgIkYjIGlzIGEgRm9ydGggYWJvdmUgQyMiLi4uIDot
> KS4gIEFub3RoZXIgcG9pbnRlZCBvdXQgaG93IGVhc2lseSAiRiMiIGJlY29tZXMgIkYjIUAiLi4u
> DQoNCiANCg0KDQogDQoNCg==
> -------------------
> 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
> 
-------------------
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

RE: [Caml-list] F#

[Chris Hecker]

>F# programs compiled for V1 of the CLR use the type "object" for all 
>values of variable (i.e. 'a) type.  This is simple erasure.

Huh.  I must not understand the issues, because I thought it was harder 
than this.  If you can just make 'a into objects, why were people 
complaining that it's hard to make it work?  (Xavier called your work a 
tour de force, and I thought I'd learn something by trying to understand 
why.  But, I'm a relative beginner, and the research papers dive in deep 
pretty quick.  :)

Also, what are the dlls that are installed?  When you say "compiled for V1 
of the CLR", does that mean you have a bytecode file that will run anywhere 
(like Java), or does it need the extension dlls to be installed?

I'm mostly just trying to figure out exactly what I could use F# for.  I 
need to write an applet that runs on a webpage.  The applet it going to be 
a stripped down version of a program I'm writing in caml.   The ultimate 
thing for me would be ocaml code compiled onto the JVM, since it's 
everywhere.  Ocaml compiled for the .net CLR would be an okay second place 
since I assume the .net runtime will be close to everywhere 
eventually.  Requiring people to install dlls is not quite as nice, but 
still might be better than rewriting my app in java.

Hopefully the questions make sense?

Thanks,
Chris


-------------------
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

RE: [Caml-list] F#

[Don Syme]

> I was under the impression that the CLR as it's currently shipped could not
> do parametric polymorphism.  [Xavier's post from last year listing what
> isn't supported is here:  http://caml.inria.fr/archives/200102/msg00190.html]

F# programs compiled for V1 of the CLR use the type "object" for all values of variable (i.e. 'a) type.  This is simple erasure.  It is an OK way to implement PP (it's how GJ does it) - there are a few problems, e.g. type distinctions get lost in the IL so interop is not quite how you might want it, and it's not the model we ultimately wanted for C# because of performance and runtime-type reasons (we would like an object's full type to be visible at runtime, e.g. for reflection, just as it is for array types for the JVM and CLR).  

Probably the most irritating thing about using erasure for F# is that it forces the treatment of arrays to be slightly non-uniform.  F#-when-compiling-for-V1-of-the-CLR supports two families of array types: truly parametric arrays of the form "'a array"  and a family of .NET array types "'a[]".  In the former  are always compiled as "object[]", hence, for example, byte arrays won't have the representation you might expect.  In the latter 'a is effectively a weak type variable and must always be known at compile time, i.e. you can't generalize over variables used in _[] types.  The former are for polymorphic programming over arrays where you don't care about interop (e.g. when you're writing new data structures like hash tables built using arrays).  The latter are for when you need to build or access components that transact .NET array types (i.e. int[] in F# is guaranteed to be identical to C#'s int[] type).  F# supports the latter by inlining all code that manipulates _[] types.  It strikes me that it's possible that GJ could have made this distinction as well (as far as I know you can't currently write any code in GJ that polymorphically manipulates array types, e.g. creates new arrays - they could have allowed this but forced all source-language compilers to inline all such code).

> PS.  Why F#?  The last thing we need are more symbolic characters in our
> language names!  :)  What was wrong with caml.net, just the compatibility
> issues?

I concluded that it wasn't really appropriate for Microsoft Rsearch to release anything with the name "Caml" in it - that is up to the INRIA team.  Also the language isn't exactly OCaml or Caml-light, especially because of immutable strings, as well as the extensions like the one above.  As for F#, well it gave the /. crowd a good chance to crack some pretty good jokes, the best of which was "F# is a Forth above C#"... :-).  Another pointed out how easily "F#" becomes "F#!@"...

 


 

RE: [Caml-list] F#

[Chris Hecker]

Can I ask a dumb-and-uninformed question about this work?

I was under the impression that the CLR as it's currently shipped could not 
do parametric polymorphism.  [Xavier's post from last year listing what 
isn't supported is here:  http://caml.inria.fr/archives/200102/msg00190.html]

So, this work uses a runtime extension (there seem to be some dlls listed 
in the ppt on the site), or a workaround was found?

In other words, if I write an F# applet, can I put it on a webpage like a 
java applet, or would the user need to download and install dlls to extend 
their runtime for it to work?

Thanks,
Chris

PS.  Why F#?  The last thing we need are more symbolic characters in our 
language names!  :)  What was wrong with caml.net, just the compatibility 
issues?

-------------------
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

Re: [Caml-list] F#

[Xavier Leroy]

> http://research.microsoft.com/projects/ilx/fsharp.htm
> 
> F# is a .NET language based on the core of OCaml.  It can use the .NET
> libraries and interact with C#.  What do you guys think?

I think that Don Syme and his Microsoft Cambridge colleagues did a
great job with adding parametric polymorphism to the .NET framework --
something that was initially overlooked in .NET --, and I'm very happy
that they chose core Caml to demonstrate this extension in action.

By the way, for those of you who are in the Paris area: Don Syme will
give a talk on F# at INRIA Rocquencourt on the morning of June 14th,
and everyone is welcome to attend.  E-mail me privately for more info.

- Xavier Leroy
-------------------
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

[Caml-list] F#

[Vincent Foley]

http://research.microsoft.com/projects/ilx/fsharp.htm

F# is a .NET language based on the core of OCaml.  It can use the .NET
libraries and interact with C#.  What do you guys think?

Vincent

-- 

Vincent Foley-Bourgon
Email: vinfoley@iquebec.com
Homepage: http://darkhost.mine.nu:81
-------------------
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