"Daniel Yokomiso" <daniel_yokomiso@yahoo.com.br> wrote in message news:bijk1e$1p1u$1@digitaldaemon.com...
> "Sean L. Palmer" <palmer.sean@verizon.net> escreveu na mensagem news:bihoeq$1usj$1@digitaldaemon.com...
> > I like the lazy integer division producing rationals.  ;)
>
>     If you like it probably you'll love the natural number implementation
> using church numerals and the real number implementation based on Dedekind
> cuts ;)

The church numbers just seems like it would bloat your compile times excessively.  Neat proof though.

Dedekind cuts:  I never heard of this before.  Good stuff!

> > I might like this language... seems alot like Haskell, but a bit
> modernized.
> > I like Haskell but it seems perhaps to be falling behind the pack..
> >
> > Sean
>
>     Hmmm, how do you think that Haskell is falling behind the pack? I'm
> really interested in hearing what people expect from a programming
language,
> and how some languages don't make it.

It just gives me the feeling that not many people are using it.  I think most people wouldn't be able to program in such languages just because you damn near have to be a mathematician to understand how it works.  ;)

I still don't have a good feel for functional languages due to lack of exposure and experience.  Haskell is one of the most interesting of the bunch that I've seen.

The main problem seems to be that you can't do useful work (in the usual sense) without side effects.  It also seems hard to represent state. Despite the many problems both of those things lead to, they are the foundation of imperative programming, and you almost have to invert your whole way of thinking to be able to grok functional style.  It's difficult to unlearn imperative concepts.

A programming language that I might actually use has to make it easy to do real work, such as file I/O, user input, and graphical output, and none of those things are possible without some kind of side effects or persistent object state.  I guess I need to research monads more.

Sean

Daniel Yokomiso wrote:

>     Hmmm, how do you think that Haskell is falling behind the pack? I'm
> really interested in hearing what people expect from a programming language,
> and how some languages don't make it.

To me it's important to get things done. A language is there to be learned, then. :)
This draws that, with many different needs there come many different languages. So, you see a programmer's profile and kinda know what he/she needs.
Also a clarification - to get things done in the "best" way possible, regarding time/effort for both the developer and the end user. That's why Visual Basic has so many followers, although it may be ridiculous from the standpoint of more "low-level" developers.

Metta,

Alen

Alen Siljak says...
>
>To me it's important to get things done. A language is there to be
>learned, then. :)
>This draws that, with many different needs there come many different
>languages. So, you see a programmer's profile and kinda know what he/she
>needs.
>Also a clarification - to get things done in the "best" way possible,
>regarding time/effort for both the developer and the end user. That's
>why Visual Basic has so many followers, although it may be ridiculous
>from the standpoint of more "low-level" developers.

Alen,

You are 100% correct.  To elucidate these points, here's a challenge for skeptics.

1. Write a D program with 10,000 concurrent threads and keep it from crashing.
2. Write one to express the rock-paper-scissors game without multimethods.
3. Implement a custom embedded domain-specific language in D.
4. Write a mathematics program mixing functional and OO styles.

Just one such exercise will reveal why languages like Alice, Needle, Haskell, and Eon are of interest for people who like to get things done.

Imperative programmers mostly don't know what they are missing.  If they did, there would be more widespread usage of Haskell and the rest.  So the problem is likely to be one of education.  That's not my opinion alone; it crops up on LtU all the time (read the archives).

The Oz book agrees, saying (for example) that Java programmers think concurrency is intrinsically hard, merely because Java makes it hard.  Java's language model is the absolute worst case from a concurrency standpoint.  In fact concurrency is easy, but Java programmers don't know that.  So Java folks will spend weeks in a state of resigned suffering to achieve a half-baked solution, while Alice or Erlang could solve such a problem in mere days.

The educational problem may be the same syndrome that makes people try to assemble kits without reading instructions.  Reading about languages is like reading instructions.  The payoff is not immediate, so people avoid it.  They just start hacking away no matter the pain.

Microsoft has hired several stars of language research, including Peyton-Jones of Haskell fame.  Microsoft also worked with 'exotic language' groups like Mercury to ensure that .NET would interoperate with emerging paradigms.  Maybe the good news is that Microsoft's marketing machinery will eventually get the word out, even if nothing else has.

Regards,
Mark

>It just gives me the feeling that not many people are using it.  I think most people wouldn't be able to program in such languages just because you damn near have to be a mathematician to understand how it works.  ;)

You probably felt that way when you learned C, which is a very contorted language, being as polite as I can.

