[Caml-list] OCaml popularity

[Caml-list] OCaml popularity

[Graham Guttocks]

Greetings,

I discovered OCaml on Doug Bagley's computer shootout page where he
gives it a rave review over all the other languages he evaluated.

After looking into it further, I'm just surprised that OCaml isn't
more popular.  It seems to have all the rapid development features of
a scripting language like Python, but unlike scripting languages
offers fast native code like a compiled language.  Seemingly the best
of both worlds.

Any ideas why OCaml isn't more well known?  Is it just because the
language is not as old as something like Python, or perhaps because
the syntax is more difficult to learn?

=====
Regards,
Graham

http://mobile.yahoo.com.au - Yahoo! Mobile
- Check & compose your email via SMS on your Telstra or Vodafone mobile.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml popularity

[Paul Steckler]

=?iso-8859-1?q?Graham=20Guttocks?= wrote:
> Any ideas why OCaml isn't more well known?  Is it just because the
> language is not as old as something like Python, or perhaps because
> the syntax is more difficult to learn?

It's certainly not a question of age.  OCaml is derived from 
the Caml language, developed back in the 1980's.

-- Paul

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml popularity

[Gerd Stolpmann]

Am Fre, 2003-03-07 um 00.27 schrieb Graham Guttocks:
> Greetings,
> 
> I discovered OCaml on Doug Bagley's computer shootout page where he
> gives it a rave review over all the other languages he evaluated.
> 
> After looking into it further, I'm just surprised that OCaml isn't
> more popular.  It seems to have all the rapid development features of
> a scripting language like Python, but unlike scripting languages
> offers fast native code like a compiled language.  Seemingly the best
> of both worlds.
> 
> Any ideas why OCaml isn't more well known?  Is it just because the
> language is not as old as something like Python, or perhaps because
> the syntax is more difficult to learn?

I suppose it has to do with the label "functional language", and
these languages are often seen as toys of academic people. I.e. nothing
for the real programmer. Not really sexy.

(Don't try to explain your colleagues the lambda calculus, and that
O'Caml is just an instance of it. This is the wrong way. You get answers
like that the lambda calculus is THE thing they have never understood at
university. There is a learning barrier.)

Of course, this is not true. O'Caml is also an unorthodox imperative
language, and it is attractive enough for some adventures at night
(don't take this too seriously).

I don't think it is the syntax. People are programming in C, with a
really strange syntax, and they take the C syntax as a natural way to
express algorithms. I hear only few complaints about that, so I think
most people just take syntax as it is.

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
------------------------------------------------------------

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml popularity

[Brian Hurt]

On 11 Mar 2003, Gerd Stolpmann wrote:

> I don't think it is the syntax. People are programming in C, with a
> really strange syntax, and they take the C syntax as a natural way to
> express algorithms. I hear only few complaints about that, so I think
> most people just take syntax as it is.

Most of my responses have been off list, but for this I feel compelled to 
respond on-list :-).

C is a category killer language.  For what it is good for, I cannot 
envision a language that would be sufficiently better than C to make it 
worth learning, let alone implementing.

Note that it's category is 'low-level' programming- embedded software, 
operating systems, device drivers, the higher level parts of the BIOS, 
etc.  Code banging directly on hardware.

C is a very low-level language, very close to the hardware in important
ways.  It is, in essence, a model of the Von Neumann architecture.  While
still maintaining some semblance of portability and structure.  C is a
great choice for when the alternative is assembler.

Note that if you're not at this level, it's idiotic to be using C IMHO.  
Things which are plusses at the hardware level become minuses at any other 
level- for example, explicit memory management.  Explicit memory 
management is *required* (for example) in situations where not all memory 
is equal- for example, in many OSs (like Windows, HP-UX, and others) you 
have swappable memory and nonswappable memory.  And your interrupt 
handlers had better never touch swappable memory.  Or if the memory is 
actually a memory mapped I/O device.  Etc.  But if you're not working at 
that level, explicit memory management is only good for introducing bugs.

This is no one perfect programming language.  

Brian


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml popularity

[Nicolas Cannasse]

> I discovered OCaml on Doug Bagley's computer shootout page where he
> gives it a rave review over all the other languages he evaluated.
>
> After looking into it further, I'm just surprised that OCaml isn't
> more popular.  It seems to have all the rapid development features of
> a scripting language like Python, but unlike scripting languages
> offers fast native code like a compiled language.  Seemingly the best
> of both worlds.
>
> Any ideas why OCaml isn't more well known?  Is it just because the
> language is not as old as something like Python, or perhaps because
> the syntax is more difficult to learn?

There is few beginnings of answers two your question :
- some people are telling that you need a PhD to fully understand (and
appreciate) OCaml . That's somehow exagerate, but not so much, since you
need to know at least several programming languages to really understand how
Ocaml is great compared to them :)
- about the syntax, I had some experience of teaching Ocaml to some people,
plus my own Ocaml-learning experience. The current syntax take some time to
get, but is quite good and brief once you got it. But you have to really
understand the underlying typing algorithm when you got a type error. I
think this is perhaps the biggest problem with OCaml syntax right now :
while C/Java will tell you " missing ';' " , Ocaml will simply said " Syntax
Error ". The same goes for typing. Just make write few lines to a beginner,
he will hit into something like " this expression has type unit -> string
but is here used with 'a -> unit" ( quite an obvious error message for
people here, but perhaps a little bit difficult to get when you don't know
the language )

Nicolas Cannasse

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml popularity

[Pierre Weis]

[...]

To briefly answer your question: I think Caml is not so popular
because there were no big company or extremely important and
successful tool to advertize it all over the place (like Sun did for
Java or Unix for C). In short, Caml is more and more recognized as a
powerful and well-crafted language among expert programmers, but it is
almost unknown to the general audience.

> There is few beginnings of answers two your question :
> - some people are telling that you need a PhD to fully understand (and
> appreciate) OCaml . That's somehow exagerate, but not so much, since you
> need to know at least several programming languages to really understand how
> Ocaml is great compared to them :)

You're right: it seems that people need to suffer a lot by programming
(bugs) in C or Java before they really appreciate Objective Caml.

> - about the syntax, I had some experience of teaching Ocaml to some people,
> plus my own Ocaml-learning experience. The current syntax take some time to
> get, but is quite good and brief once you got it. But you have to really
> understand the underlying typing algorithm when you got a type error. I
> think this is perhaps the biggest problem with OCaml syntax right now :
> while C/Java will tell you " missing ';' " , Ocaml will simply said " Syntax
> Error ".

In this case, you should try camlp4 (ocamlc -pp camlp4o): it very
often gives a fairly good hint about the syntax error (although you
have to know something about the Caml AST to fully benefit from the
error report).

> The same goes for typing. Just make write few lines to a beginner,
> he will hit into something like " this expression has type unit -> string
> but is here used with 'a -> unit" ( quite an obvious error message for
> people here, but perhaps a little bit difficult to get when you don't know
> the language )

You are also right: this language has to be taught before being
profitably used. The darker side of this fact is that conversely, you
have to learn it. This may be the main drawback of Objective Caml:
there is no ``Objective Caml for dummies''. That may be the price to
pay to use a powerful and theoretically well-founded language.

As a long time Caml teacher, I used to start the course with a small
introductory speech that roughly goes like that: «you're smart guys,
all of you; today you are smart {\em and} lucky, since you get the
opportunity to learn the smartest programming language I know, so
smart that it could change your way of thinking about programs and
computers. Indeed, it will not be easy, but you will gain a lot of new
ideas from Caml and this is worth the effort!»

After such an introduction, some students are afraid and some are
enthousiastic; after a while, they all discover that this is plain
true: learning Caml is indeed profitable to the way you deal with
programming problems, but on the other hand, yes, it is not so easy !

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis/


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml popularity

[Guillaume Marceau]

On Mon, 2003-03-10 at 18:48, Gerd Stolpmann wrote:
> 
> I suppose it has to do with the label "functional language", and
> these languages are often seen as toys of academic people. I.e.
> nothing for the real programmer. Not really sexy.


What about Python and Ruby? They were both heavily influenced by 
functional programming, yet they do not appear to carry the "toy
functional language" stigma. 

Is Ocaml special in that respect?


On Tue, 2003-03-11 at 05:23, Pierre Weis wrote:
> [...]
> 
> To briefly answer your question: I think Caml is not so popular
> because there were no big company or extremely important and
> successful tool to advertize it all over the place (like Sun did for
> Java or Unix for C). In short, Caml is more and more recognized as a
> powerful and well-crafted language among expert programmers, but it is
> almost unknown to the general audience.
> 

Well, since we cannot do much about Ocaml's lack of buzz-word laden
marketing campaign, maybe we should look at other indicator of language
success and work of those.


I believe most of today's mainstream language kick started their
popularity with a killer app :


   C was once the only language you could hack Unix with

   Java had web applets

   Perl had regular expressions

   Visual Basic had that really nice beginner-friendly dialog box editor

   PHP does server side web page generation.

   Tcl had Tk


We could strive to find (or develop) something ocaml can do that cannot
be done with any other mainstream language. Or, alternatively, something
that is an order or two faster in ocaml than in any other language. So
easy in fact, that the time time saved on a single project offsets the
time cost of learning the rudiments ocaml [*]. 

While writing these lines reminds me of Todd Proebsting's presentation
at LL2. 
    http://ll2.ai.mit.edu/talks/proebsting.ppt
Among other things, he offered a starter list of domains which are
begging for better support at the programming language level. If only we
could nail one of them solid...



One other unrelated observation on language acceptance:

In the the industry, they accept new languages as their IDE become
usable. Somehow, a solid IDE has become the sign that the language
matured and is now stable enough for industrial usage. Also, by their
own account, industrial coders spent so much time in VC++, they are now
IDE-dependent. IDE in this context means one-key compilation, hypertext
jumps between name usages and definitions, and a tree overview of the
components of the project, context sensitive work completion and context
sensitive help, etc. Ocaml would gain at having an official IDE project
which implement these features.




[*] : Ocaml makes writing compilers a delicacy. Unfortunately, not
enough people write compilers to start a critical mass seed around it.
For now I am selling ocaml as the language of choice to do error prone
data structure gymnastics. This is rather vague and unlikely to trigger
at coder into thinking : "wow, I'm about to do error prone data
structure gymnastics! This is the perfect occasion to learn ocaml!"


-- 
  "In Google non est, ergo non est." 

- Guillaume


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml popularity

[David Brown]

On Tue, Mar 11, 2003 at 09:27:18AM -0500, Guillaume Marceau wrote:

> We could strive to find (or develop) something ocaml can do that cannot
> be done with any other mainstream language. Or, alternatively, something
> that is an order or two faster in ocaml than in any other language. So
> easy in fact, that the time time saved on a single project offsets the
> time cost of learning the rudiments ocaml [*]. 

Almost everything I've done in ocaml was an order or two faster to
develop in ocaml than it would have been in another language.  I don't
think I was at all that productive while learning ocaml, though.

Dave

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml popularity

[Fred Yankowski]

Richard Gabriel, author of the famous "Worse is Better" paper about
C/Unix vs Lisp, makes some interesting points in his recent book while
discussing his theory of what it takes for a programming language to
be accepted and evolve:

    The second mandatory feature is that the language cannot require
    mathematical sophistication from its users. Programmers are not
    mathematicians, no matter how much we wish and wish for it. And I
    don't mean sophisticated mathematicians, but just people who can
    think precisely and rigorously in the way that mathematicians can.

    For example, to most language theorists the purpose of types is to
    enable the compiler to reason about the correctness of a program
    in at least skeletal terms. Such reasoning can produce programs
    with no run-time type errors. Strict type systems along with other
    exemplary behavior, moreover, enable certain proofs about
    programs.

    Well, the average programmer might be grateful somewhere in his
    heart for the lack of run-time type errors, but all he or she
    really cares about is that the compiler can produce good code, and
    types help compiler writers write compilers that do that.

    Furthermore, types that try to do more than that are a hindrance
    to understanding. For example, abstract data types allow one to
    write programs in which the interface is completely separate from
    the implementation. Perhaps some large programming teams care a
    lot about that, but a lot of programming goes on in ones and twos,
    maybe threes. Types of this variety, with complicated syntax and
    baffling semantics, is a hindrance to programming for many of
    these folks. Sure, someday this will be important as the size of
    programming teams increases and as the level of mathematics
    education increases (no laughing, please), but today it is not.

    Inheritance and polymorphism are examples of programming language
    concepts requiring mathematical sophistication to understand.

[From "Patterns of Software", 1996, Richard P. Gabriel, chapter titled
"The End of History and the Last Programming Language"]


-- 
Fred Yankowski      fred@ontosys.com           tel: +1.630.879.1312
OntoSys, Inc	    PGP keyID: 7B449345        fax: +1.630.879.1370
www.ontosys.com     38W242 Deerpath Rd, Batavia, IL 60510-9461, USA

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] about -rectypes

[Christophe Raffalli]

[-- Attachment #1: Type: text/plain, Size: 2103 bytes --]

It would be nice to be able to use recursive types without -rectypes.
Not in general (accept too much bad programs with very strange type)
but at least in one of the two case:

- the recursive types are introduced by a recursive definition

- the "loopin types" respects a positivity condition (I have no example 
of bad programs accepted with strange types in the case ... but this is 
probably because this is not implemented).

Here is a nice program (that needs -rectypes) and this is a pitty :-)

----------

(*
   a very short representation of ordinals up to epsilon_0 as a fixpoint 
of list (remark: the are more than one representation for each ordinals:
   [[];[[]]] = [[[]]] != [[[]];[]] ) *)
*)
type ord = ord list

let rec compare  (o1:ord) (o2:ord) = match o1, o2 with
   | [], [] -> 0
   | [], _ -> -1
   | _, [] -> 1
   | x::o1', y::o2' ->
       match compare x y with
	-1 -> compare o1' o2
       | 1 -> compare o1 o2'
       | 0 -> compare o1' o2'

let lesseq o1 o2 = compare o1 o2 <= 0

(* compute the simplest form of an ordinal*)
let rec normalize (o1:ord) =
   let rec add l x =
     let x = normalize x in
     match l with
       [] -> [x]
     | y::l' -> if lesseq x y then x::l else add l' x
   in
   List.rev (List.fold_left add [] o1)

let zero = ([] : ord)
let un = ([[]] : ord)
let deux = ([[];[]] : ord)
let omega = ([[[]]] : ord)
let deux_omega = ([[[]];[[]]] : ord)
let omega_carré = ([[[];[]]] : ord)
let omega_to_the_omega = ([[[[]]]] : ord)

(* exercise: implements addition, multiplication and exponentiation of
ordinals, as epsilon_0 is the smallest ordinals closed for these 
operation after omega *)

---------
-- 
Christophe Raffalli
Université de Savoie
Batiment Le Chablais, bureau 21
73376 Le Bourget-du-Lac Cedex

tél: (33) 4 79 75 81 03
fax: (33) 4 79 75 87 42
mail: Christophe.Raffalli@univ-savoie.fr
www: http://www.lama.univ-savoie.fr/~RAFFALLI
---------------------------------------------
IMPORTANT: this mail is signed using PGP/MIME
At least Enigmail/Mozilla, mutt or evolution
can check this signature
---------------------------------------------

[-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]

Re: [Caml-list] OCaml popularity

[Graham Guttocks]

Pierre Weis <pierre.weis@inria.fr> wrote:
>
> This may be the main drawback of Objective Caml: there is no
> ``Objective Caml for dummies''. That may be the price to pay to use
> a powerful and theoretically well-founded language.

Do you mean that such a book could not be written, or simply that it
just has not been written yet?  I personally would like to see an
``Objective Caml for dummies'' as the available introductory material
(in English) is pretty poor IMO.

> learning Caml is indeed profitable to the way you deal with
> programming problems, but on the other hand, yes, it is not so easy

In http://caml.inria.fr/FAQ/general-eng.html you said:

``Caml is a programming language, easy to learn, easy to use''.

So is it easy or not easy?

=====
Regards,
Graham

http://mobile.yahoo.com.au - Yahoo! Mobile
- Check & compose your email via SMS on your Telstra or Vodafone mobile.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml popularity (long!)

[mgushee]

On 11 Mar 2003 at 10:26, Fred Yankowski wrote:

> Richard Gabriel, author of the famous "Worse is Better" paper about
> C/Unix vs Lisp, makes some interesting points in his recent book while
> discussing his theory of what it takes for a programming language to
> be accepted and evolve:
> 
>     The second mandatory feature is that the language cannot require
>     mathematical sophistication from its users. Programmers are not
>     mathematicians, no matter how much we wish and wish for it. And I
>     don't mean sophisticated mathematicians, but just people who can
>     think precisely and rigorously in the way that mathematicians can.

That's probably true as far as it goes, but I think statements about 
what a language can or cannot *require* miss the mark a bit. I would 
argue that there are very few languages that intrinsically require 
sophisticated thinking for basic programming (I would place Prolog 
among those few, but not Ocaml--more below), but that you do need 
that precision and rigor to write great programs in any language.

But how the language is presented to the world, through 
documentation, teaching, advocacy, and the activities and attitude of 
the user community, can make a big difference.

If I may illustrate from personal experience: some time early last 
year I decided that I wanted to learn a new language, and that it was 
going to be functional. My background as a programmer is mainly in 
Python and Java, with bits of Tcl, Perl, Ruby, and Visual Basic here 
and there. Oh, and I studied Asian history in college.

Why functional? I guess it's because I had been working with XSLT
for a couple of years. There were aspects of the language that had
been very puzzling. But someone pointed out to me that XSLT was a 
functional language, and as I began learning what functional 
programming was, it all started to make sense, and I wanted more. 
However, this was not an academic exercise; I was and am convinced 
that functional programming is a powerful tool for real-world tasks. 
But having practical goals obviously places some constraints on your 
choices: you need a good selection of libraries for real-world 
programming tasks (database interface, GUI, text processing, 
graphics, system interface, and so on), and you need a language that 
can be learned in a reasonable time period. So Prolog was clearly out 
;-)

