"Mark Evans" <Mark_member@pathlink.com> wrote in message news:biojgp$a7s$1@digitaldaemon.com...
> You're too fixated on syntax.  C has you brainwashed.  Many powerful
languages
> have awful syntax but they are still worthwhile.  Mathematica is a
Lisp-ish

No, I dislike C syntax also.  But not many languages beat it for expressive power on builtins.  Some languages are just excessively wordy.

> Interactive games are the wrong application for a gentle FP introduction.
You
> want something involving data manipulation.

If I'm going to use it at all, I have to understand the mechanisms that allow cyclic control and controlled progressive evaluation of state over time.  Simple games are perfect... they have some simple I/O (keyboard and graphics) and logic running in a simple main loop.

> Push syntax to the back of your brain.  Otherwise you'll just lose out on
the
> power of alternative languages.  Ask yourself why C syntax is any good and you'll realize it's just habit.  In SML function calls are "foo a" instead
of
> "foo(a)" so they are less busy than C.

That's good.  I'm not saying Haskell is too wordy, it's just that it's different enough than C that I don't have any intuitive sense what to type to get it to do what I want.

> What you're trying to do will change once you realize that functional
style
> offers superior expressiveness.  You might reorganize data structures anticipating functional style.  If you're just going to do imperative programming, then do that, and forget functional style.

> Maybe you can start here. http://www.dcs.warwick.ac.uk/fpresearch/whatis.html

Read.  The C and COM interoperability will help propel Haskell forward since that will interface it to the multitude of C and Windows code libraries.

> They are not necessary.  That's why I advised reading the Oz book.
Monadic
> languages are poor choices for newcomers to functional programming.  They
demand
> a solid grasp of functional style.  So monadic languages put FP beginners
in a
> Catch-22.

Please describe how you'd do, say, file I/O or any sort of resource management in functional style without monads to hold state, and without passing the state to all the functions as parameters?

close(read(open("myfile.txt"), line_string));    ????

There has to be something more elegant.  A function can only return one thing, so threading through calls like this would mean you couldn't have a "read" function on a file that returns a value and still pass the file itself through to later reads or to close it.  Yes, there are ways to do it, but this is such a common pattern that it deserves special attention.

> Starting with Haskell is a mistake.  It's still a very good language, but
not
> for FP beginners.

I don't know about all that.  Besides, I'm hardly the average beginner.  ;)

> >Haskell seems to have a pretty steep curve.  About as bad as C++
templates
> >were.
>
> Monads are part of the problem.

Actually it's the declaration and call syntax that are getting me at the moment.

Sean

"Sean L. Palmer" wrote:
> 
> "Mark Evans" <Mark_member@pathlink.com> wrote in message news:biojgp$a7s$1@digitaldaemon.com...
> > You're too fixated on syntax.  C has you brainwashed.  Many powerful
> languages
> > have awful syntax but they are still worthwhile.  Mathematica is a
> Lisp-ish
> 
> No, I dislike C syntax also.  But not many languages beat it for expressive power on builtins.

???

Perl:
   $s = "2 7 - 3";
   $s =~ s/(\d+)/{ $1*$1; }/ge;
   print($s);
Output:
   4 49 - 9

I like the "expressive power"of C, but what a long way would you have to go to reproduce this Perl builtin sample! And that's only one of a myriad of usages.

-- 
Helmut Leitner    leitner@hls.via.at
Graz, Austria   www.hls-software.com

"Sean L. Palmer" <palmer.sean@verizon.net> escreveu na mensagem news:bipoo5$29no$1@digitaldaemon.com...
> "Mark Evans" <Mark_member@pathlink.com> wrote in message news:biojgp$a7s$1@digitaldaemon.com...

[snip]

