www.digitalmars.com         C & C++   DMDScript  

D - Eon Language

reply Mark Evans <Mark_member pathlink.com> writes:
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...

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
Aug 26 2003
next sibling parent reply Derek Parnell <Derek.Parnell No.Spam> writes:
On Wed, 27 Aug 2003 02:01:44 +0000 (UTC) (08/27/03 12:01:44)
, Mark Evans <Mark_member pathlink.com> wrote:

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

 Anyway thanks to Daniel for his thoughtful contributions to D
 and good luck with Eon.

I had to chuckle at this news. Many, many, many years ago, when still new to programming, I wrote down a specification for what I thought would be a 'real neat' language and I called it Event-Object Notation - EON! There are just so many letters available for acronyms ;-) But I wish you good luck also Daniel. Personally, I see little folly in a programming Tower of Babel - (but let's not stretch that metaphor too much). Maybe I should dig it up and publish it on the web (if it still seems neat, that is). -- Derek
Aug 26 2003
parent "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
"Derek Parnell" <Derek.Parnell No.Spam> escreveu na mensagem
news:oprujpaer1yj5swd news.digitalmars.com...

[snip]

 I had to chuckle at this news. Many, many, many years ago, when still new
 to programming, I wrote down a specification for what I thought would be a
 'real neat' language and I called it Event-Object Notation - EON!

 There are just so many letters available for acronyms ;-)

As today there are more programming languages than human languages, and we (programmers) like acronyms... Probably there are a few others.
 But I wish you good luck also Daniel. Personally, I see little folly in a
 programming Tower of Babel - (but let's not stretch that metaphor too
 much).

Thanks for the wishes. If the current programming languages where good enough, it wouldn't be a problem to adopt the best for the job. But most languages are deficient in a way or another. The few exclusions are Scheme, Self and Forth IMO, because they embody everything possible in their paradigms leaving no pieces. If we had a perfect language for each paradigm combination, no new languages are necessary. I see a lot of room to improve on statically-typed, side-effect free, strict languages.
 Maybe I should dig it up and publish it on the web (if it still seems
 neat, that is).

Publish it anyway. It's always worth to read about another programming language. Almost every language has a neat concept, even if it's hidden behind a mountain of keywords.
 --
 Derek

Best regards, Daniel Yokomiso. "We hope Buddha's finger could inspire friendly love and peace across the Taiwan Strait to China." - Chinese monk I Kong, about the finger-bones of Buddha --- 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
Aug 27 2003
prev sibling next sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
I like the lazy integer division producing rationals.  ;)

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

"Mark Evans" <Mark_member pathlink.com> wrote in message
news:bih3e8$rn6$1 digitaldaemon.com...
 http://www.minddrome.com/produtos/eon/

 I assume this is Daniel Yokomiso's language.  I like the write-up so far.

 bit about the Turing tar pit is spot-on.  That's why languages are

 D/16134

 ..it's not about ultimate capability, but expressing thought concisely

 minimum error.  Yes, a Turing machine can do anything, as can C and

 But I'd much rather write 2*8 than 2+2+2+2+2+2+2+2.  That's a good

 I'm curious how Eon will compare with Needle, Oz, Alice ML, and other

 languages.  Needle and Alice are statically type-inferred like Eon, but

 contractual (?).  Anyway thanks to Daniel for his thoughtful contributions

 and good luck with Eon.

 Mark

Aug 27 2003
next sibling parent reply Mark Evans <Mark_member pathlink.com> writes:
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

In what ways? Mark
Aug 27 2003
parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
It just doesn't seem to be gaining much ground on other languages.  Not
compatible enough with C, I guess...

Sean

"Mark Evans" <Mark_member pathlink.com> wrote in message
news:bij75j$164k$1 digitaldaemon.com...
I might like this language... seems alot like Haskell, but a bit


I like Haskell but it seems perhaps to be falling behind the pack..

Sean

In what ways? Mark

Aug 28 2003
prev sibling parent reply "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
"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 ;)
 I might like this language... seems alot like Haskell, but a bit

 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. Best regards, Daniel Yokomiso. "Sometimes I lie awake at night, and I ask, 'Where have I gone wrong?' Then a voice says to me, 'This is going to take more than one night." - Charles Schulz --- 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
Aug 27 2003
next sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
"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

 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

 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
Aug 28 2003
next sibling parent reply Mark Evans <Mark_member pathlink.com> writes:
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
Aug 28 2003
parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
"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


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:

 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'

 pure functional languages and their theoreticians.  Eon aims for

 purity so it requires monads.  Other functional languages like Needle,

 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.

 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

 ever survived without it.  Until then, you will imagine the skill to be

 Some folks never learn how to swim, others never learn how to drive, but

 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

 Myself, I don't see how Dedekind cuts could matter to any programming

 even at the implementation level.  Dedekind cuts only matter in

 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!

 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
Aug 29 2003
parent reply Mark Evans <Mark_member pathlink.com> writes:
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
Aug 29 2003
next sibling parent reply "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
"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



 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

 what you wrote.

 You're too fixated on syntax.  C has you brainwashed.  Many powerful

 have awful syntax but they are still worthwhile.  Mathematica is a

 numerics package with terrible syntax, but I couldn't live without it.

 power in its multiparadigm language is awesome and its efficiency is

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

 want something involving data manipulation.

 Push syntax to the back of your brain.  Otherwise you'll just lose out on

 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

 "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


way to express that concept.

They are not necessary. That's why I advised reading the Oz book.

 languages are poor choices for newcomers to functional programming.  They

 a solid grasp of functional style.  So monadic languages put FP beginners

 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

 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
Aug 29 2003
parent reply Mark Evans <Mark_member pathlink.com> writes:
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
Aug 29 2003
parent "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
"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

 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


for IO they're are means to express computations, and how such


can be composed. If you grok monads you'll be able to better modularize


code and even evaluation strategy.

Monads are ULTRA BAD NEWS for FP beginners. My advice to beginners:

 MONADS AT ALL COSTS.  Use a langauge like O'Caml which is not so far from

 you already know.  Then you can grow into FP by steps, without feeling

 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

 talking about basic stateful programming, not generalized monadic

 Explicit state makes equivalent monad constructions look like castles in

 and make FP look weird.  Monads will turn people off.  As well they

 This is the whole point of multi-paradigm programming (Oz, O'Caml,

 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

 newbies.  You've already stated a concern for FP marketing to the masses.

 is more to it than marketing, but in essence monads are not more general

 the overall Oz kernel model, or for that matter any non-functional

 Monads are just handy for CS theoreticians, functional language

 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


 You are also a language guru who enjoys learning new languages for their

 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

 Thanks for the joust Daniel!  I have more remarks about Needle and Eon,

 some info about your type system, references to any academic work that

 using, and rationales for the necessity of doing things in the ways

 But at this point we probably belong on LtU. :-)  Why don't you post a

 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

 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


for IO they're are means to express computations, and how such


can be composed. If you grok monads you'll be able to better modularize


code and even evaluation strategy.

Monads are ULTRA BAD NEWS for FP beginners. My advice to beginners:

 MONADS AT ALL COSTS.  Use a langauge like O'Caml which is not so far from

 you already know.  Then you can grow into FP by steps, without feeling

 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

 talking about basic stateful programming, not generalized monadic

 Explicit state makes equivalent monad constructions look like castles in

 and make FP look weird.  Monads will turn people off.  As well they

 This is the whole point of multi-paradigm programming (Oz, O'Caml,

 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

 newbies.  You've already stated a concern for FP marketing to the masses.

 is more to it than marketing, but in essence monads are not more general

 the overall Oz kernel model, or for that matter any non-functional

 Monads are just handy for CS theoreticians, functional language

 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


 You are also a language guru who enjoys learning new languages for their

 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

 Thanks for the joust Daniel!  I have more remarks about Needle and Eon,

 some info about your type system, references to any academic work that

 using, and rationales for the necessity of doing things in the ways

 But at this point we probably belong on LtU. :-)  Why don't you post a

 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)."
Aug 30 2003
prev sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
"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

 have awful syntax but they are still worthwhile.  Mathematica is a

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.

 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

 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

 "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

 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.

 languages are poor choices for newcomers to functional programming.  They

 a solid grasp of functional style.  So monadic languages put FP beginners

 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

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


were.

Monads are part of the problem.

Actually it's the declaration and call syntax that are getting me at the moment. Sean
Aug 30 2003
next sibling parent reply Helmut Leitner <leitner hls.via.at> writes:
"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

 have awful syntax but they are still worthwhile.  Mathematica is a

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
Aug 30 2003
parent "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
"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


 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
Aug 30 2003
prev sibling next sibling parent "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
"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

 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,


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


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
Aug 30 2003
prev sibling parent Mark Evans <Mark_member pathlink.com> writes:
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
Aug 30 2003
prev sibling parent "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
"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


 using church numerals and the real number implementation based on


 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

 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

 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
Aug 28 2003
prev sibling parent reply Alen Siljak <alen djesi.ba_nospam> writes:
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
Aug 28 2003
parent Mark Evans <Mark_member pathlink.com> writes:
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
Aug 28 2003
prev sibling parent reply Daniel Yokomiso <Daniel_member pathlink.com> writes:
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...

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
Aug 27 2003
next sibling parent "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
For anyone interested, I updated the examples section
<http://www.minddrome.com/produtos/eon/examples.html>. Just part of it was
updated, but the new syntax for definitions, type expressions and macros is
available.


---
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
Aug 27 2003
prev sibling next sibling parent reply Mark Evans <Mark_member pathlink.com> writes:
 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.
 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.
 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?
 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. 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.
 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.
 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 -Mark
Aug 27 2003
parent "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
"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
Aug 28 2003
prev sibling parent reply "Charles Sanders" <sanders-consulting comcast.net> writes:
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.


bit about the Turing tar pit is spot-on.  That's why languages are


D/16134

..it's not about ultimate capability, but expressing thought concisely


minimum error.  Yes, a Turing machine can do anything, as can C and


But I'd much rather write 2*8 than 2+2+2+2+2+2+2+2.  That's a good


I'm curious how Eon will compare with Needle, Oz, Alice ML, and other


languages.  Needle and Alice are statically type-inferred like Eon, but


contractual (?).  Anyway thanks to Daniel for his thoughtful


and good luck with Eon.

Mark

Argh! I really need to update the documentation. That's what happens when

 leave draft publications publicly, people dig your rants ;)

 Seriously, I really need to update everything, the concept is unchanged

 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

 Needle - it'll be probably very similar to Needle, modulo predicate-based

 (AFAIK Needle has none of these), purity and the macro syntax (Eon macro

 are explicit, [ ] denote macro call, with the first token inside being the

 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

 for bindings and constraints, and allowing imperative code. Eon is
 statically-strong typed using predicate-based typing for constraints and

 all imperative code inside monads. Eon will also support concurrency, but

 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

 tell much about it, except for the ML part of it (IIRC it's a variant of

 Eon probably is able to express everything a ML-like language can,

 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

Sep 07 2003
parent "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
"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
Sep 07 2003