My first stop was Erlang, partly because it was developed by and for 
industry. But that didn't last too long. Ericsson's OTP interpreter 
(or VM? I can't remember) was horribly slow, the selection of 
libraries was poor, there doesn't seem to be a serious effort to 
integrate Unicode into the core platform, and the documentation was 
abysmal (mostly disorganized rather than incomplete, I suppose, but 
incoherent information isn't much better than none).

Then I found Haskell. It was a good learning experience, but after a 
few weeks of intensive study and experimentation, my feeling was: 
"Yes, Haskell, you are the One True Language. Now go away and let me 
get some work done." Though I really appreciated Haskell on a 
conceptual level, there were two major reasons I gave up on it. One 
was that, although there is a reasonable selection of libraries, when 
you look closely you find that many of them are suffering from bit-
rot; in fact, the Haskell community seems to be dominated by 
academics who feel no need to develop generally useful tools. That's 
fine, but not what I was looking for.

My other big problem with Haskell was ... you guessed it: monads! I 
must have read every introduction to monads that's available on line 
(and there are at least half a dozen), but I still don't really 
understand them. Without monads, you can't do any real work in 
Haskell, and monads are universally acknowledged to be a difficult 
concept. Yet every introductory text I have seen on Haskell insists 
that you learn the theory of monads before you can learn how to do 
things like I/O.

Since I don't understand monads, maybe I'm missing something, but 
this insistence on theory before practice seems like pure dogma to 
me. I've even seen two or three Haskell tutorials that open with 
statements to the effect that "I could teach you how to write a 
Hello, World program, but I won't, because then you wouldn't 
understand why Haskell is so great."

I don't buy that argument--at least I don't accept that it's 
universally true. People have different learning styles, but many 
learn best by doing. I don't know how typical I am, but I find that a 
good experience working with a new language naturally leads to a 
desire for deeper understanding.

Which brings me around, finally, to OCaml. The main reasons I like 
OCaml and will probably stick with it are:

  OCaml and its community are focused on promoting good design and  
  good programming practices, but not on enforcing theoretical  
  orthodoxy. Knowledge about OCaml is freely available to those who 
  want to learn; they don't have to think in any certain way;

  There is a good selection of libraries available. Certainly there 
  are some gaps, but OCaml has up-to-date tools for a wide variety of 
  common programming tasks; and, on a related note:

  OCaml seems to have momentum. Though the language isn't wildly 
  popular, useful applications and libraries are being developed all 
  the time; there is something new almost every week.
  
>     Furthermore, types that try to do more than that are a hindrance
>     to understanding. For example, abstract data types allow one to
>     write programs in which the interface is completely separate from
>     the implementation. Perhaps some large programming teams care a
>     lot about that, but a lot of programming goes on in ones and twos,
>     maybe threes. Types of this variety, with complicated syntax and
>     baffling semantics, is a hindrance to programming for many of
>     these folks.

I wonder. It seems to me that the need for sophisticated program 
design stems mainly from the complexity of the problem. He also seems 
to be saying that larger teams are smarter ... because they have more 
bodies? My experience is just the opposite: the small teams I've 
known are smarter because every member is highly skilled and internal 
communications are easier. 

Let me propose an alternate (and perhaps somewhat cynical) view. 
Companies that employ large programming teams tend to favor Java. 
They may or may not be aware that there are other languages that 
foster much higher productivity. But Java is good for large teams, 
partly because its rigid OO paradigm means there are relatively few 
ways to structure a program, so managers can assign tasks with 
relative ease. Also, Java keeps everyone busy.

Now, suppose someone were to propose that a large team adopt a 
"smarter" language, such as OCaml. Well, either all team members can 
handle it, or they can't. If some people can't handle it, then you 
have to either lay them off or find other work for them to do. Big 
problem for management. But what if all team members *can* handle it? 
What if they all love their new language? That may sound good, but 
now suddenly you have a large team full of highly motivated 
developers finishing their assigned tasks in half the time it used to 
take them. Then what? Probably some will just get bored, but others 
will start wanting to get more involved with the "big picture." Also 
a big problem for management.

However much the business press may talk about people being 
empowered, the reality is that most large corporations assume--even 
depend on the fact--that the large majority of their employees are 
mediocre. Too many people working too effectively would upset the 
status quo, and is therefore a scary thought.

So I say that Java is a corporate-friendly language, and OCaml, for 
better or worse, is not.

--
Matt Gushee
Englewood, CO USA

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml popularity

[Nicolas Cannasse]

> One other unrelated observation on language acceptance:
>
> In the the industry, they accept new languages as their IDE become
> usable. Somehow, a solid IDE has become the sign that the language
> matured and is now stable enough for industrial usage. Also, by their
> own account, industrial coders spent so much time in VC++, they are now
> IDE-dependent. IDE in this context means one-key compilation, hypertext
> jumps between name usages and definitions, and a tree overview of the
> components of the project, context sensitive work completion and context
> sensitive help, etc. Ocaml would gain at having an official IDE project
> which implement these features.

You're raising here a remanent subject :)

This had been in my mind (and also in the mind of several other people of
this list I think) since I started with OCaml. Right now, as one of the few
ocaml-windows developpers, I'm editing and compiling Ocaml under Visual
Studio 6. The language is not fully integrated since VC6 does not enable it
( while .Net can do it, but is far more expensive and more difficult to
deploy for a single basic user ). There is the workspace, syntax
highlightning, automatic compilation, one-key compilation start and
compilation-error-jump-to-file+line. So it is right now quite convenient to
work with.

An IDE will require a far more level of integration such as the possibility
to "debug" types visualy when having an error ( e.g. just put your mouse /
cursor on a variable to see its type ) , perhaps an integrated debugger ,
and of course a multiplatform (unix+windows) GUI since doing it from
unix-only won't help people from the industry and doing it for windows only
won't help the large part of the ocaml community.

The problem here is that such kind of editor is more or less a personnal
choice, and if you want the current OCaml+Emacs users to switch to such an
IDE, you'll have to make it fully customizable and add key features that
will make the difference. Quite a challenge.

Nicolas Cannasse

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Cross-platform GUI (was Re: [Caml-list] OCaml popularity)

[mgushee]

On 12 Mar 2003 at 11:32, Nicolas Cannasse wrote:

> > One other unrelated observation on language acceptance:
> >
> > In the the industry, they accept new languages as their IDE become
> > usable. 

> and of course a multiplatform (unix+windows) GUI since doing it from
> unix-only won't help people from the industry and doing it for windows only
> won't help the large part of the ocaml community.

I wonder if anyone has thought about developing an OCaml interface to 
FOX (www.fox-toolkit.org)? Though I haven't done any serious 
programming with it yet, I've tried out a couple of FOX applications, 
and was quite impressed with the quality of the interface. If you 
read the Goals & Approach statement on the Web site, it's also very 
impressive.

I think OCaml + FOX could be a winning combination. Unfortunately, I 
don't know C++, or I'd write the wrapper myself. But if anyone else 
feels like taking it on, I'm happy to help with testing and 
documentation.

--
Matt Gushee
Englewood, CO USA

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] OCaml popularity

[Alex Romadinoff]

[-- Attachment #1: Type: text/plain, Size: 3127 bytes --]

Nicolas,
 
Why should we switch? In fact, Tuareg or ocaml-mode provides reasonable
IDE based on emacs. 
And those IDEs are much betters then those broken VC++. Really. 
In fact, I’m industry Java programmer and use emacs JDE mode with
ClearCase integration to develop out OSS product. This IDE is better
integrated into our development process than so called industry-strength
IDEs, such as IDEA and Together/J. 
 
I think, emacs provides good framework for building such standard IDE,
and all things, you mentioned, could be easily implemented in it.
 
Alex
 
 
-----Original Message-----
From: Nicolas Cannasse [mailto:warplayer@free.fr] 
Sent: Wednesday, March 12, 2003 5:32 AM
To: Guillaume Marceau; caml-list@inria.fr
Subject: Re: [Caml-list] OCaml popularity
 
> One other unrelated observation on language acceptance: 
> 
> In the the industry, they accept new languages as their IDE become 
> usable. Somehow, a solid IDE has become the sign that the language 
> matured and is now stable enough for industrial usage. Also, by their 
> own account, industrial coders spent so much time in VC++, they are
now 
> IDE-dependent. IDE in this context means one-key compilation,
hypertext 
> jumps between name usages and definitions, and a tree overview of the 
> components of the project, context sensitive work completion and
context 
> sensitive help, etc. Ocaml would gain at having an official IDE
project 
> which implement these features. 
You're raising here a remanent subject :) 
This had been in my mind (and also in the mind of several other people
of 
this list I think) since I started with OCaml. Right now, as one of the
few 
ocaml-windows developpers, I'm editing and compiling Ocaml under Visual 
Studio 6. The language is not fully integrated since VC6 does not enable
it 
( while .Net can do it, but is far more expensive and more difficult to 
deploy for a single basic user ). There is the workspace, syntax 
highlightning, automatic compilation, one-key compilation start and 
compilation-error-jump-to-file+line. So it is right now quite convenient
to 
work with. 
An IDE will require a far more level of integration such as the
possibility 
to "debug" types visualy when having an error ( e.g. just put your mouse
/ 
cursor on a variable to see its type ) , perhaps an integrated debugger
, 
and of course a multiplatform (unix+windows) GUI since doing it from 
unix-only won't help people from the industry and doing it for windows
only 
won't help the large part of the ocaml community. 
The problem here is that such kind of editor is more or less a personnal

choice, and if you want the current OCaml+Emacs users to switch to such
an 
IDE, you'll have to make it fully customizable and add key features that

will make the difference. Quite a challenge. 
Nicolas Cannasse 
------------------- 
To unsubscribe, mail caml-list-request@inria.fr Archives:
http://caml.inria.fr 
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ:
http://caml.inria.fr/FAQ/ 
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners 

[-- Attachment #2: Type: text/html, Size: 13537 bytes --]

Re: [Caml-list] OCaml popularity (long!)

[Diego Olivier Fernandez Pons]

    Bonjour,

> My other big problem with Haskell was ... you guessed it: monads! I
> must have read every introduction to monads that's available on line
> (and there are at least half a dozen), but I still don't really
> understand them.

Monads are not specific to Haskell and they may be useful in many
other situations than IO in a lazy context. FFTW and FFTW-GEL both use
monads for graph traversal (even if I think afterwards it may not be
the best way).

I will try to explain monads briefly and in a non-academic manner,
since all academic explainations seem to have failed.

When you write a program, you usually have some data x and functions f
and g that you apply over your data

let x1 = f x
let x2 = g x1

Which we will write g (f x)

In functional languages, functions are first class citizens and then
you can use them as if they were data. You can do this transformation
(which I will call duality) in an explicit manner :

let dual = function x -> (function f -> f x)

Instead of writing g (f x) we will have  (dual x) (g o f) where the
'o' stands for composition

let (o) = fun f g -> (function x -> g (f x))

You can write all your programs in this 'higher-order' style. We will
use a small example I have already used in a precedent post on
continuation passing style

let rec min_list_rec m= function
  | [] -> m
  | x :: tail when x < m -> min_list_rec x tail
  | _ :: tail -> min_list_rec m tail

val min_list_rec : 'a -> 'a list -> 'a = <fun>

let min_list = function
  | [] -> failwith "the list is empty"
  | x :: tail -> min_list_rec x tail

val min_list : 'a list -> 'a

This is the 'level 0' style.

To transform it to a 'higher-order' style we will use the 'min'
function and a 'list-traversal' function as basic data

let rec list_traversal f = function
  | [] -> failwith "empty list"
  | [x] -> x
  | x :: tail -> f x (list_traversal f tail)

val list_traversal : ('a -> 'a -> 'a) -> 'a list -> 'a

let min_list = list_traversal min

min_list : 'a list -> 'a

The computation may be seen in the following way

let f1 = F f
let f2 = G f1
 ...

fn (x)


Why would you want to do something like this ?

When you write in a functional language f x y, the order in which the
two arguments will be evaluated in undefined. When you want to do IO
this may be a problem : which data will be printed first ?

On the other hand, the higher order style has a defined order : when
you write g o f, f will always be evaluated before g.

Then several solutions are available :

- Write your code with explicit sequences : f x y => f2 (f1 x y)
  where f1 does the first operation, f2 the second one.

- use a built-in sequence operator (Caml sequence ';')

- use a built-in higher order tool (Haskell monads, Scheme
continuations)

One more thing, you will find two classical 'higher order' styles :
monadic style and continuation passing style

let rec min_list_rec f = function
  | [] -> failwith "empty list"
  | [x] -> f x
  | x :: tail -> min_list_rec (fun y -> f (min x y)) tail

val min_list_rec : ('a -> 'b) -> 'a list -> 'b

let min_list = min_list_rec (function x -> x)

What is the difference ?

Roughtly, in monadic style you only apply on the right (dual x) (f (g
(h))),in CPS you can apply on the left or the right (dual x) (h (f
(g))).

This is achived by giving you one more parameter, the 'continuation'
of the current computation. In my 'min_list' example the continuation
is just the identity function.

Monads also need some 'algebraic' properties, the correct mathematical
formalisation is the theory of categories (Saunders Mac Lane, Samuel
Eilenberg)

Wadler has shown that in fact CPS and monads are equivalent (you can
simulate each one with the other one). The combination with lazy
evaluation (which can also be done in Caml) can give strange monads
like 'backtracking monad' (Wadler) which may be used to implement
backtracking searches, embedding a Prolog in a functional language
(Hinze). This can be also achieved by CPS like Screamer, a Lisp
preprocessor that rewrittes backtracking function in CPS (Siskind,
McAllester) or direct implementation with some kind of queue.


    Hope this helps,

        Diego Olivier

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml popularity

[Richard W.M. Jones]

On Wed, Mar 12, 2003 at 08:02:30AM +1300, Graham Guttocks wrote:
> Pierre Weis <pierre.weis@inria.fr> wrote:
> >
> > This may be the main drawback of Objective Caml: there is no
> > ``Objective Caml for dummies''. That may be the price to pay to use
> > a powerful and theoretically well-founded language.
> 
> Do you mean that such a book could not be written, or simply that it
> just has not been written yet?  I personally would like to see an
> ``Objective Caml for dummies'' as the available introductory material
> (in English) is pretty poor IMO.

Someone else actually said it well on this list a while back. There
is no "Programming Perl"-equivalent for OCaml.

And please don't start by telling me about the lambda calculus or
higher-order functions.

Start by telling me how to read and write files. How to draw a nice
picture. Go on to tell me how to access my SQL database from an
OCaml application server.

Rich.

-- 
Richard Jones, Red Hat Inc. (London, UK) http://www.redhat.com/software/ccm
http://www.annexia.org/ Freshmeat projects: http://freshmeat.net/users/rwmj
PTHRLIB is a library for writing small, efficient and fast servers in C.
HTTP, CGI, DBI, lightweight threads: http://www.annexia.org/freeware/pthrlib/

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml popularity

[Alwyn Goodloe]

 I agree. This is really the difference between what most people do in
industry and what we do in academia. People out there just don't care
about how well you can build an automated theorem prover if they can't
draw their GUI screens and access their Oracle data bases. I think this is
why people will say it takes a while to be productive in OCAML. If you
want to read and write files, access the DB, and draw a screen, then you
probably have to go beyond most introductions to OCAML. Unfortunately,
most developers will just stop there. A book akin to the O Riley Java
networking book would be great as well. There is a lot of cool OCAML stuff
out there for networking - hopefully someone will write a book to spread
the news.

  On the other hand there really isn't a good intro to CS in OCAML book in
English. The good texts combiled with the DrScheme environmnet is a big
reason for the use of Scheme at many Universities in the US.

Alwyn

agoodloe@gradient.cis.upenn.edu

On Wed, 12 Mar 2003, Richard W.M. Jones wrote:

> On Wed, Mar 12, 2003 at 08:02:30AM +1300, Graham Guttocks wrote:
> > Pierre Weis <pierre.weis@inria.fr> wrote:
> > >
> > > This may be the main drawback of Objective Caml: there is no
> > > ``Objective Caml for dummies''. That may be the price to pay to use
> > > a powerful and theoretically well-founded language.
> >
> > Do you mean that such a book could not be written, or simply that it
> > just has not been written yet?  I personally would like to see an
> > ``Objective Caml for dummies'' as the available introductory material
> > (in English) is pretty poor IMO.
>
> Someone else actually said it well on this list a while back. There
> is no "Programming Perl"-equivalent for OCaml.
>
> And please don't start by telling me about the lambda calculus or
> higher-order functions.
>
> Start by telling me how to read and write files. How to draw a nice
> picture. Go on to tell me how to access my SQL database from an
> OCaml application server.
>
> Rich.
>
> --
> Richard Jones, Red Hat Inc. (London, UK) http://www.redhat.com/software/ccm
> http://www.annexia.org/ Freshmeat projects: http://freshmeat.net/users/rwmj
> PTHRLIB is a library for writing small, efficient and fast servers in C.
> HTTP, CGI, DBI, lightweight threads: http://www.annexia.org/freeware/pthrlib/
>
> -------------------
> To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
> Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml popularity

[Max Kirillov]

On Wed, Mar 12, 2003 at 11:32:09AM +0900, Nicolas Cannasse wrote:
> This had been in my mind (and also in the mind of several other people of
> this list I think) since I started with OCaml. Right now, as one of the few
> ocaml-windows developpers, I'm editing and compiling Ocaml under Visual
> Studio 6. The language is not fully integrated since VC6 does not enable it
> ( while .Net can do it, but is far more expensive and more difficult to
> deploy for a single basic user ). There is the workspace, syntax
> highlightning, automatic compilation, one-key compilation start and
> compilation-error-jump-to-file+line. So it is right now quite convenient to
> work with.
> 
> An IDE will require a far more level of integration such as the possibility
> to "debug" types visualy when having an error ( e.g. just put your mouse /
> cursor on a variable to see its type ) , perhaps an integrated debugger ,
> and of course a multiplatform (unix+windows) GUI since doing it from
> unix-only won't help people from the industry and doing it for windows only
> won't help the large part of the ocaml community.
> 
> The problem here is that such kind of editor is more or less a personnal
> choice, and if you want the current OCaml+Emacs users to switch to such an
> IDE, you'll have to make it fully customizable and add key features that
> will make the difference. Quite a challenge.
> 
> Nicolas Cannasse

There is ocamlbrowser in the distribution. It can typecheck and then be
the type browser as you mention it. I dont know how much of it works on
Windows (I surely have seen it started), but the functionality you want
should not be very os-depended. It is based on analysis of typed tree
after successful typecheck.

As a first step, one writing the VS (or whatever) plugin could just
start from here and take some code from ocamlbrowser.

To go further, there are 2 points.

First, there would be nice to dump a typed tree just like the parsetree
by -dparsetree option. It should be easy to do. Then, you can read the
output and do whatever you want with it.  (though, it is doubtful
parsing the output to use it in VS-ish ides is easier than adding a
IDE-specific reporter to the compiler)

Then, this all OK when there are no errors. But, when there are some
(and this it what is mostly wanted for IDE), typechecking is aborted and
no information if returned. So, it would be great to have possibility to
freeze the typechecking (or even force it further), getting as much
information as possible.  Then, one could see the inferred types and
easily locate the point where they goes wrong. Currently, locating a
typing error it an iterative process -- I insert explicit type
constraint here and there, then compile, then just stare at output and
think, then again. If I could look at typedtree at the moment the typing
error was detected, I suppose this will be much faster.

-- 
Max

P.S. btw, is the "typecheck at error" done for the other languages. I
know there are alot of languages support for the VS. How many of them
cat acquire information from a wrong source?

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml popularity

[Martin Weber]

On Fri, Mar 07, 2003 at 12:27:31PM +1300, Graham Guttocks wrote:
> Greetings,
> 
> I discovered OCaml on Doug Bagley's computer shootout page where he
> gives it a rave review over all the other languages he evaluated.
> (...)

Yes, that's where I stumbled over Ocaml for the first time, too ...

> After looking into it further, I'm just surprised that OCaml isn't
> more popular.

I'm not. Exaggerating:

Most programmers are idiots, and idiots won't be able to appreciate
the good things - they take the language which fits their intellectual
base. Still wondering why tons of people program in perl ? :)

> (...)
> Any ideas why OCaml isn't more well known?  Is it just because the
> language is not as old as something like Python, or perhaps because
> the syntax is more difficult to learn?

Bluntly, why should Ocaml be known more ? I'm programming in about a
dozen languages, and I don't give a **** about whether the language
is known or not. If it needs a run-time environment and I gotta deliver,
fine, then they gotta install the run-time environment too. As long as
it's not java you're delivering, they can even download it via the 'net
and still live to see it finishing :)

>From all the things I judge a language, its popularity is nothing
I'm looking at. Well, okay, it can serve to amuse me. The popularity
of lisp for example ("lisp is dead" (yeah - as dead as I am)), or that
of perl (@{%$}!!) ...

On the syntax bit, I think it's just sad that ocaml requires different
special operators for different arguments, that's about it which might
drive off new people.  (why +. ? Can't 'a + 'a be enough for integer, 
bignum, rational, float, string, whatsoEVER addition ? sigh ...).

regards,

-martin

PS: I'm using perl and java myself, so just making sure that you get
that this is no flamebait. If you can't help yourself, cat > /dev/null.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml popularity

[Xavier Leroy]

> Exaggerating:
> 
> Most programmers are idiots, and idiots won't be able to appreciate
> the good things - they take the language which fits their intellectual
> base. Still wondering why tons of people program in perl ? :)

On a loosely related note, see the article at
        http://archive.salon.com/21st/feature/1998/05/cov_12feature.html
titled "The dumbing-down of programming", and subtitled "Rebelling
against Microsoft, 'My Computer' and easy-to-use wizards, an engineer
rediscovers the joys of difficult computing."  The beginning is a bit
of a rant, but still "rediscovering the joys of difficult computing"
isn't a bad line for Caml :-)

- Xavier Leroy

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml popularity (long!)

[Max Kirillov]

On Tue, Mar 11, 2003 at 12:47:56PM -0700, mgushee@havenrock.com wrote:
> My other big problem with Haskell was ... you guessed it: monads! I 
> must have read every introduction to monads that's available on line 
> (and there are at least half a dozen), but I still don't really 
> understand them. Without monads, you can't do any real work in 
> Haskell, and monads are universally acknowledged to be a difficult 
> concept. Yet every introductory text I have seen on Haskell insists 
> that you learn the theory of monads before you can learn how to do 
> things like I/O.
> 
> Since I don't understand monads, maybe I'm missing something, but 
> this insistence on theory before practice seems like pure dogma to 
> me. I've even seen two or three Haskell tutorials that open with 
> statements to the effect that "I could teach you how to write a 
> Hello, World program, but I won't, because then you wouldn't 
> understand why Haskell is so great."
> 
> I don't buy that argument--at least I don't accept that it's 
> universally true. People have different learning styles, but many 
> learn best by doing. I don't know how typical I am, but I find that a 
> good experience working with a new language naturally leads to a 
> desire for deeper understanding.

I wonder, why people are so troubled by monads. I suppose the answer is:
bacause they try to "understand" it. But there are really nothing to
understand! You don't need to have PhD in math or read Leibnitz to use
the IO monad, and the IO monad is the only monad a beginner could
need (list/maybe monads looks like just incidental thing to me; ST s
monads are very similar to IO monads, and can, for a beginners, be
replaced by it; the only I can recall now is monad of parsers, but,
consider, it is not an introductory question at all).

This is very simple:

Values in haskell are not a "contents of variables" or omething like
this; they are values in concept. Function (that is to produce them),
can therefore be called just anytime compiler will decide it to do. They
can be executed multiple time (e.g. when inlined) or not executed at
all, when we don't need the value. Beacause of that, Haskell functions
can not represent actions.

Instead, that does values of type IO a.  A notion "IO a" means "make
something, and provide a [way to compute] value of type a". Note here:
not "a -> IO b", but "IO a" -- action without an argument is quite
meaningful thing.  For example, (counter :: IO Integer) produces
infinitely increasing numbers. (time :: IO Double) returns time in some
units, or (is_connected :: IO Bool) reports, is, for example, our
program connected to the server and so on. Gong back to ocaml, I would
say that "IO a" is roughly equivalent to "unit -> 'a" (indeed, "(unit ->
'a Lazy.t) Lazy.t" would be more right). Now remember, have you ever had
to add the "unit" argument to your ocaml functions (in fact, not very
often -- since ocaml is strict, there's always a possibility to use some
of real argument to trigger the execution).

To use actions, there must be a way to combine them. There are operators
">>" and ">>=". The first combines two actions in an action, which is a
sequence of them. The second form is intended to propagate the results
of execution to the succeeding actions. It combnes an action of type IO
a and function taking a value of type a and producing an action, which,
when executed, first executes the first action, then takes it result,
computes the second action and executes it.

"do" notation inteded to make the sequences of action look similar to
the imperative languages.

Since a program is definetly an action, your main function must have
type "IO something". It really does: "IO ()" -- takes nothing, doing
something, produces nothing.

That's just all. Is it so hard?

> --
> Matt Gushee
> Englewood, CO USA

-- 
Max

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] Monads was OCaml popularity

[Christophe Raffalli]

[-- Attachment #1: Type: text/plain, Size: 2073 bytes --]


> My other big problem with Haskell was ... you guessed it: monads! I 
> must have read every introduction to monads that's available on line 
> (and there are at least half a dozen), but I still don't really 
> understand them. Without monads, you can't do any real work in 
> Haskell, and monads are universally acknowledged to be a difficult 
> concept. Yet every introductory text I have seen on Haskell insists 
> that you learn the theory of monads before you can learn how to do 
> things like I/O.
> 

Maybe if people where calling monads by their real name: quasi-morphism 
:-) that would be better !

- A monad M is given by a mapping M from type to type,

a function apply : M (a -> b) -> M a -> M b

and a function unit : a -> M a

such that unit (f a) = apply (unit f) (unit a)

- A real morphism M would be given by a mapping M from type to type,

a function unit : a -> M a

such that unit (f a) = (unit f) (unit a)

But this to be true enforces
M (a -> b) = M a -> Mb otherwise the previous equation makes no sense.
So monads introduces apply to be less restrictive : the equation
M (a -> b) = M a -> M b is replaced by a function
apply : M (a -> b) -> M a -> Mb

But when you see that, it is like morphism in math. There are very few 
result true for a morphism/monads, and when you use a specific monad, 
you may/have better to forget that this is a monad (do you really need 
to know that x |-> exp x is a group morphisme to use it even if this is 
an important remark ?)

PS: the bindlib library for data-types with bound variables is a monad 
<http://www.lama.univ-savoie.fr/~raffalli/bindlib.html>

-- 
Christophe Raffalli
Université de Savoie
Batiment Le Chablais, bureau 21
73376 Le Bourget-du-Lac Cedex

tél: (33) 4 79 75 81 03
fax: (33) 4 79 75 87 42
mail: Christophe.Raffalli@univ-savoie.fr
www: http://www.lama.univ-savoie.fr/~RAFFALLI
---------------------------------------------
IMPORTANT: this mail is signed using PGP/MIME
At least Enigmail/Mozilla, mutt or evolution
can check this signature
---------------------------------------------

[-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]

Re: [Caml-list] OCaml popularity

[Michael Schuerig]

On Wednesday 12 March 2003 19:08, Alwyn Goodloe wrote:
>  I agree. This is really the difference between what most people do
> in industry and what we do in academia. People out there just don't
> care about how well you can build an automated theorem prover if they
> can't draw their GUI screens and access their Oracle data bases.

Is software development in industry only about GUI screens, web pages 
and database access? Well, from my own experience, I fear the answer is 
mostly yes. That being as it is, would things in industry be that much 
better if OCaml had everything it takes for writing enterprise 
applications? Could OCaml in this area bring such a big improvement 
over, say, Java and J2EE? Or are there other -- niche? -- areas where 
the advantages OCaml provides are far more important?

Michael

-- 
Michael Schuerig                  Failures to use one's frontal lobes
mailto:schuerig@acm.org           can result in the loss of them.
http://www.schuerig.de/michael/   --William H. Calvin

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml popularity

[Martin Weber]

On Wed, Mar 12, 2003 at 11:34:34PM +0100, Michael Schuerig wrote:
> (...)
> Is software development in industry only about GUI screens, web pages 
> and database access? Well, from my own experience, I fear the answer is 
> mostly yes. 

I'm working next to asic designers, and they give a shit about the web,
database access and guis :) They want scriptability and a clean programming
interface instead ... (and yeah, they appreciate good guis).