>I still don't have a good feel for functional languages due to lack of exposure and experience.  Haskell is one of the most interesting of the bunch that I've seen.

Haskell is a good language.

>The main problem seems to be that you can't do useful work (in the usual sense) without side effects.  It also seems hard to represent state.

Functions do useful work and that is the whole point of functional style:  they can often do it better than stepwise instructions.

You can also do useful work with state.  Side effects are only 'problems' for pure functional languages and their theoreticians.  Eon aims for functional purity so it requires monads.  Other functional languages like Needle, O'Caml, and Alice are not as strict, so you might feel more comfortable with them. Personally I dislike monads.

>Despite the many problems both of those things lead to, they are the foundation of imperative programming, and you almost have to invert your whole way of thinking to be able to grok functional style.  It's difficult to unlearn imperative concepts.

You don't need to unlearn imperative concepts to learn applicative ones.  You don't need to toss your blackbelt in Karate to learn boxing.

Any new skill has a learning curve.  Once you learn it, you will wonder how you ever survived without it.  Until then, you will imagine the skill to be hard. Some folks never learn how to swim, others never learn how to drive, but neither is very difficult.

Don't let Eon scare you away with Dedekind cuts.  Those are peripheral issues. Myself, I don't see how Dedekind cuts could matter to any programming language even at the implementation level.  Dedekind cuts only matter in mathematical proofs about the real number system.

>A programming language that I might actually use has to make it easy to do real work, such as file I/O, user input, and graphical output, and none of those things are possible without some kind of side effects or persistent object state.  I guess I need to research monads more.

Functions do real work.  The Oz book was written for people like you!  Forget monads, read that, and pay attention to the Haskell case studies!

Good luck-

Mark

"Mark Evans" <Mark_member@pathlink.com> escreveu na mensagem news:bik3f5$2g4e$1@digitaldaemon.com...
>
> > Argh! I really need to update the documentation. That's what happens when you leave draft publications publicly, people dig your rants ;)
>
> Your write-up is good. It did not seem like a rant. The phrase "Turing tar pit" is a good one. I like it a lot.

Well, it's not an article or paper (it's too short) and since I don't have a working implementation, it's more of a rant on How Things Should Be.

> > except for dropping side-effects in favour of monads... purity and the macro syntax
>
> Monads will buy purity. You may want to read the Wadler paper "The marriage of effects and monads" before getting too deep though. http://www.research.avayalabs.com/user/wadler/topics/monads.html
>
> Oz uses 'cells' and 'tickets.' Wadler I alerted to the Oz research several months ago. I'm not sure whether he's had a chance to compare notes.

AFAIK monads are a more general model to describe computations, where the Oz model is more specific to side-effects.

> > Needle - it'll be probably very similar to Needle, modulo predicate-based typing (AFAIK Needle has none of these)
>
> Hmm. Needle employs the MLsub type algebra,
> http://www.exalead.com/Francois.Bourdoncle/popl97.html
> The type constraints are predicates. MLsub is "a generalization of the
> classical Hindley-Milner predicative type system" (p. 69). Maybe you
> mean something else by predicate-based.
>
> It almost seems like Needle might be a good starting point for Eon? Or that they could merge?