> Please describe how you'd do, say, file I/O or any sort of resource management in functional style without monads to hold state, and without passing the state to all the functions as parameters?
>
> close(read(open("myfile.txt"), line_string));    ????
>
> There has to be something more elegant.  A function can only return one thing, so threading through calls like this would mean you couldn't have a "read" function on a file that returns a value and still pass the file itself through to later reads or to close it.  Yes, there are ways to do
it,
> but this is such a common pattern that it deserves special attention.

Aha! I gotcha mister Palmer ;)
Languages with a better type system usually provide a tuple type, so
functions can return more than one value. In Haskell:


min_max x y = (min x y, max x y)

let (lower, upper) = min_max a b in ...


It's not unusual to functions return more than one value. But besides monads you can deal with state using continuation passing style (CPS). A continuation is a function that representes the remainder of the call. A continuation-based factorial (k is the usual continuation variable):


id x = x            -- the identity function
fac n = fac-k n id  -- we're telling the fact-k function that after
computing
                    -- the factorial it must use the "id" function as a
continuation

fact-k 0 k = k 1
fact-k n k = fact-k (n - 1) (\x -> k (n * x))


The "k" continuation keeps track of what it needs to do after the base case of "fact-k" is reached. When "n == 0" k represents all the multiplications we need to do with "1" before returning the value. The inductive case of "fact-k" states that the continuation for the "n - 1" case is an anonymous function taking "x" and returning the current continuation "k" (i.e. the k passed as parameter of "fact-k n k") applied to (n * x). The type signature is:


fact :: Int -> Int
fact-k :: Int -> (Int -> Int) -> Int


In IO we can pass explicit continuations to tell the IO functions "what to do next":


using_file "myfile.txt" (\file_handle -> read file_handle (\line_string ->
print line_string))

or with better layout (the parenthesis are unnecessary).

using_file "myfile.txt" \file_handle ->
    read file_handle \line_string ->
        print line_string


You can see that using_file encapsulate the file usage, instead of explicit
opening and close the file. Of course a CPS IO library is more complete than
that, but it's the basic idea.
Going back to the multiple return functions in the Clean language exist
something called unique types. An unique type is like a regular type, but
it's values can be used only once (it's based on linear logic) and the
compiler knows about it. So Clean states that the World type (represents the
outside world) is an unique type and every function dealing with the world
must take it as a parameter an return it as a value. The same goes for file
handles and primitive arrays (uniqueness typing let you do destructive
updates because the compiler can guarantee that the value isn't shared).


print_file world
    #    file = open "myfile.txt"
        (file, line_string) = read file
         _ = close file
    = print line_string world


My Clean may be wrong (I know less about Clean than Haskel), but the
"print_file" function takes the world and give it back. The "open" returns a
unique "file" object, the read uses it and give it back, along with the
"line_string", then the file is closed (the actual Clean program may be
different but the general idea is that) with the result ignored. The
"print_file" value is the world returned by "print".
You can read more about clean ar <http://www.cs.kun.nl/~clean/>. Also Clean
has a game library, so perhaps it's more suited to your needs. They have a
book available in pdf format.


> > Starting with Haskell is a mistake.  It's still a very good language,
but
> not
> > for FP beginners.
>
> I don't know about all that.  Besides, I'm hardly the average beginner.
;)
>
> > >Haskell seems to have a pretty steep curve.  About as bad as C++
> templates
> > >were.
> >
> > Monads are part of the problem.

Here I disagree strongly with Mark. You don't need to grok monads to understand Haskell programs, just remember to use "do" "<-" instead of the normal syntax. But if you grok monads you'll be a better programmer. It's similar to groking C++ templates or groking OO design patterns but the reward will be better IME.

> Actually it's the declaration and call syntax that are getting me at the moment.
>
> Sean

    Best regards,
    Daniel Yokomiso.

"Sanity is the playground for the unimaginative."


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.514 / Virus Database: 312 - Release Date: 28/8/2003

"Helmut Leitner" <leitner@hls.via.at> escreveu na mensagem news:3F507640.F6E7F6F9@hls.via.at...
> "Sean L. Palmer" wrote:

[snip]

> > No, I dislike C syntax also.  But not many languages beat it for
expressive
> > power on builtins.
>
> ???
>
> Perl:
>    $s = "2 7 - 3";
>    $s =~ s/(\d+)/{ $1*$1; }/ge;
>    print($s);
> Output:
>    4 49 - 9

That's why we study both type theory and popular languages. If we have a type "RegEx a" where the "a" type parameter is the resulting type that can be deconstructed by the regular expression, we can define (assuming any possible name for tokens, but they must be separated by spaces, and [# ] for comments):

\d : RegEx Natural   [# the \d object is a RegEx that can transform strings
into natural numbers]
+ regex : (RegEx a) -> (RegEx b)  [# "+" is an abstract method of RegEex
that transform a "RegEx a" into a "RegEx b". In some cases you can declare a
RegEx to return a list of something, that's why it's abstract]
+ regex : (RegEx Natural) -> (RegEx Natural) [# "+" for RegEx of Natural
return a RegEx of Natural, the digits just are placed together]

replace-all text regex transform : String -> (RegEx a) -> (a -> a) -> String [# this method apply the "regex" to the "text", deconstructing the values obtained by the result of applying them to the "transform" and then calling "to-string" to the result]

"2 7 - 3" replace-all (\d +) (_ squared) print
[# "_ squared" is a anonymous function with a unkown parameter "_". The type
matches with the type required by transform. "print" is applied to the
result of "replace-all" so we don't need parenthesis]


Voilá using a good library, a good syntax and polymorphic types we can write code as succint as Perl (around 10% of character count), but type-safe. AFAICT the Haskell type-system can deal with such constructions, of course the syntax would be different. My example doesn't compile in any language available but, I hope, it'll be valid Eon syntax.


perl: print("2 7 - 3" =~ s/(\d+)/{ $1*$1; }/ge);
eon:  "2 7 - 3" replace-all (\d +) (_ squared) print


I agree that it isn't easy to understand how the type-safe example works, but the same goes for the Perl compiler. If we just look for the usage, both are easy to understand, once you understand the idioms of the language.

> I like the "expressive power"of C, but what a long way would you have to go to reproduce this Perl builtin sample! And that's only one of a myriad of usages.
>
> -- 
> Helmut Leitner    leitner@hls.via.at
> Graz, Austria   www.hls-software.com


    Best regards,
    Daniel Yokomiso.

"Later in this talk, I intend to define the universe and give three
examples."
 - Larry Wall


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.514 / Virus Database: 312 - Release Date: 28/8/2003

"Mark Evans" <Mark_member@pathlink.com> escreveu na mensagem news:bip2sd$12ag$1@digitaldaemon.com...
> Daniel Yokomiso says...
> >
> >Sometimes syntax matters....if the language support[s] currying...while in languages without currying...
>
> The difference between currying and non-currying is substantially more
than a
> syntax difference!


Then we'll have to agree to disagree. Currying is not a matter of semantics, just syntax. Semantics is something like supporting higher-order functions, while syntax is how you need to define them.

[snip]

> >Nothing is *necessary*, but they can help your life. Monads aren't used
just
> >for IO they're are means to express computations, and how such
computations
> >can be composed. If you grok monads you'll be able to better modularize
your
> >code and even evaluation strategy.
>
> Monads are ULTRA BAD NEWS for FP beginners.  My advice to beginners:
AVOID
> MONADS AT ALL COSTS.  Use a langauge like O'Caml which is not so far from
what
> you already know.  Then you can grow into FP by steps, without feeling
totally
> lost.

Again we'll have to agree in disagreeing. When learning a new paradigm you should drop your baggage and embrace the new paradigm. C programmers moving to C++ can believe they program in OO even if they don't use OO features. Ditto for Java programmers. Most people who think they know about OO don't really get it, most of them need to be exposed to Smalltalk, Self, etc. to truly understand how OO should work. The same goes for FP. "The Koan of Side Effects" at <http://www.bagley.org/~doug/ocaml/Notes/okoans.shtml> provides a a very good metaphor.


> Yes monads are very capable, and useful, in the right hands.  So are good old-fashioned variables!  We are talking about beginners here.  We are
also
> talking about basic stateful programming, not generalized monadic
constructions.
>
> Explicit state makes equivalent monad constructions look like castles in
the air
> and make FP look weird.  Monads will turn people off.  As well they
should!
> This is the whole point of multi-paradigm programming (Oz, O'Caml,
Needle):  use
> the paradigm that fits.  Don't lock yourself in.  When you need state, use state.

Basic imperative programming is very difficult, but most of people ignore it because they were told that way. It's hard to write correct programs when you deal with side effects. But most people use a half-baked form of imperative programming and think that it's all it takes. If we look at Dijkstra, Parnas or Hoare writings about procedural programming (with all the proofs and explicit controls) we see how hard is to do things right. Common imperative languages hide this, while FPLs show it, but let you control how you'll deal with it. If you tell people monads are easy, and explain them without the math and just with examples they'll get it. Monad's aren't the boogeyman.

> Loss of a familiar concept like 'variable' is pretty severe boot camp for
FP
> newbies.  You've already stated a concern for FP marketing to the masses.
There
> is more to it than marketing, but in essence monads are not more general
than
> the overall Oz kernel model, or for that matter any non-functional
language.
> Monads are just handy for CS theoreticians, functional language
implementors,
> and FP blackbelts, all of whom wish to avoid side effects.

I don't see how the Oz kernel model is more general than monads. Could you give some example? Monads can be written using basic language concepts, either in Scheme, Haskell, Clean, OCaml or even Java, D and C++. The only problem is the syntax (Haskell's do notation), but that can be defined with a simple preprocessor (or macros in Scheme).

[snip]

> >Haskell...was hard [to learn] but I preferred it to Scheme or ML
variants.
>
> You are also a language guru who enjoys learning new languages for their
own
> sake.  That is not the case with everyone.

Err, when I started learning Haskell I was a programmer with professional experience in Java, and some toying with C and Pascall. Also I had knew a little bit of Cobol and Natural, not enough to program, but sufficient enough to understand what people were talking about. I'm no language guru, I don't even have a CS graduation (I dropped my physics graduation, 3/5 completed). But I felt Haskell was more "natural" than Scheme or OCaml. So I don't think I'm an exceptional case. There's a Haskell programmer talking about why he uses Haskell:


"Not to mention that I am not very good with programming  which makes it easier for me (Funktionall Programming rules)." http://haskell.org/pipermail/haskell/2003-August/012537.html


>  Also, the Oz book covers Haskell's
> 'flaws' in detail - er, from a certain point of view called
'multiparadigm.'
>
> Thanks for the joust Daniel!  I have more remarks about Needle and Eon,
but need
> some info about your type system, references to any academic work that
you're
> using, and rationales for the necessity of doing things in the ways
indicated.
> But at this point we probably belong on LtU. :-)  Why don't you post a
note
> there about Eon and the details of its type system.