On the other hand, they are electrical engineers, so I guess they are not
too keen on learning yet another language - most proprietary tools they
use offer tcl as the scripting language, so that's a de facto standard -
and they're not interested in typing(1) around either ... as soon as it works
it's fine :) (see pentium bug - it's still there... but patched:-)) 

> That being as it is, would things in industry be that much 
> better if OCaml had everything it takes for writing enterprise 
> applications? 
> (...)

I don't know what usually classifies as 'enterprise application' but I
think what I'm doing is one - application(s) written solely for the use
within the producing corner - no end user will ever see it (except if
we release the stuff as opensource, but that's still being debated :).

That said, in *my* environment I don't think (oca)ml really has any
chance against tcl and/or perl, just because those two (or especially
tcl) are so simple. And I don't think that it can be the intention of
ocaml to get that simple as is tcl...

On the other hand, *I* could write the application in Ocaml, plugging
in both C extensions and (on that way, too) a tcl interpreter while
enabling an ocaml toplevel for the savvy.... hmmm.... 

but you know.. inherit a ton of C code..

regards,

-martin (taking another couple of notes for the 2.0)

(1) not as in inputting text into the computer, but stumbling over
beginner errors like my beloved +. :)

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml popularity

[Daniel Bünzli]

> Someone else actually said it well on this list a while back. There
> is no "Programming Perl"-equivalent for OCaml.

Books have both the advantage and disadvantage to end in a (more or 
less) well structured exposition of whole topic.

Very often what is needed is a way to figure out how you can do this or 
that in the language along with relevant pointers in the documentation 
graph. This is why I think that a bunch of well edited online tutorials 
would do a better job; assuming that the reader has a minimal knowledge 
of the language, something like the first two chapter of the ocaml 
reference manual with a little more details.

Besides, tutorials can show good programming style, features of the 
language, how to set up things (e.g. make a new toplevel), give 
background for newbies (e.g. Pcre is a good alternative to Str), etc. I 
guess the top level would make that kind of tutorials very enjoyable, 
both to write and read.

 From simple things --- not too long --- to more complex ones with a 
very well defined and pleasing goal.

 > Using the socket interface. Show how to build your dummy little 
server.
 > Using regular expressions (pcre) and i/o. Show how to install the lib 
and implement a grep.
 > Accessing a database.
 > Using the thread library.
...

And well,
 > Show how to write a lambda calculus interpreter.

Just little things to help you start playing.

Daniel

P.S. See for example the tutorials available on www.oreilly.com (e.g. 
the ones on cocoa / objective-c programming). Of course it's about book 
promotion there, but some tutorial are not bad.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml popularity

[Michael Schuerig]

On Thursday 13 March 2003 00:13, Martin Weber wrote:
> I don't know what usually classifies as 'enterprise application' but
> I think what I'm doing is one - application(s) written solely for the
> use within the producing corner - no end user will ever see it

In my experience, the term "enterprise application" is not used 
generically for all custom or behind-the-scenes application used in an 
enterprise. Rather, it's used more specifically for applications that 
handle large amounts of data managed in databases; stuffing data into 
and getting it out of a DB and accomodating business processes while 
doing so.

I've been working on this kind of software for a couple of years and 
can't say that I'm particularly attracted to it. To be sure, I 
recognize that there are interesting aspects to it, but it's not what I 
myself find interesting. Also, as I said before, I don't see that OCaml 
provides a decisive advantage for *this* kind of software.

Michael

-- 
Michael Schuerig              The usual excuse for our most unspeakable
mailto:schuerig@acm.org         public acts is that they are necessary.
http://www.schuerig.de/michael/                      --Judith N. Shklar

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml popularity

[Brian Hurt]

On Wed, 12 Mar 2003, Michael Schuerig wrote:

> On Wednesday 12 March 2003 19:08, Alwyn Goodloe wrote:
> >  I agree. This is really the difference between what most people do
> > in industry and what we do in academia. People out there just don't
> > care about how well you can build an automated theorem prover if they
> > can't draw their GUI screens and access their Oracle data bases.
> 
> Is software development in industry only about GUI screens, web pages 
> and database access? Well, from my own experience, I fear the answer is 
> mostly yes. 

Comming from the industry- mostly, yes.  Completely, no.

> That being as it is, would things in industry be that much 
> better if OCaml had everything it takes for writing enterprise 
> applications? Could OCaml in this area bring such a big improvement 
> over, say, Java and J2EE? Or are there other -- niche? -- areas where 
> the advantages OCaml provides are far more important?
> 

I could easily see an Ocaml J2EE.  If you read the vapor in the right way, 
.NET could be considered a language-agnostic J2EE (that already has it's 
own Ocaml-variant in F#).  Having had some experience with Microsoft, 
Microsoft's products, and Microsoft's history of product announcements, 
I'd recommend a wait and see approach.  However, the concept is doable in 
theory.

It's hard to estimate how ignorant the "bottom of the barrel" programmers 
are.  My father was teaching a class recently, attempting to teach OO 
programming to a bunch of Cobol programmers in Visual Basic (that last 
wasn't mentioned until after he had signed on).  He was a more than a 
little surprised when programmers with decades of 'experience' didn't know 
what a for loop was.  Twenty years in the industry, and they'd never had 
to use one.

Of course, this also raises the question of what a programmer is.  I have
a friend who considers herself a technical writer/buisness analyst.  For
one reason or another, she does an awful lot of Visual Basic scripting.  
She doesn't use for loops either- on the other hand, she also doesn't
consider herself a programmer, let alone an experienced senior software
engineer.

Brian


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml popularity

[Brian Hurt]

On Thu, 13 Mar 2003, Daniel Bünzli wrote:

> Very often what is needed is a way to figure out how you can do this or 
> that in the language along with relevant pointers in the documentation 
> graph. This is why I think that a bunch of well edited online tutorials 
> would do a better job; assuming that the reader has a minimal knowledge 
> of the language, something like the first two chapter of the ocaml 
> reference manual with a little more details.

I have a theory (backed up with a fair bit of circumstancial evidence) 
that a large number of purchasing decisions are influenced by the number 
of running feet of books in the local bookstore are dedicated to the 
topic.  The theory is (as I infer it) 'if I have a problem, I'll simply 
buy a book to tell me how to solve it.  After all, look at all of these 
books!  Surely one of them will be what I need!'

Having *the* perfect introductory book is actually a detriment, as 
it discourages other books from entering the field, thus reducing your 
runnning foot total.  Likewise, being intuitive or easy to understand is 
also a detriment, as this makes both for fewer books and for slimmer 
books.  Much better to have multi-thousand page tomes (tombs?).  And 
naturally, you can't measure running feet of web pages :-).

Brian


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] monads for dummies

[james woodyatt]

[followups redirected to ocaml_beginners@yahoogroups.com]

On Tuesday, Mar 11, 2003, at 11:47 US/Pacific, mgushee@havenrock.com 
wrote:
>
> [...] My other big problem with Haskell was ... you guessed it: 
> monads! I
> must have read every introduction to monads that's available on line
> (and there are at least half a dozen), but I still don't really
> understand them. [...]

I'm a self-taught "programmer" with no formal education in mathematics 
or computer science, and I found the monad concept to be fairly 
difficult to learn.  It took a leap of consciousness that feels about 
the same level of difficulty as what I remember needing to get through 
my high school calculus class.

I've been seeing a lot of attempts to explain the theory lately, but 
most of them remind me of the kind of thing that I found more confusing 
than helpful when I was trying to get my head around the practical 
matters.  What I really wanted is a Monads For Dummies tutorial.

Here's what I remember being the crucial tip that got me over the hump: 
if you are working with immutable data structures (and there are at 
least three in the Ocaml standard library: Map, Set and List), then the 
monadic programming style can be really useful for composing 
complicated functions for manipulating the contents of those data 
structures from assemblies of simpler functions.

Without the monadic programming style, you end up concocting huge 
specialized functions for passing into the higher-order standard 
library functions, e.g. fold, map, filter, etc., and achieving any kind 
of modularity requires careful design work.  The problem can quickly 
become hard enough that learning monadic programming starts to seem 
like a decent trade.

Once you start using immutable data structures in complex ways (e.g. 
doing lots of weird transformations on 'a list values), you may find 
that writing your functions as monads will help you modularize your 
program, allowing you to encapsulate and reuse computations that would 
otherwise be duplicated in scattered fragments of code all over the 
place.  (Alternatively, you may want to use mutable data structures 
instead, which is always a popular way out of this problem.)

If you discover your immutable data structure manipulations are getting 
out of hand, and you want to reorganize your code for better 
encapsulation and reusability-- without changing them to use mutable 
data structures instead-- then I recommend learning about the 
continuation monad first.

Here is the signature of a module I use for the continuation monad in 
Ocaml:

   type ('x, 'a) t = ('a -> 'x) -> 'x

   (* let ( >>= ) m f x = m (fun a -> f a x) *)
   val ( >>= ): ('x, 'a) t -> ('a -> ('x, 'b) t) -> ('x, 'b) t

   val return: 'a -> ('x, 'a) t          (* let return x f = f x         
      *)
   val lift: 'x -> ('x, 'a) t            (* let lift x _ = x             
      *)
   val cont: ('x -> 'x) -> ('x, unit) t  (* let cont f g = f (g ())      
      *)
   val eval: ('x, unit) t -> 'x -> 'x    (* let eval m x = m (fun () -> 
x)    *)

By using this module, I can make new continuations (functions of type 
'x -> 'x) by composing appropriate instances of the continuation monad 
type and binding them with functions that chain the results of previous 
computations into the subsequent computations.