Hmmm, as far as I read from Needle (the MIT talk and something from the site) I understand that they would be using a terminating type algebra (assuming that MLsub isn't terminating). Eon type system is non-terminating, like Cayenne, but if Needle has a similar type-system perhaps we could merge the two languages (in the byte-code form or something like). There's still a big difference between Eon's classes and Needle's classes: in Eon a class define a object interface only (no attributes), wile needle can define data and methods.

> > Oz - very big differences IMO. Oz is dynamically-strong typed
>
> Dynamic typing is a difference, but not a critical one from a language expressiveness standpoint.

But it's pretty important when we are talking about reasoning tools. Eon type system is designed to deal with nasty depent types, so we can express dependencies between the input (e.g. a floating-point with at least n digits of precision) to the output (a floating-point with at most sqrt(n) digits of precision).

> Eon, Needle, and Alice all use type
> inference anyhow - pushing types into the background as it were. I was
> more interested in the comparison of Eon's goals with those of Oz,
> especially regarding multiparadigm programming. As an
> "object-oriented...functional programming language," Eon is trying to
> bridge similar gaps.

Yes, but we still have to see what it will become.

> > Eon will also support concurrency, but more in the model of Erlang using some kind of Process monad instead.
>
> OK. A reason for asking about Oz was that Haskell and Erlang seem to be motivating inspirations for Eon. These two languages are in-depth case studies in the Oz book, so in that sense Oz was inspired by them too. http://www.info.ucl.ac.be/people/PVR/book.html I can see where you are going though.  Too bad D is not very concerned about concurrency.

It's almost impossible to come with a good concurrency system for an imperative language like D. Java's model sucks, and to write a better model we need to (AFAICT): either lots of primitives and go the Ada way, or use a Actor-like model. IMO it's better to define the concurrency in the libraries and hope for the best ;)

> > Alice ML - unfortunately this language is still in my reading queue
>
> It's a statically typed ML with Oz inclusions and controlled dynamic typing.  There is a paper about its implementation, http://www.ps.uni-sb.de/Papers/abstracts/Kornstaedt2001.html

Then it's probably similar in intent to Eon.

    Best regards,
    Daniel Yokomiso.

"All the water in the world cannot sink the smallest ship unless it gets
inside."
 - Boyd K. Packer


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

"Sean L. Palmer" <palmer.sean@verizon.net> escreveu na mensagem news:bikddc$312t$1@digitaldaemon.com...
> "Daniel Yokomiso" <daniel_yokomiso@yahoo.com.br> wrote in message news:bijk1e$1p1u$1@digitaldaemon.com...
> > "Sean L. Palmer" <palmer.sean@verizon.net> escreveu na mensagem news:bihoeq$1usj$1@digitaldaemon.com...
> > > I like the lazy integer division producing rationals.  ;)
> >
> >     If you like it probably you'll love the natural number
implementation
> > using church numerals and the real number implementation based on
Dedekind
> > cuts ;)
>
> The church numbers just seems like it would bloat your compile times excessively.  Neat proof though.

The basic implementation/specification will define all naturals to be Church numerals. When the compiler is able to narrow down some specific usage (e.g. a function bounded to 1 .. 10000) the compiler can replace the natural implementation with a smaller one (int32 or int16 or whatever) as long as the invariants are respected. It seems to work in theory, so I'm happy with it ;)

> Dedekind cuts:  I never heard of this before.  Good stuff!

My guess is that symbolic arithmetic is faster/safer than using ints and floats, because once we can constrain the symbolic arithmetic properly we can choose the best implementation.

> > > I might like this language... seems alot like Haskell, but a bit
> > modernized.
> > > I like Haskell but it seems perhaps to be falling behind the pack..
> > >
> > > Sean
> >
> >     Hmmm, how do you think that Haskell is falling behind the pack? I'm
> > really interested in hearing what people expect from a programming
> language,
> > and how some languages don't make it.
>
> It just gives me the feeling that not many people are using it.  I think most people wouldn't be able to program in such languages just because you damn near have to be a mathematician to understand how it works.  ;)
>
> I still don't have a good feel for functional languages due to lack of exposure and experience.  Haskell is one of the most interesting of the bunch that I've seen.
>
> The main problem seems to be that you can't do useful work (in the usual sense) without side effects.  It also seems hard to represent state. Despite the many problems both of those things lead to, they are the foundation of imperative programming, and you almost have to invert your whole way of thinking to be able to grok functional style.  It's difficult to unlearn imperative concepts.

The problem with imperative concepts is that they hide stuff for us, most of the time. There's lots of implicit assumptions hidden in every imperative program. It's similar to global variables: they may help sometimes, but they hide the program's structure. With pure fp io (either monads or linear logic) you'll state your assumptions and draw the program structure, but it'll make the code clearer. But I agree that imperative mindset is very difficult to unlearn, easier only than OO mindset.

> A programming language that I might actually use has to make it easy to do real work, such as file I/O, user input, and graphical output, and none of those things are possible without some kind of side effects or persistent object state.  I guess I need to research monads more.

There's a very good tutorial available in: http://www.nomaware.com/monads/html/index.html, but be warned that knowledge in Haskell is required.

> Sean

    Best regards,
    Daniel Yokomiso.

"Life is not a matter of holding good cards, but of playing a poor hand
well."
 - Robert Louis Stephenson


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

"Mark Evans" <Mark_member@pathlink.com> wrote in message news:bilgl0$1p9g$1@digitaldaemon.com...
>
> >It just gives me the feeling that not many people are using it.  I think most people wouldn't be able to program in such languages just because
you
> >damn near have to be a mathematician to understand how it works.  ;)
>
> You probably felt that way when you learned C, which is a very contorted language, being as polite as I can.

I take your point, but what I felt when I learned C was both a sigh of relief that the wordy syntax of Pascal could be eliminated while gaining power, and simultaneous nausea from the linker hassles.  Compiling was slow and painful.  I knew people were using it, and nothing in the language really scared me.  So it was a different situation.

