From: Brian Hurt <bhurt@janestcapital.com>
To: Chung-chieh Shan <ccshan@post.harvard.edu>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Re: Which syntax to teach ?
Date: Tue, 30 Oct 2007 12:38:40 -0400 [thread overview]
Message-ID: <47275E10.4070705@janestcapital.com> (raw)
In-Reply-To: <5i2kv4-hmj.ln1@mantle.rutgers.edu>
[-- Attachment #1: Type: text/plain, Size: 1273 bytes --]
Chung-chieh Shan wrote:
>Adrien <camaradetux@gmail.com> wrote in article <666572260710241205x19edbd4ar840811b1d7a7315f@mail.gmail.com> in gmane.comp.lang.caml.inria:
>
>
>>>7. They easily understand how the standard library is used (but not the
>>>functors), the open statement, the fact that a program may be in several
>>>.ml files. The .mli files are a bit more mysterious. Functors are _very_
>>>mysterious.
>>>
>>>
>
>Any tips on how (and perhaps how not) to teach functors? I'm using a
>Haskell equivalent of functors (namely constructor classes) in an AI
>class (!) and they seem to be mysterious. It didn't seem to work to
>explain the Java/C# code that I would like to write (but can't, because
>these languages have no interface _on_ generics (as opposed to generic
>interfaces)).
>
>
>
Not sure how well this would work, but my idea would be to map the
concepts onto the standard code concepts.
For example,
module type Foo = sig ... end;;
maps to:
type foo = ...;;
module Foo = struct ... end;;
maps to:
let foo = ...;;
module Foo(Bar: Baz) : Quux = struct ... end;;
maps to:
let foo (bar: baz) : quux = ...;;
and so on. Functors, then, are a way to manipulate modules, in the same
way that functions are a way to manipulate values.
Brian
[-- Attachment #2: Type: text/html, Size: 1997 bytes --]
next prev parent reply other threads:[~2007-10-30 16:38 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-24 11:36 David Teller
2007-10-24 13:18 ` [Caml-list] " Loup Vaillant
2007-10-24 13:24 ` Peng Zang
2007-10-24 13:54 ` Julien Moutinho
2007-10-24 17:23 ` Andrej Bauer
2007-10-24 19:05 ` Adrien
2007-10-25 5:14 ` Aleks Bromfield
2007-10-30 16:26 ` Chung-chieh Shan
2007-10-30 16:38 ` Brian Hurt [this message]
2007-10-30 16:59 ` Chung-chieh Shan
2007-10-30 17:08 ` [Caml-list] " Edgar Friendly
2007-10-30 17:56 ` skaller
2007-10-30 19:02 ` Vincent Aravantinos
2007-10-30 18:50 ` William D. Neumann
2007-10-30 21:45 ` Eliot Handelman
2007-10-30 18:56 ` Daniel Bünzli
2007-10-25 9:43 ` [Caml-list] " Richard Jones
2007-10-24 22:52 ` Nathaniel Gray
2007-10-24 23:10 ` Jon Harrop
2007-10-25 1:48 ` skaller
2007-10-25 2:02 ` Jon Harrop
2007-10-25 9:49 ` Richard Jones
2007-10-25 11:32 ` Stefano Zacchiroli
2007-10-25 11:52 ` Daniel Bünzli
2007-10-25 12:39 ` Richard Jones
2007-10-25 12:59 ` Michael Ekstrand
2007-10-25 13:39 ` Loup Vaillant
2007-10-25 20:32 ` Andrej Bauer
2007-10-25 22:11 ` Loup Vaillant
2007-10-25 15:14 ` Richard Jones
2007-10-25 18:47 ` Re : " Adrien
2007-11-02 16:08 ` Nathaniel Gray
2007-10-26 11:11 ` David Teller
2007-10-24 23:02 ` Jon Harrop
2007-10-26 11:09 ` David Teller
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=47275E10.4070705@janestcapital.com \
--to=bhurt@janestcapital.com \
--cc=caml-list@inria.fr \
--cc=ccshan@post.harvard.edu \
/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