For a very simple example: if you have a bunch of continuation 
functions, e.g. f1, f2, f3 each of type 'x -> 'x, then you can compose 
them in sequence like so:

	let m: ('x, unit) t =
	  cont f1 >>= fun _ ->
	  cont f2 >>= fun _ ->
	  cont f3

In fact, it might be easier to represent f1, f2 and f3 as their monads 
to begin with:

	let m1: ('x, unit) t = cont f1
	let m2: ('x, unit) t = cont f2
	let m2: ('x, unit) t = cont f3

	let m: ('x, unit) t =
	  m1 >>= fun _ ->
	  m2 >>= fun _ ->
	  m3

This defines a new instance of the continuation monad type, but it 
isn't exactly the composed continuation function yet.  You *evaluate* 
the monad to get the continuation it represents:

	let f: 'x -> 'x = eval m

The 'return' function is also sometimes called the 'unit' function (but 
'unit' is a reserved word in Ocaml, so I like to avoid it).  It 
constructs a monad that passes a value through the ( >>= ) operator to 
the function that constructs a new monad value with it.  It's good for 
use in monad functions that take input from "outside" the encapsulation 
and pass it along to other monads.

The 'lift' function is a variant of the 'cont' function which ignores 
the 'x value that is input from any previous computation and produces 
the 'lifted' value as output.  It's good for use in monad functions 
that initialize (or reinitialize) the encapsulated value of the monad.  
I probably should have named it 'init' instead.

If I were writing a book on using monads for dummies, I'd launch here 
into a series of useful examples showing how to use monads to simplify 
very complicated list manipulation functions.  The example above is too 
simple to show the power of monadic programming adequately.  I don't 
have the time, but it's certainly something that needs to be done.

The continuation monad is only the beginning.  There are several 
fundamental types of monad, and it's possible to combine them into 
composites to support more operations, e.g. state manipulation, 
exception handling, backtracking, etc.  Once you understand how to use 
monads in a systematic design, you can take better advantage of the 
support for pure functional programming available in the Ocaml language.

In lieu of my writing a long list of examples, here is a paper that I 
found immensely helpful in the learning process:

	<http://www.math.chalmers.se/~augustss/AFP/monads.html>

The examples are written in Haskell, but I found them pretty easy to 
translate in my head to the equivalent Ocaml.

Warning: you don't have to go down this path very far before you will 
begin to chafe at the "operator overloading" problem.  You can't define 
a ( >>= ) operator that will be good for all monad types.  I don't know 
how to explain exactly why.  You just can't.  Some folks have proposed 
that "extensional polymorphism" would be very helpful  in helping solve 
the problem.  I buy that.

Warning2: since Ocaml strictly evaluates all the arguments to a 
function before executing it (unless the argument is of type 'a 
Lazy.t), you really can't define a proper ( >> ) operator for your 
monads.  It won't work the same as the one in Haskell, because Ocaml 
evaluates the right operand before it's needed, and you don't buy 
anything by fixing it so that it takes a Lazy.t value instead.

If what I've written isn't very helpful to you, then please tell me so 
I know not to try to explain this stuff to people.  On the other hand, 
if it *is* helpful, that would be nice to know too.


-- 
j h woodyatt <jhw@wetware.com>
that's my village calling... no doubt, they want their idiot back.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml popularity

[Graham Guttocks]

Martin Weber <Ephaeton@gmx.net> wrote:
>
> Most programmers are idiots, and idiots won't be able to appreciate
> the good things - they take the language which fits their
> intellectual base.

This may be a bit harsh, but I understand your sentiment. How about
the group in between the idiots and the language specialists? i.e,
folks who _would_ appreciate OCaml if they were exposed to it and had
some better teaching tools available?

> Bluntly, why should Ocaml be known more ?

Notoriety leads to a greater userbase which has many trickle-down
effects such as external suggestions and contributions, conferences,
additional funding, etc. all of which improve the language and insure
its future. The benefits of opensource are all about getting the code
into more hands. You lose all of these if OCaml remains obscure and
shrouded in mystery.

Look, I'm not talking about turning OCaml into a commercially driven
behemoth like Java folks. I'd just like to see OCaml get the exposure,
support, credit, etc. I think it deserves.

=====
Regards,
Graham

http://mobile.yahoo.com.au - Yahoo! Mobile
- Check & compose your email via SMS on your Telstra or Vodafone mobile.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml popularity

[William Lovas]

On Wed, Mar 12, 2003 at 05:12:43PM +0000, Richard W.M. Jones wrote:
> On Wed, Mar 12, 2003 at 08:02:30AM +1300, Graham Guttocks wrote:
> > Do you mean that such a book could not be written, or simply that it
> > just has not been written yet?  I personally would like to see an
> > ``Objective Caml for dummies'' as the available introductory material
> > (in English) is pretty poor IMO.
> 
> Someone else actually said it well on this list a while back. There
> is no "Programming Perl"-equivalent for OCaml.

What about the O'Reilly book, "Developing Applications With Objective
Caml"?  It's not perfect yet, but the preliminary translation from the
French is available at:

    http://caml.inria.fr/oreilly-book/html/index.html

Is this the sort of thing you're looking for?

> And please don't start by telling me about the lambda calculus or
> higher-order functions.

The O'Reilly book starts in Chapter 2 with the basics of functional
programming.  This makes sense because that's really what sets O'Caml
apart from other more mainstream languages.

> Start by telling me how to read and write files.

Chapter 3 goes into the imperative aspects, including I/O.

> How to draw a nice picture

Chapter 5: The Graphics Interface.

> Go on to tell me how to access my SQL database from an
> OCaml application server.

Not quite -- but Chapter 6 has several example applications, including one
that models a simple database.

The rest of the book has a very practical feel to it, constantly grounding
itself in real-world examples and applications.


Like i said, it's not quite ideal at this point, but i'm surprised nobody's
mentioned it yet.  Would it help O'Caml's cause, do you think, if O'Reilly
were to polish this up and publish it?

cheers,
William

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Haskell-like syntax (was: [Caml-list] OCaml popularity (long!))

[Oleg]

While we are on the subject of Haskell, has anyone thought about creating a 
Haskell-like syntax for O'Caml? I don't know Haskell, but its syntax appeals 
to me very much.

Oleg

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml popularity

[Graham Guttocks]

William Lovas <wlovas@stwing.upenn.edu> wrote: 

> What about the O'Reilly book, "Developing Applications With
> Objective Caml"?

[...]

> Like i said, it's not quite ideal at this point, but i'm surprised
> nobody's mentioned it yet.

I'm not that surprised.  I got nothing out of the book when I tried to
read it.  It reads like a reference manual, so it may be of more use
once I've learned the language, but it's not an adequate introductory
text IMO.

Despite its brevity, I got more out of:
http://caml.inria.fr/FAQ/stephan.html

Then I did the first several sections of the O'Reilly translation.
This clear, explanatory style was much easier to digest.

=====
Regards,
Graham

http://mobile.yahoo.com.au - Yahoo! Mobile
- Check & compose your email via SMS on your Telstra or Vodafone mobile.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] monads for dummies

[Christopher Quinn]

whoops! i should have read your piece further.
you clearly have a handle on the matter - i just took issue with some 
of your preliminary statements!

sorry,
- chris

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml popularity

[Alessandro Baretta]

Michael Schuerig wrote:
> On Thursday 13 March 2003 00:13, Martin Weber wrote:
> 
> 
> I've been working on this kind of software for a couple of years and 
> can't say that I'm particularly attracted to it. To be sure, I 
> recognize that there are interesting aspects to it, but it's not what I 
> myself find interesting. Also, as I said before, I don't see that OCaml 
> provides a decisive advantage for *this* kind of software.

Actually, I must say that it does provide THE decisive 
advantage over all other tools I reviewed, at least in terms 
of Web applications. After developing the Xcaml sytem, which 
is currently on Sourceforge--and wanting a little bugfix 
update, coming up--my company is now able to release a new 
custom "enterprise application" to the customer in more or 
less one week's time.

The Xcaml system, which is basically nothing other than 
XML/HTML-embedded Ocaml, is giving us the edge to give our 
customers whatever they ask for the moment they ask for it.

I think that Ocaml is a little more than the "the tool of 
choice for the discriminating hacker": it's tool of choice 
for professional business software development, at least if 
your employees are endowed with a measure of cognitive 
abilities. It does take a little thinking to get the hang of 
Ocaml--and Xcaml equivalently--but not that much after all. 
Hey, it's an imperative language at the end!

Alex

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml popularity

[Pierre Weis]

> Pierre Weis <pierre.weis@inria.fr> wrote:
> >
> > This may be the main drawback of Objective Caml: there is no
> > ``Objective Caml for dummies''. That may be the price to pay to use
> > a powerful and theoretically well-founded language.
> 
> Do you mean that such a book could not be written, or simply that it
> just has not been written yet?  I personally would like to see an
> ``Objective Caml for dummies'' as the available introductory material
> (in English) is pretty poor IMO.

I tried a lot to figure out what such a book could be; unfortunately I
still don't know.

> > learning Caml is indeed profitable to the way you deal with
> > programming problems, but on the other hand, yes, it is not so easy
> 
> In http://caml.inria.fr/FAQ/general-eng.html you said:
> 
> ``Caml is a programming language, easy to learn, easy to use''.
> 
> So is it easy or not easy?
>
> Graham
> 
> http://mobile.yahoo.com.au - Yahoo! Mobile
> - Check & compose your email via SMS on your Telstra or Vodafone mobile.

Oups! Well spotted :)

Hence, I should be a bit more precise: my feeling is that Caml is easy
to learn (and indeed in some sense, I think it is a true pleasure to
learn Caml). But, as I tried to say in the preceeding message, it is
also mandatory to learn it. In other terms, grasping Caml needs some
efforts from you. It is not difficult or painful but you must do this
effort. So, on the one hand, it is not difficult which means «it's
easy». On the other hand, you have to think and learn some new
concepts; a lot of people consider this kind of activity as hard and
tedious, in a word «difficult»; so that, for them, «it's not so easy».

I hope this is clearer. In some sense the book we should write is not
«Caml for dummies» but something like «Caml for the curious» or «Caml
for the voluntary learners».

Thank you for your interesting feed-back.

Best regards,

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis/


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] how to interface with integer Bigarrays using camlidl

[francois bereux]

Hello,

I posted this question on the beginner list, but I got no answer.
I do not manage to interface a 1D Bigarray of integers with C code, using
camlidl.
Here is an example :

----- code.c ------
void linear( int* m, int* ia )
{
   int i;
   for( i=0; i< *m; i++ ) { ia[i] = i; }
}

----- bug.idl -----
void linear( [in,ref] int* m, [in,out,length_is(*m),bigarray] int ia[] );


----- test.ml -----
open Bigarray;;
open Bug;;

let lin n =
   let ia = Array1.create int32 c_layout n in
      begin linear ia; ia; end;;

------ Makefile ------
SOURCES = code.c bug.idl test.ml
LIBS = bigarray
RESULT = essai

-include $(OCAMLMAKEFILE)

----------------------------------------------------------
When I compile, I get the following error :
File "test.ml" line 7, character 12-14
This expression has type
   (int32, Bigarray.int32_elt, Bigarray.c_layout) Bigarray.Array1.t
but is here used with type
   (int, Bigarray.int32_elt, Bigarray.c_layout) Bigarray.Array1.t

As far as I understand, the kind of the array in the stub code generated by
camlidl is (int,int32_elt) kind, whereas the
int32 in my test.ml file defines a (int32, int32_elt) kind. Am I correct ? And how
can I modify my code so that it works ?
( I do not know how to define by myself an Array1 with (int, int32_elt) kind. )

If I use floats in the code, this works fine.

Any help would be appreciated,

Sincerely yours,

F. Béreux



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml popularity

[Richard W.M. Jones]

On Wed, Mar 12, 2003 at 09:15:17PM -0500, William Lovas wrote:
> What about the O'Reilly book, "Developing Applications With Objective
> Caml"?  It's not perfect yet, but the preliminary translation from the
> French is available at:
> 
>     http://caml.inria.fr/oreilly-book/html/index.html
> 
> Is this the sort of thing you're looking for?

No offence intended to the authors, but it has to be said that I
thought it an entirely unsuitable introduction to the language.  Take
a look at the section on Input/Output channels for a good (ie. bad)
example. It takes all the way through to the middle of chapter 3
before we get this section which actually tells you how to do
something practical with the language. Then to find that the
introduction to I/O channels is next to useless - I could find out the
same stuff by reading the header file. At least there's a couple of
rather artificial examples.

Rich.

-- 
Richard Jones, Red Hat Inc. (London, UK) http://www.redhat.com/software/ccm
http://www.annexia.org/ Freshmeat projects: http://freshmeat.net/users/rwmj
MAKE+ is a sane replacement for GNU autoconf/automake. One script compiles,
RPMs, pkgs etc. Linux, BSD, Solaris. http://www.annexia.org/freeware/makeplus/

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] how to interface with integer Bigarrays using camlidl

[Xavier Leroy]

> I posted this question on the beginner list, but I got no answer.
> I do not manage to interface a 1D Bigarray of integers with C code, using
> camlidl.
> [...]
> This expression has type
>    (int32, Bigarray.int32_elt, Bigarray.c_layout) Bigarray.Array1.t
> but is here used with type
>    (int, Bigarray.int32_elt, Bigarray.c_layout) Bigarray.Array1.t

You have to decide whether you want your bigarray to hold values of
type int32 (i.e. 32-bit integers) or int (i.e. Caml native integers --
31 bits on a 32-bit processor).

In the first case, change your IDL spec as follows:

void linear([in,ref] int* m,
            [in,out,length_is(*m),*int32,bigarray] int ia[] );

In the second case, change your Caml client code as follows:

let lin n =
   let ia = Array1.create int c_layout n in
      begin linear ia; ia; end;;

- Xavier Leroy

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml popularity

[Michael Schuerig]

On Thursday 13 March 2003 09:02, Alessandro Baretta wrote:
> Michael Schuerig wrote:
> > On Thursday 13 March 2003 00:13, Martin Weber wrote:
> >
> >
[database + GUI variety enterprise applications]
> > I've been working on this kind of software for a couple of years
> > and can't say that I'm particularly attracted to it. To be sure, I
> > recognize that there are interesting aspects to it, but it's not
> > what I myself find interesting. Also, as I said before, I don't see
> > that OCaml provides a decisive advantage for *this* kind of
> > software.
>
> Actually, I must say that it does provide THE decisive
> advantage over all other tools I reviewed, at least in terms
> of Web applications. After developing the Xcaml sytem, which
> is currently on Sourceforge--and wanting a little bugfix
> update, coming up--my company is now able to release a new
> custom "enterprise application" to the customer in more or
> less one week's time.

I'm not familiar with the kind of project that can be done from start to 
finish that short a time. I just can't say how common they are. But 
anyway, great if OCaml can give such a boost, there.

My experience is from projects eating up several person years of effort. 
There coding speed isn't necessarily the limiting factor.

Michael

-- 
Michael Schuerig                All good people read good books
mailto:schuerig@acm.org         Now your conscience is clear
http://www.schuerig.de/michael/ --Tanita Tikaram, "Twist In My Sobriety"

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] monads for dummies

[Christian Lindig]

[-- Attachment #1: Type: text/plain, Size: 939 bytes --]

On Wed, Mar 12, 2003 at 04:03:19PM -0800, james woodyatt wrote:
> If what I've written isn't very helpful to you, then please tell me so 
> I know not to try to explain this stuff to people.  On the other hand, 
> if it *is* helpful, that would be nice to know too.

I have some experience with the state monad but your article has sparked
my interest for the continuation monad that you explained. I would have
liked at least one example that uses some data, not just functions.

Since you seem to have quite some experience with monads, is performance
a problem? I would expect that the strict evaluation of OCaml leads to
an enormous numbers of closures in a monadic programming style,
something that might not happen in Haskell. For the same reason the
combinator style that is so poular in Haskell seems not very popular in
OCaml. The standard library not even defines a function composition
operator.

-- Christian

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[Caml-list] Re: Haskell-like syntax

[Max Kirillov]

On Wed, Mar 12, 2003 at 09:36:11PM -0500, Oleg wrote:
> While we are on the subject of Haskell, has anyone thought about creating a 
> Haskell-like syntax for O'Caml? I don't know Haskell, but its syntax appeals 
> to me very much.
> 
> Oleg

Not with camlp4. First, it does not allow '\' as a token. Second, it
does not care for whitespaces to do layout parsing.

Even trading the above (very nice) things, camlp4 is based on Stream,
which cannot support backtrack. This leads to the "keyword cancer" and
the overall syntactic ugliness, which holded be away from ocaml for a
long time. The nice Haskell syntax is more difficult to parse and, I'm
afraid, very much more difficult to extend in camlp4 way.

I'm sure, one could reuse some things of camlp4 (namely, quotations and
maybe the Fstream library) to produce the parser you want.

But, you know, haskell is nice not only due to the syntax. It has many
features which ocaml does not. Moreover, I think, that without
things like lazy computaion (and binding), very democratic patterns, type
classes, type support for purity (the damned monads) seeing just the
syntax would just make me anger:).

Talking about the single thigs: at the beginning of my way into ocaml, I
did some camlp4 hacks. For example, that was "where" keyword support
(much more powerful than in revised syntax) and some support for "from
top to bottom" style of sources. If you interested, I could post them.

-- 
Max

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml popularity

[William Lovas]

On Thu, Mar 13, 2003 at 10:52:32AM +0100, Oliver Bandel wrote:
> I/O is on page 76, where imperative programming
> is explained.
> 
> When looking into K&R's C book, it's in the first chapter
> on the first page to create a feedback from the machine
> with the well-known "hello world"-example...

Well, since C lacks a top-level read-eval-print loop, being able to
do I/O is crucially important early on.  Less so with O'Caml -- one
can get right into the interesting bits of the programming language
without having to know a wink of I/O.  The necessary evils like I/O
can wait 'til a little bit later... like Chapter 3 :)

Plus, the top-level loop approach introduces a number of important
concepts early on, like expressions, values, and types.

> When you have a functional language and say: Yes, functional
> programming is so genious, but get the I/O not before
> the chapter about imperative programming, then it looks
> not very honestly...
> 
> But adding the FP-features as a "what other languages have not"
> (or not so clear) later, this might (not proven it;-)) be
> a beter approach in making the language interesting.

You're basic objection here is that O'Caml is not being taught in the
same way that other programming languages have been taught in the past.
Should it be?  Maybe O'Caml is different enough from other programming
languages that it should be *taught* differently.

I suppose it's arguable, though, that O'Caml might be more popular if
its teaching style catered more to peoples' expectations.

William

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml popularity

[Oliver Bandel]

On Thu, Mar 13, 2003 at 03:50:11PM -0500, William Lovas wrote:
> On Thu, Mar 13, 2003 at 10:52:32AM +0100, Oliver Bandel wrote:
> > I/O is on page 76, where imperative programming
> > is explained.
> > 
> > When looking into K&R's C book, it's in the first chapter
> > on the first page to create a feedback from the machine
> > with the well-known "hello world"-example...
> 
> Well, since C lacks a top-level read-eval-print loop, being able to
> do I/O is crucially important early on.  Less so with O'Caml -- one
> can get right into the interesting bits of the programming language
> without having to know a wink of I/O.  The necessary evils like I/O
> can wait 'til a little bit later... like Chapter 3 :)

Well, for unpatient people, this is a very long time!
(Even if you have not time to work every day with
that language and that book!)


> 
> Plus, the top-level loop approach introduces a number of important
> concepts early on, like expressions, values, and types.
> 
> > When you have a functional language and say: Yes, functional
> > programming is so genious, but get the I/O not before
> > the chapter about imperative programming, then it looks
> > not very honestly...
> > 
> > But adding the FP-features as a "what other languages have not"
> > (or not so clear) later, this might (not proven it;-)) be
> > a beter approach in making the language interesting.
> 
> You're basic objection here is that O'Caml is not being taught in the
> same way that other programming languages have been taught in the past.
> Should it be?  Maybe O'Caml is different enough from other programming
> languages that it should be *taught* differently.

Yes, I have thought about that too.
Maybe programmers are - when looking at OCaml's
imperative features - not very impressed (namespace
of variables (records,..)).

Well, but on the other side, people are often very unpatient.
If the question is, to spread OCaml more, then people want
to have results fast.

E.G. scripting... some I/O-stuff right from the beginning,
and you can do some things, where you have used Perl before...

So, waiting with this until Chapter 3 may cause people
to stop learning the new language...


> 
> I suppose it's arguable, though, that O'Caml might be more popular if
> its teaching style catered more to peoples' expectations.

Yes. Shure.

But if people have to wait too long - who has the time
today to invest so much time, if not a researcher or
unemployed (or workoholic, who comes home with rectangular
eyes and again take seat in front of the computer?)

Ciao,
   Oliver

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml popularity

[Brian Hurt]

On Thu, 13 Mar 2003, Oliver Bandel wrote:

> But if people have to wait too long - who has the time today to invest
> so much time, if not a researcher or unemployed (or workoholic, who
> comes home with rectangular eyes and again take seat in front of the
> computer?)


Um, those of us who actually *care* about our craft, and realize that if 
we just learn what our job needs us to know *right now* enough to have us 
take time off to be taught it, we'll become dinosaurs?  And/or 
unemployeed, when we're replaced by someone who *did* go out and learn the 
hot new technology?

I'm assuming you meant this humorously- but it's a serious question I've 
been asked myself.

Brian


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml popularity

[Oliver Bandel]

Hi,

well, my english... :(

On Thu, Mar 13, 2003 at 10:17:02PM +0100, Oliver Bandel wrote:
> Well, for unpatient people, this is a very long time!
> (Even if you have not time to work every day with
   ^^^^\
    especially

> that language and that book!)

Ciao,
   Oliver   ( at this time exploring the Stack-module... :) )

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml popularity

[Michal Moskal]

On Thu, Mar 13, 2003 at 10:17:02PM +0100, Oliver Bandel wrote:
> E.G. scripting... some I/O-stuff right from the beginning,
> and you can do some things, where you have used Perl before...

I don't believe replacing perl scripts with ocaml ones is The Right
Thing to do... Just because in simple cases perl or sh is going to be
twice as short. OCaml mainly favors programming in large.

I know OCaml quite well, but still do scripting in perl or sh. Example:
extended lambda calculi interpreter written in OCaml + test suite
written in perl.

-- 
: Michal Moskal ::::: malekith/at/pld-linux.org :  GCS {C,UL}++++$ a? !tv
: PLD Linux ::::::: Wroclaw University, CS Dept :  {E-,w}-- {b++,e}>+++ h

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

RE: [Caml-list] OCaml popularity

[MikhailFedotov]

Hi!

> You're basic objection here is that O'Caml is not being
> taught in the same way that other programming languages have
> been taught in the past. Should it be?  Maybe O'Caml is
> different enough from other programming languages that it
> should be *taught* differently.

Key word is motivation. First visible results should be instant
and appealing in order to keep motivation. Simple programs
like "Hello world" are very important to keep motivation high.
All those samples ready to cut&paste.

As for the good practice, it's about simple tasks among the
more complex ones. The good example is "Concrete
Mathematics" by D.Knuth with its exercises, from trivial
to almost impossible - there is no single boring line.

If you forget about motivation to start (simple exersises), then it
doesn't really matter how sophiscated the language is by itself.

If you forget about motivation to progress (medum-difficulty
exersises, real tasks), then the reader will become bored.

If you forget about training how to use the language properly
for regular tasks (even just truncating the file after specified
position), then the reader will get the feeling of beautiful
academical language with no practical use. This is also
the case if all tasks were trivial and dedicated to learning
language constructs.

He will also become bored if someone will try to teach him
the theory behind the languge when all he wants is to learn
to use the language, preferrably by intuition (it is faster) using
examples.

As a summary:
1. Introduction.
2. Examples.
3. Reference manual with examples somewhere (not just grammar).

This is pretty enough... at least it works for me. :)

Mikhail


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml popularity

[Johann Spies]

On Fri, Mar 14, 2003 at 01:13:29PM +0300, MikhailFedotov wrote:

> As a summary:
> 1. Introduction.
> 2. Examples.
> 3. Reference manual with examples somewhere (not just grammar).

With at least one simple example of the usage of every available
function/type/class/module in the reference manual please.  I think
the Turbo Pascal 7 reference manual is a good example of this.

Johann
-- 
Johann Spies          Telefoon: 021-808 4036
Informasietegnologie, Universiteit van Stellenbosch

     "Let your light so shine before men, that they may see 
      your good works, and glorify your Father which is in 
      heaven."         Matthew 5:16 

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml popularity

[Markus Mottl]

On Fri, 14 Mar 2003, Michal Moskal wrote:
> I don't believe replacing perl scripts with ocaml ones is The Right
> Thing to do... Just because in simple cases perl or sh is going to be
> twice as short. OCaml mainly favors programming in large.

"Short" <> "written quickly". OCaml is certainly more verbose than
Perl or sh for scripting tasks, but this hardly adds to the development
time. Writing down a function call instead of some funny Perl-operator
only requires a second more, but makes parsing scripts much simpler
for humans.

Actually, though I have learnt it, I never use Perl: when I need to write
some really trivial script that just executes a couple of commands, I use
bash. If it's a bit less trivial, OCaml is already the better choice IMHO.

Regards,
Markus Mottl

-- 
Markus Mottl                                             markus@oefai.at
Austrian Research Institute
for Artificial Intelligence                  http://www.oefai.at/~markus

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml popularity

[Oliver Bandel]