> >I still don't have a good feel for functional languages due to lack of exposure and experience.  Haskell is one of the most interesting of the bunch that I've seen.
>
> Haskell is a good language.

I am giving Haskell another shot.  It took like 2 hours to add a "key up" clause to that little game "Paratrooper", just constantly fighting the syntax, mostly, because I have no idea what I'm doing and it's all unfamiliar.  The syntax is certainly much different.  Got a lot of libraries, symbols, types to learn too.

It seems more complicated than it needs to be.  Don't worry, I get the same feeling, probably worse, when I program C++.  ;)

> >The main problem seems to be that you can't do useful work (in the usual sense) without side effects.  It also seems hard to represent state.
>
> Functions do useful work and that is the whole point of functional style:
they
> can often do it better than stepwise instructions.

If you can express what you're trying to do in a functional way, as the result of an expression on some inputs.  Really everything is sorta like that.

> You can also do useful work with state.  Side effects are only 'problems'
for
> pure functional languages and their theoreticians.  Eon aims for
functional
> purity so it requires monads.  Other functional languages like Needle,
O'Caml,
> and Alice are not as strict, so you might feel more comfortable with them. Personally I dislike monads.

It seems that they shouldn't be necessary somehow.  Maybe there's a better way to express that concept.

> You don't need to unlearn imperative concepts to learn applicative ones.
You
> don't need to toss your blackbelt in Karate to learn boxing.

Hmm.

> Any new skill has a learning curve.  Once you learn it, you will wonder
how you
> ever survived without it.  Until then, you will imagine the skill to be
hard.
> Some folks never learn how to swim, others never learn how to drive, but
neither
> is very difficult.

Haskell seems to have a pretty steep curve.  About as bad as C++ templates were.

> Don't let Eon scare you away with Dedekind cuts.  Those are peripheral
issues.
> Myself, I don't see how Dedekind cuts could matter to any programming
language
> even at the implementation level.  Dedekind cuts only matter in
mathematical
> proofs about the real number system.

The results are the only thing that is really important.  Does it make me more productive?  Does it generate "good" code?  Can it express complex systems easily?

> Functions do real work.  The Oz book was written for people like you!
Forget
> monads, read that, and pay attention to the Haskell case studies!

The problem is getting the right data into the functions, I guess.
Threading state through a lot of functions is tedious.
I'll check into it.  Thanks Mark!

Sean

Sean L. Palmer says...
>>
>> You probably felt that way when you learned C, which is a very contorted language, being as polite as I can.
>
>I take your point, but what I felt when I learned C was both a sigh of relief that the wordy syntax of Pascal could be eliminated

Learning anything brings a sigh of relief.  The situation is more or less identical.  Replace 'Pascal' with 'C' and 'C' with 'multiparadigm language X' in what you wrote.

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 numerics package with terrible syntax, but I couldn't live without it.  The power in its multiparadigm language is awesome and its efficiency is unbeatable. (Something of interest to Eon might be its advanced variable-precision numerics.)

>I am giving Haskell another shot.  It took like 2 hours to add a "key up" clause to that little game "Paratrooper", just constantly fighting the syntax, mostly, because I have no idea what I'm doing and it's all unfamiliar.  The syntax is certainly much different.

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

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.

>If you can express what you're trying to do in a functional way, as the result of an expression on some inputs.  Really everything is sorta like that.

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

>> Personally I dislike monads.
>
>It seems that they shouldn't be necessary somehow.  Maybe there's a better way to express that concept.

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.

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


>Haskell seems to have a pretty steep curve.  About as bad as C++ templates were.

Monads are part of the problem.


>The results are the only thing that is really important.  Does it make me more productive?  Does it generate "good" code?  Can it express complex systems easily?

You got it, exactly.  That's why more multiparadigm languages are coming on the scene and why Microsoft has FP gurus on its research staff.


>> The Oz book was written for people like you!
>> Forget monads, read that, and pay attention to the Haskell case studies!
>
>The problem is getting the right data into the functions, I guess. Threading state through a lot of functions is tedious.

The idea of the Haskell case studies was not to teach Haskell or monads, but to showcase a better alternative.  Oz is multiparadigm, so you can break out of functional style when desired - without monads.

FP masters can employ monads to great effect.  They certainly assist language theorists and implementors.  End users are another story.  Monads just don't belong in a first FP language, if indeed they belong anywhere.

Mark

"Mark Evans" <Mark_member@pathlink.com> escreveu na mensagem news:biojgp$a7s$1@digitaldaemon.com...
> Sean L. Palmer says...
> >>
> >> You probably felt that way when you learned C, which is a very
contorted
> >> language, being as polite as I can.
> >
> >I take your point, but what I felt when I learned C was both a sigh of relief that the wordy syntax of Pascal could be eliminated
>
> Learning anything brings a sigh of relief.  The situation is more or less identical.  Replace 'Pascal' with 'C' and 'C' with 'multiparadigm language
X' in
> what you wrote.
>
> 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
> numerics package with terrible syntax, but I couldn't live without it.
The
> power in its multiparadigm language is awesome and its efficiency is
unbeatable.
> (Something of interest to Eon might be its advanced variable-precision
> numerics.)

Sometimes syntax matters. Sometimes it clutters. Today there's the idea that syntax is the least important piece of a PL, but if the syntax doesn't help, you can't express some ideas. Take a look at FPLs, if the language support currying, writing combinators is natural and direct, while in languages without currying people tend to use few combinators and less higher-order functions. Lisp and Scheme, for example, tend to use macros for iteration. Or try to implement macros in a language that doesn't have a uniform syntax. People say much about template meta-programming in C++ but it's awful due to its syntax. In languages with parametric polymorphism working with generics is much simpler. But I agree that you need to get over syntax to understand new languages, but it's a big step sometimes (I suffered to learn Haskell ;).

> >I am giving Haskell another shot.  It took like 2 hours to add a "key up" clause to that little game "Paratrooper", just constantly fighting the syntax, mostly, because I have no idea what I'm doing and it's all unfamiliar.  The syntax is certainly much different.
>
> Interactive games are the wrong application for a gentle FP introduction.
You
> want something involving data manipulation.
>
> 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.

Hmmm, I don't know about this. In D is pretty easy to write "min(sqrt(x * x)
+ sqrt(y * y), x + y)" but in SML you need more parenthesis: "min (sqrt (x *
x) + sqrt (y * y)) (x + y)". The advantage of not having commas and
parenthesis around function arguments doesn't work for more complex
expressions.

[snip]

> >> Personally I dislike monads.
> >
> >It seems that they shouldn't be necessary somehow.  Maybe there's a
better
> >way to express that concept.
>
> 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.

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. Suppose you have a function that can fail or return some value and you need to sequence the application of such function for a list of values, you'll have something like:


my_function :: (Monad m) => Something -> m Otherthing
my_function some = if foo some then return (bar some) else fail "ops"


meaning that the function is parametrized by a Monad "m" and return a "m
something". You can see this declaration as some m that implements the Monad
interface (so in terms of D, this "m" is a subtype of Monad) and such m has
a type-parameter "a" (meaning that this "m" is a parametrized class). The
code says if "foo some" is true we'll construct a value of "m Otherthing"
using the "return" constructor (you can see "return" as a virtual
constructor defined in the "Monad" class) else it'll fail with the
intelligent "ops" error message.
We then can use the "sequence" standard function to execute all the
computations in a list:


somethings :: [Something] -- a list of Something
computations = map my_function somethings
result = sequence computations


The interesting thing is that "sequence" fails if any of the computations fail, but the monad type is still unspecified, we can use a monad report failure normally or a Monad that binds an error value and let the remaining computations continue. The client can specify if he wants early termination or not, because you parametrized the computation sequencing strategy. Note that the code may be wrong, I'm not sure that I should use "sequence", but the general idea is that. Nowhere I talked about IO, this code is generic to any kind of monad.

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

YMMV, but I was a FP beginner (and still feel like) and used Haskell. It was hard but I preferred it to Scheme or ML variants.

[snip]

    Best regards,
    Daniel Yokomiso.

"Sodium and Chloride are both dangerous to humans. Therefore any combination of sodium and chloride will be dangerous to humans."


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

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!

Look, I am all for great syntax - but when someone claims FP pain because of unfamiliar syntax -- while accepting C as if Moses brought it down the mountain -- then it's correction time.  Unfamiliar syntax is a general problem in learning any new language.  FP should not be blamed for that.

>Hmmm, I don't know about this [various syntax comparisons here]

Of course.  These cases can be constructed.  So can counter-cases.  All I mean is that C syntax is not sacrosanct.  Anyone endeavoring to learn new languages should focus on what's truly important.  Syntax is not, in general.  Bad syntax can get in the way, but you can also get used to it, as people have with C/C++.

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

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.

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.

>The interesting thing is that "sequence" fails

One of the few things that makes me like monads is their ability to imitate the success/failure paradigm of Icon. :-)  Of course, Icon never asked me to use monads qua monads.  I might not like the paradigm if it required monads.

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

Mark