AFAIK there's no single type system that I can use for Eon, so I'm mixing a
type system supporting Hindley-Milner like type inference with the Cayenne
type system and Coq-like capabilities. In Eon types are sets, with subsets
and supersets, all common set operations (e.g. union, intersection,
negation, difference). They also behave as predicates, implication means
subtyping (e.g. given types A and B, A implies in B, B is a subtype of A).
Another problem is that Eon uses opaque objects (instead of transparent
records with explicit constructor) and classes as interfaces, so I need some
object calculus to define some things, and Luca Cardelli's sigma calculus
doesn't fit my needs. I'll probably end definining some basic typed object
calculus.
But I don't think it's a good idea to post about Eon in LtU. It's still
vaporware ;) I post here because people ask, and the forum seems to like
really OT discussions ;) Perhaps in a year or so I'll have a working
compiler, then I'll post about it.

> Mark

    Best regards,
    Daniel Yokomiso.

"Chaos! Panic! Disaster! (My work here is done)."
"Mark Evans" <Mark_member@pathlink.com> escreveu na mensagem
news:bip2sd$12ag$1@digitaldaemon.com...
> Daniel Yokomiso says...
> >
> >Sometimes syntax matters....if the language support[s] currying...while in languages without currying...
>
> The difference between currying and non-currying is substantially more
than a
> syntax difference!