On Fri, Mar 14, 2003 at 12:50:13PM +0100, Markus Mottl wrote:
> On Fri, 14 Mar 2003, Michal Moskal wrote:
> > I don't believe replacing perl scripts with ocaml ones is The Right
> > Thing to do... Just because in simple cases perl or sh is going to be
> > twice as short. OCaml mainly favors programming in large.
> 
> "Short" <> "written quickly".

Yes, I agree here fully.

If you had asked me this last week, I would have
a different opinion.

But I now have seen this very impressive.


> OCaml is certainly more verbose than
> Perl or sh for scripting tasks, but this hardly adds to the development
> time.

But on the first view this is not to see!
I often thought, that verbosity is annoying,
and perls "short constructs" are useful
to achieve faster development.

I recently saw that this is not the case.

But I'm shure, that it is a very common
assumption....



> Writing down a function call instead of some funny Perl-operator
> only requires a second more, but makes parsing scripts much simpler
> for humans.
[...]

ACK.


Ciao,
   Oliver

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: Haskell-like syntax

[Max Kirillov]

[-- Attachment #1: Type: text/plain, Size: 3096 bytes --]

On Fri, Mar 14, 2003 at 12:33:36AM +0600, Max Kirillov wrote:
> Talking about the single thigs: at the beginning of my way into ocaml, I
> did some camlp4 hacks. For example, that was "where" keyword support
> (much more powerful than in revised syntax) and some support for "from
> top to bottom" style of sources. If you interested, I could post them.

I'm sending the changes. Note that, though they are quite stable, I
picked them from an environment, so something may broke.

A little comment what is it.

file test_where.ml -- obvious. Very little, more to demonstrate, than to
cover all possible (and really seen) dangers.

file lazyX.ml -- misc functions to handle lazy values (see later)
note that it is already uses the extension

file where.ml -- the main thing

There are several things:

1) 'where' notation:

<expr> ::=  <expr> where { [rec] <let-binding> }
	|   <expr> where [begin] [rec] <let-binding> end

the two version are the same (some like {..}, some begin..end).
there are some unresolved quastions with prioriries, so, in practice, I
often had to use brackets. However, I think that the level I choose is
quite reasonable.

2) reorder srt_items

there are keyword 'WHERE' (uppercase) in place of structure item. At the
point, the structure (or the whole file if at toplevel) is cut, then
pieces swapped and concated again. this allows writing:

------- file.ml
main ();;
WHERE
let main () =
    do_this ();
    do_that ();;
WHERE
let do_this () =
    <.......>
and do_that () =
    <........>
------

3) lazy values predeclaration

<str-item> ::=	[let] [lazy] [rec] <let-binding>

this allows define lazy value, which is seen to the whole structure, and
not only to the following items. Every value that is binded is lazy
value, that, when forced, computes the definition. It uses the LazyX
module: nondef () produces the value, set dest src replaces the
unforced lazy value dest by the unforced lazy expression src, if any of
then is already forced (it is at module initialization time, so it's
easy to catch), the exception is raised.

I used it in plays with "functional GUI", where needed to declare many
inter-depended values and, for various reasons, didn't want to use "let
rec <...> and <...>" chain.

There is one trouble. When you define a type, and then a lazy value of
the type, the compiler complains "the type xxx would escape its scope".
this berore it comes to need to infer the type for the initial
declaration "let x = LazyX.nondef ()", where it is not yet defined.
To solve the problem, I added "HEADER" keyword. It explicitly says that
the forward declataions must be placed here instead of beginning of the
file. You place it after the type declaration. Of course the lazy values
definitions must itself follow the type declarations.

The lazy stuff is intended to work only in toplevel, it is not for
"struct..end".

I used the (1) very much, and would say it quite workable. The (2) is
also quite stable, but, now, I would say the realization needs to be
changed. The (3) are more a toy than real thing. There could be problems
with that.

-- 
Max

[-- Attachment #2: test_where.ml --]
[-- Type: text/plain, Size: 355 bytes --]


let main () =
    Lazy.force a;
    Lazy.force b;
    Lazy.force c;
    Lazy.force d

WHERE

lazy c = Int 123
lazy b = String "4567"

HEADER

lazy a = Int 123
lazy d = match Lazy.force b with Int n -> n | String s -> s2i s
    where {s2i = int_of_string}

WHERE

lazy c = Int 123
lazy b = String "4567"

WHERE

type value = Int of int | String of string

[-- Attachment #3: where.ml --]
[-- Type: text/plain, Size: 2609 bytes --]

open Pcaml;;

type exprT = MLast.expr Grammar.Entry.e
and  pattT = MLast.patt Grammar.Entry.e;;

let let_gen = Grammar.Entry.create gram "let_general";;
let expr_where = Grammar.Entry.create gram "expr_where";;
let str_item_semi = Grammar.Entry.create gram "str_item_semi";;
let implem_pre = Grammar.Entry.create gram "implem_pre";;
let let_lazy_binding = Grammar.Entry.create gram "let_lazy_binding";;

let rec insert ?(word="WHERE") elems lst =
    match lst with [] -> elems
	| (<:str_item< $str:name$ >>,_ as w)::tl when name=word -> elems@(w::tl)
	| hd::tl -> hd::insert ~word elems tl

let is_header = function <:str_item< value $lid:_$ = LazyX . nondef () >>, _ -> true | _ -> false

EXTEND
    implem:
	[[ (l,stopped) = implem_pre -> 
	    let lst1,lst2 = List.partition is_header l in
	    (List.rev (insert ~word:"HEADER" lst1 lst2),stopped) ]];
    implem_pre:
	[[ "WHERE"; (sil,stopped) = SELF ->
			    ((<:str_item< $str:"WHERE"$ >>,loc)::sil, stopped)
	| "HEADER"; (sil,stopped) = SELF ->
			    (insert [(<:str_item< $str:"HEADER"$ >>,loc)] sil, stopped)
	| si = str_item_semi; OPT ";;"; (sil, stopped) = SELF ->
			    (insert si sil, stopped)
	| "#"; n = LIDENT; dp = OPT expr; ";;" ->
	      ([(<:str_item< # $n$ $opt:dp$ >>, loc)], true)
	| EOI -> ([], false) ]];
    str_item_semi:
	[[ si = str_item; OPT ";;" ->
	    match si with 
		<:str_item< LazyX.set $lid:dest$ $e$ >> as si ->
		    [(<:str_item< value $lid:dest$ = LazyX . nondef () >>,loc);(si, loc)];
		| _ -> [(si, loc)] ]];
    str_item: LEVEL "top"
	[[ "let"; "lazy"; lb = let_lazy_binding -> lb
	| "lazy"; lb = let_lazy_binding -> lb]];
    let_lazy_binding:
	[[ lb = let_binding ->
	    let tr (p,e) = match p with
		<:patt< $lid:name$ >> ->
		    <:str_item< LazyX.set $lid:name$ ( lazy $e$ ) >>
		| _ -> raise Stream.Failure in
	    tr lb ]];
    expr: BEFORE "top"
	[[ e = SELF; (ifRec,l) = expr_where -> 
	    <:expr< let $rec:ifRec!=None$ $list:l$ in $e$ >> ]];
    expr_where:
	[["where"; _ = OPT "begin"; (ifRec,l) = let_gen; "end" ->
	    (ifRec,l)
	| "where"; "{"; (ifRec,l) = let_gen; "}" -> (ifRec,l) ]];
    let_gen: [[r = OPT "rec"; l = LIST1 let_binding SEP "and" -> (r,l)]];
    module_expr:
	[[ "struct"; st = LIST0 [ "WHERE" -> `Where
			    | s = str_item; OPT ";;" -> `Item s ]; "end" ->
		    let rec f ((il::ils) as ilS:'a list list) =
			    function [] -> ilS
				    | (`Item i::l) -> f ((i::il)::ils) l
				    | (`Where::l) -> f ([]::ilS) l in
		    let s = <:str_item< $lid:"b"$ = $lid:"a"$ >> in
		    <:module_expr< struct $list:(List.concat (List.map List.rev (f [[]] st)))$ end >>
	]];
END;;

[-- Attachment #4: lazyX.ml --]
[-- Type: text/plain, Size: 319 bytes --]

exception Already_forced
let nondef () = lazy ( raise Lazy.Undefined )
let set (dest:'a Lazy.t) (src:'a Lazy.t) =
    (if	Obj.tag dobj <> Obj.lazy_tag ||
	    Obj.tag sobj <> Obj.lazy_tag
	then raise Already_forced
	else Obj.set_field dobj 0 (Obj.field sobj 0))
    where {dobj = Obj.repr dest and sobj = Obj.repr src}

[Caml-list] Re: Haskell-like syntax

[Max Kirillov]

On Sat, Mar 15, 2003 at 01:30:56AM +0600, Max Kirillov wrote:
> I'm sending the changes.

Just come to an idea. Make "let" from the toplevel optional or remove it
completely (looking for ;;) and require the "let _ = <..>" to be written
as "do ... done" or "do {..}" or just "do ... ;;"

That's really attractive. I will do it.

-- 
Max

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: Haskell-like syntax

[Seth Kurtzberg]

I find this syntax (with WHERE) much more intuitive than the alternatives.  I 
strongly support the effort to integrate this into OCaml.  While it seems 
like a small thing in practice it makes it much easier to see what is 
actually going on, which is of course very desirable.

On Friday 14 March 2003 12:30 pm, Max Kirillov wrote:
> On Fri, Mar 14, 2003 at 12:33:36AM +0600, Max Kirillov wrote:
> > Talking about the single thigs: at the beginning of my way into ocaml, I
> > did some camlp4 hacks. For example, that was "where" keyword support
> > (much more powerful than in revised syntax) and some support for "from
> > top to bottom" style of sources. If you interested, I could post them.
>
> I'm sending the changes. Note that, though they are quite stable, I
> picked them from an environment, so something may broke.
>
> A little comment what is it.
>
> file test_where.ml -- obvious. Very little, more to demonstrate, than to
> cover all possible (and really seen) dangers.
>
> file lazyX.ml -- misc functions to handle lazy values (see later)
> note that it is already uses the extension
>
> file where.ml -- the main thing
>
> There are several things:
>
> 1) 'where' notation:
>
> <expr> ::=  <expr> where { [rec] <let-binding> }
>
> 	|   <expr> where [begin] [rec] <let-binding> end
>
> the two version are the same (some like {..}, some begin..end).
> there are some unresolved quastions with prioriries, so, in practice, I
> often had to use brackets. However, I think that the level I choose is
> quite reasonable.
>
> 2) reorder srt_items
>
> there are keyword 'WHERE' (uppercase) in place of structure item. At the
> point, the structure (or the whole file if at toplevel) is cut, then
> pieces swapped and concated again. this allows writing:
>
> ------- file.ml
> main ();;
> WHERE
> let main () =
>     do_this ();
>     do_that ();;
> WHERE
> let do_this () =
>     <.......>
> and do_that () =
>     <........>
> ------
>
> 3) lazy values predeclaration
>
> <str-item> ::=	[let] [lazy] [rec] <let-binding>
>
> this allows define lazy value, which is seen to the whole structure, and
> not only to the following items. Every value that is binded is lazy
> value, that, when forced, computes the definition. It uses the LazyX
> module: nondef () produces the value, set dest src replaces the
> unforced lazy value dest by the unforced lazy expression src, if any of
> then is already forced (it is at module initialization time, so it's
> easy to catch), the exception is raised.
>
> I used it in plays with "functional GUI", where needed to declare many
> inter-depended values and, for various reasons, didn't want to use "let
> rec <...> and <...>" chain.
>
> There is one trouble. When you define a type, and then a lazy value of
> the type, the compiler complains "the type xxx would escape its scope".
> this berore it comes to need to infer the type for the initial
> declaration "let x = LazyX.nondef ()", where it is not yet defined.
> To solve the problem, I added "HEADER" keyword. It explicitly says that
> the forward declataions must be placed here instead of beginning of the
> file. You place it after the type declaration. Of course the lazy values
> definitions must itself follow the type declarations.
>
> The lazy stuff is intended to work only in toplevel, it is not for
> "struct..end".
>
> I used the (1) very much, and would say it quite workable. The (2) is
> also quite stable, but, now, I would say the realization needs to be
> changed. The (3) are more a toy than real thing. There could be problems
> with that.

-- 
Seth Kurtzberg
M. I. S. Corp.
480-661-1849
seth@cql.com

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: Haskell-like syntax

[brogoff]

If you are really desparate to be able to do this kind of thing, that is, to 
write your programs in a top down fashion, you can do it right now in OCaml, 
sans CamlP4, by writing code like 

    let rec main () = 
       let foo_arg = foo_aux () in 
        foo foo_arg 
    and foo = ... 
    and foo_aux = ...

I agree that "where" is nice, and there are other features of Revised I like a lot 
(I prefer that syntax to the classic one in fact) but it's hard to get too 
worked up about this issue, and I don't find what I wrote above counterintuitive 
at all. 

-- Brian


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: Haskell-like syntax

[Sebastien Carlier]

brogoff@speakeasy.net writes:

> If you are really desparate to be able to do this kind of thing, that is, to 
> write your programs in a top down fashion, you can do it right now in OCaml, 
> sans CamlP4, by writing code like 
> 
>     let rec main () = 
>        let foo_arg = foo_aux () in 
>         foo foo_arg 
>     and foo = ... 
>     and foo_aux = ...

This is different: "let rec" doesn't give you polymorphism in OCaml.
The following code doesn't pass the type checker because the type of
"id" is not generalized:

let rec main () =
    print_string (id ""); print_int (id 0)
and id = fun x -> x;;

In Haskell, "where" generalizes - the following similar code is
accepted by Haskell compilers:

main =
    do putStr (id "")
       print (id 0)
    where id = \ x -> x

-- 
Sebastien

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: Haskell-like syntax

[brogoff]

That's a good point, though I have to say it hasn't been a problem in 
code I've written when I've wanted top down style. However, if this is such a 
bummer, maybe you should be agitating for polymorphic recursion instead. That 
would remove this complaint (if we didn't have to explicitly annotate; if we 
did, it loses the lightweight aspect) *and* add some power to OCaml. 

If I'm not mistaken, the Revised version of your code does not have that problem. 
Also, if you are really interested in making this happen, the right thing to do 
is to attempt to change Revised, which is the bucket that all syntax 
experimentation is dumped into. 

-- Brian


On 14 Mar 2003, Sebastien Carlier wrote:

> 
> brogoff@speakeasy.net writes:
> 
> > If you are really desparate to be able to do this kind of thing, that is, to 
> > write your programs in a top down fashion, you can do it right now in OCaml, 
> > sans CamlP4, by writing code like 
> > 
> >     let rec main () = 
> >        let foo_arg = foo_aux () in 
> >         foo foo_arg 
> >     and foo = ... 
> >     and foo_aux = ...
> 
> This is different: "let rec" doesn't give you polymorphism in OCaml.
> The following code doesn't pass the type checker because the type of
> "id" is not generalized:
> 
> let rec main () =
>     print_string (id ""); print_int (id 0)
> and id = fun x -> x;;
> 
> In Haskell, "where" generalizes - the following similar code is
> accepted by Haskell compilers:
> 
> main =
>     do putStr (id "")
>        print (id 0)
>     where id = \ x -> x
> 
> -- 
> Sebastien
> 
> 

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: Haskell-like syntax

[Oleg]

As was pointed out to me in private email, Andreas Rossberg might have 
something quite close to a usable preprocessor.

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=3D105596.8FF65D58%40ps.uni-sb.de

I'm sending him a copy of this message as a request to share his work.

Cheers
Oleg

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml popularity

[Tushar Samant]

02003-03-11 | Pierre Weis <pierre.weis@inria.fr> writes:
> have to learn it. This may be the main drawback of Objective Caml:
> there is no ``Objective Caml for dummies''. That may be the price to

Well said. I have had haphazard formal training in programming,
and until I arrived at the idea of informally reasoning out type
inference I essentially could not go beyond print_string(). This
is a type of thing which can go in "Ocaml for Dummies". As another
example, take type constructors. Here is their first occurrence in
the proposed O'Reilly book:

  In contrast with tuples or records, which correspond to a Cartesian
  product, the declaration of a sum type corresponds to a union of sets.
  Different types (for example integers or character strings) are gathered
  into a single type. The various members of the sum are distinguished by
  -constructors-, which support on the one hand, as their name indicates,
  construction of values of this type and on the other hand, thanks to
  pattern matching, access to the components of these values. To apply
  a constructor to an argument is to indicate that the value returned
  belongs to this new type.

A programmer who is constantly asked to parse xml, make database
queries etc at work is not going to be sympathetic to this. And
no considerations of why other ways of doing it lead to a stronger
or weaker system are going to sway him. But a Dummies book, hand-
waving a constructor away as a flag or label, might. The third and
last example is the introduction of structures in the reference manual:

  A primary motivation for modules is to package together related
  definitions (such as the definitions of a data type and associated
  operations over that type) and enforce a consistent naming scheme
  for these definitions. This avoids running out of names or acci-
  dentally confusing names. Such a package is called a -structure-
  and is introduced by the struct...end construct, which contains
  an arbitrary sequence of definitions. The structure is usually
  given a name with the module binding.

Since C programmers mean something else by structure, it would be
nice if there was a Dummies book which said that a structure is a
namespace which may contain types, values and exceptions. Perhaps
it's not--who cares, that's merely the truth about it. A Dummies
book abandons the responsibility of being truthful all the time,
and hence manages to communicate with harried, seat of the pants
programmers. You know that it's just this type--myself included--
which stands the most to benefit from a safe fast language.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] Re: Haskell-like syntax

[Max Kirillov]

On Fri, Mar 14, 2003 at 01:01:59PM -0700, Seth Kurtzberg wrote:
> I find this syntax (with WHERE) much more intuitive than the alternatives.  I 
> strongly support the effort to integrate this into OCaml.  While it seems 
> like a small thing in practice it makes it much easier to see what is 
> actually going on, which is of course very desirable.

No. No! NO!!! I would rather see globally valid declarations, not only
forward. This concening not only the module body, but inter-module
connections as well. Just imagine -- it the third millenium, compiling the
"best language", we need carefully order the .cmo files. Doing this also
would push the "mutually recursive modules" problem.

-- 
Max

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml popularity

[Andreas Eder]

Tushar Samant writes:
 > A Dummies
 > book abandons the responsibility of being truthful all the time,
 > and hence manages to communicate with harried, seat of the pants
 > programmers. You know that it's just this type--myself included--
 > which stands the most to benefit from a safe fast language.

I think dumbing down is not the right way (c) to go. It would be far
better to try to educate the harried, seat of the pants programmer,
than to cater to his perceived needs. There are already too many of
this kind and we definitely need better educated programmers; and I
mean educated, not trained!

'Andreas

-- 
Wherever I lay my .emacs, there´s my $HOME.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: Haskell-like syntax

[Markus Mottl]

On Sat, 15 Mar 2003, Max Kirillov wrote:
> Just imagine -- it the third millenium, compiling the "best language",
> we need carefully order the .cmo files. Doing this also would push the
> "mutually recursive modules" problem.

Things are not this easy: the order is actually required for linking,
not for compiling (as long as you provide explicit signatures in
.mli-files).  The order during linking determines in which order side
effects will be caused when values are initialized, which only the user
can know. Furthermore, the "mutually recursive modules"-problem is more
of a typing problem than one of compilation.

Regards,
Markus Mottl

-- 
Markus Mottl                                             markus@oefai.at
Austrian Research Institute
for Artificial Intelligence                  http://www.oefai.at/~markus

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] globally valid symbols (was: Haskell-like syntax)

[Max Kirillov]

On Sat, Mar 15, 2003 at 11:58:46AM +0100, Markus Mottl wrote:
> Things are not this easy: the order is actually required for linking,
> not for compiling (as long as you provide explicit signatures in
> .mli-files).  The order during linking determines in which order side
> effects will be caused when values are initialized, which only the user
> can know. Furthermore, the "mutually recursive modules"-problem is more
> of a typing problem than one of compilation.

Writing a programming language is usually considered as a diffucult
task...:). The linking problem is not unsolvable. I believe it's a
matter of political choice. For example there are the following way
(that's just an idea): most meaningful side effects are unnamed
(let _ = or let () =), so there's no need to reorder them, and most
side-effect in evaluting the named values are some initialization, the
order of which is not important. So, compiler might safely reorder the
named values definitions (considering only the side-effects, not the
binding, so function declarations would be untouched) and preserve the
order of unnamed code pieces (that is always possible). There could be
an option to warn user when the compiler have to reorder some
impure value definitions.

In fact, only few of real life modules doing something during
initialization, so it could not be a real trouble. 

Typing of recursive modules might be a problem. But, I think it's not
fatal. At least, haskell has a way to do that. Well, when developer need
to solve 2 problem to do something, he is more likely to reject any
action when one of the problems was already solved.

-- 
Max

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: Haskell-like syntax

[David Brown]

On Sat, Mar 15, 2003 at 11:58:46AM +0100, Markus Mottl wrote:

> Things are not this easy: the order is actually required for linking,
> not for compiling (as long as you provide explicit signatures in
> .mli-files).  The order during linking determines in which order side
> effects will be caused when values are initialized, which only the user
> can know. Furthermore, the "mutually recursive modules"-problem is more
> of a typing problem than one of compilation.

Ada has an interesting approach to this problem.  The Ada module system
is very similar to ocaml's.  However, they don't normally specify what
order things happen in (they call it elaboration order).  There are a
few directives you can put in source files to declare that something
else must be elaborated before the current module (package).

The GNU Ada compiler has a default mode that is much simpler, and much
more like how ocaml does it.  The elaboration order is determined by
statically analyzing the dependencies, performing a topological sort.
It doesn't work if there are circular dependencies, and you have to be
more explicit about elaboration.

They handle the circular dependencies by allowing the spec (the .mli
file) to come before the body (.ml) in the order.  This means that the
types, and names of functions are available early, but you can't call
them until that part has been loaded.

The other thing that Ada95 does well is their notion of child packages.
The child packages are compiled and elaborated independently of the
parents (well, after the parents).  For example, I have the modules A,
A.B, C and D.  C uses A, and D uses A.B, but A.B uses C.  The following
order would work.

  A  C  A.B  D

You could kind of think of compiling/linking module A.B just adds a new
child package to A.  After this, D is permitted to use A.B as well.
There is a conflict if A already has a definition for B.

I've thought about trying to throw this into ocaml.  The tricky part is
figuring out which .cmi files to look into for the information.  Perhaps
when you have a reference to A.B.xxx, you would first search for
a.b.cmi, and if not, look in a.cmi for the symbol.  (Gnu ADA also
changes all of the leading dots in the filenames to hyphens for systems
that don't like multiple dots in a name, so the name would be a-b.cmi).

Ada definitely has some annoying features, but there are some aspects of
the language that are well thought out (such as the module system).

Dave Brown

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Module recursion (Was Re: [Caml-list] Re: Haskell-like syntax)

[brogoff]

On Sat, 15 Mar 2003, Markus Mottl wrote:
> Furthermore, the "mutually recursive modules"-problem is more
> of a typing problem than one of compilation.

The most annoying (to me) case where the lack of module recursion is 
really hits is the problem of wanting type declarations and functor 
instantiations in a recursive relationship. If this problem, which seems 
like more of a compilation problem than a typing problem, were fixed, I 
don't think I'd care that much about having a general recursive module 
facility. I can live with the (admittedly sometimes ugly) workarounds in 
other cases where module recursion is desirable.

That's not to say I wouldn't like or use a general recursive module feature, 
but the full problem seems awfully hard in a (strict, impure) language like ML 
and I doubt that I'll see it in OCaml before I retire. 

-- Brian



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: Module recursion (Was Re: [Caml-list] Re: Haskell-like syntax)

[Chris Hecker]

>The most annoying (to me) case where the lack of module recursion is 
>really hits is the problem of wanting type declarations and functor 
>instantiations in a recursive relationship. If this problem, which seems 
>like more of a compilation problem than a typing problem, were fixed, I 
>don't think I'd care that much about having a general recursive module 
>facility. I can live with the (admittedly sometimes ugly) workarounds in 
>other cases where module recursion is desirable. ... That's not to say I 
>wouldn't like or use a general recursive module feature, but the full 
>problem seems awfully hard in a (strict, impure) language like ML and I 
>doubt that I'll see it in OCaml before I retire.

I agree with this.  If I could just call functions and use types 
recursively across modules, I'd be 95% satisfied and it would allow 95% of 
the decoupling needed for large projects, and it's probably only 5% of the 
work (I think there was a tiny patch that allowed this in an older version 
of caml).  That would be great.  We don't need the 100% perfect recursion 
solution to make caml much more useful large projects.  95% now better than 
100% never.  :)

Chris


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: Module recursion (Was Re: [Caml-list] Re: Haskell-like syntax)

[Markus Mottl]

On Sat, 15 Mar 2003, brogoff@speakeasy.net wrote:
> That's not to say I wouldn't like or use a general recursive module feature, 
> but the full problem seems awfully hard in a (strict, impure) language like ML 
> and I doubt that I'll see it in OCaml before I retire. 

Actually, I more often regret the lack of first class modules in OCaml
rather than module recursion.

In any case, this seems like a suitable moment for once again suggesting
that Claudio Russo's module system as implemented in Moscow ML be
integrated into OCaml :-)

It would be interesting to learn about future directions concerning the
type- and the module system. Are there any plans of implementing the
suggestion above? And how about extensional polymorphism - it seems that
Jun Furuse's thesis was already finished last December?

Regards,
Markus Mottl

-- 
Markus Mottl                                             markus@oefai.at
Austrian Research Institute
for Artificial Intelligence                  http://www.oefai.at/~markus

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: Module recursion (Was Re: [Caml-list] Re: Haskell-like syntax)

[brogoff]

On Sun, 16 Mar 2003, Markus Mottl wrote:
> On Sat, 15 Mar 2003, brogoff@speakeasy.net wrote:
> > That's not to say I wouldn't like or use a general recursive module feature, 
> > but the full problem seems awfully hard in a (strict, impure) language like ML 
> > and I doubt that I'll see it in OCaml before I retire. 
> 
> Actually, I more often regret the lack of first class modules in OCaml
> rather than module recursion.

I here you, I guess it depends on your style and your applications. I'm 
guessing now, but I think I'd prefer a more powerful record system to 
ease those problems. Currently people use records or objects to workaround 
the lack of first class modules, so I'd look at raising the power of records. 
That said, of course, if we had first class modules I'm sure I'd use them ;-)

