From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 6E685BC0C for ; Fri, 19 Jan 2007 00:45:05 +0100 (CET) Received: from ptb-relay03.plus.net (ptb-relay03.plus.net [212.159.14.214]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l0INj4Nf011272 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 19 Jan 2007 00:45:05 +0100 Received: from [80.229.56.224] (helo=[10.0.0.5]) by ptb-relay03.plus.net with esmtp (Exim) id 1H7gwJ-0006Kl-7B for caml-list@yquem.inria.fr; Thu, 18 Jan 2007 23:45:04 +0000 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@yquem.inria.fr Subject: Re: Fwd: [Caml-list] Polymorphic Variants Date: Thu, 18 Jan 2007 21:14:09 +0000 User-Agent: KMail/1.9.5 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701182114.10133.jon@ffconsultancy.com> X-Miltered: at concorde with ID 45B00680.001 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; variants:01 sqrt:01 vectors:01 matrices:01 overload:01 ocaml:01 ocaml:01 annotations:01 subtyping:01 subtyping:01 reused:01 ocaml's:01 compiler:01 compiler:01 ocaml's:01 On Thursday 18 January 2007 16:23, Tom wrote: > No... i rather thought it that way: > x is anything > x * x is either int or float, so x is either int or float > x * x + x * x is either int or float, so the two (x * x) are either > both int or both float > sqrt accepts a float argument, so x * x + x * x must be float, so (x * > x) must be float, so x must be float. Much better. Except I want + to work on int, float, float32, 'a^n (static vectors), 'a^n^m (static matrices), 'a array, 'a list, 'a set. Not only that, I want + and * to work on two values of different types: date+time, float*vector and so on. Hell, I want to overload 0 to mean 0, 0., 0. + 0.i, zero vector and the zero matrix. Of course, the zero matrix has arbitrary dimensionalities that could be static, so my type now contains variables for those. Now, where your type inferencer had a simple type expression or atom (int or float), it can have expressions of mutually-recursive sets of type expressions. You see how things will get more complicated to define correctly, slower to compile and much harder to comprehend when things go wrong? You've opened a whole can of worms. Some of those worms look tasty but you either eat them all or you put them all back. > > You could even add a float literal: > > > > x +. 0. > > and have it optimized away No, because x+0=x is not true for all floats: # -0. +. 0.;; - : float = 0. > You see, I am not against OCaml. No! I love it. And I am not trying to > change it. You seem to be a priori against my ideas, just because they are > not what is generally accepted. Not at all. They are very good ideas on the surface. The problem is what costs lay hidden beneath the surface in an implementation of such a language. > All I want to do is write my own language, > both for the sake of writing one (they say it's good practice) and for the > sake of correcting things that I have found bother me when I program OCaml. > As pointed out a number of times, you should design a language for > yourself, not for others, not for the "general public" [1]. Ok. > So what I want > is something that will enable me to program in a fast, yet efficient > manner, and to be able to express many things as naturally as possible. > Therefore, most of the features I suggested are not "evil" or "mean", they > are just my solutions to what I think are the most common problems - > actually, one biggest problem: too much typing. Then I think you need to choose bigger examples in order to weigh the reduction in code size that you've seen with the increase in code size due to type annotations. > No, actually, the nominal > subtyping of records is because it's faster than structural subtyping of > objects, as implemented by OCaml. That's a good idea. I'd like to have vec2 and vec3 records that reused x and y field names. > If anyone has any idea, how to make > structural subtyping faster, I would love to incorporate it. Right. I think structural subtyping is a good complement to the rest of OCaml's type system. > > What happens at code boundaries? e.g. to compile a DLL, the compiler must > > generate all possible permutation of type variables for every function. > > Then > > you end up with a compiler that's 2,000x slower than OCaml's, like the > > Stalin > > scheme compiler. > > In addition to what I have written in the previous remark, I think you are > overly concerned with performance only. I am, yes. OCaml's designers were too, I think. > It's great you think about many > things, but these things have quite simple answers. Either, one could write > an incremental compiler (similar to the way OCaml provides separate > compilation, but somehow more refined is what I have in mind), or write > interfaces - again what OCaml does (to optimise say, the min function (let > min (x: int) y = if x > y then y else x) so that it is faster) - it's just > that what you would actually need to do is DELETE interfaces, because the > compiler would infer the whole interface for you, and you would just delete > the entries you don't want to have in it. Good idea. Not having to repeat types in .mli files would be an improvement, IMHO. > All in all, I believe that optimizations (compile-time evaluation (and > don't say I forgot that some functions have side effects)), incremental > compilation and a smart and powerful IDE, along with OCaml's already > existent debugger and profiler should keep one from being stopped by > implementation issues. Idea, ideas, ideas are important, ideas are what > matters. Absolutely. I would welcome a decent OCaml IDE. I've even considered writing one a few times, but you'd need a good GPU to run mine. ;-) -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. Objective CAML for Scientists http://www.ffconsultancy.com/products/ocaml_for_scientists