Then we'll have to agree to disagree. Currying is not a matter of semantics, just syntax. Semantics is something like supporting higher-order functions, while syntax is how you need to define them.

[snip]

> >Nothing is *necessary*, but they can help your life. Monads aren't used
just
> >for IO they're are means to express computations, and how such
computations
> >can be composed. If you grok monads you'll be able to better modularize
your
> >code and even evaluation strategy.
>
> Monads are ULTRA BAD NEWS for FP beginners.  My advice to beginners:
AVOID
> MONADS AT ALL COSTS.  Use a langauge like O'Caml which is not so far from
what
> you already know.  Then you can grow into FP by steps, without feeling
totally
> lost.

Again we'll have to agree in disagreeing. When learning a new paradigm you should drop your baggage and embrace the new paradigm. C programmers moving to C++ can believe they program in OO even if they don't use OO features. Ditto for Java programmers. Most people who think they know about OO don't really get it, most of them need to be exposed to Smalltalk, Self, etc. to truly understand how OO should work. The same goes for FP. "The Koan of Side Effects" at <http://www.bagley.org/~doug/ocaml/Notes/okoans.shtml> provides a a very good metaphor.


> Yes monads are very capable, and useful, in the right hands.  So are good old-fashioned variables!  We are talking about beginners here.  We are
also
> talking about basic stateful programming, not generalized monadic
constructions.
>
> Explicit state makes equivalent monad constructions look like castles in
the air
> and make FP look weird.  Monads will turn people off.  As well they
should!
> This is the whole point of multi-paradigm programming (Oz, O'Caml,
Needle):  use
> the paradigm that fits.  Don't lock yourself in.  When you need state, use state.

Basic imperative programming is very difficult, but most of people ignore it because they were told that way. It's hard to write correct programs when you deal with side effects. But most people use a half-baked form of imperative programming and think that it's all it takes. If we look at Dijkstra, Parnas or Hoare writings about procedural programming (with all the proofs and explicit controls) we see how hard is to do things right. Common imperative languages hide this, while FPLs show it, but let you control how you'll deal with it. If you tell people monads are easy, and explain them without the math and just with examples they'll get it. Monad's aren't the boogeyman.

> Loss of a familiar concept like 'variable' is pretty severe boot camp for
FP
> newbies.  You've already stated a concern for FP marketing to the masses.
There
> is more to it than marketing, but in essence monads are not more general
than
> the overall Oz kernel model, or for that matter any non-functional
language.
> Monads are just handy for CS theoreticians, functional language
implementors,
> and FP blackbelts, all of whom wish to avoid side effects.

I don't see how the Oz kernel model is more general than monads. Could you give some example? Monads can be written using basic language concepts, either in Scheme, Haskell, Clean, OCaml or even Java, D and C++. The only problem is the syntax (Haskell's do notation), but that can be defined with a simple preprocessor (or macros in Scheme).

[snip]

> >Haskell...was hard [to learn] but I preferred it to Scheme or ML
variants.
>
> You are also a language guru who enjoys learning new languages for their
own
> sake.  That is not the case with everyone.

Err, when I started learning Haskell I was a programmer with professional experience in Java, and some toying with C and Pascall. Also I had knew a little bit of Cobol and Natural, not enough to program, but sufficient enough to understand what people were talking about. I'm no language guru, I don't even have a CS graduation (I dropped my physics graduation, 3/5 completed). But I felt Haskell was more "natural" than Scheme or OCaml. So I don't think I'm an exceptional case. There's a Haskell programmer talking about why he uses Haskell:


"Not to mention that I am not very good with programming  which makes it easier for me (Funktionall Programming rules)." http://haskell.org/pipermail/haskell/2003-August/012537.html


>  Also, the Oz book covers Haskell's
> 'flaws' in detail - er, from a certain point of view called
'multiparadigm.'
>
> Thanks for the joust Daniel!  I have more remarks about Needle and Eon,
but need
> some info about your type system, references to any academic work that
you're
> using, and rationales for the necessity of doing things in the ways
indicated.
> But at this point we probably belong on LtU. :-)  Why don't you post a
note
> there about Eon and the details of its type system.

AFAIK there's no single type system that I can use for Eon, so I'm mixing a
type system supporting Hindley-Milner like type inference with the Cayenne
type system and Coq-like capabilities. In Eon types are sets, with subsets
and supersets, all common set operations (e.g. union, intersection,
negation, difference). They also behave as predicates, implication means
subtyping (e.g. given types A and B, A implies in B, B is a subtype of A).
Another problem is that Eon uses opaque objects (instead of transparent
records with explicit constructor) and classes as interfaces, so I need some
object calculus to define some things, and Luca Cardelli's sigma calculus
doesn't fit my needs. I'll probably end definining some basic typed object
calculus.
But I don't think it's a good idea to post about Eon in LtU. It's still
vaporware ;) I post here because people ask, and the forum seems to like
really OT discussions ;) Perhaps in a year or so I'll have a working
compiler, then I'll post about it.

> Mark

    Best regards,
    Daniel Yokomiso.

"Chaos! Panic! Disaster! (My work here is done)."

Sean, Daniel-

Trying to help Sean learn FP and Daniel think about Eon has induced debates that I can live without.  However I wish to restate my slightly mischaracterized position, otherwise outsiders will lose perspective on FP.  Here the idea is not to paraphrase, refute, or agree with anyone.  The idea is to clarify my own thoughts.

1. Monads and syntax are almost irrelevant to doing good FP.  We have
spent too much time on both subjects.  The heart of FP has been truly
ignored in this thread, sadly.  FP is beautiful in many domains.
The take home lesson is that you can do FP without knowing monads.
Monads are a side-show.

2. There are however corner-cases in FP.  State and I/O are two of them. FP does not handle them well.  At that point, a good language should allow the programmer to slide seamlessly into an imperative/stateful paradigm.  That is best from a user point of view IMO.  Such languages are called 'multiparadigm' or 'functional-OO' or something like that.

3. However from the viewpoint of language implementors/theorists/purists, just switching paradigms is not so easy.  In this sense monads are really 'the easy way out' for language designers, who push the burden onto end users.  Monads are used as a band-aid.

4. Monads still have theoretical generality.  I never said otherwise.
So does a Turing machine.  Both are awful for users.
Other computational models have equal generality -- I never said
superior, although that would not surprise me.  Wadler has shown
equivalence between monads and continuation-passing style IIRC.
The Oz model was specifically designed for working programmers.
Monads were not.  In fact, moands fell out of highly abstract
mathematics called category theory - really exotic stuff.
Monads do have a certain unique beauty of their own, much like
an M.C. Escher print.  It's one thing to admire a print, but
another to draw one yourself.  That is what you are doing when
you use monads.

5. There are certain things that cannot be done in pure FP without
monad techniques.  I never pretended otherwise.  On the other hand
I do say that (a) monads are the wrong place to start learning FP;
(b) multiparadigm languages eliminate the need for them and
solve the same problems more intuitively; (c) monads give FP a bad
reputation and detract from the success of FP generally.

6. Currying: http://lambda.weblogs.com/discuss/msgReader$4670?mode=topic

Best regards and happy programming-
Mark

What is this OZ book ?  Whats the best functional language to start with ?