> In any case, this seems like a suitable moment for once again suggesting
> that Claudio Russo's module system as implemented in Moscow ML be
> integrated into OCaml :-)

Not quite yet! Google this 

    dreyer "moscow ml" unsound

I'd give the URL but I'm having trouble clipping text in this VNC window on the 
laptop. 

> It would be interesting to learn about future directions concerning the
> type- and the module system. Are there any plans of implementing the
> suggestion above? And how about extensional polymorphism - it seems that
> Jun Furuse's thesis was already finished last December?

Certainly my top request. Those Haskell guys are having too much fun, and it 
isn't because of syntax, or laziness, but because of all of the cool post HM 
type features in the core language. 

-- Brian


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: Module recursion (Was Re: [Caml-list] Re: Haskell-like syntax)

[Markus Mottl]

On Sun, 16 Mar 2003, brogoff@speakeasy.net wrote:
> > In any case, this seems like a suitable moment for once again suggesting
> > that Claudio Russo's module system as implemented in Moscow ML be
> > integrated into OCaml :-)
> 
> Not quite yet! Google this 
> 
>     dreyer "moscow ml" unsound

Ok, I take back "as implemented in Moscow ML" ;-)

Thanks for the hint!

The unsoundness, however, does not arise from Claudio's thesis, but from
the interaction of generative and applicative functors as implemented in
Moscow ML. In short, if I have understood things correctly, it is possible
to "infect" generative functors with applicativeness by using generative
functor signatures (which only exist in Moscow ML, not SML!) within the
argument signature of applicative functors to essentially eta-expand
passed generative functors.

In any case, there are solutions to this problem. Wouldn't this be a
fine research topic for our OCaml-team? ;-)

Regards,
Markus Mottl

-- 
Markus Mottl                                             markus@oefai.at
Austrian Research Institute
for Artificial Intelligence                  http://www.oefai.at/~markus

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: Module recursion (Was Re: [Caml-list] Re: Haskell-like syntax)

[brogoff]

Are you sure you agree? I was claiming that I could survive (just barely, 
but the will to live is strong) with the ability to have functor instantiations 
and type declarations be mutually recursive. 

Of the two issues you bring up, I think having the ability to have mutually 
recursive functions across module boundaries is *by far* more important than 
the ability to spread types across module boundaries. We can sort of do it 
now, with references, but we have the same problem as with theworkaround I 
mentioned for "where": reduced polymorphism. 

A few years ago, on this list, in a discussion on polymorphic recursion, Pierre 
Weis mentioned a "forward" construct in an experimental Caml which could be used 
for both PR and module spanning recursive functions. Such a construct seems 
worthwhile. 

As far as spreading types across module boundaries, I'm content with the status 
quo, but, as always, open to being convinced by examples and well reasoned 
arguments. Do you have compelling examples? I see this a lot in OO languages, 
but I find a lot of what I see there spaghetti data typing. 

-- Brian

On Sat, 15 Mar 2003, Chris Hecker wrote:

> 
> >The most annoying (to me) case where the lack of module recursion is 
> >really hits is the problem of wanting type declarations and functor 
> >instantiations in a recursive relationship. If this problem, which seems 
> >like more of a compilation problem than a typing problem, were fixed, I 
> >don't think I'd care that much about having a general recursive module 
> >facility. I can live with the (admittedly sometimes ugly) workarounds in 
> >other cases where module recursion is desirable. ... That's not to say I 
> >wouldn't like or use a general recursive module feature, but the full 
> >problem seems awfully hard in a (strict, impure) language like ML and I 
> >doubt that I'll see it in OCaml before I retire.
> 
> I agree with this.  If I could just call functions and use types 
> recursively across modules, I'd be 95% satisfied and it would allow 95% of 
> the decoupling needed for large projects, and it's probably only 5% of the 
> work (I think there was a tiny patch that allowed this in an older version 
> of caml).  That would be great.  We don't need the 100% perfect recursion 
> solution to make caml much more useful large projects.  95% now better than 
> 100% never.  :)
> 
> Chris
> 
> 
> -------------------
> To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
> Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> 

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: Haskell-like syntax

[Nicolas Cannasse]

> > Just imagine -- it the third millenium, compiling the "best language",
> > we need carefully order the .cmo files. Doing this also would push the
> > "mutually recursive modules" problem.
>
> Things are not this easy: the order is actually required for linking,
> not for compiling (as long as you provide explicit signatures in
> .mli-files).  The order during linking determines in which order side
> effects will be caused when values are initialized, which only the user
> can know. Furthermore, the "mutually recursive modules"-problem is more
> of a typing problem than one of compilation.

Yes, of course, module initialization order should be specified by the CMO
order the user gived at linking phase, but that actually does not imply that
the CMO have to be passed to the linker in the compilation tree order. Well,
right now, that's it... but there does not seems to be a theorical wall
since any C linker is accepting files in any order ( I'm not talking here
about compilation, just linking of course ! )

Nicolas Cannasse

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: Module recursion (Was Re: [Caml-list] Re: Haskell-like syntax)

[Jacques Garrigue]

From: brogoff@speakeasy.net

> Of the two issues you bring up, I think having the ability to have mutually 
> recursive functions across module boundaries is *by far* more important than 
> the ability to spread types across module boundaries. We can sort of do it 
> now, with references, but we have the same problem as with theworkaround I 
> mentioned for "where": reduced polymorphism. 

Not so since 3.05: you have to be explicit, but you can define
polymorphic mutable values.

a.ml:
type id = { mutable id: 'a. 'a -> 'a }
let id = { id = fun _ -> failwith "A.id not defined yet" }
...
   id.id 1, id.id true

b.ml:
let () = A.id.A.id <- (fun x -> prerr_endline "Got you!"; x)


Hope this helps,

     Jacques

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: Module recursion (Was Re: [Caml-list] Re: Haskell-like syntax)

[Chris Hecker]

>Are you sure you agree?

I agree with what I thought you were saying.  :)  I thought we had the same 
high-concept, which is just that you can apply the 80/20 rule here and do 
_something_ to alleviate the DAG module problem without doing some totally 
general thing like Tom's mixin modules thing.  I think 80% of the problem 
for me would be solved by allowing recursive function calls.  The next 15% 
would be solved by allowing types to recurse (the example you asked for is 
two records that refer to each other).  The next 5% is everything 
else.  But, I'd happily take just functions calling recursively across 
modules, because that would just be huge, and allow me to refactor into 
smaller modules, increasing compile speed, decoupling, etc.

I would even be happy with this in as a temporary feature and I'd have to 
rewrite code when the real thing came along.  I actually wish the ocaml 
team was a bit more interested in these kinds of temporary experimental 
things.  I guess people scream when features get taken out, but it's way 
better to do this sort of thing now than later when there are more caml users.

Chris

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: Module recursion (Was Re: [Caml-list] Re: Haskell-like syntax)

[brogoff]

On Sun, 16 Mar 2003, Chris Hecker wrote:
> >Are you sure you agree?
> 
> I agree with what I thought you were saying.  :)  I thought we had the same 
> high-concept, which is just that you can apply the 80/20 rule here and do 
> _something_ to alleviate the DAG module problem without doing some totally 
> general thing like Tom's mixin modules thing. 

Yes, we have the same high level concept, namely, that we can look for solutions 
to specific problems that result from not being able to call modules recursively, 
without solving the whole thing, as with mixin modules. 

I think any disagreement was more one of degree, in that my "pet problem(s)" are 
not prioritized the same way yours are. I won't give percentages, since I don't 
know what they mean in this context. I find that the inability to have type 
declarations recursive with functor instantiation reduces the value of functors, 
and the workaround (the parameterization trick) forces you to introduce 
polymorphism just to do this. I agree that the lack of cross module function 
recursion is also a significant problem. Jacques Garrigue showed how you can use 
the newish explicit polymorphism to alleviate the problem I mentioned with the 
well known reference to function workaround for this problem. That's an 
improvement, but we still end up using mutation directly (a bit ugly, to me) and 
abusing the first class polymorphism a bit, just like when we use dictionary 
records to simulate polymorphic recursion. I'd still prefer an explict "forward" 
construct to handle both of these. 

> I think 80% of the problem for me would be solved by allowing recursive function calls.  

The workaround Jacques provided should satisfy this need for now. What do you 
think? 

> The next 15% would be solved by allowing types to recurse (the example you asked for is 
> two records that refer to each other). 

I think that two records that refer to each other belong in the same module :-)

Seriously, I *know* that's what allowing types to recurse across modules is an 
example of allowing types to recurse across modules. I was searching for a 
compelling example of when that is necessary. In a previous incarnation of this 
discussion, Fergus Henderson cited some example from the Mercury compiler where 
the *functions* were getting huge (on the order of 10KLOC) before being split 
up. So that's part of a good argument for directly supporting cross module 
function recursion. I don't mind types getting big, partly because, IMO, a 
good factoring in OCaml often involves pulling type declarations into their own 
separate .mli file. 

> The next 5% is everything 
> else.  But, I'd happily take just functions calling recursively across 
> modules, because that would just be huge, and allow me to refactor into 
> smaller modules, increasing compile speed, decoupling, etc.
> 
> I would even be happy with this in as a temporary feature and I'd have to 
> rewrite code when the real thing came along.

I think the reference to function trick, augmented by a naming convention (say, 
prefixing the funs with fwd_<funname>) and using higher order polymorphism, as 
JG just showed, is an acceptable workaround for now. But it doesn't seem as 
elegant as a forward construct. 

-- Brian


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: Module recursion (Was Re: [Caml-list] Re: Haskell-like syntax)

[Ville-Pertti Keinonen]

> I think that two records that refer to each other belong in the same 
> module :-)

That's a pretty strong generalization.

My example doesn't involve only records specifically, but I think it is 
worth consideration.  Note that this is based on my experiences while 
writing my first OCaml program, I have only been learning OCaml over 
the past couple of months in what little spare time I have, so it is 
entirely possible that there are better solutions available that I've 
missed.

I've implemented a Scheme interpreter in OCaml (R5RS, including the 
full tower of number types, continuations, dynamic extents and hygienic 
macros, all implemented in OCaml with no Scheme library dependencies).  
OCaml was very well suited for this, but I thought it was annoying that 
I had to declare most of the types used in one file.

IMO the only thing that should be visible throughout the program (and 
possible extensions) is the sum type of Scheme values/expressions but 
that wasn't reasonably possible.

I would've wanted to make many of the specific types (pre-analyzed code 
in procedures, scopes of lexical bindings, dynamic extent records etc.) 
abstract, but couldn't.  I could've made many of the types themselves 
abstract, since every operation relying on their specific content was 
isolated to a few functions, but the functions operating on those types 
require Scheme values as inputs and/or outputs, so that would've caused 
circular references between .mlis. (A notable exception was ports, 
which could be abstract and implemented without the need for knowledge 
of Scheme values)

Additionally (and mostly unrelated to the above), I think that cases 
where there are a limited set of functions operating on an abstract 
type defined within a module could be more permissive.  For an abstract 
type ('a, 'b) t of mappings from 'a to 'b, as long as no function 
operating on ('a, 'b) t returns 'a or accepts as an argument any 
function with an input of type 'a, it should be possible to create an 
instance of ('a, 'b) t where 'a is [> ] - it's possible to have such a 
variable, but (if I understand correctly - and I hope I do, because 
otherwise OCaml is broken) not as a member of an (unparametrized) 
record or object.

I realize that this is a non-trivial wish, though, since it would 
require an analysis of what you can do with a type as well as a new 
implementation of polymorphic variants without the possibility of hash 
collisions.

Still, I think that OCaml is a very interesting and powerful language, 
and in many respects more practical compared to other functional 
languages.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: Module recursion (Was Re: [Caml-list] Re: Haskell-like syntax)

[Chris Hecker]

>I think any disagreement was more one of degree, in that my "pet 
>problem(s)" are not prioritized the same way yours are.

I actually don't see this as a "pet problem" thing.  I'm trying to write a 
real shipping application in ocaml (currently 13kloc and will probably be 
4x that at ship, not the largest app ever written to be sure, but certainly 
not a test app).  Not allowing recursion makes it harder to refactor and 
improve compile times, which is not a good thing for process (especially 
since the native compiler is a bit pokey (6x slower than a C++ compiler for 
same LOC last time I checked), and my app can't run bytecode because the 
framerate is too low).  It's also something that just flabbergasts 
professional C++ programmers when they look a caml...the concept that you 
can't break up a compilation unit any way you want to save compile time or 
to make it more readable is crazy to them, and they're right.

I've already committed to using caml for this project and will see my 
experiment through to ship, so these things are just "annoyances" that just 
go in the "cons" column in the article I'm going to write at the end.  For 
somebody not as committed to trying it as me, they're probably showstoppers 
and they'll decide not to use caml.

> > I think 80% of the problem for me would be solved by allowing recursive
>  function calls.
>The workaround Jacques provided should satisfy this need for now. What do 
>you think?

The "id" thing he showed?  That's just the same as doing a ref option and 
then stuffing the functions, isn't it?  Anyway, it's an ugly hack, it 
spreads knowledge of what one module needs from another explicitly into the 
interface, you have to explicitly type the forward functions, it requires 
an error-prone manual stuffing step, and there are order of initialization 
issues (which there aren't if you just allow functions to be called, and 
not arbitrary values) if I undertstand it correctly.  Basically, this 
workaround is not making a professional programmer looking at ocaml feel 
better about using it for large projects, in my opinion.

>I think that two records that refer to each other belong in the same 
>module :-)

The reason I didn't bother giving an example is that out of context any 
example can be "redesigned by the list" to not need it, or the list can 
claim that you can just shove things in the same module.  I think this is a 
case of good old "you don't need that" syndrome, which computer people fall 
prey to all the time.  Somebody's favorite thing doesn't support X, so many 
bytes will be sacrificed convincing the other person that they don't need 
X.  It's a pretty big waste of time, in my opinion.  The ability to have 
two types refer to each other is a totally reasonable thing to do, and if 
you agree that it's reasonable (which you seem to), then the ability to 
have them in different files is also reasonable by extension.  The 
limitation that they have to be in the same file is just that, a 
limitation.  It's not a feature leading to better design, or any other 
rationalization like that.

>I think the reference to function trick, augmented by a naming convention 
>(say, prefixing the funs with fwd_<funname>) and using higher order 
>polymorphism, as JG just showed, is an acceptable workaround for now.

