From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 2612EBC8B for ; Mon, 14 Feb 2005 03:22:45 +0100 (CET) Received: from smtp3.adl2.internode.on.net (smtp3.adl2.internode.on.net [203.16.214.203]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j1E2MhEL023411 for ; Mon, 14 Feb 2005 03:22:44 +0100 Received: from [192.168.1.200] (ppp212-197.lns2.syd3.internode.on.net [203.122.212.197]) by smtp3.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id j1E2MQI4014616; Mon, 14 Feb 2005 12:52:26 +1030 (CST) Subject: Re: [Caml-list] The boon of static type checking From: skaller Reply-To: skaller@users.sourceforge.net To: Thomas Fischbacher Cc: Michael Walter , Daniel Heck , caml-list@yquem.inria.fr In-Reply-To: References: <877e9a17050206221653d14456@mail.gmail.com> <877e9a17050212145737cc30d6@mail.gmail.com> <200502131451.02231.edgin@slingshot.co.nz> <20050213112630.73930e19@hobbes> <877e9a1705021312525337a907@mail.gmail.com> <877e9a1705021314512ff095b9@mail.gmail.com> Content-Type: text/plain Organization: Message-Id: <1108347745.2584.208.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 14 Feb 2005 13:22:26 +1100 Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 42100B73.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 sourceforge:01 wrote:01 syntax:01 syntax:01 compiler:01 api:01 glebe:01 agglomerate:98 061:98 nsw:01 lisp:01 lisp:01 checking:01 constraints:01 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.2 X-Spam-Level: On Mon, 2005-02-14 at 10:59, Thomas Fischbacher wrote: > I must say, I did it, transliterating much of (it's not a lot of work > to be done, yet not quite complete) C's syntax to lisp, with the > intention to provide people with their own syntax which they even can > extend, say, for new operators, should they feel like it. I know I > probably will never use it. Neither will _any_ advanced lisp hacker, I > suppose. But it should help some people if you build them a bridge. What else is a compiler but a bridge to assembler? In that light, one might say 'it would help some novices program that can't do assembler' .. > My point is: one should not agglomerate things prematurely that better > first should be studied in isolation. You should know from Quantum Physics this idea must be taken with few grain of salt and a couple of Schroedinger cats. > Just as one can learn more about the structure of the proton by probing it > with electrons rather than with another proton, I would not mind a more > systematic approach towards finding out what makes a good language and > what not than throwing together a set of features from various corners, > shaking it well, and seeing how pretty the thing one gets turns out to be. We're open to suggestions on how to do this, for surely no one knows. All the maths in the world won't create a good programming language, even though it may help weed out poor ones. > So, again, syntax is not by itself an essential feature of the language. Sure it is: it is what distinguishes the system from a mere library. In particular, it provides a way of enforcing constraints mere library calls cannot -- and perhaps someone else can list other advantages of languages over lower level raw API calls? -- John Skaller, mailto:skaller@users.sf.net voice: 061-2-9660-0850, snail: PO BOX 401 Glebe NSW 2037 Australia Checkout the Felix programming language http://felix.sf.net