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

http://www.digitalmars.com/drn-bin/wwwnews?D/16134

..it's not about ultimate capability, but expressing thought concisely with
minimum error.  Yes, a Turing machine can do anything, as can C and FORTRAN.
But I'd much rather write 2*8 than 2+2+2+2+2+2+2+2.  That's a good analogy.

I'm curious how Eon will compare with Needle, Oz, Alice ML, and other laboratory
languages.  Needle and Alice are statically type-inferred like Eon, but not as
contractual (?).  Anyway thanks to Daniel for his thoughtful contributions to D
and good luck with Eon.

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


[snip]


 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.


The

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


important...

 http://www.digitalmars.com/drn-bin/wwwnews?D/16134

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


with

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


FORTRAN.

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


analogy.

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


laboratory

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


not as

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


to D

 and good luck with Eon.

 Mark
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




modernized.

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


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.

    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


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




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






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


than a

 syntax difference!



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

[snip]


Nothing is *necessary*, but they can help your life. Monads aren't used




just

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




computations

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




your

code and even evaluation strategy.


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


AVOID

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


what

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


totally

 lost.


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



 Yes monads are very capable, and useful, in the right hands.  So are good
 old-fashioned variables!  We are talking about beginners here.  We are


also

 talking about basic stateful programming, not generalized monadic


constructions.

 Explicit state makes equivalent monad constructions look like castles in


the air

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


should!

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


Needle):  use

 the paradigm that fits.  Don't lock yourself in.  When you need state, use
 state.


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


 Loss of a familiar concept like 'variable' is pretty severe boot camp for


FP

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


There

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


than

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


language.

 Monads are just handy for CS theoreticians, functional language


implementors,

 and FP blackbelts, all of whom wish to avoid side effects.


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

[snip]


Haskell...was hard [to learn] but I preferred it to Scheme or ML




variants.

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


own

 sake.  That is not the case with everyone.


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


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



  Also, the Oz book covers Haskell's
 'flaws' in detail - er, from a certain point of view called


'multiparadigm.'

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


but need

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


you're

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


indicated.

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


note

 there about Eon and the details of its type system.


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


 Mark


    Best regards,
    Daniel Yokomiso.

"Chaos! Panic! Disaster! (My work here is done)."
"Mark Evans" <Mark_member pathlink.com> escreveu na mensagem
news:bip2sd$12ag$1 digitaldaemon.com...

 Daniel Yokomiso says...

Sometimes syntax matters....if the language support[s]
currying...while in languages without currying...


 The difference between currying and non-currying is substantially more


than a

 syntax difference!



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

[snip]


Nothing is *necessary*, but they can help your life. Monads aren't used




just

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




computations

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




your

code and even evaluation strategy.


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


AVOID

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


what

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


totally

 lost.


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



 Yes monads are very capable, and useful, in the right hands.  So are good
 old-fashioned variables!  We are talking about beginners here.  We are


also

 talking about basic stateful programming, not generalized monadic


constructions.

 Explicit state makes equivalent monad constructions look like castles in


the air

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


should!

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


Needle):  use

 the paradigm that fits.  Don't lock yourself in.  When you need state, use
 state.


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


 Loss of a familiar concept like 'variable' is pretty severe boot camp for


FP

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


There

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


than

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


language.

 Monads are just handy for CS theoreticians, functional language


implementors,

 and FP blackbelts, all of whom wish to avoid side effects.


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

[snip]


Haskell...was hard [to learn] but I preferred it to Scheme or ML




variants.

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


own

 sake.  That is not the case with everyone.


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


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



  Also, the Oz book covers Haskell's
 'flaws' in detail - er, from a certain point of view called


'multiparadigm.'

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


but need

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


you're

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


indicated.

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


note

 there about Eon and the details of its type system.


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


 Mark


    Best regards,
    Daniel Yokomiso.

"Chaos! Panic! Disaster! (My work here is done)."
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


languages

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


Lisp-ish

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


 Interactive games are the wrong application for a gentle FP introduction.


You

 want something involving data manipulation.


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


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


the

 power of alternative languages.  Ask yourself why C syntax is any good and
 you'll realize it's just habit.  In SML function calls are "foo a" instead


of

 "foo(a)" so they are less busy than C.


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


 What you're trying to do will change once you realize that functional


style

 offers superior expressiveness.  You might reorganize data structures
 anticipating functional style.  If you're just going to do imperative
 programming, then do that, and forget functional style.



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


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


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


Monadic

 languages are poor choices for newcomers to functional programming.  They


demand

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


in a

 Catch-22.


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

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

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


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


not

 for FP beginners.


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


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




templates

were.


 Monads are part of the problem.


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

Sean
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


 languages

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


 Lisp-ish
 
 No, I dislike C syntax also.  But not many languages beat it for expressive
 power on builtins.  


???

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

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

-- 
Helmut Leitner    leitner hls.via.at
Graz, Austria   www.hls-software.com
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




expressive

 power on builtins.


 ???

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


That's why we study both type theory and popular languages. If we have a
type "RegEx a" where the "a" type parameter is the resulting type that can
be deconstructed by the regular expression, we can define (assuming any

comments):


into natural numbers]

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]

return a RegEx of Natural, the digits just are placed together]

replace-all text regex transform : String -> (RegEx a) -> (a -> a) -> String

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

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


it,

 but this is such a common pattern that it deserves special attention.


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


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

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


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


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

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


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


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


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


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

or with better layout (the parenthesis are unnecessary).

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


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


print_file world

        (file, line_string) = read file
         _ = close file
    = print line_string world


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



 Starting with Haskell is a mistake.  It's still a very good language,




but

 not

 for FP beginners.


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


;)

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




 templates

were.


 Monads are part of the problem.




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


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

 Sean


    Best regards,
    Daniel Yokomiso.

"Sanity is the playground for the unimaginative."


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




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

http://www.digitalmars.com/drn-bin/wwwnews?D/16134

..it's not about ultimate capability, but expressing thought concisely with
minimum error.  Yes, a Turing machine can do anything, as can C and FORTRAN.
But I'd much rather write 2*8 than 2+2+2+2+2+2+2+2.  That's a good analogy.

I'm curious how Eon will compare with Needle, Oz, Alice ML, and other laboratory
languages.  Needle and Alice are statically type-inferred like Eon, but not as
contractual (?).  Anyway thanks to Daniel for his thoughtful contributions to D
and good luck with Eon.

Mark


Argh! I really need to update the documentation. That's what happens when you
leave draft publications publicly, people dig your rants ;)

Seriously, I really need to update everything, the concept is unchanged (well
except for dropping side-effects in favour of monads), but the semantics
improved and the syntax changed heavily.

Regarding the comparison against Needle, Oz and Alice ML here goes a draft:
Needle - it'll be probably very similar to Needle, modulo predicate-based typing
(AFAIK Needle has none of these), purity and the macro syntax (Eon macro calls
are explicit, [ ] denote macro call, with the first token inside being the macro
name: [if 1 < n then 1 else 2]). Of course the basic libraries will be
different.
Oz - very big differences IMO. Oz is dynamically-strong typed, using unification
for bindings and constraints, and allowing imperative code. Eon is
statically-strong typed using predicate-based typing for constraints and keeping
all imperative code inside monads. Eon will also support concurrency, but more
in the model of Erlang using some kind of Process monad instead.
Alice ML - unfortunately this language is still in my reading queue, so I can't
tell much about it, except for the ML part of it (IIRC it's a variant of ML).
Eon probably is able to express everything a ML-like language can, probably with
similar syntax.
Thanks for your wishes.

Best regards,
Daniel Yokomiso.

"Why should I care about posterity? What's posterity ever done for me?"
 - Groucho Marx
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.




The

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




important...

http://www.digitalmars.com/drn-bin/wwwnews?D/16134

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




with

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




FORTRAN.

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




analogy.

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




laboratory

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




not as

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




contributions to D

and good luck with Eon.

Mark


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


you

 leave draft publications publicly, people dig your rants ;)

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


(well

 except for dropping side-effects in favour of monads), but the semantics
 improved and the syntax changed heavily.

 Regarding the comparison against Needle, Oz and Alice ML here goes a


draft:

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


typing

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


calls

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


macro

 name: [if 1 < n then 1 else 2]). Of course the basic libraries will be
 different.
 Oz - very big differences IMO. Oz is dynamically-strong typed, using


unification

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


keeping

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


more

 in the model of Erlang using some kind of Process monad instead.
 Alice ML - unfortunately this language is still in my reading queue, so I


can't

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


ML).

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


probably with

 similar syntax.
 Thanks for your wishes.

 Best regards,
 Daniel Yokomiso.

 "Why should I care about posterity? What's posterity ever done for me?"
  - Groucho Marx
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