Define "for now".  You have to decide when the workaround is doing more 
damage to the cause of making ocaml viable/more popular/whatever your goal 
is.  If it reduces pressure for a real solution, but you still have to 
explain the workaround with a straight face to every person who asks why 
their 4 line a.ml+b.ml example won't link with this fancy new "high level 
language" but their crappy C compiler can do it, then it's not clear to me 
that it's a win.

The other thing is that something crazy like the mixin modules thing will 
incur runtime overhead to do the module creation at init time, where you 
just don't need that to call functions, so there are arguments for adding 
this even if you plan to do mixins in the long run.  But anyway, I doubt 
I've convinced anybody on the other side of the fence.

Chris


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: Module recursion (Was Re: [Caml-list] Re: Haskell-like syntax)

[brogoff]

On Mon, 17 Mar 2003, Chris Hecker wrote:
> >I think any disagreement was more one of degree, in that my "pet 
> >problem(s)" are not prioritized the same way yours are.
> 
> I actually don't see this as a "pet problem" thing. 

I also use OCaml in my job. By "pet problem", I meant that set of language 
quirks that annoy you. If you work with even one other OCaml programmer, I'll 
bet you find that what annoys you may not annoy the other guy as much, and vice 
versa. 

> It's also something that just flabbergasts 
> professional C++ programmers when they look a caml...the concept that you 
> can't break up a compilation unit any way you want to save compile time or 
> to make it more readable is crazy to them, and they're right.

C++ has explicit pointers, and allows them to be uninitialized, so it shouldn't 
be surprising that it can allow more of this kind of thing. 
 
> > > I think 80% of the problem for me would be solved by allowing recursive
> >  function calls.
> >The workaround Jacques provided should satisfy this need for now. What do 
> >you think?
> 
> The "id" thing he showed?  That's just the same as doing a ref option and 
> then stuffing the functions, isn't it?

Sort of, but it allows polymorphism by using the higher order polymorphism 
features, like polymorphic methods, but for record fields instead.

> Anyway, it's an ugly hack, it  spreads knowledge of what one module needs 
> from another explicitly into the interface, you have to explicitly type the 
> forward functions, it requires an error-prone manual stuffing step, 

Yes, I agree, it's a workaround. 

> and there are order of initialization issues (which there aren't if you just 
> allow functions to be called, and not arbitrary values) 

Are you sure? I think the order of initialization issues still occur even if you 
just allow functions. 

> Basically, this workaround is not making a professional programmer looking at 
> ocaml feel better about using it for large projects, in my opinion.

Again, I agree, but every language has annoying flaws. 

> >I think that two records that refer to each other belong in the same 
> >module :-)
> 
> The reason I didn't bother giving an example is that out of context any 
> example can be "redesigned by the list" to not need it, or the list can 
> claim that you can just shove things in the same module. 

Well, of course we can redesign everything down to assembly code, but if you use 
this as a reason then you'll have to assume all discussion is pointless. I found 
Fergus Henderson's Mercury code size statistics pretty convincing as an argument 
that cross module functions should have more direct support. 

> The ability to have two types refer to each other is a totally reasonable 
> thing to do, and if you agree that it's reasonable (which you seem to), then 
> the ability to have them in different files is also reasonable by extension.  

I don't follow your logic here. 

> The limitation that they have to be in the same file is just that, a 
> limitation.  It's not a feature leading to better design, or any other 
> rationalization like that.

Actually, I've read some SML programmers arguing exactly that, that it is a 
limitation leading to better designs, and that allowing the types and functions 
to be spread out will lead to more bad designs. Good SML programmers too. My 
opinion is closer to yours than theirs wrt functions, but I wouldn't just 
discount that opinion as nonsense. I'd have to hear more from a range of ML 
programmers on various sized projects, before changing my mind on types. 

> >I think the reference to function trick, augmented by a naming convention 
> >(say, prefixing the funs with fwd_<funname>) and using higher order 
> >polymorphism, as JG just showed, is an acceptable workaround for now.
> 
> Define "for now".  

Until a generally better language and implementation for the sort of programming 
I do comes along, that has this feature. I'm not optimistic. 

> The other thing is that something crazy like the mixin modules thing will 
> incur runtime overhead to do the module creation at init time, where you 
> just don't need that to call functions, so there are arguments for adding 
> this even if you plan to do mixins in the long run.  But anyway, I doubt 
> I've convinced anybody on the other side of the fence.

I'm on your side for functions, though I have another axe to grind that annoys 
me even more, but still on the other side for types. If my pet problem (couldn't 
resist ;) were solved, it might allow better workarounds for spreading types 
across modules too, by functorizing the parts, and allowing you to instantiate 
the parts into a new type declaration.

-- Brian


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: Module recursion (Was Re: [Caml-list] Re: Haskell-like syntax)

[Chris Hecker]

>I also use OCaml in my job. By "pet problem", I meant that set of language
>quirks that annoy you. If you work with even one other OCaml programmer, 
>I'll bet you find that what annoys you may not annoy the other guy as 
>much, and vice versa.

Sure, I was just indicating that there are some things that go beyond "pet 
problems" and get into "real problems", and I think this is one of 
them.    The question is just whether programming is enough of an 
engineering discipline to be able to say "this is a quantifiably bad thing 
for implementing large programs".  I guess it's not since things like this 
are still very subjective, but if it was then I'd say this function thing 
falls into that category because you want to enable decoupling.  It's also 
gray because compile times and coupling aren't going to kill a project, 
they're just going to make the process more painful than it needs to 
be.  So, the rationalizers always can point to success and say, "see, it 
wasn't needed", which misses the subtlety of the situation.

> > and there are order of initialization issues (which there aren't if you 
> just
> > allow functions to be called, and not arbitrary values)
>Are you sure? I think the order of initialization issues still occur even 
>if you just allow functions.

Hmm.  There are no "0th order" initialization order problems, since a 
function is always just callable (as opposed to trying to call through an 
uninitialized value).  I guess there are 1st order problems in that if A 
calls into B.f and B hasn't been initialized and B.f uses a global in B 
then you'll be in trouble.  I don't think there's a problem if you do not 
reference any globals, though.  I think it's still a valuable tool in that 
case, but yeah, I guess it's not totally safe.  That's probably why this 
hasn't been implemented.  I wonder what that patch did in this case, if 
anything.  Ah, here's Fabrice's original post, and it looks like you have 
to enforce the constraint manually:

http://groups.google.com/groups?selm=fa.hlh6e5v.1fmkppq%40ifi.uio.no
(related post by Xavier, replying to me complaing about this limitation in 
2001 when I learned about it :)
http://groups.google.com/groups?selm=fa.dks4ugv.1a6iho7%40ifi.uio.no

>Again, I agree, but every language has annoying flaws.

Sure, but again, there has to be some metric for when something is more 
than just an annoying flaw.  I guess large programs get written in caml, so 
by some measure it "works".  Maybe that is the only metric available at 
this point.  However, given that metric, large programs got written in asm, 
but that didn't stop people from trying to fix the "annoying flaws" and 
finding value in fixing them.  :)

>Actually, I've read some SML programmers arguing exactly that, that it is 
>a limitation leading to better designs, and that allowing the types and 
>functions to be spread out will lead to more bad designs. Good SML 
>programmers too. My opinion is closer to yours than theirs wrt functions, 
>but I wouldn't just discount that opinion as nonsense.

I don't discount it as nonsense, I just trust professional programmers 
more.  We're so far away from a language that actually helps design 
programs for you, that any steps in that direction right now are usually 
naive and more limiting than useful, in my opinion.  Caml needs Obj.magic, 
for example.  It would be a less viable language without it, even though 
every argument for its use could be called "bad design".

Chris


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml popularity

[Graham Guttocks]

Gerd Stolpmann <info@gerd-stolpmann.de> wrote:
>
> I suppose it has to do with the label "functional language", and
> these languages are often seen as toys of academic
> people. I.e. nothing for the real programmer. Not really sexy.

If this is the case, I wonder why there are so many instructional
texts available for SML (a couple dozen probably).  Quite a few for
Haskell as well.  Only one (Cousineau & Mauny) for OCaml.  Rather
disappointing since OCaml seems more promising than any of these.

=====
Regards,
Graham

http://mobile.yahoo.com.au - Yahoo! Mobile
- Check & compose your email via SMS on your Telstra or Vodafone mobile.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] ocamlopt speed (was Re: Module recursion)

[Chris Hecker]

Christophe Troestler contacted me off list to ask about this comment from 
one of my mails:

>especially since the native compiler is a bit pokey (6x slower than a C++ 
>compiler for same LOC last time I checked)

Christophe asked if I was using ocamlopt.opt or ocamlopt.  I said I thought 
I was using the latter but that I'd check and post back to the list.

It turns out I was using ocamlopt (the bytecode build of the native code 
compiler).  I had built the .opt versions but not switched over to them (I 
was using camlp4o.opt where I was using camlp4, though).  I switched and it 
got almost twice as fast, which is very nice.  I also retimed the C project 
that I was informally comparing to, and the timings on this machine (laptop 
with very fast cpu, very slow hard drive) are quite different than the 
other machine I originally tested on (desktop with slow cpu, fast hard 
drive, or I made a mistake on that machine, which is more than 
possible).  I will retime things there as well when I go to the office.

Here are the results on this machine, which shows ocamlopt.opt just about 
matching msvc6.  This isn't trying to be a formal test, so I don't account 
for things like the difference in code complexity (they're both games), 
system headers included in C files (which would favor C if they were 
cleaned up) or the fact that my makefile for caml doesn't pass multiple ml 
files to the compiler (which should favor ocamlopt), etc.

compiler      sec    loc  loc/sec
------------  ---  -----  -------
msvc6          12  27865     2322
ocamlopt       13  15483     1191
ocamlopt.opt    7  15483     2211

Chris


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] ocamlopt speed (was Re: Module recursion)

[Michal Moskal]

On Tue, Mar 18, 2003 at 06:34:29PM -0800, Chris Hecker wrote:
> Here are the results on this machine, which shows ocamlopt.opt just about 
> matching msvc6.  This isn't trying to be a formal test, so I don't account 
> for things like the difference in code complexity (they're both games), 

My experience shows that ocaml code is very often twice (or more) as
short as C equivalent. For example for language shootout sources:

language        loc
~~~~~~~~~~~~~~~~~~~
ansic:         1403
cpp:           1107
ml:             646

Of course one may argue, that for bigger programs C gets less verbose
(once you have written lists, hash tables, trees etc).

> system headers included in C files (which would favor C if they were 
> cleaned up) or the fact that my makefile for caml doesn't pass multiple ml 
> files to the compiler (which should favor ocamlopt), etc.

In case of C compiler you should enable precompiled headers (if it
supports one), because ocaml compiler uses some form of it. 

> compiler      sec    loc  loc/sec
> ------------  ---  -----  -------
> msvc6          12  27865     2322
> ocamlopt       13  15483     1191
> ocamlopt.opt    7  15483     2211

Combined with semantic density, this makes ocamlopt twice as fast as
msvc.

-- 
: Michal Moskal ::::: malekith/at/pld-linux.org :  GCS {C,UL}++++$ a? !tv
: PLD Linux ::::::: Wroclaw University, CS Dept :  {E-,w}-- {b++,e}>+++ h

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] ocamlopt speed (was Re: Module recursion)

[Gerd Stolpmann]

> On Tue, Mar 18, 2003 at 06:34:29PM -0800, Chris Hecker wrote:
>> Here are the results on this machine, which shows ocamlopt.opt just
>> about  matching msvc6.  This isn't trying to be a formal test, so I
>> don't account  for things like the difference in code complexity
>> (they're both games),
>
> My experience shows that ocaml code is very often twice (or more) as
> short as C equivalent. For example for language shootout sources:
>
> language        loc
> ~~~~~~~~~~~~~~~~~~~
> ansic:         1403
> cpp:           1107
> ml:             646
>
> Of course one may argue, that for bigger programs C gets less verbose
> (once you have written lists, hash tables, trees etc).
>
>> system headers included in C files (which would favor C if they were
>> cleaned up) or the fact that my makefile for caml doesn't pass
>> multiple ml  files to the compiler (which should favor ocamlopt), etc.
>
> In case of C compiler you should enable precompiled headers (if it
> supports one), because ocaml compiler uses some form of it.
>
>> compiler      sec    loc  loc/sec
>> ------------  ---  -----  -------
>> msvc6          12  27865     2322
>> ocamlopt       13  15483     1191
>> ocamlopt.opt    7  15483     2211
>
> Combined with semantic density, this makes ocamlopt twice as fast as
> msvc.

Sorry that I must say that, but these comparisons are absolutely
nonsense. I have some ocaml sources that are _much_ slower (e.g.
2500 lines, but compilations take longer than 20 seconds), and I know
that you can slow down C++ compilers by turning on optimization
switches. So the question arises: which features take which time?

My impression is that some type inference tasks can be very slow
for ocaml, especially if subtyping is involved. This feature is not
available in C++. On the other hand, C++ compilers usually implement
better optimization techniques, and these take time, too.

Gerd
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
------------------------------------------------------------





-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] ocamlopt speed (was Re: Module recursion)

[Chris Hecker]

Last useless-numbers post...

>are quite different than the other machine I originally tested on (desktop 
>with slow cpu, fast hard drive, or I made a mistake on that machine, which 
>is more than possible).  I will retime things there as well when I go to 
>the office.

The answer is I must have been smoking crack the first time I timed things, 
because this desktop machine has msvc6 @ 15sec, ocamlopt @ 25sec, 
ocamlopt.opt @ 10sec.  It is a wider gap msvc6 vs. ocamlopt (~3x), but I 
still obviously made a mistake or was sloppy, and still .opt makes a big 
difference on my code.

Chris

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: Haskell-like syntax

[Andreas Rossberg]

Oleg wrote:
> As was pointed out to me in private email, Andreas Rossberg might have 
> something quite close to a usable preprocessor.
> 
> http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=3D105596.8FF65D58%40ps.uni-sb.de
> 
> I'm sending him a copy of this message as a request to share his work.

Back from holidays. ;-)

For people who are really interested I put the last version of the 
sources at

   http://www.ps.uni-sb.de/~rossberg/hocaml-0.12.tgz

But please be aware that the code is almost 5 years old, was kind of 
work in progress, and must have experienced a fair amount of bit rot by 
now. Last time I checked it still built, though.

I'm not entirely happy with some of the syntactic decisions I made. 
Also, I'm not sure whether the preprocessor approach really is terribly 
useful for this kind of thing. But if somebody feels like digging into 
it, feel free to contact me for questions.

Enjoy,

   - Andreas

-- 
Andreas Rossberg, rossberg@ps.uni-sb.de

"Computer games don't affect kids; I mean if Pac Man affected us
  as kids, we would all be running around in darkened rooms, munching
  magic pills, and listening to repetitive electronic music."
  - Kristian Wilson, Nintendo Inc.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Belated thanks (was Re: [Caml-list] OCaml popularity)

[Matt Gushee]

Hello!

A couple of weeks ago I jumped into an "OCaml Popularity" thread, and
started griping about Monads in Haskell. Several people responded with
some very thoughtful (and probably helpful, once I finish reading them)
comments. I just want thanks to all of you. I'm sorry I didn't respond
earlier--life has been chaotic lately.

Also, I'm thinking it might be useful if I summarized that thread for
posterity. There's lots of good stuff in there. Would people be
interested in that?

-- 
Matt Gushee                 When a nation follows the Way,
Englewood, Colorado, USA    Horses bear manure through
mgushee@havenrock.com           its fields;
http://www.havenrock.com/   When a nation ignores the Way,
                            Horses bear soldiers through
                                its streets.
                                
                            --Lao Tzu (Peter Merel, trans.)

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] Re: Belated thanks

[cashin]

Matt Gushee <mgushee@havenrock.com> writes:

> A couple of weeks ago I jumped into an "OCaml Popularity" thread, and
> started griping about Monads in Haskell. Several people responded with
> some very thoughtful (and probably helpful, once I finish reading them)
> comments. 
...
> Also, I'm thinking it might be useful if I summarized that thread for
> posterity. There's lots of good stuff in there. Would people be
> interested in that?

I know I would.  I am always in a rush these days.  The responses
looked interesting but long.

-- 
--Ed L Cashin            |   PGP public key:
  ecashin@uga.edu        |   http://noserose.net/e/pgp/

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: Belated thanks (was Re: [Caml-list] OCaml popularity)

[Johann Spies]

On Sat, Mar 29, 2003 at 10:59:06PM -0700, Matt Gushee wrote:
> 
> Also, I'm thinking it might be useful if I summarized that thread for
> posterity. There's lots of good stuff in there. Would people be
> interested in that?
> 

That would be helpful, thank you.

Johann
-- 
Johann Spies          Telefoon: 021-808 4036
Informasietegnologie, Universiteit van Stellenbosch

     "Therefore, if anyone is in Christ, he is a new   
      creation; the old has gone, the new has come."   
                      II Corinthians 5:17  

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml popularity

[Sergey Goldgaber]

--- Oliver Bandel <oliver@first.in-berlin.de> wrote:
>
>  - An introductional text, which has helped me a lot before the OCaml
>    book in english was put on the server. I don't know who has
>    written it, because the author has not written his name/mailaddres
>    into it.
>    The first two sentences in this paper: "This documentation is an
>    introduction to ML programming, specifically for the OCaml
>    implementation. In CS134a, we used C (and variations) to specify
>    processes, monitors, semaphores, devices and more." (and so on)
>    (Could be better, with a table of content and an index; but to
>    start it's much better than the O'Reilley book, because of a lot
of
>    examples.)

It looks like this is Jason Hickey's "Introduction to the Objective
Caml
Programming Language"


  --Sergey


__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml popularity

[Oliver Bandel]

On Fri, Mar 14, 2003 at 07:43:53PM -0600, Tushar Samant wrote:
> 02003-03-11 | Pierre Weis <pierre.weis@inria.fr> writes:
> > have to learn it. This may be the main drawback of Objective Caml:
> > there is no ``Objective Caml for dummies''. That may be the price to
> 
> Well said. I have had haphazard formal training in programming,
> and until I arrived at the idea of informally reasoning out type
> inference I essentially could not go beyond print_string(). This
> is a type of thing which can go in "Ocaml for Dummies". As another
> example, take type constructors. Here is their first occurrence in
> the proposed O'Reilly book:
> 
>   In contrast with tuples or records, which correspond to a Cartesian
>   product, the declaration of a sum type corresponds to a union of sets.
>   Different types (for example integers or character strings) are gathered
>   into a single type. The various members of the sum are distinguished by
>   -constructors-, which support on the one hand, as their name indicates,
>   construction of values of this type and on the other hand, thanks to
>   pattern matching, access to the components of these values. To apply
>   a constructor to an argument is to indicate that the value returned
>   belongs to this new type.
> 
> A programmer who is constantly asked to parse xml, make database
> queries etc at work is not going to be sympathetic to this.

Well, maybe it's better that he is not. :)

> And
> no considerations of why other ways of doing it lead to a stronger
> or weaker system are going to sway him. But a Dummies book, hand-
> waving a constructor away as a flag or label, might. The third and
> last example is the introduction of structures in the reference manual:
> 
>   A primary motivation for modules is to package together related
>   definitions (such as the definitions of a data type and associated
>   operations over that type) and enforce a consistent naming scheme
>   for these definitions. This avoids running out of names or acci-
>   dentally confusing names. Such a package is called a -structure-
>   and is introduced by the struct...end construct, which contains
>   an arbitrary sequence of definitions. The structure is usually
>   given a name with the module binding.


Well, I don't think it's a good idea to throw such (imho hard) stuff
away. A better presentation will be a way to go.

I'm happy to have books like the O'Reilley-book (even if it
sometimes sounds different, when I criticize it). They use
the language, which is necessary to explain something.
But it sometimes (or often) could be more well explained to
peiople who are not so familiar with this sort of thinking.

It's IMHO not a problem that there is to learn a lot.
The only problem IMHO is, if there are no texts and/or people,
who I can ask to go further.

When things are complicated,and different and unknown, then
it is not a good idea to oversimplify.
It's better, when explaining the complicated/new/unknown
in more detail.

So I had found some papers, not all covering my knowledge-level,
but each of them is interesting (some has helped me, others
may will help me later, when I have more experience/knowledge in
the FP-area).

