Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[Caml-list] Teaching bottomline, part 3: what should improve.

3 views
Skip to first unread message

David Teller

unread,
May 22, 2007, 6:11:58 PM5/22/07
to OCaml
Third and (probably) last part of my Teaching bottomline. I hope some of
you find this useful.


Let's start by problems I didn't cause.

= Not my fault =

== Environment ==

* OCamlWinPlus, in its current incarnation, is just awful. To improve
it, one would need to fix the bugx, make it possible to remember the
list of modules loaded, link it to the documentation, etc.


* Camelia IDE is simple and good but difficult to install, as it
requires Cygwin. It lacks project management, though -- and, now,
ocamlbuild support. I believe that it could draw some inspiration from
Dr.Java.


* Students just can't install LablGtk, LablGl, Camlimage... by
themselves, nor would I expect them to. A nice, centralised, installer,
would be nice.


* Building projects is just too hard. I hope ocamlbuild will solve this.


* It seems that Graphics doesn't work with Cygwin, hence with Camelia
for Windows. Which is bad, as they seem to enjoy both Graphics and
Camelia. What prevents Graphics in Cygwin+X ?


== Error messages ==

* Error messages of the type system are somewhat obscure. The reflex of
many students is "OCaml wants it to be of type XXX", rather than "there
is a contradiction in what I wrote". It would be nice if there was a way
to ask OCaml to display additional information on type errors. Say
something like, whenever typing of an expression fails, restarting the
type algorithm but printing out the various unifications as they take
place.


== Documentation ==

* Documentation of LablTk is non-existent. I'm thinking about taking a
student to write a more OCaml-ish layer on top of LablTk but I don't
know if/when this will happen.


* Type 'option' doesn't appear in the list of types of the
documentation. Nor do 'Some' and 'None' appear in the list of values.


* A nice *beginner-oriented* tutorial is really missing for students who
failed to pay attention to the beginning of the lecture. Something more
applied than _Developing applications with OCaml_ and less technical
than http://ocaml-tutorial.org . Say, leading a beginner to define a
Connect 4 game. I'm willing to participate into writing this, but not
alone. I might launch a thread on this subject on the ML.


= My fault =

* That's not OCaml-specific but there must be some construction better
suited than "for" or "while" to write loops without having to handcode a
recursive loops. Right now, I can't think of anything better than a
"hidden" Y combinator, but there must be something.

* Arrays of arrays (of arrays...) are a bit obscure for students,
although they're getting better at it.

* Some students rely too much on references.

* The usual note-taking/attention deficit/motivation deficit problems.

* Anonymous functions are still beyond most of them.

--
David Teller ------------------------------------------
Security of Distributed Systems -----------------------
-- http://www.univ-orleans.fr/lifo/Members/David.Teller
----- Laboratoire d'Informatique Fondamentale d'Orleans

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

William D. Neumann

unread,
May 22, 2007, 6:22:14 PM5/22/07
to David Teller
On Tue, 22 May 2007, David Teller wrote:

> * Type 'option' doesn't appear in the list of types of the
> documentation. Nor do 'Some' and 'None' appear in the list of values.

Huh? It's there in section 19.1 of the manual -- Built-in types and
pre-defined exceptions.

William D. Neumann

---

"There's just so many extra children, we could just feed the
children to these tigers. We don't need them, we're not doing
anything with them.

Tigers are noble and sleek; children are loud and messy."

-- Neko Case

Life is unfair. Kill yourself or get over it.
-- Black Box Recorder

Erik de Castro Lopo

unread,
May 22, 2007, 6:27:51 PM5/22/07
to caml...@inria.fr
David Teller wrote:

> Third and (probably) last part of my Teaching bottomline. I hope some of
> you find this useful.

Thanks David. I'm not even a teacher (well not currently) and I
still found that an interesting read.

Erik
--
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"Copyrighting allows people to benefit from their labours,
but software patents allow the companies with the largest
legal departments to benefit from everyone else's work."
-- Andrew Brown
(http://www.guardian.co.uk/online/comment/story/0,12449,1387575,00.html)

skaller

unread,
May 22, 2007, 7:19:56 PM5/22/07
to David Teller
On Tue, 2007-05-22 at 18:10 -0400, David Teller wrote:

> * Error messages of the type system are somewhat obscure. The reflex of
> many students is "OCaml wants it to be of type XXX", rather than "there
> is a contradiction in what I wrote". It would be nice if there was a way
> to ask OCaml to display additional information on type errors.

This is a long standing peeve of mine. Lets face it: Ocaml just lies.
If it has inferred a type, then finds a contradiction, it should
report both the location of the contradication AND all of the source
lines that contributed to the inference.

I understand that is may be hard, if not impossible, to implement,
as it would require a unification engine that could manage
source references in parallel with deductions .. still the information
IS available originally.

I bet this would be an interesting and valuable PhD project,
and, IMHO, without it type inferencing languages are useless
in industry. Type errors in Ocaml code are very common for the
simple reason they're just about the only error you can make :)


--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

skaller

unread,
May 22, 2007, 7:20:22 PM5/22/07
to David Teller
On Tue, 2007-05-22 at 18:10 -0400, David Teller wrote:

> * Students just can't install LablGtk, LablGl, Camlimage... by
> themselves, nor would I expect them to. A nice, centralised, installer,
> would be nice.

This sound like your School's fault. Why aren't they running
Debian or Ubuntu?

Because on those systems .. installing Ocaml packages is a breeze.

--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

_______________________________________________

Jon Harrop

unread,
May 22, 2007, 7:46:29 PM5/22/07
to caml...@yquem.inria.fr

Fascinating. Thanks for reporting the information. If I might be so brash as
to comment on the problems you had that have already been fixed by F#:

On Tuesday 22 May 2007 23:10:23 David Teller wrote:
> * OCamlWinPlus...Camelia IDE...LablGtk, LablGl, Camlimage ...
> ... It seems that Graphics doesn't work with Cygwin, hence with Camelia ...

There are two possibilities here:

You want to use Windows => Use F#, Visual Studio and F# for Visualization and
not OCaml.

You want good free software => Use Linux and not Windows.

> == Error messages ==
>
> * Error messages of the type system are somewhat obscure. The reflex of
> many students is "OCaml wants it to be of type XXX", rather than "there
> is a contradiction in what I wrote". It would be nice if there was a way
> to ask OCaml to display additional information on type errors. Say
> something like, whenever typing of an expression fails, restarting the
> type algorithm but printing out the various unifications as they take
> place.

F# currently has better graphical throwback of inferred type information but
slightly worse messages, IMHO.

> * Documentation of LablTk is non-existent. I'm thinking about taking a
> student to write a more OCaml-ish layer on top of LablTk but I don't
> know if/when this will happen.

You get what you pay for as far as documentation is concerned. OCaml is
largely undocumented (the compiler, several code libraries, the top-level,
camlp4). There is some additional documentation (e.g. my book) but you must
pay for it.

> * A nice *beginner-oriented* tutorial is really missing for students who
> failed to pay attention to the beginning of the lecture. Something more
> applied than _Developing applications with OCaml_ and less technical
> than http://ocaml-tutorial.org . Say, leading a beginner to define a
> Connect 4 game. I'm willing to participate into writing this, but not
> alone. I might launch a thread on this subject on the ML.

I'm very interested in writing an introduction to OCaml and publishing it as a
very cheap book, maybe through O'Reilly.

> * That's not OCaml-specific but there must be some construction better
> suited than "for" or "while" to write loops without having to handcode a
> recursive loops. Right now, I can't think of anything better than a
> "hidden" Y combinator, but there must be something.

I often use a nest function:

let rec nest n f x = if n=0 then x else nest (n-1) f (f x)

F# also provides sequences and comprehensions:

let factorial n = Seq.fold ( * ) 1 {2 .. n}

> * Arrays of arrays (of arrays...) are a bit obscure for students,
> although they're getting better at it.

F# provides multidimensional arrays, arbitrary-size arrays, immutable arrays,
resizeable arrays, allows array subscript syntax to be overloaded and is
faster than OCaml on array code. Arrays are a real weak point of OCaml ATM,
along with div and mod, functors, concurrency and some other things.

> * Some students rely too much on references.

F# doesn't help you there.

> * The usual note-taking/attention deficit/motivation deficit problems.

Or there...

> * Anonymous functions are still beyond most of them.

SML can do them with one fewer letters!

If you want your students to be future proof then you would do well to prepare
them for massively parallel computing on CPUs with hundreds or even thousands
of cores. OCaml it completely ill-equipped for this. In contrast, F# provides
native threads/locks/semaphores/threads/threadpools inherited from .NET as
well as async programming via extra syntax. Concurrency is beautiful in F#
and it works today.

--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?e

David Thomas

unread,
May 22, 2007, 10:48:29 PM5/22/07
to OCaml
Would it be possible for this to be an option? I
mean, it seems like the information is at least
available on another pass through the code. Twice the
compilation time in some cases will typically win out
over minutes-to-hours trying to figure out where it
inferred THAT.


--- skaller <ska...@users.sourceforge.net> wrote:


____________________________________________________________________________________Ready for the edge of your seat?
Check out tonight's top picks on Yahoo! TV.
http://tv.yahoo.com/

Dan Grossman

unread,
May 23, 2007, 1:25:07 AM5/23/07
to caml...@yquem.inria.fr, Ben Lerner

>> * Error messages of the type system are somewhat obscure. The reflex
>> of many students is "OCaml wants it to be of type XXX", rather than
>> "there is a contradiction in what I wrote". It would be nice if
there >> was a way to ask OCaml to display additional information on type
>> errors.

> This is a long standing peeve of mine. Lets face it: Ocaml just lies.
> If it has inferred a type, then finds a contradiction, it should
> report both the location of the contradication AND all of the source
> lines that contributed to the inference.

Reporting all of the source lines has been investigated; see

C. Haack and J. B. Wells. Type error slicing in implicitly typed
higher-order languages. Science of Computer Programming, 50(1-
3):189–224, 2004.

My intuition is there are many situations where this gives you too much
information just as one location gives you too little.

Switching to personal horn-tooting mode, you may be interested in a
paper we have in PLDI next month where we take a completely different
approach to presenting Caml type-errors -- we don't report any types at
all, but rather we report a similar program that does type-check.

See http://www.cs.washington.edu/homes/blerner/seminal.html. The PLDI
paper is the place to start. The prototype implementation may prove
useful to the very brave of heart, but it's really designed to
demonstrate the idea.

--Dan

Loup Vaillant

unread,
May 23, 2007, 4:05:38 AM5/23/07
to caml...@yquem.inria.fr
On Tue, 22 May 2007, David Teller wrote:

> * That's not OCaml-specific but there must be some construction better
> suited than "for" or "while" to write loops without having to handcode a
> recursive loops. Right now, I can't think of anything better than a
> "hidden" Y combinator, but there must be something.

What about map fold, filter, and the like? Sure, they are somewhat
specialized, but most can be rewritten for many data structures.
If you are really desperate, You can write The Recursive Loops
(terminal and not terminal, 3 lines each). But I guess you tried.


> * Arrays of arrays (of arrays...) are a bit obscure for students,
> although they're getting better at it.
>

> * Some students rely too much on references.

If they are used to for and while loops, they will think more often in
terms of references (as I did). Then, we have the array, a collection
of references. Do you think your students could learn some purely
functional data structures instead? Should they?

> * Anonymous functions are still beyond most of them.

That sounds surprising, for anonymous function are no different from named ones:

5;; (* a value *)
fun x -> x+1;; (* another value, which happens to be a function *)

a = 5;; (* a bound value *)
b = fun x -> x+1;; (* another bound value, which happens to be a function *)

Did your students used map and fold-like functions much? These almost
require anonymous functions.

regards,
Loup Vaillant

Vincent Hanquez

unread,
May 23, 2007, 5:28:07 AM5/23/07
to skaller, David Teller, OCaml
On Wed, May 23, 2007 at 09:16:44AM +1000, skaller wrote:
> On Tue, 2007-05-22 at 18:10 -0400, David Teller wrote:
>
> > * Error messages of the type system are somewhat obscure. The reflex of
> > many students is "OCaml wants it to be of type XXX", rather than "there
> > is a contradiction in what I wrote". It would be nice if there was a way
> > to ask OCaml to display additional information on type errors.
>
> This is a long standing peeve of mine. Lets face it: Ocaml just lies.
> If it has inferred a type, then finds a contradiction, it should
> report both the location of the contradication AND all of the source
> lines that contributed to the inference.

I agree, this is one of the worst thing about ocaml type inference,
and you sometimes end up to have to put explicit type to functions to
find the offending lines (usually hundreds lines before the actual line
that's printed), defeating the whole thing...

Cheers,
--
Vincent Hanquez

Richard Jones

unread,
May 23, 2007, 6:46:00 AM5/23/07
to skaller, David Teller, OCaml
On Wed, May 23, 2007 at 09:19:20AM +1000, skaller wrote:
> On Tue, 2007-05-22 at 18:10 -0400, David Teller wrote:
>
> > * Students just can't install LablGtk, LablGl, Camlimage... by
> > themselves, nor would I expect them to. A nice, centralised, installer,
> > would be nice.
>
> This sound like your School's fault. Why aren't they running
> Debian or Ubuntu?
>
> Because on those systems .. installing Ocaml packages is a breeze.

Just what I was going to say!

Hopefully it'll be a breeze on Fedora soon too.

Rich.

--
Richard Jones
Red Hat

Vincent Aravantinos

unread,
May 23, 2007, 7:05:17 AM5/23/07
to caml...@yquem.inria.fr
On Wed, 23 May 2007, Loup Vaillant wrote :

> (...)

>> * Anonymous functions are still beyond most of them.
>
> That sounds surprising, for anonymous function are no different
> from named ones:
>
> 5;; (* a value *)
> fun x -> x+1;; (* another value, which happens to be a function *)

Those are typically the comments of a "used-to-functional-
programming" guy.
It certainly doesn't match what a beginner would think (no beginner
will call a
function a "value").

Or do you really think that seeing functions as first-class object is
the natural way ?
IMHO this is not the case, and therefore not the case of a beginner.

To my eyes, there are (I mean, "in human mind" or at least in an
ocaml beginner's mind)
values AND functions. A function turns into a value (in the mind of
the programmer)
only when it is used by a higher order function.

> a = 5;; (* a bound value *)
> b = fun x -> x+1;; (* another bound value, which happens to be a
> function *)
>
> Did your students used map and fold-like functions much? These almost
> require anonymous functions.

Indeed, using map and fold puts the focus on the fact that functions
_can_ be values.
Thus their importance in a pedagogical context.

Maybe all this is just a matter of belief...

Regards,
Vincent

Brian Hurt

unread,
May 23, 2007, 8:53:58 AM5/23/07
to Vincent Hanquez, OCaml
Vincent Hanquez wrote:

>On Wed, May 23, 2007 at 09:16:44AM +1000, skaller wrote:
>
>
>>On Tue, 2007-05-22 at 18:10 -0400, David Teller wrote:
>>
>>
>>
>>>* Error messages of the type system are somewhat obscure. The reflex of
>>>many students is "OCaml wants it to be of type XXX", rather than "there
>>>is a contradiction in what I wrote". It would be nice if there was a way
>>>to ask OCaml to display additional information on type errors.
>>>
>>>
>>This is a long standing peeve of mine. Lets face it: Ocaml just lies.
>>If it has inferred a type, then finds a contradiction, it should
>>report both the location of the contradication AND all of the source
>>lines that contributed to the inference.
>>
>>
>
>I agree, this is one of the worst thing about ocaml type inference,
>and you sometimes end up to have to put explicit type to functions to
>find the offending lines (usually hundreds lines before the actual line
>that's printed), defeating the whole thing...
>
>Cheers,
>
>

Hundreds of lines? I've seen ten's of lines, but never hundreds.

Of course, I generally type annotate at the level of functions at least
(using .mli files is to be encouraged, IMO). So type errors generally
don't escape functions. And I keep functions reasonably short- tens of
lines long at most...

Brian

Loup Vaillant

unread,
May 23, 2007, 9:25:05 AM5/23/07
to caml...@yquem.inria.fr
2007/5/23, Vincent Aravantinos <vincent.a...@yahoo.fr>:

> On Wed, 23 May 2007, Loup Vaillant wrote :
>
> > (...)
>
> >> * Anonymous functions are still beyond most of them.
> >
> > That sounds surprising, for anonymous function are no different
> > from named ones:
> >
> > 5;; (* a value *)
> > fun x -> x+1;; (* another value, which happens to be a function *)
>
> Those are typically the comments of a "used-to-functional-
> programming" guy.
> It certainly doesn't match what a beginner would think (no beginner
> will call a
> function a "value").

You are quite right. My point was to find a way to tell the beginners.
A way to stress upon the fact that functions are values like any other
(in Ocaml, at the very least).

I see some difficulties, thought :

First, the syntax:
b = fun x -> x+1;; (* b defined as a functionnal value *)
b x = x+1;; (* b defined as a mere function *)

Second, imperative languages, where b can only be defined as a mere
function. Many courses begin with an imperative language.

Third, high school, where the only functions we dare name as such are
of type number -> number. Derivation and composition, for instance,
are named "operations", not functions. As if they have anything
special (usefulness excepted). Finally, each function has a name in
high shool mathematics.


> Or do you really think that seeing functions as first-class object is
> the natural way ?
> IMHO this is not the case, and therefore not the case of a beginner.

I agree. I just hope it can become A natural way.

> To my eyes, there are (I mean, "in human mind" or at least in an
> ocaml beginner's mind)
> values AND functions. A function turns into a value (in the mind of
> the programmer)
> only when it is used by a higher order function.

I think there are some other uses, too : data structures can contain
closures for instance. A lazily evaluated value is a function (a
closure).


> > Did your students used map and fold-like functions much? These almost
> > require anonymous functions.
>
> Indeed, using map and fold puts the focus on the fact that functions
> _can_ be values.
> Thus their importance in a pedagogical context.

Not only : most loops in a list or an array can be expressed as a
combination of map and fold (and filter, and...). Using these
significantly reduce the amount of code.

> Maybe all this is just a matter of belief...

I am quite a zeelot of abstraction. :)

Regards,
Loup

Gerd Stolpmann

unread,
May 23, 2007, 9:41:58 AM5/23/07
to Brian Hurt, OCaml
Am Mittwoch, den 23.05.2007, 08:49 -0400 schrieb Brian Hurt:
> Vincent Hanquez wrote:
> > On Wed, May 23, 2007 at 09:16:44AM +1000, skaller wrote:
> >
> > > On Tue, 2007-05-22 at 18:10 -0400, David Teller wrote:
> > >
> > >
> > > > * Error messages of the type system are somewhat obscure. The reflex of
> > > > many students is "OCaml wants it to be of type XXX", rather than "there
> > > > is a contradiction in what I wrote". It would be nice if there was a way
> > > > to ask OCaml to display additional information on type errors.
> > > >
> > > This is a long standing peeve of mine. Lets face it: Ocaml just lies.
> > > If it has inferred a type, then finds a contradiction, it should
> > > report both the location of the contradication AND all of the source
> > > lines that contributed to the inference.
> > >
> >
> > I agree, this is one of the worst thing about ocaml type inference,
> > and you sometimes end up to have to put explicit type to functions to
> > find the offending lines (usually hundreds lines before the actual line
> > that's printed), defeating the whole thing...
> >
> > Cheers,
> >
>
> Hundreds of lines? I've seen ten's of lines, but never hundreds.

I can confirm that: hundreds. This happens especially for mismatching
class types, because the compiler tries to break the mismatch down.

But beginners shouldn't use classes.

> Of course, I generally type annotate at the level of functions at
> least (using .mli files is to be encouraged, IMO). So type errors
> generally don't escape functions. And I keep functions reasonably
> short- tens of lines long at most...

There is certainly a point. The length of type errors depends on your
programming style. A teacher can give hints how to make everything
easier to handle. (Although it is also a valid point in education to let
the students find their limits.)

Gerd
--
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany
ge...@gerd-stolpmann.de http://www.gerd-stolpmann.de
Phone: +49-6151-153855 Fax: +49-6151-997714
------------------------------------------------------------

ols...@verizon.net

unread,
May 23, 2007, 9:58:10 AM5/23/07
to
On May 22, 11:20 pm, skaller <skal...@users.sourceforge.net> wrote:
> On Tue, 2007-05-22 at 18:10 -0400, David Teller wrote:
> > * Students just can't install LablGtk, LablGl, Camlimage... by
> > themselves, nor would I expect them to. A nice, centralised, installer,
> > would be nice.
>
> This sound like your School's fault. Why aren't they running
> Debian or Ubuntu?
>
> Because on those systems .. installing Ocaml packages is a breeze.
>
> --

When did you go to school? These days many people have their own
computers and aren't working in school maintained computer labs. ;-)

skaller

unread,
May 23, 2007, 10:08:46 AM5/23/07
to Gerd Stolpmann, OCaml
On Wed, 2007-05-23 at 15:36 +0200, Gerd Stolpmann wrote:

>
> There is certainly a point. The length of type errors depends on your
> programming style.

It can also depend on the size of the type involved,
which is not nearly as much of a stylistic thing.

If you have several polymorphic variants types of
20-30 constructors each, recursively included in
each other .. you can get errors many hundreds of lines
long, involving scores of invented type variables, and
for me, when i get such errors, the information in the
diagnostic is more or less entirely useless.

I use the error location and knowledge of my last
change to track down where to add coercions and
annotations to help find the error ..

I got one a couple of days ago in code generated
by dypgen .. and just gave up .. since I didn't write
the code and had no idea what the types were (my
types were involved too .. the combination was
a type about 80 lines long .. :)

Ocaml has improved though: today it often gives a nasty
message and the kindly tells you which constructor is
causing the mismatch. This helps a LOT!


--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

_______________________________________________

Florian Hars

unread,
May 23, 2007, 10:58:00 AM5/23/07
to OCaml
Brian Hurt schrieb:

> Hundreds of lines? I've seen ten's of lines, but never hundreds.

Not only hundreds of lines, but usually in a completely different file, too.

This expression has type exactly_what_it_should be, but is here used with
type compeletly_off_the_mark.

How I hate it.

Yours, Florian.

Brian Hurt

unread,
May 23, 2007, 11:13:42 AM5/23/07
to Florian Hars, OCaml
Florian Hars wrote:

>Brian Hurt schrieb:
>
>
>>Hundreds of lines? I've seen ten's of lines, but never hundreds.
>>
>>
>
>Not only hundreds of lines, but usually in a completely different file, too.
>
>This expression has type exactly_what_it_should be, but is here used with
>type compeletly_off_the_mark.
>
>How I hate it.
>
>
>

mli files. Use them. Trust me.

Simply because code compiles doesn't necessarily mean it's right. Often
times I write the .mli file first, as it's a convient level to think
about what the interface to a module should be. But at the very least
you should use ocamlc -i to generate the .mli file when you are more or
less done with the module, and then hand verify it as correct. And then
keep it around, to make sure the module remains correct in the face of
future changes. Doing this will keep type errors in the same file, at
least.

Brian


Pal-Kristian Engstad

unread,
May 23, 2007, 1:12:38 PM5/23/07
to Vincent Aravantinos, caml...@yquem.inria.fr
Vincent Aravantinos wrote:
> Those are typically the comments of a "used-to-functional-programming"
> guy.
> It certainly doesn't match what a beginner would think (no beginner
> will call a
> function a "value").
This reminds me of a "game" I used to teach my math students the concept
of a function. I think it should be able to be used for an introductory
computer science class as well.

Essentially, the game involves having person A come up with a rule.
Person B will have to provide an input value, and A has to faithfully
give the result of the rule/computation. Examples of functions could be
\x->x+2, \x->2*x, etc. More interesting examples involves the function
that returns the first letter of the name of the input (f "one" = "o"),
or the successor of a "red, yellow, green" traffic light symbol.

When doing this, A and B will quickly have to agree on the allowed input
values (the domain) and in order to have a chance it is also helpful if
B knows the range of output values (the image). And for sure - they will
have to agree that the rule x = y => f(x) = f(y) has to hold in order to
be able to guess what "f" is. [I would also disallow closures for this
game - otherwise it would be too hard to guess.]

The reason this exercise is good is that it teaches the students (in a
fun way) the important concepts behind a function. It will make them
understand that a function is just a computation, but also point out the
importance of defining the types (sets) of inputs and outputs. I think
that after playing this game, you can venture to talk about the "name"
of the function, and they will realize that it does not matter what the
name of the function is - just what it does.

Perhaps after this, you can teach the concept of treating a function as
a value, or input to another function? Person A makes a function that
takes person B's function, etc.

Thanks,

PKE

--
Pål-Kristian Engstad (eng...@naughtydog.com), Lead Graphics & Engine Programmer,
"Uncharted"-team, Naughty Dog, Inc., 1601 Cloverfield Blvd, 6000 North,
Santa Monica, CA 90404, USA. Ph.: (310) 633-9112.

"Most of us would do well to remember that there is a reason Carmack
is Carmack, and we are not Carmack.",
Jonathan Blow, 2/1/2006, GD Algo Mailing List

Pal-Kristian Engstad

unread,
May 23, 2007, 1:24:50 PM5/23/07
to Pal-Kristian Engstad, caml...@yquem.inria.fr, Vincent Aravantinos
Sorry, I forgot to mention the point of the game. Person B is supposed
to figure out what function person A is using.

Robert C Fischer

unread,
May 23, 2007, 1:59:29 PM5/23/07
to caml...@yquem.inria.fr
I actually did something like this back in my CSci education. We would
debug programs by isolating the buggy code, then having each student be
one expression in the code, and walk through the program having each
person perform their little function. Of course, you got "swapped out"
if you failed to perform your expression right -- it was surprisingly
fun and provided a nice way to visualize things going on in an otherwise
abstract system.

~~ Robert.

_______________________________________________

Richard Jones

unread,
May 23, 2007, 2:56:22 PM5/23/07
to caml...@inria.fr
On Wed, May 23, 2007 at 12:39:29AM +0100, Jon Harrop wrote:
> If you want your students to be future proof then you would do well
> to prepare them for massively parallel computing on CPUs with
> hundreds or even thousands of cores. OCaml it completely
> ill-equipped for this. In contrast, F# provides native
> threads/locks/semaphores/threads/threadpools inherited from .NET as
> well as async programming via extra syntax. Concurrency is beautiful
> in F# and it works today.

F# scales to hundreds or thousands of cores?

If the OP wants to teach his students about massively parallel
computing, he should avoid the Microsoft lock-in and teach them about
it on Linux clusters.

Rich.

--
Richard Jones
Red Hat

_______________________________________________

Robert C Fischer

unread,
May 23, 2007, 3:32:50 PM5/23/07
to Richard Jones, caml...@inria.fr
..and locks and threads are not a viable long-term solution to the
problem of concurrency in general. You're future-proofing enough by
teaching them functional languages: Erlang and Cilk are closer to the
needed future.

~~ Robert.

Richard Jones wrote:
> On Wed, May 23, 2007 at 12:39:29AM +0100, Jon Harrop wrote:
>
>> If you want your students to be future proof then you would do well
>> to prepare them for massively parallel computing on CPUs with
>> hundreds or even thousands of cores. OCaml it completely
>> ill-equipped for this. In contrast, F# provides native
>> threads/locks/semaphores/threads/threadpools inherited from .NET as
>> well as async programming via extra syntax. Concurrency is beautiful
>> in F# and it works today.
>>
>
> F# scales to hundreds or thousands of cores?
>
> If the OP wants to teach his students about massively parallel
> computing, he should avoid the Microsoft lock-in and teach them about
> it on Linux clusters.
>
> Rich.
>
>

_______________________________________________

Jon Harrop

unread,
May 23, 2007, 3:39:43 PM5/23/07
to caml...@yquem.inria.fr
On Wednesday 23 May 2007 19:54:28 Richard Jones wrote:
> ... he should avoid the Microsoft lock-in ...

Then he should not be using Microsoft Windows.

I think Linux users should use OCaml and Windows users should use F#. Anything
else is just perverted.

I suspect the reality is that both Windows and zero-budget have been imposed
upon David, which is simply insane because Windows is a very expensive
commercial platform and the quality of free software on Windows is far below
that on Linux.

--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?e

_______________________________________________

Brian Hurt

unread,
May 23, 2007, 3:41:44 PM5/23/07
to robert....@smokejumperit.com, caml...@inria.fr
Robert C Fischer wrote:

> ...and locks and threads are not a viable long-term solution to the

> problem of concurrency in general. You're future-proofing enough by
> teaching them functional languages: Erlang and Cilk are closer to the
> needed future.
>

I think you mean "Haskell+STM" instead of Cilk. Cilk isn't a
particularly functional language (being effectively C plus a little bit).

Brian

Robert Fischer

unread,
May 23, 2007, 3:55:32 PM5/23/07
to caml...@inria.fr
Granted, although I haven't played with Haskell+STM: the point I was
trying to make was that we need to be denoting parallelism instead of
implementing it. To that end, functional languages are better for that
kind of work (due to their disdain of side effects, if nothing else).

Robert Fischer
IT Firefighter
Smokejumper Consulting

Jon Harrop

unread,
May 23, 2007, 5:53:38 PM5/23/07
to caml...@inria.fr
On Wednesday 23 May 2007 20:27:24 Robert C Fischer wrote:
> ...and locks and threads are not a viable long-term solution to the

> problem of concurrency in general.

Absolutely, that's why we have parallel iter, map, fold etc.

> You're future-proofing enough by teaching them functional languages

Functional programming is not a panacea. GUI programming is one application
area where functional programming, immutability and the parallelizable
constructs that I just mentioned are not so beneficial.

To solve GUI programming you need different constructs (events, message pumps
etc.).

Look at some of the example F# programs on our site. This Sudoku solver uses a
worker thread to keep the GUI responsive while it solves puzzles:

http://www.ffconsultancy.com/dotnet/fsharp/sudoku/index.html

This ray tracer uses concurrency for incremental update of a responsive GUI:

http://www.ffconsultancy.com/dotnet/fsharp/raytracer/index.html

This particle simulator runs the simulation thread in parallel with the GUI
thread, for real-time visualization of the particle system:

http://www.ffconsultancy.com/products/fsharp_for_visualization/demo3.html

In the future, I hope OCaml will support concurrency not only to handle
parallel constructs but also to handle GUI programming elegantly. If there is
one thing that I have been singularly impressed by from .NET, it is GUI
programming.

--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?e

_______________________________________________

Vincent Hanquez

unread,
May 23, 2007, 5:55:38 PM5/23/07
to Brian Hurt, OCaml
On Wed, May 23, 2007 at 08:49:57AM -0400, Brian Hurt wrote:
> Hundreds of lines? I've seen ten's of lines, but never hundreds.

It's happening sometimes, and it's a major pain. It usually because you
got the wrong type returned, and you got lots of passthrough functions.
when it gets into the function that actually do something with the data,
ocaml see a mismatch obviously... in this case you want to correct the
source function, not where the error happened ...

> Of course, I generally type annotate at the level of functions at least
> (using .mli files is to be encouraged, IMO). So type errors generally
> don't escape functions. And I keep functions reasonably short- tens of
> lines long at most...

this is certainly a very good thing to do, but some people doesn't do
this unfortunately :(

For .mli file, it's not always an advantage to have them; having 2
files to edit each time you make a modification is quite annoying..
I wish there was an inline signature ala Haskell for OCaml, something
along the line of:

=== string.ml ====
val length : string -> int
...

let length s = ...
...
==================

Jacques Garrigue

unread,
May 23, 2007, 6:19:03 PM5/23/07
to j...@ffconsultancy.com, caml...@inria.fr
From: Jon Harrop <j...@ffconsultancy.com>

> To solve GUI programming you need different constructs (events,
> message pumps etc.).
>
> Look at some of the example F# programs on our site. This Sudoku
> solver uses a worker thread to keep the GUI responsive while it
> solves puzzles:
>
> http://www.ffconsultancy.com/dotnet/fsharp/sudoku/index.html
>
> This ray tracer uses concurrency for incremental update of a responsive GUI:
>
> http://www.ffconsultancy.com/dotnet/fsharp/raytracer/index.html
>
> This particle simulator runs the simulation thread in parallel with the GUI
> thread, for real-time visualization of the particle system:
>
> http://www.ffconsultancy.com/products/fsharp_for_visualization/demo3.html
>
> In the future, I hope OCaml will support concurrency not only to handle
> parallel constructs but also to handle GUI programming elegantly. If
> there is one thing that I have been singularly impressed by from
> .NET, it is GUI programming.

But... this is exactly the kind of things for which you can already
use concurrency in ocaml. For instance, lablgtk2 provides a GtkThread
module, which lets you run the GUI in another thread, and post updates
asynchronously. This is also possible with labltk, albeit not
documented.
I do not say this is elegant in its current form, but we are limited
by the underlying library.

There are weaknesses, like the fact you cannot kill a worker thread,
but this looks like a limitation of posix threads, since you can do it
with bytecode threads.

Jacques Garrigue

Jon Harrop

unread,
May 23, 2007, 9:47:48 PM5/23/07
to Jacques Garrigue, caml...@inria.fr
On Wednesday 23 May 2007 23:14:05 Jacques Garrigue wrote:
> But... this is exactly the kind of things for which you can already
> use concurrency in ocaml. For instance, lablgtk2 provides a GtkThread
> module, which lets you run the GUI in another thread, and post updates
> asynchronously. This is also possible with labltk, albeit not
> documented.
> I do not say this is elegant in its current form, but we are limited
> by the underlying library.

I appreciate the limitations of the existing GUI libraries on Linux. I'll try
to translate some of the examples from the tutorials into F# and show you the
difference.

I'm going to let you in on a recurring dream of mine. Ever since I saw how
easy .NET makes GUI and web programming, and ever since I saw the demos of a
Windows GUI based on hardware-accelerated vector graphics in Vista, Windows
Presentation Foundation and now Silverlight, I have wanted to see this on
Linux.

The fact is, the OCaml community are extraordinarily talented and I've been
sitting on the OCaml translation of our hardware-accelerated vector graphics
engine for years. We are in the process of translating this into F# for
Windows:

http://www.ffconsultancy.com/products/fsharp_for_visualization/

and we already have customers.

Is there any chance that we can team up to produce Linux's Vista- and
Silverlight-killer and write the whole thing in OCaml?

Here are my ideas:

1. A new GUI library written in a functional style that renders controls as
vector graphics via Smoke. Everything is rendered using OpenGL but abstracted
behind Smoke.

2. Typesetting graphical IDEs for programming with integrated visualization.

3. A document format to replace HTML that provides mathematical typesetting
and embedded, scriptable 2D and 3D vector graphics, and a browser to
view/edit these documents.

Does anyone else find this idea awe inspiring?

--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?e

_______________________________________________

skaller

unread,
May 23, 2007, 10:44:25 PM5/23/07
to Jon Harrop, Jacques Garrigue, caml...@inria.fr
On Thu, 2007-05-24 at 02:38 +0100, Jon Harrop wrote:

> Here are my ideas:
>
> 1. A new GUI library written in a functional style that renders controls as
> vector graphics via Smoke. Everything is rendered using OpenGL but abstracted
> behind Smoke.

> Does anyone else find this idea awe inspiring?

Just one problem: OpenGL has a non-reentrant interface.
How anyone could be allowed to get away with this utter
garbage today I don't know. But the implication is you need
to provide a GUI server with a proper design, which requires
some work. Some operations can be done in parallel and some
must be serialised and some don't make sense unless explicitly
synchronised.

--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

_______________________________________________

Chris King

unread,
May 23, 2007, 11:24:59 PM5/23/07
to Jon Harrop, Jacques Garrigue, caml...@inria.fr
On 5/23/07, Jon Harrop <j...@ffconsultancy.com> wrote:
> 1. A new GUI library written in a functional style that renders controls as
> vector graphics via Smoke. Everything is rendered using OpenGL but abstracted
> behind Smoke.

I don't know anything about Smoke, but part of my secret plan behind
my O'Caml Reactive Toolkit project is to allow one to develop a pretty
GUI widget set using OpenGL (or Cairo or what-have-you) and have much
of the GUI functionality (such as layout management) already there.
Whether I get as far as implementing an OpenGL-based widget set in the
nine weeks I'm working with Jane St. Capital remains to be seen (I
sort of doubt it, given the amount of other work I'll have), but I'm
keeping that goal in mind as I design it so the infrastructure to
support it will be there.

(Re OpenGL reentrancy, in O'Caml RT multiple OpenGL contexts are
handled in such a way that they are invisible to the user.)

I've also been considering the possibility of writing the library in
such a way that it also compiles under F#, or compiles with a few
changes, but right now I don't know enough about F# to know whether
that's at all possible (especially since I make use of objects,
polymorphic variants, and private types for software engineering
purposes, and would like to avoid giving them up).

- Chris

Markus E.L.

unread,
May 24, 2007, 4:26:19 AM5/24/07
to caml...@yquem.inria.fr

> For .mli file, it's not always an advantage to have them; having 2
> files to edit each time you make a modification is quite annoying..
> I wish there was an inline signature ala Haskell for OCaml, something
> along the line of:
>
> === string.ml ====
> val length : string -> int
> ....

>
> let length s = ...
> ....
> ==================


let len (s :string) : int = ... ?

Regards -- M

Vincent Hanquez

unread,
May 24, 2007, 4:40:01 AM5/24/07
to Markus E.L., caml...@yquem.inria.fr
On Thu, May 24, 2007 at 10:04:21AM +0200, Markus E.L. wrote:
> let len (s :string) : int = ... ?

yes I know about this but I'ld rather create and modify an .mli than
have this horrible syntax inlined in the implementation.

The signature code (the one in sig end) is nice, and I want to use that
for describing my functions, so that implementation and description
stays reasonably distinct. OCaml let you do that inline when you
create a module in a file:

module xx : sig
....
end = struct
....
end

but for a file (which is also a module), you need to have a separate
file (a .mli) to do that.. and that's my point.

Cheers,
--
Vincent Hanquez

skaller

unread,
May 24, 2007, 5:53:28 AM5/24/07
to Vincent Hanquez, caml...@yquem.inria.fr
On Thu, 2007-05-24 at 10:32 +0200, Vincent Hanquez wrote:
> On Thu, May 24, 2007 at 10:04:21AM +0200, Markus E.L. wrote:

> OCaml let you do that inline when you
> create a module in a file:
>
> module xx : sig
> ....
> end = struct
> ....
> end
>
> but for a file (which is also a module), you need to have a separate
> file (a .mli) to do that.. and that's my point.

Can't you can fix that by:

module xx : sig .. end = struct
.
end include xx

That way all the symbols you want are in the .ml
file.

However this isn't really the same as

private val f: int -> int
let f x = ..

which can be done by:

let f (x:int):int = ..

the problem being it is invasive (you have to
edit the function decl instead of writing a
separate type decl).

--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

_______________________________________________

Vincent Hanquez

unread,
May 24, 2007, 7:30:47 AM5/24/07
to skaller, caml...@yquem.inria.fr
On Thu, May 24, 2007 at 07:51:02PM +1000, skaller wrote:
> Can't you can fix that by:
>
> module xx : sig .. end = struct
> ..

> end include xx
>
> That way all the symbols you want are in the .ml
> file.

Yes that would kind of work, however that generate an ugly signature
with ocamlc -i (I know i'm beeing difficult here ;))

> However this isn't really the same as
>
> private val f: int -> int
> let f x = ..
>
> which can be done by:
>
> let f (x:int):int = ..
>
> the problem being it is invasive (you have to
> edit the function decl instead of writing a
> separate type decl).

I like the separation personally. Haskell has it, and I found it quite neat.

Cheers,
--
Vincent Hanquez

David Teller

unread,
May 24, 2007, 9:17:34 AM5/24/07
to Richard Jones, OCaml, skaller
That's a non-argument, I'm afraid. You can't demand the (unenthusiastic)
administrator and all students to install Linux just for one lecture. I
mean, I guess I could, but for a lecture titled "Algorithmics,
Functional Programming", that's a bit drastic.

Cheers,
David


On Wed, 2007-05-23 at 11:41 +0100, Richard Jones wrote:


> On Wed, May 23, 2007 at 09:19:20AM +1000, skaller wrote:
> > On Tue, 2007-05-22 at 18:10 -0400, David Teller wrote:
> >
> > > * Students just can't install LablGtk, LablGl, Camlimage... by
> > > themselves, nor would I expect them to. A nice, centralised, installer,
> > > would be nice.
> >
> > This sound like your School's fault. Why aren't they running
> > Debian or Ubuntu?
> >
> > Because on those systems .. installing Ocaml packages is a breeze.
>

> Just what I was going to say!
>
> Hopefully it'll be a breeze on Fedora soon too.
>
> Rich.
>
--
David Teller ------------------------------------------
Security of Distributed Systems -----------------------
-- http://www.univ-orleans.fr/lifo/Members/David.Teller
----- Laboratoire d'Informatique Fondamentale d'Orleans

David Teller

unread,
May 24, 2007, 9:18:30 AM5/24/07
to skaller, OCaml
On Wed, 2007-05-23 at 09:16 +1000, skaller wrote:
> On Tue, 2007-05-22 at 18:10 -0400, David Teller wrote:
>
> > * Error messages of the type system are somewhat obscure.

[...]

> I understand that is may be hard, if not impossible, to implement,
> as it would require a unification engine that could manage
> source references in parallel with deductions .. still the information
> IS available originally.

I tend to believe that there is a simple solution to the problem (I
haven't looked at Dan Grossman's paper yet): re-run the typing of the
last function and print out the hypothesis and each unification as it
happens.

> I bet this would be an interesting and valuable PhD project,
> and, IMHO, without it type inferencing languages are useless
> in industry.

I concur.

> Type errors in Ocaml code are very common for the
> simple reason they're just about the only error you can make :)

:)

David Teller

unread,
May 24, 2007, 9:20:21 AM5/24/07
to William D. Neumann, OCaml
Indeed, but not in Appendix V, "Index of types" and "Index of values".
Which is the right place to look for this kind of information.

Cheers,
David

On Tue, 2007-05-22 at 16:22 -0600, William D. Neumann wrote:
> On Tue, 22 May 2007, David Teller wrote:
>
> > * Type 'option' doesn't appear in the list of types of the
> > documentation. Nor do 'Some' and 'None' appear in the list of values.
>
> Huh? It's there in section 19.1 of the manual -- Built-in types and
> pre-defined exceptions.
>
> William D. Neumann

David Teller

unread,
May 24, 2007, 9:29:24 AM5/24/07
to Loup Vaillant, caml...@yquem.inria.fr
On Wed, 2007-05-23 at 10:03 +0200, Loup Vaillant wrote:
> On Tue, 22 May 2007, David Teller wrote:
>
> > * That's not OCaml-specific but there must be some construction better
> > suited than "for" or "while" to write loops without having to handcode a
> > recursive loops. Right now, I can't think of anything better than a
> > "hidden" Y combinator, but there must be something.
>
> What about map fold, filter, and the like? Sure, they are somewhat
> specialized, but most can be rewritten for many data structures.
> If you are really desperate, You can write The Recursive Loops
> (terminal and not terminal, 3 lines each). But I guess you tried.

I was thinking about a fold specialised in integers. But with a "better"
syntax and semantics than either fold (i.e. no anonymous functions) or
for (i.e. no reliance on references). Of course, I don't have such a
construction at hand.

> > * Some students rely too much on references.
>
> If they are used to for and while loops, they will think more often in
> terms of references (as I did). Then, we have the array, a collection
> of references. Do you think your students could learn some purely
> functional data structures instead? Should they?

There is such a thing as relying *too much* on references.

> > * Anonymous functions are still beyond most of them.
[...]
> Did your students used map and fold-like functions much? These almost
> require anonymous functions.

That's the thing: anonymous functions are not natural for them, hence
map, fold et al. are not natural.

Regards,
David

David Teller

unread,
May 24, 2007, 9:29:38 AM5/24/07
to Jon Harrop, caml...@yquem.inria.fr
On Wed, 2007-05-23 at 00:39 +0100, Jon Harrop wrote:
> Fascinating. Thanks for reporting the information. If I might be so brash as
> to comment on the problems you had that have already been fixed by F#:

I mentioned F# to them, by the way. Somewhere along the lines of "It looks
good, it might be the future, unfortunately, at the moment, you need Windows and 400€
worth of Visual Studio to try it".


> There are two possibilities here:
>
> You want to use Windows => Use F#, Visual Studio and F# for Visualization and
> not OCaml.
>
> You want good free software => Use Linux and not Windows.

Not my call, unfortunately. So far, I have no budget, and Windows.

> > * Error messages of the type system are somewhat obscure. [...]

> F# currently has better graphical throwback of inferred type information but
> slightly worse messages, IMHO.

Good to know. Can I get this graphical throwback without VS ?

> OCaml is
> largely undocumented (the compiler, several code libraries, the top-level,
> camlp4). There is some additional documentation (e.g. my book) but you must
> pay for it.

There's no way I'm going to demand additional purchases from my
students.

> > * Arrays of arrays (of arrays...) are a bit obscure for students,
> > although they're getting better at it.
>
> F# provides multidimensional arrays, arbitrary-size arrays, immutable arrays,
> resizeable arrays, allows array subscript syntax to be overloaded and is
> faster than OCaml on array code. Arrays are a real weak point of OCaml ATM,
> along with div and mod, functors, concurrency and some other things.

Div and mod ? How so ?


> If you want your students to be future proof then you would do well to prepare
> them for massively parallel computing on CPUs with hundreds or even thousands
> of cores. OCaml it completely ill-equipped for this. In contrast, F# provides
> native threads/locks/semaphores/threads/threadpools inherited from .NET as
> well as async programming via extra syntax. Concurrency is beautiful in F#
> and it works today.

Well, I didn't have enough time to tell them much about threads et al. I
just had time to mention their existence.

Plus I tend to believe that the OCaml-style future looks more like
JoCaml (or Acute, or Oz, or Erlang) than like semaphores.

Cheers,

Brian Hurt

unread,
May 24, 2007, 9:42:46 AM5/24/07
to Jon Harrop, caml...@inria.fr
Jon Harrop wrote:

>On Wednesday 23 May 2007 20:27:24 Robert C Fischer wrote:
>
>
>>...and locks and threads are not a viable long-term solution to the
>>problem of concurrency in general.
>>
>>
>
>Absolutely, that's why we have parallel iter, map, fold etc.
>
>

The problem is not so much expressing the parallelism (especially
data-level parallelism), it's dealing with the consequences- especially
the race conditions and deadlocks that result. How do you gaurentee
that the function passed into the parallel iter, map, or fold is
appropriately reentrant?

>Functional programming is not a panacea. GUI programming is one application
>area where functional programming, immutability and the parallelizable
>constructs that I just mentioned are not so beneficial.
>
>To solve GUI programming you need different constructs (events, message pumps
>etc.).
>
>
>

Yep. The advantage of data-level parallelism is that it scales with the
amount of data. You can always use more processors simply by throwing
more data at the program. The problem is that it is of limited
applicability, and that a lot of problems don't fit well (or at all) in
it. The advantage of event/message based parallelism is that it is more
widely applicable, the problem is that it doesn't scale- if you write
your ap with N threads, it'll use up to about N processors- but the
N+1st processor will be useless. This is a problem because the current
proper formulation of Moore's law is that the number of processors
available is doubling every 18-24 months (maybe faster).

Brian

Richard Jones

unread,
May 24, 2007, 9:54:48 AM5/24/07