Re: Teaching bottomline, part 3: what should improve.

Re: Teaching bottomline, part 3: what should improve.

[Dan Grossman]

 >>  * 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

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

[Loup Vaillant]

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

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

[David Teller]

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

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

[Loup Vaillant]

2007/5/23, David Teller <David.Teller@ens-lyon.org>:
> 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
[...]
> > What about map fold, filter, and the like? Sure, they are somewhat
[...]
>
> 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.

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.

Another solution to your problem is to use a Lisp syntax, and write
the appropriate macros (and go explain what a macro is...). :)

> > > * 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.

Ah. Well, are they sometimes incapable of solving a problem in a pure
functional way? Is it just harder? By the way, for how long have they
been exposed to imperative languages before your course?

regards,
Loup

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

[Jon Harrop]

On Thursday 24 May 2007 17:30:56 Loup Vaillant wrote:
> It sounds like you need some kind of macro which can encapsulate a
> chunk of code into an anonymous function like :

Might be worth going F# compatible here:

> for_each i : my_list
> begin
>   i*2
> end
> (* map (fun i -> i*2) my_list *)

  [for i in my_list -> i*2]

To be honest, this kind of syntactic sugar doesn't wash with me. I just end up 
using functions everywhere.

> Problem : works only on lists (or arrays, depending of your choice).

You can generate arrays and lazy sequences using a slightly different syntax:

  [|for i in my_list -> i*2|]
  {for i in my_list -> i*2}

> And a Haskell like syntax for creating lists would help. (something
> like [0..10]).

Range comprehensions:

  [0 .. 10]

Also, with increments:

  [10 .. -2 .. 0]

And over lazy sequences, hence the factorial example:

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

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

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

[David Teller]

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

accumulate acc = 0 with i traversing my_list
begin
 acc+i
end

...

where "traversing my_list" is a value with 'a lazy list, or something
similar. Nothing then prevents from using different styles of
"traversing" to provide left-to-right or right-to-left list traversal,
or array traversal...

Cheers,
 David

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

[Loup Vaillant]

2007/5/24, David Teller <David.Teller@ens-lyon.org>:
> 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 :
> >[...]
>
> Or perhaps
>
> map i traversing my_list
> begin
>   i*2
> end
>
> accumulate acc = 0 with i traversing my_list
> begin
>  acc+i
> end
>
> ...

Discussing of syntactic sugar, I prefer Jon's syntax : more concise,
and no ugly "begin end" (I hate those, and I proposed them only
because I lacked a better Idea).

Another solution, no macro of any kind required : why not explain map
and fold as mere syntactic constructions?

Sure, such a syntax looks a bit weird, but you can then wait before
explaining anything about anonymous functions.

Your students could just know they have some construction to iterate
over a list, some other to select some elements of a list, and some
other to accumulate a list on something through a computation.

When complaints arise about such an awful syntax, have them implement
map, filter, and fold. You may have to make clear that the first
argument is a function.

Personally, I'd begin by the latter part (implementation), so the
former are useless. My brother is currently in his first year in
college, and he is studying Caml light. I'll try to have him implement
map.

 cheers,
Loup

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

[Markus E.L.]

> 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

Teaching bottomline, part 3: what should improve.

[David Teller]

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