These texts I have found:

 - The documentation, coming with OCaml (Reference != learning papers)
 - Tutorial: stephan.html (very good intro to start first steps!)
 - Caml quick reference guide (good idea, but layout could be better)
 - An introductional text, which has helped me a lot before the OCaml
   book in english was put on the server. I don't know who has written
   it, because the author has not written his name/mailaddres into it.
   The first two sentences in this paper: "This documentation is an
   introduction to ML programming, specifically for the OCaml
   implementation. In CS134a, we used C (and variations) to specify
   processes, monitors, semaphores, devices and more." (and so on)
   (Could be better, with a table of content and an index; but to start
   it's much better than the O'Reilley book, because of a lot of
   examples.)
   
 - O'Reilley-OCaml-book (good for gaining an overview on the language)

 - Didier Remy: Using, Understanding, and Unraveling The OCaml Language
   (Sometimes I understand some paragraphs. Good work, but is more
    a paper for the OCaml-gurus with theoretical background, but
    neverheless interesting and some example code is used there too.)
    If there are books, explaining how to go from imperative
    non-computer-studied person to a person who understands this
    text fully, please let me know...


There are a lot of papers, but there are too much gaps between
the one knowledge (and it's representation) and the other.
Filling the gaps would be a way, nut dumbing down!

Ciao,
   Oliver

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml popularity

[Daniel M. Albro]

	Someone (sorry, deleted the email before I could use it to
respond) mentioned that they had thought that the first edition of
SICP used Lisp (this isn't true, by the way -- I used the first
edition when I took 6.001 way back when and it was Scheme).  Maybe
you were thinking of _The_Little_Lisper_, which has since changed
to _The_Little_Schemer_ (with the sequel _The_Seasoned_Schemer_).
That book is a pretty good introduction to functional programming,
by the way, albeit a bit mind-bending when it starts going into
Y-Combinators and stuff like that.  I still haven't managed to finish
_The_Seasoned_Schemer_.  They have a book called "_The_Little_MLer_"
that talks about ML and has a section on how to convert their code
into OCaml, but it's not really as good as the Scheme version; it
spends too much time on the specifics of ML, really.  Maybe that's
appropriate, but then it should be longer so they can get all of the
nice lambda calculus in.

-- 
Daniel M. Albro <albro@humnet.ucla.edu>

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml popularity

[Daniel M. Albro]

	Well, I'm certainly learning a lot this way, anyway...
Might be useful stuff for a tutorial!  This continuation-
passing style here runs quite fast, by the way -- equivalent to the
original exception-for-loop suggestion:

real    0m30.056s
user    0m29.950s
sys     0m0.100s

On Fri, 2003-03-14 at 01:05, Ville-Pertti Keinonen wrote:
> > Break simulated by continuation passing (I think that's
> > what this is -- it looks like a call/cc to me, anyway)
> 
> Sort of, except that the continuation can't be used outside the 
> function called by escape.  Here's a different approach (this is 
> essentially a variation of the recursive style, because you need to 
> make sure the continuation is called as a tail call):
> 
> let _ =
>    let ary = [| 1; 2; 3; 4; 5; 6; 7; 8; 9; 10; 11; 12 |] in
>    let rec loop f j =
>      if j = 10 || ary.(j) = 5 then f ()
>      else loop f (j + 1)
>    in
>      let rec outer i =
>        if i <= 1_000_000_000 then
>          loop (fun _ -> outer (i + 1)) 0
>      in
>        outer 1
> 
> This style is useful in some cases when you can write a significant 
> part of your program using continuations.
-- 
Daniel M. Albro <albro@humnet.ucla.edu>

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml popularity

[Ville-Pertti Keinonen]

> Break simulated by continuation passing (I think that's
> what this is -- it looks like a call/cc to me, anyway)

Sort of, except that the continuation can't be used outside the 
function called by escape.  Here's a different approach (this is 
essentially a variation of the recursive style, because you need to 
make sure the continuation is called as a tail call):

let _ =
   let ary = [| 1; 2; 3; 4; 5; 6; 7; 8; 9; 10; 11; 12 |] in
   let rec loop f j =
     if j = 10 || ary.(j) = 5 then f ()
     else loop f (j + 1)
   in
     let rec outer i =
       if i <= 1_000_000_000 then
         loop (fun _ -> outer (i + 1)) 0
     in
       outer 1

This style is useful in some cases when you can write a significant 
part of your program using continuations.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml popularity

[Daniel M. Albro]

	I imagine everyone was laughing at me when they saw the timing
tests I did -- they weren't doing the same thing!  D'oh.  Here they are
again with comparable code (the conclusion is basically the same,
though -- use tail recursive functions if you want speed in OCaml,
at least if you're going to be exiting the loop early):

Break simulated with exceptions:
----------------------------------------------
exception Break

let _ =
  let ary = [|1;2;3;4;5;6;7;8;9;10;11;12|] in
    for i = 1 to 1_000_000_000 do
      try
        for j = 0 to 9 do
          if ary.(j) = 5 then
            raise Break
        done
      with Break -> ()
    done

real    0m35.123s
user    0m34.600s
sys     0m0.120s
-----------------------------------------------

Break by causing the while test to fail
-----------------------------------------------
let _ =
  let ary = [|1;2;3;4;5;6;7;8;9;10;11;12|] in
  let j = ref 0 in
    for i = 1 to 1_000_000_000 do
      j := 0;
      while !j < 10 do
        if ary.(!j) = 5 then
          j := 10
        else
          incr j
      done
    done

real    0m40.135s
user    0m39.600s
sys     0m0.200s
------------------------------------------------

Break simulated by tail recursive functions
------------------------------------------------
let _ =
  let ary = [|1;2;3;4;5;6;7;8;9;10;11;12|] in
  let rec loop j =
    if j = 10 then 
      ()
    else if ary.(j) = 5 then
      ()
    else
      loop (j + 1)
  in
    for i = 1 to 1_000_000_000 do
      loop 0
    done

real    0m27.075s
user    0m26.940s
sys     0m0.120s
------------------------------------------------

Break simulated by continuation passing (I think that's
what this is -- it looks like a call/cc to me, anyway)
------------------------------------------------
let escape body =
  let module Fail = struct exception T end in
  let datum = ref None in
  let throw v =
    begin
      datum := Some v;
      raise Fail.T
    end
  in
    try
      body throw
    with
        Fail.T -> (match !datum with Some v -> v | None -> assert false)


let _ =
  let ary = [|1;2;3;4;5;6;7;8;9;10;11;12|] in
    for i = 1 to 1_000_000_000 do
      escape (fun exit ->
                for j = 0 to 9 do
                  if ary.(j) = 5 then exit()
                done)
    done

real    1m50.006s
user    1m49.470s
sys     0m0.350s
------------------------------------------------


On Thu, 2003-03-13 at 14:22, Neel Krishnaswami wrote:
> Daniel M. Albro writes:
> > 
> > Hmm...  Apparently I'm a liar.  OK, I take it back.  Doing your
> > version 1 billion times takes 25 seconds on my machine, and my
> > version takes 29 seconds.  I still think a break statement would
> > look nicer.
> 
> Use the power of higher order functions!
> 
> let escape body =
>   let module Fail = struct exception T end in
>   let datum = ref None in
>   let throw v =
>     begin
>       datum := Some v;
>       raise Fail.T
>     end
>   in
>   try
>     body throw
>   with
>     Fail.T -> (match !datum with Some v -> v | None -> assert false)
> 
> Now you can bail out of any computations early, by using an escape:
> 
> escape (fun exit ->
>   for i = 1 to 100 do
>     Printf.printf ".";
>     if i = 25 then exit();
>   done)
> 
> What's nice about this is that it gives you a multi-level break, and
> that you can return values from it, too. Suppose you want to multiply
> the numbers in a list; you can use an escape to stop computing if we
> ever see a 0 in the list.
> 
> let multiply_ints lst =
>   escape (fun exit -> 
>     List.fold_left
>       (fun acc n -> if n = 0 then exit 0 else n * acc)
>       1 
>       lst)
-- 
Daniel M. Albro <albro@humnet.ucla.edu>

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml popularity

[Brian Hurt]

On Thu, 13 Mar 2003, Karl Zilles wrote:

> Daniel M. Albro wrote:
> > imperative side of the language will get fleshed out a bit with some
> > expanded loop features like break statements, 
> 
> You can always implement a break statement as an exception:
> 
> exception Break;;
> 
> try for i = 1 to 10 do
> 	if i == 5 then raise Break
> done with Break -> ();;
> 
> As an exception, you could (if you wanted) include special case handling 
> for the break, or create a more aptly named exception and pass through 
> data.

How efficient is this vr.s rewritting the loop as a tail recursion?  I.e.:

    let rec loop idx = 
        if (idx == 10) then () (* exit the loop *)
        else if special_case(idx) then () (* early exit of the loop *)
        else
        begin
            foo(idx);
            loop (idx + 1)
        end
    in
    loop 1

Naturally, instead of returning unit, the function can return whatever.
All for loops can be rewritten as while loops, and all while loops can be
rewritten as tail recursive functions.

What I'm worried about is the costs of throwing an exception.  This isn't
C++ (where throwing an exception needs to unroll the stack, calling all
the correct destructors, and can therefor be quite expensive), but that
doesn't mean exceptions are 'cheap'.  Exceptions, by definition, are
exceptional.  Were I writting the optimizer, I'd freely assume that any
code path that ends in throwing an exception is not a critical path and 
can be slow.

Brian


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml popularity

[Daniel M. Albro]

	Hmm...  Apparently I'm a liar.  OK, I take it back.  Doing your
version 1 billion times takes 25 seconds on my machine, and my version
takes 29 seconds.  I still think a break statement would look nicer.

					- Dan


On Thu, 2003-03-13 at 13:29, Karl Zilles wrote:
> Daniel M. Albro wrote:
> > imperative side of the language will get fleshed out a bit with some
> > expanded loop features like break statements, 
> 
> You can always implement a break statement as an exception:
> 
> exception Break;;
> 
> try for i = 1 to 10 do
> 	if i == 5 then raise Break
> done with Break -> ();;
> 
> As an exception, you could (if you wanted) include special case handling 
> for the break, or create a more aptly named exception and pass through 
> data.
-- 
Daniel M. Albro <albro@humnet.ucla.edu>

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml popularity

[Daniel M. Albro]

	Yeah, I know, but in time testing I've noticed (I think) that

exception Break;;
try for i = 1 to 10 do
	if i = 5 then raise Break
done with Break -> ();;

	is slower than the (ugly) equivalent

	let i = ref 1 in
	while !i <= 10 do
		if !i = 5 then i := 11;
		incr i
	done;;


On Thu, 2003-03-13 at 13:29, Karl Zilles wrote:
> Daniel M. Albro wrote:
> > imperative side of the language will get fleshed out a bit with some
> > expanded loop features like break statements, 
> 
> You can always implement a break statement as an exception:
> 
> exception Break;;
> 
> try for i = 1 to 10 do
> 	if i == 5 then raise Break
> done with Break -> ();;
> 
> As an exception, you could (if you wanted) include special case handling 
> for the break, or create a more aptly named exception and pass through 
> data.
-- 
Daniel M. Albro <albro@humnet.ucla.edu>

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml popularity

[Karl Zilles]

Daniel M. Albro wrote:
> imperative side of the language will get fleshed out a bit with some
> expanded loop features like break statements, 

You can always implement a break statement as an exception:

exception Break;;

try for i = 1 to 10 do
	if i == 5 then raise Break
done with Break -> ();;

As an exception, you could (if you wanted) include special case handling 
for the break, or create a more aptly named exception and pass through 
data.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml popularity

[Neel Krishnaswami]

Daniel M. Albro writes:
> 
> I also hope that the stream parsing [< >] syntax stuff will get put
> back into the main language and made parseable by ocamldep [...]

You can already do this! Just add a '-pp camlp4o' argument to the
ocamldep command line, like this:

  ocamldep -pp camlp4o [whatever] > .depend

-- 
Neel Krishnaswami
neelk@alum.mit.edu

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml popularity

[Michael Schuerig]

On Thursday 13 March 2003 15:39, Oliver Bandel wrote:

> Well, in GUIs there OO does makes sense.
> But using a more functional approach might help here too.

Yes, "might". But apparently, there's currently no rational reason to 
prefer FP over OO for GUIs. 

> For GUIs OO might be a good choice; but as long as it is
> not tested that FP doesn't help here, I will insist on
> such a solution.

If your mind is set for adventure, you can hope for it and go FP full 
hog. As a general advices this would be irresponsible.


> > [Typical database + GUI enterprise applications]
> >
> > > > Could OCaml in this area bring such a big improvement
> > > > over, say, Java and J2EE?
> > >
> > > See above.
> >
> > No, unfortunately not. You speculate a lot, but don't provide any
> > usable solutions.
>
> When there are hundreds of FP-programmers do not offer solutions
> (not counted the one haskell-approach),
> and many-thousands of OO-programmers are throwing around their
> OO-mess, how should I (not computer science studied; have studied
> electrical engeneering) provide a solution?

"OO-mess"?
(1) Would you be able to distinguish a good OO-solution _that you don't 
understand_ from a bad OO-solution?
(2) Don't expect good OO to be any easier than good FP.
(3) There *are* good OO-solutions for UI programming. Why are you 
convinced that there are even better FP ones? Currently there don't 
seem to be, otherwise I'd like to learn about them. Ideally, such an FP 
solution would be not only just as good as the OO counterpart, but 
instead would be markedly better. It's not much help, if one can say, 
"Look, finally I can do just the same as you".

> When looking at the code, I know what's good and wrong,

> Writing in FP is like having functions, that behave
> determined; when looking at OO-stuff, it looks like
> a stochastical process.

Are you comparing code that does the same? Same task? Same complexity?


> > Being important is an interesting property in a research context.
> > It doesn't make a language popular.
>
> I'm now a t a point, where the popularity is not so much a matter
> to me. I want to learn and to use that language.
> If other people want not, it's their problem.

Ah, well, but this thread is not concerned with you personally. It 
started with someone's wish of OCaml being more popular. I guess, the 
point I'm trying to make is that FP/OCaml won't become more popular in 
an area where it's only just as good as established OO languages and 
techniques.


> If you had asked me this in the beginnings of my OCaml-
> journey, I would have said (and I had said that), that
> I think, that OCaml might be good for larger projects,
> but not for scrippting.
>
> But even there it is better!

So, then let's push it there.


Michael

-- 
Michael Schuerig                All good people read good books
mailto:schuerig@acm.org         Now your conscience is clear
http://www.schuerig.de/michael/ --Tanita Tikaram, "Twist In My Sobriety"

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml popularity

[Daniel M. Albro]

	I thought I might comment a bit on this thread as a recent
learner of OCaml, which I've finally managed to learn at least well
enough to write a nice (in my opinion) MCFG (multiple
context free grammar) chart parser in it.  I don't think the language is
inherently any more difficult to learn than any other (well, maybe
difficult to learn ALL of), but for non-French speakers the lack of
introductory material is a problem.  I tried off and on (mostly
off) to learn the language for a year or two before getting it, and
the thing that allowed me to easily learn the language was the
recent translation of the O'Reilly book into English.  If they
ever publish the thing in English (I guess there's no agreement to
do so), I think the language will begin to take off outside of
France, because of what I think is the language's natural nitch -- it's
a rapid prototyping language (by which I just mean that it's a very high
level language and takes care of garbage collecting, etc.) that produces
fast code.  Lots of recent converts have been brought in
for that very reason, mostly by Doug Bagley's language comparison
page.

	Of course there are areas where the language or its development
environment might be improved, and hopefully this would help with
the popularity problem -- the debugger is rather nonintuitive and could
use random extra features; I've found it a bit difficult to work with. 
I also hope that the stream parsing [< >] syntax stuff will get put back
into the main language and made parseable by ocamldep, that the
imperative side of the language will get fleshed out a bit with some
expanded loop features like break statements, and that someone will do a
wxWindows port.  But these are minor points.  The main thing is to
keep pushing at the compiled code speed, availability of nice
libraries, and good development environment that the language already
has.  Oh, and to advertise them!

-- 
Daniel M. Albro <albro@humnet.ucla.edu>

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] OCaml popularity

[Michael Schuerig]

On Thursday 13 March 2003 00:53, Oliver Bandel wrote:

[misadventure with Tk]
> But: I found out that this terrible OO-stuff is - again -
> a horror!

Are you sure the problem was with the OO part? It's hard to assess this, 
without knowing how well-versed you are in OO. As little as I know Tk, 
it doesn't make construction of a complex UI for a complex application 
particularly easy, but it doesn't make it impossible, either. Java's 
Swing, for all it's faults, does a lot for UIs that are well-structured 
in themselves and well-separated from the application core. More or 
less, it comes down to variations on the MVC (Model-View-Controller) 
pattern.

In effect, all I can say is that OO in itself doesn't get in the way -- 
rather, in my opinion, it helps a lot. Just don't expect Good OO 
Programming to be any easier than Good O'Caml Programming.

Recommendation: "Agile Software Development" by Robert C. Martin 
(Prentice-Hall, 2003). See 
http://www.objectmentor.com/resources/articleIndex

> (I have seen mess in Tcl/Tk-programming as well as
>  in OO-stuff for other applications (that was Java-stuff),
>  at least if the objects were splitted into too small
>  pieces (design-question; OO-gurus may tell you more abot this
>  problem)).

No guru here, but someone who thinks it's a good idea to split things 
into individual pieces that each do a single thing and can be tested 
separately.


> If there would be a more FP-like approach to GUI-programming
> - and that is what you have mentioned above with "what OCaml
> can contribute to GUI-programming" - then this would help
> a lot.

[GUI ideas snipped]

You're mostly dealing with the (comparatively) easy part: visual 
appearance. The hard part is setting things in motion: Reacting to user 
inputs and actions. Displaying data consistently (even after changes 
done in another place).

There are broadly tested and published ways of dealing with GUIs in the 
OO way. MVC, which I already mentioned, is the arch-pattern in this 
regard. Common OO languages help, as the idea of reactive objects that 
handle messages is natural to them.

I've only had very little exposure to purely-functional UIs. Several 
years ago I looked into how GUIs are done in Clean. It was interesting, 
possibly mind-expanding -- but, at least to me, far from intuitive.


>  - trees/hashtables/trees-of-hashtables which binds GUI-objects
>    to it's *function*s (if a GUI-object would be handled like
>    functions in FPLs, then you may use one button as a parameter
>    for a menue (or vice versa).... => higher-order /functional)
>    GUI-objects; GUI-objects as first-citizens...)

Have a look at this overview of the Swing architecture
http://java.sun.com/products/jfc/tsc/articles/architecture/


[Typical database + GUI enterprise applications]
> > Could OCaml in this area bring such a big improvement
> > over, say, Java and J2EE?
>
> See above.

No, unfortunately not. You speculate a lot, but don't provide any usable 
solutions. Not that you're required to, of course. But current OO 
languages do have proven ways of dealing with the problems you've 
encountered.

It's not my intention to disparage OCaml! But I'd like to point out that 
there currently doesn't seem to be a reason to believe that OCaml just 
needs some more libs and app servers to make a combo that's 
*decisively* superior to J2EE (and similar) for a class of very common 
applications.


> > Or are there other -- niche? -- areas where
> > the advantages OCaml provides are far more important?
>
> There are many areas, where OCaml could be important.

Being important is an interesting property in a research context. It 
doesn't make a language popular. The practically interesting areas are 
those, where OCaml provides a significant advantage over other 
languages. These may well be areas deserving of the moniker "difficult 
computing" (as quoted by Xavier in this thread). As a case in point, I 
remember Markus Mottl explaining recently in comp.lang.functional ("AI 
and functional programming") why he chose OCaml.


Michael

-- 
Michael Schuerig                       They tell you that the darkness
mailto:schuerig@acm.org                      is a blessing in disguise.
http://www.schuerig.de/michael/           --Janis Ian, "From Me To You"

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml popularity

[isaac gouy]

Why isn't X more popular?
Why isn't X mainstream?

Such fascinating questions! The many answers often
have as much to do with the specific history of a
language, as they do with language features or design.

Then there's philosophy-
'There are many ways of trying to understand programs.
People often rely too much on one way, which is called
"debugging" and consists of running a
partly-understood program to see if it does what you
expected. Another way, which ML advocates, is to
install some means of understanding in the very
programs themselves.' 
Robin Milner, preface to The Little MLer.

It's the immediate-gratification of getting
"something" to work (and then making it the "right
something") versus the deferred-pleasure of knowing
that you will have a "correct" program.

best wishes, Isaac

__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners