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.3 required=5.0 tests=AWL autolearn=disabled version=3.1.3 Received: from discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id 38DD4BC0A for ; Fri, 25 May 2007 11:48:09 +0200 (CEST) Received: from server2.thinkcrime.de (server2.thinkcrime.de [213.133.110.149]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l4P9m8D5019581 for ; Fri, 25 May 2007 11:48:08 +0200 Received: from hod-sarge-2005-10.lan.m-e-leypold.de (dslb-088-072-200-017.pools.arcor-ip.net [88.72.200.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server2.thinkcrime.de (Postfix) with ESMTP id 364DB488016 for ; Fri, 25 May 2007 11:48:14 +0200 (CEST) Received: by hod-sarge-2005-10.lan.m-e-leypold.de (Postfix, from userid 1003) id C270C37BC9; Fri, 25 May 2007 11:57:02 +0200 (CEST) To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Re: Teaching bottomline, part 3: what should improve. References: <20070522234715.0BCB2BC74@yquem.inria.fr> <4653CF5C.4040305@cs.washington.edu> <6f9f8f4a0705230103r7152299esca6b56db93cfcf08@mail.gmail.com> <1179924683.6966.90.camel@Blefuscu> <6f9f8f4a0705240930t612a7ea9n725c42cbceb864f1@mail.gmail.com> <1180042153.6098.40.camel@Blefuscu> From: "Markus E.L." Date: Fri, 25 May 2007 11:57:02 +0200 In-Reply-To: <1180042153.6098.40.camel@Blefuscu> (David Teller's message of "Thu, 24 May 2007 17:29:08 -0400") Message-ID: User-Agent: Some cool user agent (SCUG) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Miltered: at discorde with ID 4656B0D8.001 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; markus:01 0200,:01 arrays:01 haskell:01 syntax:01 camlp:01 traversing:01 syntax:01 ocaml:01 avoided:01 ocaml:01 drscheme:01 readable:01 recursion:01 bindings:01 > On Thu, 2007-05-24 at 18:30 +0200, Loup Vaillant wrote: >> It sounds like you need some kind of macro which can encapsulate a >> chunk of code into an anonymous function like : >> >> for_each i : my_list >> begin >> i*2 >> end >> (* map (fun i -> i*2) my_list *) >> >> and : >> >> accumulate acc = 0 in i : my_list >> begin >> acc+i >> end >> (* fold (+) 0 my_list *) >> >> Problem : works only on lists (or arrays, depending of your choice). >> And a Haskell like syntax for creating lists would help. (something >> like [0..10]). I think camlp4 can handle all that. > > Or perhaps > > map i traversing my_list > begin > i*2 > end <...> I wonder, why you need extra syntax. My take on that (a simplified loop) would just have been: let loop_for i_min i_max s0 body = let rec step i s = if i>i_max then s else step (i+1) (body i s) in step i_min s0 ;; let result = loop_for 1 5 0 (fun i s -> print_int i; print_newline (); s + i*i ) ;; print_result result;; Yes, I know: Anonymous functions and you said, your students don't like them. My idea is, that this kind of loop construction would even provide the opportunity to make anon functions understandable: A function here is a recipe, not to be directly executed (where its stands) but at a later time. In case of loop_for the recipe explains how to advance the state (the section of data on which we currently do computation) with every step. Using (fun ... -> ...) would even be better than some $loop_declaration begin ... end; because, if one looks thoroughly, the stuff in begin ... end (in this case, not where and how OCaml uses it!) is just a suspension anyway (i.e. executed later / put into a closure). The (fun () ...) makes it just explicit. Having had my share of people who want to reform the parenthesis out of Lisp :-), I've come to the conclusion that custom syntax is a thing to be avoided (not only in development where the question of maintenance comes up fairly quickly -- see the current leap in campl4 development) but ESPECIALLY in teaching: Introducing a syntax that is foreign to the language you teach is very likely to give you more problems in the long run than it solves: Your students will learn the wrong language (your custom syntax), not the real live language. If you want to teach an imperative language, teach it. If you want to teach Pascal, teach it. But don't teach pascalish syntax embedded into Ocaml especially for the purpose of teaching: That somehow defeats the purpose and afterwards your students don't know Ocaml even if they can program in your custom teaching language. That said, I've been thinking for some time about a language system for teaching purposes that (much in the spirit of DrScheme) is implemented as a series of languages L1, L2, L3 (most of which are extensions from each other) and which compiles from the frontend language just to something like Ocaml. Intentionally I wouldn't take campl4, since I'd want the error messages extremely readable and explanatory. During the course the language(s) would be upgraded step-by-step when introducing new stuff. Of course that would require of the students that they develop from the beginning some awareness that there are DIFFERENT languages in the world -- perhaps something that would create more confusion than it solves problems, I'm not sure. At the end, all this is probably not worth the trouble :-) -- experience shows (at least mine) that the major problem of beginners seems to be to get their mind wrapped around some basic concepts, like recursion, values vs. storage and local variables (bindings). Syntax seems to be a minor problem. Regards -- Markus