[Caml-list] Teaching bottomline, part 3: what should improve.
David Teller
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
> * 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
> 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
> * 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
> * 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
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
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
>> * 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
> * 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
> 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
> 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
> (...)
>> * 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
>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
> 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
> 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
> 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
>
> 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
> 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
>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
> 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").
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
to figure out what function person A is using.
Robert C Fischer
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
> 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
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
> ... 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
> ...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
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
> ...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
> 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
> 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
> 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
> 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
> 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.
> 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
> 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
> 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
> 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
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
> On Tue, 2007-05-22 at 18:10 -0400, David Teller wrote:
>
[...]
> 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
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
> On Tue, 22 May 2007, David Teller wrote:
>
> > 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
> 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
>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
> 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.
Live CDs might be a solution ...
Building a custom Live CD isn't too easy, although apparently there
are sites which do it now.
Rich.
--
Richard Jones
Red Hat
_______________________________________________
Jon Harrop
> 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.
You realise this is as easy as putting a Knoppix CD in your drive and
rebooting into Linux directly from the CD?
If you can't afford anything and they can't afford anything then this is
easily your best course of action.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?e
_______________________________________________
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.
Heck no, I'd demand they eradicate Windows entirely,
it has no place in institutions of any kind.
One sensible government has already banned closed
source software in all departments (Peru).
There really is NO excuse for publically funded institutions
to continue to waste taxpayer money on insecure operating
environments which don't meet the most basic principles
or western democracy, namely open government. Since it
is software that implements most decisions of the legislature,
the software should be open to public scrutiny, and
the principle should descend to other institutions which
are expected to be accountable.
Universities should take the lead, because in the event
of a problem they have inhouse resources -- namely students --
who can fix them.
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
_______________________________________________
Robert Fischer
for my presentation on Test Driven Development with OCaml for Agile
2007 -- I don't have a Mac or a Linux laptop kicking around (former is
too expensive, latter won't get wireless working for me), but I
definitely want to be in Linux for development.
So, if you're willing to wait until the early Augustish timeframe, I
might have just such a LiveCD to share.
Robert Fischer
IT Firefighter
Smokejumper Consulting
Jon Harrop wrote:
> On Wednesday 23 May 2007 14:04:06 David Teller wrote:
>
>> 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.
>>
>
> You realise this is as easy as putting a Knoppix CD in your drive and
> rebooting into Linux directly from the CD?
>
> If you can't afford anything and they can't afford anything then this is
> easily your best course of action.
>
>
_______________________________________________
David Teller
simplified, declarative, UI creation. Aims to be slightly more readable
and customisable than [what I've seen of] your work, Chris, but based
essentially on the same ideas.
If this module interface brings anything interesting, I'll be sure to
warn the list.
On the other hand, I'd be very interested in participating to the
development of a functional, cross-platform, GUI library that could be
deployed with OCaml.
Cheers,
David
skaller
> 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".
You do? Doesn't it run on Visual Studio Express .. which is
completely free?
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
_______________________________________________
Jon Harrop
> 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".
This blog entry implies that F# works with free editions of Visual Studio:
http://grammerjack.spaces.live.com/blog/cns!F2629C772A178A7C!156.entry
I'll try F# on a machine without the commercial Visual Studio ASAP and see if
I can get it working.
> So far, I have no budget, and Windows.
Could they boot the machines into Linux at the start of each lecture?
> Can I get this graphical throwback without VS ?
I do not believe so although there are some free IDEs:
http://sourceforge.net/projects/sharpedit/
> Div and mod ? How so ?
Div and mod by constants are not optimized by the OCaml compiler, which can
lead to pathological performance on some programs (e.g. sieve, sudoku).
> Plus I tend to believe that the OCaml-style future looks more like
> JoCaml (or Acute, or Oz, or Erlang) than like semaphores.
Except for Erlang, none of those languages have a significant number of users
today. I haven't tried Erlang but it may be worth a look.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?e
_______________________________________________
David Teller
besides the internal HD. Still, I might be able to convince the
administrator to let me boot on CD.
Thanks for the suggestion,
David
On Thu, 2007-05-24 at 15:00 +0100, Jon Harrop wrote:
> On Wednesday 23 May 2007 14:04:06 David Teller wrote:
> > 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.
>
> You realise this is as easy as putting a Knoppix CD in your drive and
> rebooting into Linux directly from the CD?
>
> If you can't afford anything and they can't afford anything then this is
> easily your best course of action.
>
_______________________________________________
Robert Fischer
that boots whenever its loaded (to explain what you just did to your
student's computer and where their Windows went) isn't too bad. I'd
suggest the "Knoppix Hacks" book from O'Reilly for help on this.
I'd be willing to do this as a moonlighting gig, if someone had some
budget to burn.
Robert Fischer
IT Firefighter
Smokejumper Consulting
Richard Jones wrote:
> On Wed, May 23, 2007 at 09:04:06AM -0400, David Teller wrote:
>
>> 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.
>>
>
> Live CDs might be a solution ...
>
> Building a custom Live CD isn't too easy, although apparently there
> are sites which do it now.
>
> Rich.
>
>
_______________________________________________
Loup Vaillant
> 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
Jon Harrop
> 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
_______________________________________________
David Teller
> 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
Loup Vaillant
> 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
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
ols...@verizon.net
> On Wednesday 23 May 2007 21:20:57 David Teller wrote:
>
> > 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".
>
> This blog entry implies that F# works with free editions of Visual Studio:
>
> http://grammerjack.spaces.live.com/blog/cns!F2629C772A178A7C!156.entry
>
> I'll try F# on a machine without the commercial Visual Studio ASAP and see if
> I can get it working.
>
Strictly speaking, F# only needs a .net runtime (Microsoft's or mono)
to run.
There is an entirely optional Visual Studio plugin, that is really,
really nice, but you can write and compile programs without the IDE
stuff. I've been running it on a machine without visual studio using
emacs and tuareg mode (although as much as it pains me to say it,
emacs can be a big entry barrier for students).