Charles

"Daniel Yokomiso" <Daniel_member@pathlink.com> wrote in message news:biji5a$1m5t$1@digitaldaemon.com...
> In article <bih3e8$rn6$1@digitaldaemon.com>, Mark Evans says...
> >
> >http://www.minddrome.com/produtos/eon/
> >
> >I assume this is Daniel Yokomiso's language.  I like the write-up so far.
The
> >bit about the Turing tar pit is spot-on.  That's why languages are
important...
> >
> >http://www.digitalmars.com/drn-bin/wwwnews?D/16134
> >
> >..it's not about ultimate capability, but expressing thought concisely
with
> >minimum error.  Yes, a Turing machine can do anything, as can C and
FORTRAN.
> >But I'd much rather write 2*8 than 2+2+2+2+2+2+2+2.  That's a good
analogy.
> >
> >I'm curious how Eon will compare with Needle, Oz, Alice ML, and other
laboratory
> >languages.  Needle and Alice are statically type-inferred like Eon, but
not as
> >contractual (?).  Anyway thanks to Daniel for his thoughtful
contributions to D
> >and good luck with Eon.
> >
> >Mark
>
> Argh! I really need to update the documentation. That's what happens when
you
> leave draft publications publicly, people dig your rants ;)
>
> Seriously, I really need to update everything, the concept is unchanged
(well
> except for dropping side-effects in favour of monads), but the semantics improved and the syntax changed heavily.
>
> Regarding the comparison against Needle, Oz and Alice ML here goes a
draft:
> Needle - it'll be probably very similar to Needle, modulo predicate-based
typing
> (AFAIK Needle has none of these), purity and the macro syntax (Eon macro
calls
> are explicit, [ ] denote macro call, with the first token inside being the
macro
> name: [if 1 < n then 1 else 2]). Of course the basic libraries will be
> different.
> Oz - very big differences IMO. Oz is dynamically-strong typed, using
unification
> for bindings and constraints, and allowing imperative code. Eon is statically-strong typed using predicate-based typing for constraints and
keeping
> all imperative code inside monads. Eon will also support concurrency, but
more
> in the model of Erlang using some kind of Process monad instead.
> Alice ML - unfortunately this language is still in my reading queue, so I
can't
> tell much about it, except for the ML part of it (IIRC it's a variant of
ML).
> Eon probably is able to express everything a ML-like language can,
probably with
> similar syntax.
> Thanks for your wishes.
>
> Best regards,
> Daniel Yokomiso.
>
> "Why should I care about posterity? What's posterity ever done for me?"
>  - Groucho Marx

"Charles Sanders" <sanders-consulting@comcast.net> escreveu na mensagem news:bjgcjp$19jk$1@digitaldaemon.com...
> What is this OZ book?


http://www.info.ucl.ac.be/~pvr/


> Whats the best functional language to start with?


Depends on how your mind works. It's similar to asking "what is the best programming language to start with?". People like to learn from Scheme, perhaps you'll like it. There's online books available and a very good IDE:


Info:
http://www.schemers.org/
IDE:
http://www.drscheme.org/
Online Books:
http://www.htdp.org/
http://mitpress.mit.edu/sicp/
http://www.ccs.neu.edu/home/dorai/t-y-scheme/t-y-scheme.html


Some people (like me) prefer Haskell, the best places are:


Info:
http://www.haskell.org/
Interactive Environment:
http://www.haskell.org/hugs/
Online Tutorials:
http://www.cs.ou.edu/~rlpage/fpclassCurrent/textbook/haskell.shtml
http://www.haskell.org/tutorial/


And other prefer Ocaml or Erlang:


http://www.ocaml.org/
http://www.erlang.org/


Try to read something about each one and decide which you like most.

> Charles

   Best regards,
   Daniel Yokomiso.

"God is real, unless declared integer."




---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.514 / Virus Database: 312 - Release Date: 30/8/2003