Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: "Markus E.L." <ls-ocaml-developer-2006@m-e-leypold.de>
To: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Re: Teaching bottomline, part 3: what should improve.
Date: Fri, 25 May 2007 11:57:02 +0200	[thread overview]
Message-ID: <d0d50pdy4x.fsf@hod.lan.m-e-leypold.de> (raw)
In-Reply-To: <1180042153.6098.40.camel@Blefuscu> (David Teller's message of "Thu, 24 May 2007 17:29:08 -0400")



> 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





      parent reply	other threads:[~2007-05-25  9:48 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20070522234715.0BCB2BC74@yquem.inria.fr>
2007-05-23  5:21 ` Dan Grossman
2007-05-23  8:03   ` [Caml-list] " Loup Vaillant
2007-05-23 12:51     ` David Teller
2007-05-24 16:30       ` Loup Vaillant
2007-05-24 18:08         ` Jon Harrop
2007-05-24 21:29         ` David Teller
2007-05-25  7:58           ` Loup Vaillant
2007-05-25  9:57           ` Markus E.L. [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d0d50pdy4x.fsf@hod.lan.m-e-leypold.de \
    --to=ls-ocaml-developer-2006@m-e-leypold.de \
    --cc=caml-list@yquem.inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox