Programming AI for beginner
nanda
for academic purpose?
What about C or C++, are there AI implementation use these langauges?
Rom
"nanda" <na...@hotmail.com>
How to become a politician and what education is usually needed? Is
political science only for national politics?
What about marketing cources? Do politicians use those methods?
Regards
Rom
Christian Drumm
Intelligence Programming in Java.
it can be downloaded form http://www.markwatson.com/opencontent/.
I don't know if it is any good, i just saw the link some days ago.
Christian
"nanda" <na...@hotmail.com> wrote in message
news:atmj41$i05$1...@news.krline.net...
Arthur T. Murray
>
> How to start programming AI and what language usually use?
You may use theoretically _any_ language for GOFAI, even
http://mind.sourceforge.net/cobol.html -- old-fashioned COBOL.
What you need for AI is a good, introductory AI textbook, such as
http://www.cs.berkeley.edu/~russell/aima.html -- "Modern Approach."
If you really want to "start programming" an AI Mind, you may need
http://www.iuniverse.com/bookstore/book_detail.asp?isbn=0595259227 or
http://search.barnesandnoble.com/bookSearch/isbnInquiry.asp?ISBN=0595259227 .
> Is Lisp only use for academic purpose?
http://mind.sourceforge.net/lisp.html has _many_ purposes, not just AI.
> What about C or C++, are there AI implementation use these langauges?
http://mind.sourceforge.net/c.html is for AI Minds in C.
http://mind.sourceforge.net/cpp.html is about C++ AI Minds.
Hopes this helps, and leads to AI4U books left around via BookCrossing.
Arthur T. Murray
--
ACM SIGPLAN Notices 33(12):25-31 "Mind.Forth: Thoughts on AI & Forth"
http://www.cpan.org/authors/id/M/ME/MENTIFEX/mind.txt -- AI namespaces;
http://www.nanomagazine.com/01_10_24 "Interview with Arthur T. Murray"
http://www.bookcrossing.com/mybookshelf/Mentifex/ "Spreading AI4U"
Frecklefoot
> for academic purpose?
> What about C or C++, are there AI implementation use these langauges?
Yes, C++ is used extensively for AI. Try this web site:
http://www.gameai.com/
It has links to about everything you could ever hope for related to AI.
rasp
Language is quite independent from AI. Basically, you can use
anyone you like. If you are willing to learn about AI, there are
more source examples in C or C++ on the web that anything else. On
my part, I do my stuff in JAVA and what ever the sceptics say, it runs
fast enough :)
Learn about AI then chose the language you are the best at to
implement what you want to do.
Have fun!
Mark
michael eng
> How to become a politician and what education is usually needed?
I don't think you need look too far to figure that one out for
yourself.
Michael
Michael Adam
"nanda" <na...@hotmail.com> schrieb im Newsbeitrag
news:atmj41$i05$1...@news.krline.net...
you can easylie modify the source code at run time....
this is very good, to get the prog 'learning' from situations by
adding / removing some lines from the source code.
Randall R Schulz
And don't forget: Advice received here is worth every penny it costs
you. Especially suggestions that "it doesn't matter what language you
use." Poppycock!
From the preface to the first edition of "The C++ Programming Language"
"Language shapes the way we think,
and determines what we can think about."
-- B. L. Whorf
Also known as "Whorf's hypothesis."
Language matters. It matters a lot. Pick a good one, understand it well
and use it to it fullest, and you can go far. Choose poorly or use the
one you do choose badly, and you'll founder before long.
That said, I believe everyone should learn Lisp. Nowadays, one of the
functional / applicative languages is advisable, too. Any of Lisp, Java
or C++ can profitably be used to write large sophisticated programs, a
description that categorizes AI programming, generally speaking. But its
really hard to beat Lisp for sheer programming sophistication (something
I say in a value-neutral manner, by the way). Don't forget Lisp is
object-oriented these days (by virtue of CLOS, the Common Lisp Object
System).
I see "comp.games.development.programming.algorithms" in the
distribution list for this message. I don't know much about the world of
computerized game programming. Presumably their criteria and constraints
are different.
Randall Schulz
Mountain View, CA USA
nanda wrote:
> How to start programming AI and what language usually use?
> Is Lisp only used for academic purpose?
Alistair Maclean
In article <3dff...@news.victoria.tc.ca>, Arthur T. Murray
<uj...@victoria.tc.ca> writes
>"nanda" <na...@hotmail.com> writes on Tue, 17 Dec 2002:
>>
>> How to start programming AI and what language usually use?
>
>You may use theoretically _any_ language for GOFAI, even
>http://mind.sourceforge.net/cobol.html -- old-fashioned COBOL.
>
>What you need for AI is a good, introductory AI textbook, such as
>http://www.cs.berkeley.edu/~russell/aima.html -- "Modern Approach."
>
>If you really want to "start programming" an AI Mind, you may need
>http://www.iuniverse.com/bookstore/book_detail.asp?isbn=0595259227 or
>http://search.barnesandnoble.com/bookSearch/isbnInquiry.asp?ISBN=0595259227 .
>
>> Is Lisp only use for academic purpose?
>
>http://mind.sourceforge.net/lisp.html has _many_ purposes, not just AI.
>
>> What about C or C++, are there AI implementation use these langauges?
>
>http://mind.sourceforge.net/c.html is for AI Minds in C.
>http://mind.sourceforge.net/cpp.html is about C++ AI Minds.
>
>Hopes this helps, and leads to AI4U books left around via BookCrossing.
>
>Arthur T. Murray
--
Alistair Maclean
For his mother was Coincidence, and his father was Chaos.
- Stanislaw Lem
Peter Ashford
"Randall R Schulz" <rrsc...@cris.com> wrote in message
news:ato84l$s...@dispatch.concentric.net...
> Nand,
>
> And don't forget: Advice received here is worth every penny it costs
> you. Especially suggestions that "it doesn't matter what language you
> use." Poppycock!
It doesn't matter _in so far_ as you can program AI in any language.
> From the preface to the first edition of "The C++ Programming Language"
>
> "Language shapes the way we think,
> and determines what we can think about."
> -- B. L. Whorf
>
> Also known as "Whorf's hypothesis."
>
> Language matters. It matters a lot. Pick a good one, understand it well
> and use it to it fullest, and you can go far. Choose poorly or use the
> one you do choose badly, and you'll founder before long.
I don't think so - most programmers learn several languages, and I think
it's more important to learn different styles of programming (which knowing
other languages aids in) rather than being hung up on choosing
The-One-True-Language as your first choice. To apply that to Whorf's
hypothesis - I think the 'language' that programmers speak is a
concatenation (pun intended - given the LISP context) of all the programming
languages they know.
One can program OO in C, one can program functionally / using lists in Java.
The 'language' that computer problems are solved in is in the programmer's
mind (what tools / problem-solving-patterns he knows of) rather than in his
compiler. When I write code in C, I do not forget that I can construct
objects and classes, nor do I forget that I could use lists, recursion and
functions.
> That said, I believe everyone should learn Lisp. Nowadays, one of the
> functional / applicative languages is advisable, too. Any of Lisp, Java
> or C++ can profitably be used to write large sophisticated programs, a
> description that categorizes AI programming, generally speaking. But its
> really hard to beat Lisp for sheer programming sophistication (something
> I say in a value-neutral manner, by the way). Don't forget Lisp is
> object-oriented these days (by virtue of CLOS, the Common Lisp Object
> System).
I agree that everyone should learn LISP. I wouldn't agree that everyone
should choose it as their first language, especially if they're interested
in game programming.
Peter.
Erik Max Francis
> That said, I believe everyone should learn Lisp. Nowadays, one of the
> functional / applicative languages is advisable, too.
Right. One of those functional languages. As opposed to Lisp. Want to
try that one again?
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ The gates of Heaven are open wide / Off I ride ...
\__/ Ch'u Tz'u
Bosskey.net: Counter-Strike / http://www.bosskey.net/cs/
A personal guide to Counter-Strike.
Will Dwinnell
As for any development project, the "best" language depends on many
factors, such as cost, current familiarity with language or close
relatives, etc. A.I. is composed of many sub-disiplines. I work in
machine learning / neural networks / data mining, so I do a lot of
numeric and statistical programming and have found MATLAB to be a very
capable tool. Other fields will probably be better addressed by other
languages. Can you be more specific about your interests?
-Will Dwinnell, MBA
http://will.dwinnell.com
Rainer Deyke
> Randall R Schulz wrote:
>
>> That said, I believe everyone should learn Lisp. Nowadays, one of
the
>> functional / applicative languages is advisable, too.
>
> Right. One of those functional languages. As opposed to Lisp.
Want
> to try that one again?
Meaning (I assume) a "pure" functional language where the value
assigned to a name never is immutable (i.e. no "variables"), such as
Haskell. LISP is really no more functional than C++, its functional
aspects are just more emphasised by its users.
--
Rainer Deyke | ro...@rainerdeyke.com | http://rainerdeyke.com
Peter Ashford
"Rainer Deyke" <ro...@rainerdeyke.com> wrote in message
news:f90M9.214270$pN3.17030@sccrnsc03...
> Erik Max Francis wrote:
> > Randall R Schulz wrote:
> >
> >> That said, I believe everyone should learn Lisp. Nowadays, one of
> the
> >> functional / applicative languages is advisable, too.
> >
> > Right. One of those functional languages. As opposed to Lisp.
> Want
> > to try that one again?
>
> Meaning (I assume) a "pure" functional language where the value
> assigned to a name never is immutable (i.e. no "variables"), such as
> Haskell. LISP is really no more functional than C++, its functional
> aspects are just more emphasised by its users.
>
Shouldn't that be "where the value assigned to a name is immutable" or "not
mutable"?
Cheers,
Peter.
Frederick Crabbe
While I have no problem with the site you mentioned, I cannot agree
that it "has links to about everything you could ever hope for related
to AI." I might suggest the comp.ai FAQ at
http://www.faqs.org/faqs/ai-faq/general
Also, try the American Association for Artificial Intelligence site at
www.aaai.org
As for the original question, from the comp.ai FAQ:
Subject: [1-9] What are good programming languages for AI?
This topic can be somewhat sensitive, so I'll probably tread on a few
toes, please forgive me. There is no authoritative answer for this
question, as it really depends on what languages you like programming
in. AI programs have been written in just about every language ever
created. The most common seem to be Lisp, Prolog, C/C++, recently
Java, and even more recently, Python.
LISP- For many years, AI was done as research in universities and
laboratories, thus fast prototyping was favored over fast execution.
This is one reason why AI has favored high-level langauges such as
Lisp. This tradition means that current AI Lisp programmers can draw
on many resources from the community. Features of the language that
are good for AI programming include: garbage collection, dynamic
typing, functions as data, uniform syntax, interactive environment,
and extensibility. Read Paul Graham's essay, "Beating the Averages"
for a discussion of some serious advantages:
http://www.paulgraham.com/avg.html
PROLOG- This language wins 'cool idea' competition. It wasn't until
the 70s that people began to realize that a set of logical statements
plus a general theorem prover could make up a program. Prolog
combines the high-level and traditional advantages of Lisp with a
built-in unifier, which is particularly useful in AI. Prolog seems to
be good for problems in which logic is intimately involved, or whose
solutions have a succinct logical characterization. Its major
drawback (IMHO) is that it's hard to learn.
C/C++- The speed demon of the bunch, C/C++ is mostly used when the
program is simple, and excecution speed is the most important.
Statistical AI techniques such as neural networks are common examples
of this. Backpropagation is only a couple of pages of C/C++ code, and
needs every ounce of speed that the programmer can muster.
Java- The newcomer, Java uses several ideas from Lisp, most notably
garbage collection. Its portability makes it desirable for just about
any application, and it has a decent set of built in types. Java is
still not as high-level as Lisp or Prolog, and not as fast as C,
making it best when portability is paramount.
Python- This language does not have widespread acceptance yet, but
several people have suggested to me that it might end up passing Java
soon. Apparently the new edition of the Russell-Norovig textbook will
include Python source as well as Lisp. According to Peter Norvig,
"Python can be seen as either a practical (better libraries) version
of Scheme, or as a cleaned-up (no $@&%) version of Perl." For more
information, especially on how Python compares to Lisp, go to
http://norvig.com/python-lisp.html
Also see section [6-1] for implementations of new languages that might
be pertainant to AI practitioners and researchers.
(some of the above material is due to the comp.lang.prolog FAQ, and
Norvig's "Paradigms of Artificial Intelligence Programming: Case
Studies in Common Lisp")
Randall R Schulz
Rainer,
Yes, that's what I meant. (With the exception of either the "never" or
the "_im_mutable" bit--just a typo I assume.)
Lisp ceased being a functional language when it got "set" and "setq"
(and later "setf") and the destructive list operations. It would seem
that much of the Lisp community never looked back. I don't blame them
for doing so, but I don't consider Lisp as it stands to be a functional
or applicative language.
There is, however, Applicative Common Lisp, which restricts itself to
the side-effect free subset of Common Lisp. That's a genuine functional
language.
But actually I was thinking of ML and its relatives when I suggested a
functional language in addition to Lisp.
If language didn't matter and all of them were equally good at all
different kinds of programming, then why do we have so many languages?
The egos of their inventors? I doubt it (though it's probably
responsible for some inflation in the language landscape). We have so
many languages in active use because we need them. Because different
languages do different things well.
Rainer Deyke
> "Rainer Deyke" <ro...@rainerdeyke.com> wrote in message
> news:f90M9.214270$pN3.17030@sccrnsc03...
>> assigned to a name never is immutable (i.e. no "variables"), such
as
>> Haskell. LISP is really no more functional than C++, its
functional
>> aspects are just more emphasised by its users.
>>
>
> Shouldn't that be "where the value assigned to a name is immutable"
> or "not mutable"?
Er, yes. Sloppy editing on my part.
--
Rainer Deyke | rai...@eldwood.com | http://eldwood.com
Erik Max Francis
> Meaning (I assume) a "pure" functional language where the value
> assigned to a name never is immutable (i.e. no "variables"), such as
> Haskell. LISP is really no more functional than C++, its functional
> aspects are just more emphasised by its users.
Outside of academia, there really are no _pure_ functional languages.
Pure functional languages allow for no side effects whatsoever,
including such fundamentally important operations like input and output.
When computer scientists talk about "functional languages," they talk
about languages that are inspired by functional paradigms, not purely
functional languages only. Lisp certainly qualifies as a functional
language.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ God does not play dice with the universe.
\__/ Albert Einstein
Alcyone Systems' Daily Planet / http://www.alcyone.com/planet.html
A new, virtual planet, every day.
Randall R Schulz
Not even close.
You can write functional code in Lisp by restricting yourself to an
applicative subset. It seems that as a pragmatic compromise you could
use variables as long you discipline yourself such that each one is
assigned a value only once. Conceptually, then, they either don't (yet)
hold a value or do hold their single, ultimate value--they bear a single
value that is either known or unknown.
But it's just a fiction to regard modern Lisps as genuinely functional
languages. If Lisp is functional, with its assignable local and global
variables and its destructive list operations, then so are C, C++, Java,
Smalltalk, Perl and any other language with a function abstraction
(i.e., a value-returning subroutine mechanism). Such a definition
renders the concept of a functional language without useful meaning.
Randall Schulz
Rainer Deyke
> Outside of academia, there really are no _pure_ functional
languages.
> Pure functional languages allow for no side effects whatsoever,
> including such fundamentally important operations like input and
> output.
Clean (the language) solves this through a world object. The world
object is immutable, but returning a different world object indicates
a change in the world. Something like this (but with totally
different syntax):
main(world):
second_world, text = get_input(world)
third_world = put_output(world, text)
return third_world
It's fake, of course - you can't use 'text' and then return the
original 'world' where the user hasn't entered the input yet - but
syntactically at least, it preserves the purity of the paradigm.
There's even a game library for Clean.
> When computer scientists talk about "functional languages," they
talk
> about languages that are inspired by functional paradigms, not
purely
> functional languages only. Lisp certainly qualifies as a functional
> language.
So does C++ (in particular the functions defined in <algorithm>), by
your definition.
Gerry Quinn
I never understand why people persist in this argument, be it for Lisp,
Perl, or some other scripting language. [Basic programmers, at least,
rarely make this blunder, as Basic has always had a mixture of
interpreters and compilers.] In the first place, an incremental compile
of a 10000 LOC program on MSVC takes about 1 second. In the second
place, changing code and seeing what happens is lousy programming
practice - it should be reserved for your genetic simulation module! (I
make a small exception for a program-generated GUI.) When your code is
bugged, stop, put on the kettle, have a ponder. Finding a bug means
either finding a typo, or finding where your thinking screwed up - and
neither is served by frantic text editing.
As for the choice of language, I suspect those choosing Lisp believe
that AI is constructible in a 'top-down' way, i.e. that intelligence
somehow evolves when enough facts and logical argument are put together.
My own belief is that this is a dead end which can at best
produce sophisticated versions of Eliza. If that's what you're aiming
for, fine - since this is a game-related newsgroup, it may well be.
Gerry Quinn
--
http://bindweed.com
Entertainment software for Windows
Puzzles, Strategy Games, Kaleidoscope Screensaver
Download evaluation versions free - no time limits
Marc Lanctot
Learning what AI is and how to code some neat program that uses AI is
completely language-independant. All you need to learn AI is a language
that supports data structures (sometimes you don't even need that!). Ok,
so sh is out (and maybe perl). But pretty much every other mainstream
language can be used to learn anything about AI.
Please don't spread your ignorance to newbies who don't know any better,
especially by calling others "Poppycock" and quoting C++ books (which
are obviously biased!)
I'll be sure the next time I implement alpha-beta to compile with the
-ai compile flag to make sure the AI modules are linked against.
Marc
ps. LISP is a functional language!
Randall R Schulz
Please don't mislead people by telling them that the discipline of
language selection for AI (or any other programming or software
engineering task) is not relevant.
AI isn't about any single specific algorithm or algorithm category.
Furthermore, a great many algorithms that were originally developed
within the AI programming tradition (almost certainly in Lisp) _can_ be
programmed in Perl or even in a Unix shell.
Alpha-beta search is not AI. A* is not AI. Heuristic programming is not
AI. Logic programming is not AI. Symbolic programming is not AI. Neural
programming is not AI. Genetic programming is not AI.
AI is combining any computational technique or technology that is
required to produce programs that better approximate human capabilities
than programs previously available. Yeah--the bar is continually raised
in AI.
AI entails managing complexity, and the choice of language matters a lot
when it comes to that. They also differ greatly in their abilities to
program dynamically, and Lisp's minimal distinction between program
specification (source code) and its data representation (nested list
structures) plus the universal availability of an evaluator for
arbitrary code (i.e., any list structure that fits the requirements for
being evaluated in as a Lisp form) is a big deal. And I know other
languages have these capabilities, too.
And despite what anyone says, Lisp is not a functional language unless
you restrict yourself to its applicative subset (Applicative Common
Lisp, e.g.: <http://www.cs.utexas.edu/users/moore/acl2/>). Otherwise,
Lisp is just like C/C++, Java, Perl, Visual Basic, Python, Ruby, etc. It
has variables both lobal and global and widespread side-effects. It just
ain't a functional language.
Randall Schulz
Marc Lanctot
very important thing in the real world. This is a not a trivial software
engineering problem in most cases, but it is NOT the problem this person
is concerned about.
I suppose the initial question is a little unclear, but it seemed that
the person wanted to learn about AI, not about the software engineering
surrounding AI. The person seems (to me) to think that the capability of
using AI comes only with certain languages (ie. a feature of the
language) which you and I know is false. The point I was trying to make
is that you can learn about AI regardless of the language you use.
All the things you list don't "make up AI", but they are concepts found
within the domain of AI. Computational rationality (particularly in
game-playing) and its various algorithm implementations (ie. via minimax
or alpha-beta, etc) are contained in the domain of AI. Neural networks
are also another technique used to "learn computartionally" (obviously
an artifically intelligent concept).
ANY program (not only AI programs) entails managing complexity, but this
person would like to learn AI, not worry about the complexity of the
programs he/she is implementing!
How does having a glorified interpreter "a big deal" when it comes to
learning AI? How does it help much?
Marc
Randall R Schulz
My point is that AI is not in an algorithm or a set of algorithms or in
any single computational technique nor in an any limited set of
computational techniques or paradigms.
There is no one magic concept that, once discovered, will explain human
(natural) intelligence simply and allow it to be replicated in a
computing machine (artificial intelligence).
Thus, AI is not about studying algorithms or computational paradigms.
There's no aspect of computer science that isn't relevant to AI. Thus if
someone's goal is to learn about AI, then the goal is to learn about how
to program at (and, in fact, beyond) the limits of current computing
science and technology.
_That_ is why languages like Perl are inappropriate. Not because you
cannot use them to imlement a great many essential algorithms that are
the bread and butter of conventional AI, but because they don't hold up
when pushed to the point of producing a program that challenges the
current state of "conventional" (non-AI) programming.
AI has always been and continues to be one of if not the most demanding
branches of programming and software engineering and that's why it so
often drove the creation of new software development technologies.
Using the phrase "glorified interpreter" is an attempt to denigrate a
programming language that has more longevity and contributes more
genuine power (in the sense of its ability to amplify of human
intellectual and programming effort) than any other language yet
invented (FORTRAN's 4 year lead on Lisp notwithstanding).
Such denigration is disrespectful to those who invented, elaborated and
perfected Lisp over the past 45 years and it is a disservice to people
who want to move into the field of AI research and programming.
At the moment, if someone has to choose a language that best puts them
on the road to AI work, Lisp is it. Personally, I think Lisp is the
language all programmers should learn first. I wish I had.
Marc Lanctot
Randall R Schulz wrote:
> Marc,
>
> any single computational technique nor in an any limited set of
> computational techniques or paradigms.
>
> There is no one magic concept that, once discovered, will explain human
> (natural) intelligence simply and allow it to be replicated in a
> computing machine (artificial intelligence).
I agree with you! But I think the person who originally posted would
like to learn the some of the algorithms classically associated with AI
(alpha-beta, minimax, A* etc), probably because he/she wants to
implement some of them in a simple game or something. Otherwise, why
would have they asked what language is best to use?
> Thus, AI is not about studying algorithms or computational paradigms.
> There's no aspect of computer science that isn't relevant to AI. Thus if
> someone's goal is to learn about AI, then the goal is to learn about how
> to program at (and, in fact, beyond) the limits of current computing
> science and technology.
Wow. I just think you drastically misinterpreted what this person wants.
I agree with you that AI is a higher concept, potentially subject of
many philosophical, psychological, cognetive, etc. debates. I don't
think AI is a collection of algorithms or computational paradigms
either, but as I will state again: I really think this person just wants
to implement/learn some of the algorithms that are clasically associated
with AI. In this respect, I think choice of language is negligibly
important.
> _That_ is why languages like Perl are inappropriate. Not because you
> cannot use them to imlement a great many essential algorithms that are
> the bread and butter of conventional AI, but because they don't hold up
> when pushed to the point of producing a program that challenges the
> current state of "conventional" (non-AI) programming.
You may be correct. I wouldn't know. If you are, I'd like to know how
choosing Lisp will help you here. I asked you that earlier, but I think
I may have offended you because you never answered my question.
> Using the phrase "glorified interpreter" is an attempt to denigrate a
> programming language that has more longevity and contributes more
> genuine power (in the sense of its ability to amplify of human
> intellectual and programming effort) than any other language yet
> invented (FORTRAN's 4 year lead on Lisp notwithstanding).
>
> Such denigration is disrespectful to those who invented, elaborated and
> perfected Lisp over the past 45 years and it is a disservice to people
> who want to move into the field of AI research and programming.
>
> At the moment, if someone has to choose a language that best puts them
> on the road to AI work, Lisp is it. Personally, I think Lisp is the
> language all programmers should learn first. I wish I had.
I didn't mean to offend you or any disrespect to the inventers of the
language. Of course what I label a "glorified interpreter" was an
amazing innovation 45 years ago. But NOW, we have interpreters! I'm
quite sure you can modify an interpreter to treat Lisp code the way you
described in previous messages. I'm not entirely sure if this is true,
but if it's not I'd like to learn from my mistakes.
I've met many people who think the same way you do; In fact my semantics
teacher (whom seems to be one of the leading in the world) is a Lisp
fanatic as well. Many claim that Lisp is is the language that all
programmers should learn first. I must admit that I like Scheme's
innovative representation of infinite streams. The ability to perform
computation on infinite objects is quite interesting.
But, many have failed to convince me of WHY Lisp is "the way to go" in
certain cases (like this one!). For instance, I will repeat myself: why
is "Lisp the language that best puts you on the way to AI work" ? I'm
very interested in the answer you'll give; I trust (judging from your
passionate answers) that there may be something fundamental that I don't
know about Lisp.
Marc
Randall R Schulz
Calling someone ignorant (as you did to me) is a good way to give
offense, don't you think?
If you really want to know about the virtues of Lisp and why it is
superior in many ways for many purposes, then I suggest you investigate
the language yourself. I get the feeling you're not going to listen to
me, nor do I have the time to go to the length necessary to give a
suitable answer to your question.
This site has some interesting articles on Lisp, it's virtues and
advantages and why it should be used in some application areas with
which it is not at all commonly associated (Web programming, e.g.):
There's a mountain of good publications about Lisp, including books and
lots of on-line stuff. Seek and ye shall find.
Randall Schulz
Marc Lanctot
Randall R Schulz wrote:
> Marc,
>
> Calling someone ignorant (as you did to me) is a good way to give
> offense, don't you think?
Well, offending someone else (like you did to someone who replied to
original message), especially someone who made a very valid point, is
not the easiest way to make friends. If you're going to be offensive,
you should learn to accept that people will reciprocate. You're
obviosuly not ignorant, but I do think you were misleading the person
asking the original question.
> If you really want to know about the virtues of Lisp and why it is
> superior in many ways for many purposes, then I suggest you investigate
> the language yourself. I get the feeling you're not going to listen to
> me, nor do I have the time to go to the length necessary to give a
> suitable answer to your question.
I didn't ask for a long list of all te virtues of Lisp. I was asking you
to point out to me the ones relevant to our discussion. Otherwise, I
would investigate myself. If you're going to answer someone so
passionately with your opinion (ie. Lisp is better to use for learning
AI) you should also be willing to give justification. Otherwise, other
than the obvious fact that there's no point in arguing, nobody will
benefit from the discussion now will they?
> This site has some interesting articles on Lisp, it's virtues and
> advantages and why it should be used in some application areas with
> which it is not at all commonly associated (Web programming, e.g.):
>
> <http://www.paulgraham.com/>
>
> There's a mountain of good publications about Lisp, including books and
> lots of on-line stuff. Seek and ye shall find.
Thanks; I will look into it. I was much more interested in why YOU think
Lisp would be a better language to use for learning AI.
Marc
Peter Cowderoy
> Outside of academia, there really are no _pure_ functional languages.
> Pure functional languages allow for no side effects whatsoever,
> including such fundamentally important operations like input and output.
>
While I'm a bit hazy on the details, I believe monadic I/O solves that
problem.
'In Ankh-Morpork even the shit have a street to itself...
Truly this is a land of opportunity.' - Detritus, Men at Arms
Pascal Bourguignon
There are two features that are not found in other languages than LISP
(and most LISP-inspired languages):
- symbols,
- program representation as data.
Actually the more I use LISP, the more I find it more like a LIst and
Symbol Processing rather than mere LISt Processing language. This
gives an abstraction that is very usefull in a lot of high-level
applications, including AI. After all, LISP has strings, arrays,
structs, objects, etc, too.
And the fact that programs and data are the same give the possibility
to introspect and auto-modify ("learn", "infer") that you don't have
in other languages, or that is much more difficult to implement in OO
languages that may allow it. (Note that LISP code can be as well
stored as lists (s-expr), or as byte vectors (arrays) when
byte-compiled (or could also be compiled to native code, but that's
less interesting here).
The only contender would be Prolog, but I find LISP more supple, you
don't always have to implement backtracking algorithm. With Prolog,
often you end up breaking the backtracking to revert to procedural
programming.
On the other hand, if I had to program a neural net engine, I would
probably do it in C. But then, interconnecting neural nets and
driving them would be better done in LISP, with an external API.
So while LISP is a good starting point, you should be prepared to
learn several other languages too to apply the best tool in each
situation.
--
__Pascal_Bourguignon__ http://www.informatimago.com/
----------------------------------------------------------------------
There is a fault in reality. do not adjust your minds. -- Salman Rushdie
Randall R Schulz
I'm not conceding either of the points I made:
- Language selections matters a lot.
sub-point:
Language selection is more critical and more
constrained for AI than for most other disciplines.
- Lisp is not a functional language
Nor am I going to change, any time soon, my opinion that Lisp is a
superior programming language for AI as well as for most any
general-purpose programming task nor is there a better language to learn
as a newcomer to computer and information science.
Lastly, the expletive "poppycock" is not an insult nor does using it
turn a simple rejoinder into an insult.
I do not believe this exchange serves any further purpose for anyone,
and for my part, it's over. Feel free to have the last word, if you must.
Randall Schulz
Rom
If the rule is:
if Traffic_light_is_green and
That_is_the_right_direction
then Drive_ahead
then if ...
Traffic_light_is_green = true
but we don't know whether "That_is_the_right_direction" is true or not ....
(= unknown)
then the rule should neither return True not False.
When using boolean variables everything that is not true becomes false, and
that is not what I want to happen with this rule. I want the result to be
nil or unsolvable, so that external rules can decide what to do here.
Regards
Rom
Erik Max Francis
> While I'm a bit hazy on the details, I believe monadic I/O solves that
> problem.
You can certainly wrap I/O in mechanisms which make them more amenable
to use in (strongly) function language, but still, I/O itself is a side
effect, something which a _purely_ functional language can never
perform, as a matter of definition.
A purely functional language is an abstract, no useful languages labeled
as "functional" are truly purely functional, because then they would be
unable to do even the most fundamental practical things that a program
must do, like I/O.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ It is dark in my favorite dream.
\__/ Aaliyah
Polly Wanna Cracka? / http://www.pollywannacracka.com/
The Internet resource for interracial relationships.
Brendan Guild
> You can certainly wrap I/O in mechanisms which make them more amenable
> to use in (strongly) function language, but still, I/O itself is a side
> effect, something which a _purely_ functional language can never
> perform, as a matter of definition.
I suppose it depends on how you look at it. In Haskell, monadic IO
involves creating an IO object, and then returning it. The program can
be run to completion without any IO taking place, and no function that
is evaluated has any side effects. What is then done with the IO
object once the program is finished, or during the evaluation of the
program is up to the interpreter.
What I always thought was the defining feature of functional
programming was creating new functions at runtime. I guess that is a
little vague, but you know what I mean.
The way I look at it, a Haskell program that does IO is a function
that creates a function that converts input to output. So the result
of the program is a function, and the function can be used or not,
depending on what is desired.
On the other hand, one could just look at creating IO objects as
causing IO as a side effect.
Peter Cowderoy
>
> Randall R Schulz wrote:
> > Marc,
> >
> > My point is that AI is not in an algorithm or a set of algorithms or in
> > any single computational technique nor in an any limited set of
> > computational techniques or paradigms.
> >
> > There is no one magic concept that, once discovered, will explain human
> > (natural) intelligence simply and allow it to be replicated in a
> > computing machine (artificial intelligence).
>
> I agree with you! But I think the person who originally posted would
> like to learn the some of the algorithms classically associated with AI
> (alpha-beta, minimax, A* etc), probably because he/she wants to
> implement some of them in a simple game or something. Otherwise, why
> would have they asked what language is best to use?
>
I think you're most probably right.
> > Thus, AI is not about studying algorithms or computational paradigms.
> > There's no aspect of computer science that isn't relevant to AI. Thus if
> > someone's goal is to learn about AI, then the goal is to learn about how
> > to program at (and, in fact, beyond) the limits of current computing
> > science and technology.
>
> Wow. I just think you drastically misinterpreted what this person wants.
> I agree with you that AI is a higher concept, potentially subject of
> many philosophical, psychological, cognetive, etc. debates. I don't
> think AI is a collection of algorithms or computational paradigms
> either, but as I will state again: I really think this person just wants
> to implement/learn some of the algorithms that are clasically associated
> with AI. In this respect, I think choice of language is negligibly
> important.
>
I disagree. If you're having to ask the question, it suggests that you
aren't yet sufficiently comfortable with the tools you have for organising
code and expressing algorithms cleanly. I don't think any of us was about
to suggest the original poster start off on the PS2's vector units bashing
out assembler for an LIW instruction set working in 16k each of data and
code memory, for example! Working in a C-style imperative language one is
liable to miss the forest for the trees.
> > Using the phrase "glorified interpreter" is an attempt to denigrate a
> > programming language that has more longevity and contributes more
> > genuine power (in the sense of its ability to amplify of human
> > intellectual and programming effort) than any other language yet
> > invented (FORTRAN's 4 year lead on Lisp notwithstanding).
> >
> > Such denigration is disrespectful to those who invented, elaborated and
> > perfected Lisp over the past 45 years and it is a disservice to people
> > who want to move into the field of AI research and programming.
> >
> > At the moment, if someone has to choose a language that best puts them
> > on the road to AI work, Lisp is it. Personally, I think Lisp is the
> > language all programmers should learn first. I wish I had.
>
> I didn't mean to offend you or any disrespect to the inventers of the
> language. Of course what I label a "glorified interpreter" was an
> amazing innovation 45 years ago. But NOW, we have interpreters!
Woah, a step backwards!
> I'm
> quite sure you can modify an interpreter to treat Lisp code the way you
> described in previous messages. I'm not entirely sure if this is true,
> but if it's not I'd like to learn from my mistakes.
>
It's entirely possible. Of course, you then get to deal with all the
issues involved in keeping the language usable, and many languages are
further removed from their internal representation within a vaguely decent
interpreter than Lisp. You do *not* want to be passing strings all over
the damn place.
Peter Cowderoy
>
>
> Randall R Schulz wrote:
> > Marc,
> >
> > Calling someone ignorant (as you did to me) is a good way to give
> > offense, don't you think?
>
> Well, offending someone else (like you did to someone who replied to
> original message), especially someone who made a very valid point, is
> not the easiest way to make friends.
It's worth pointing out that there's a difference between dismissing the
idea behind someone's statement as poppycock and accusing the person who
made it of being ignorant or worse. Both are potentially inflamatory, but
the latter is far less likely to lead to further useful discussion when
queried.
> If you're going to be offensive,
> you should learn to accept that people will reciprocate.
And if you wish to learn useful things while debating with academics, you
should learn to seperate the ad hominem from the offensive. Remember, it's
about the ideas.
> Thanks; I will look into it. I was much more interested in why YOU think
> Lisp would be a better language to use for learning AI.
>
The capacity for vaguely safe (compare it to the asm equivalent if you
wish to quibble) self-modifying code, without having to create an entire
language within a language as you would in something like C++, can be
pretty useful.
Pascal Bourguignon
There is no native notion of rule in LISP (it's List Processing after
all). You have to implement your own inference engine and rule logic.
Compared to other languages, it seems much easier to do that in LISP.
For example, to implement a "That_is_the_right_direction" predicate in
LISP, you could use a symbol that-is-the-right-direction. When the
symbol has no value (not (boundp 'that-is-the-right-direction)) then
it's unknown. When the symbol is known (boundp), they it's value
would be the value of the predicate (t for true, nil for false), or
you could use other logic values like: (:yes :probably-yes
:probably-no :no) or a float for fuzzy logic, or more complicated
values, etc.
--
__Pascal_Bourguignon__ http://www.informatimago.com/
----------------------------------------------------------------------
There is a fault in reality. Do not adjust your minds. -- Salman Rushdie
Rom
> There is no native notion of rule in LISP (it's List Processing after
> all). You have to implement your own inference engine and rule logic.
> Compared to other languages, it seems much easier to do that in LISP.
That was not very encouraging for someone new to LISP.
How much time is normally needed for learning enough LISP for creating an
inference engine so I will be able to implement a rule with a truthtable
like below?
T & T -> T
T & F -> F
T & - -> -
F & T -> F
F & F -> F
F & - -> F
- & T -> -
- & F -> F
- & - -> -
(first col = "Traffic_light_is_green", second col =
"That_is_the_right_direction", and third col is conclusion, T = true/ F =
false/ '-' = nil or inconclusive).
Regards
Rom
Marc Lanctot
would have appreciated is justification for your original point, which 2
other people had to give to me.
You're missing the point. I'm not trying to convince you otherwise, nor
am I asking you to concede your points. I accept the possibility that
Lisp may be a superior choice for learning AI. All I'd like is your
justification for this argument which you've consistently refused to
give because you're offended.
Fine-- I learned Scheme, and was told that Scheme is just syntactically
different than Lisp. Since Scheme is a functional language, I assumed
that Lisp was also. I may be wrong, but this point wasn't even relavent
to our discussion.
Marc
Marc Lanctot
Marc Lanctot
Peter Cowderoy wrote:
> On Thu, 26 Dec 2002, Marc Lanctot wrote:
>>Wow. I just think you drastically misinterpreted what this person wants.
>>I agree with you that AI is a higher concept, potentially subject of
>>many philosophical, psychological, cognetive, etc. debates. I don't
>>think AI is a collection of algorithms or computational paradigms
>>either, but as I will state again: I really think this person just wants
>>to implement/learn some of the algorithms that are clasically associated
>>with AI. In this respect, I think choice of language is negligibly
>>important.
>>
> I disagree. If you're having to ask the question,
Which question? I knew about the "treat-code-as-data" abstraction and
self-modifying code. What I don't know is how this helps (with learning
AI) that much. You've said that it's "sometimes useful". Along the same
lines, Prolog may do implicit subsitution for you but if anything this
would NOT help because you'd never learn what inference is !
I think the act of choosing Lisp might help for academic pursuits.
Example: testing a totally new experimental AI algorithm you came up
with might be a little faster & easier in Lisp (even then, I'm still not
convinced-- I'd probably have to do some work in Lisp to find out for
myself). Whereas building a resolution-refutation theorem-proving
algorithm might be a little less of a hassle in Prolog. For the
majority, why not choose an imperative language? Learning AI in them
would probably be easier because it'd be more likely to find code
examples, discussion groups, and help to learn from.
> it suggests that you
> aren't yet sufficiently comfortable with the tools you have for organising
> code and expressing algorithms cleanly. I don't think any of us was about
> to suggest the original poster start off on the PS2's vector units bashing
> out assembler for an LIW instruction set working in 16k each of data and
> code memory, for example! Working in a C-style imperative language one is
> liable to miss the forest for the trees.
I might not know as much about Lisp as you or Randall does, but I think
I know enough to argue my point that in this particular case it doesn't
make a difference. In all likelihood (i'm talking probably 9 to 1), this
person wants to learn the classical algorithms not go on an academic,
theoretical pursuit of AI. AND, he probably would like to learn because
he may want to make games or work for a gaming company. In this case,
learning Lisp would only hinder him(only slightly of course, because
he'd be learning the ideas behind the algorithms) because 80-90% of the
companies which he/she may want to apply would use a typical impertive
language like C/C++. And if that's too complicated, then pick up Java or
Python. At least with python you have the "pseudo-functional paradigm"
available to you while still learning the essentials of imperative
programming.
Pascal Bourguignon
> I do not wish to have "the last word" for personal satsfaction. What I
> would have appreciated is justification for your original point, which
> 2 other people had to give to me.
>
> You're missing the point. I'm not trying to convince you otherwise,
> nor am I asking you to concede your points. I accept the possibility
> that Lisp may be a superior choice for learning AI. All I'd like is
> your justification for this argument which you've consistently refused
> to give because you're offended.
>
> Fine-- I learned Scheme, and was told that Scheme is just
> syntactically different than Lisp. Since Scheme is a functional
> language, I assumed that Lisp was also. I may be wrong, but this point
> wasn't even relavent to our discussion.
[pascal@thalassa ai]$ /usr/bin/scheme
Welcome to UMB Scheme, version 3.2 Copyright (c) 1988,1996 William R Campbell.
UMB Scheme comes with ABSOLUTELY NO WARRANTY. This is free software and
you are free to redistribute it under certain conditions.
See the UMB Scheme Release Notes for details. Type Control-d to exit.
Loading /usr/lib/scheme/prelude.scheme...
Loading /usr/lib/scheme/slib/umbscheme.init...
Loading /usr/lib/scheme/slib/require.scm...
==> (define a "toto")
a
==> (define f (lambda () (set! a "titi")))
f
==> a
"toto"
==> (f)
"titi"
==> a
"titi"
==>
You call that "functional"? Sorry, but if side-effects are possible,
I call it procedural, not functional. That you may be able to use it
in a functional way does not change anything, you could also write a
PASCAL program in a functional way!
> Marc
>
>
> Randall R Schulz wrote:
> > - Lisp is not a functional language
Erik Max Francis
> You call that "functional"? Sorry, but if side-effects are possible,
> I call it procedural, not functional.
Side effects are possible in all but the most academic functional
languages. You're equating "functional" (meaning influenced heavily by
functional language paradigms) and "purely functional" (meaning no side
effects are ever possible).
I dare say that when most computer scientists talk about functional
languages, they are talking about the former definition, not the latter.
With a total inability to do any I/O of any kind (which would by
definition involve side effects), you can't get a lot of work in the
real world done. (There are ways in functional languages to "hide"
these side effects in nice functional [by the former definition!] ways,
but they're still side effects.)
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ Did you ever love somebody / Did you ever really care
\__/ Cassandra Wilson
The laws list / http://www.alcyone.com/max/physics/laws/
Laws, rules, principles, effects, paradoxes, etc. in physics.
Brendan Guild
> Pascal Bourguignon wrote:
>
> > You call that "functional"? Sorry, but if side-effects are possible,
> > I call it procedural, not functional.
>
> Side effects are possible in all but the most academic functional
> languages. You're equating "functional" (meaning influenced heavily by
> functional language paradigms) and "purely functional" (meaning no side
> effects are ever possible).
>
> I dare say that when most computer scientists talk about functional
> languages, they are talking about the former definition, not the latter.
> With a total inability to do any I/O of any kind (which would by
> definition involve side effects), you can't get a lot of work in the
> real world done. (There are ways in functional languages to "hide"
> these side effects in nice functional [by the former definition!] ways,
> but they're still side effects.)
I am curious to know what definition of I/O you are using. It just
seems a bit counter-intuitive that part of the definition of I/O be
that it is a side-effect of a function.
This discussion brings to my mind an example that was looked at as
part of a course on Haskell. In Haskell, one can have a function that
can be applied to a list and produce another list. In the example, the
argument list contained user inputs such as mouse and keyboard events,
and the returned list contained graphical output. To me, that seems
like I/O requiring no side-effects.
Erik Max Francis
> I am curious to know what definition of I/O you are using. It just
> seems a bit counter-intuitive that part of the definition of I/O be
> that it is a side-effect of a function.
A side effect is anything that takes places outside of a function beyond
its return value. It's hard to see how you can argue that any form of
I/O could be anything but side effects.
Printing a character to a terminal certainly involves something beyond
the scope of a value being returned from a function. Thus it is by
definition a side effect.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ I am an island / A little freak of melancholy
\__/ Lamya
Physics reference / http://www.alcyone.com/max/reference/physics/
A physics reference.
Randall R Schulz
Clearly computation without input or output is worthless, so there needs
to be some moderation of the concept of functional programming to
accommodate the need to supply input / parameters / arguments to a
computation and receive its results / outputs.
Would it not be reasonable to object to a side-effect as inconsistent
with a functional programming model only if the side-effect occurs
outside the function but still within the program?
Thus output does not change any state visible to the program and hence
can reasonably be considered to be side-effect-free.
Randall Schulz
Brendan Guild
> A side effect is anything that takes places outside of a function beyond
> its return value. It's hard to see how you can argue that any form of
> I/O could be anything but side effects.
>
> Printing a character to a terminal certainly involves something beyond
> the scope of a value being returned from a function. Thus it is by
> definition a side effect.
What if the printing of the character to the terminal was the return
value of the function? I see no reason to limit returnable values to
numbers when looking for purely functional I/O.
Erik Max Francis
> Clearly computation without input or output is worthless, so there
> needs
> to be some moderation of the concept of functional programming to
> accommodate the need to supply input / parameters / arguments to a
> computation and receive its results / outputs.
Obviously. Hence the distinction between the terms "purely functional"
and "functional."
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ The love we give away is the only love we keep.
\__/ Elbert Hubbard
Bosskey.net / http://www.bosskey.net/
A personal guide to online multiplayer first person shooters.
eric leaf
"Gerry Quinn" <ger...@indigo.ie> wrote in message
news:aBhM9.36139$zX3....@news.indigo.ie...
> In article <atntf5$5k1$1...@narses.hrz.tu-chemnitz.de>, "Michael Adam"
<ze...@gmx.net> wrote:
> In the second
> place, changing code and seeing what happens is lousy programming
> practice - it should be reserved for your genetic simulation module!
I just read an article a few months back that proposes this and a number of
other things in order to improve code quality, it was in CUJ. And they were
talking about some hardcore stuff like recompiling and testing after each
line of code. (I can find the article if your interested.) They had a method
to make this meaninful, a variant of refactoring, but doing it first instead
of "re". More time is spent in design where it should be than in late
schedule bug chasing.
And secondly I agree wholeheartedly. I can easily test code line by line and
know if I have tested each and every case. Whereas when I sit and program
for half an hour my next run test has to test 100 or more cases of
execution. What happens? I spend an hour debugging the 10 bugs I found, and
only managed to hit 50 of the cases. The other 50 cases get checked in QA or
after release and the remaining 10 bugs are then found. A long time from
when they were coded and when the schedule is already filled with other
things.
Now if you are talking about the by-gone days of punchcards then I agree,
test once by hand and then again before you compile and run. ;)
Erik Max Francis
> What if the printing of the character to the terminal was the return
> value of the function? I see no reason to limit returnable values to
> numbers when looking for purely functional I/O.
How can the return value of a function be an action? That's not a
value. To get I/O, somewhere along the line, there has to be some
function that performs the activity of writing that character to the
terminal. It can't do that as part of its return value, because its
return value must be an object within the context of the system. (You
could sidestep by saying that it returns an object which _represents_
that action, but still some function must execute that action, and that
action inherently involves a side effect.)
There are many "functional" languages -- that is, languages inspired by
functional programming paradigms and techniques. But there are very few
"purely functional" languages outside of academic, for the very reason
that they aren't practical. Any purely functional language can have _no
side effects whatsoever_, and that includes fundamental things like I/O.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
Brendan Guild
> Brendan Guild wrote:
>
> > What if the printing of the character to the terminal was the return
> > value of the function? I see no reason to limit returnable values to
> > numbers when looking for purely functional I/O.
>
> How can the return value of a function be an action? That's not a
> value. To get I/O, somewhere along the line, there has to be some
> function that performs the activity of writing that character to the
> terminal. It can't do that as part of its return value, because its
> return value must be an object within the context of the system. (You
> could sidestep by saying that it returns an object which _represents_
> that action, but still some function must execute that action, and that
> action inherently involves a side effect.)
So a function returns its I/O instead of having a side-effect. That
means that that function is acceptable in a purely functional program.
Taking this idea and applying it as many times as we want we can write
any program in a purely functional language with the I/O as the return
value of the program. When the program is compiled, we just add in
some code for actually doing the I/O and we have a complete system for
writing I/O programs in a purely functional language. This is what
Haskell does, as I understand it.
As a side note, in a purely functional language, the return value of a
function does not need to have a representation in memory, since the
compiler can either store values or re-compute them as needed. An
action as a return value could just mean that when the value of the
function call is computed, the action is immediately performed and not
stored. I this way it seems a bit strange to me to say that the return
value _represents_ the action. Having I/O actions as values seems no
stranger to me than having functions as values
Erik Max Francis
> So a function returns its I/O instead of having a side-effect. That
> means that that function is acceptable in a purely functional program.
But this sounds to me like a complete cop-out, from a purely functional
perspective (again, a language in which there can be _no_ side effects,
not one in which functional paradigms have strong influence).
You could equally say that you have some environment with global
variables, and it's just "returning the action of setting one of those
global variables," and therefore it's not a side effect because you used
the word _return_. That's just using semantics to rename side effect to
mean something different; that's not avoiding the side effect.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ Women are equal because they are not different any more.
\__/ Erich Fromm
WebVal / http://www.alcyone.com/pyos/webval/
URL scanner, maintainer, and validator in Python.
Rainer Deyke
> You could equally say that you have some environment with global
> variables, and it's just "returning the action of setting one of
those
> global variables," and therefore it's not a side effect because you
> used the word _return_. That's just using semantics to rename side
> effect to mean something different; that's not avoiding the side
> effect.
There are three levels of purity in functional languages:
1. No side effects, period.
2. No side effects except for i/o.
3. Side effects other than i/o, such as global variables.
Purity level 1 is clearly useless for any kind of interactive program.
The distincition between levels 2 and 3 is real and relevant, however.
Some people call level 3 "functional languages" and level 2 "pure
functional languages". Other call level 1 "pure", level 2 "functional
languages", and don't accept level 3 as functional at all. You seem
to call level 1 "pure" and use this to justify calling level 3
"functional", ignoring the distinction between levels 2 and 3. Why?
--
Rainer Deyke | rai...@eldwood.com | http://eldwood.com
Erik Max Francis
> There are three levels of purity in functional languages:
>
> 1. No side effects, period.
>
> 2. No side effects except for i/o.
>
> 3. Side effects other than i/o, such as global variables.
>
> Purity level 1 is clearly useless for any kind of interactive program.
> The distincition between levels 2 and 3 is real and relevant, however.
> Some people call level 3 "functional languages" and level 2 "pure
> functional languages". Other call level 1 "pure", level 2 "functional
> languages", and don't accept level 3 as functional at all. You seem
> to call level 1 "pure" and use this to justify calling level 3
> "functional", ignoring the distinction between levels 2 and 3. Why?
I have never claimed that. I was merely disputing the point that
"purely functional" is your level 1. I also pointed out that often
people use "functional language" to simply mean "a language inspired by
functional paradigms," which would be your level 3. I never claimed
that your level 2 didn't exist, nor that it was not a useful
distinction; I simply wasn't addressing that.
So far I was getting heavy disagreement that "purely functional" = level
1 in the first place, so clearly a terminology problem is indicated.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ Men with empires in their purpose / And new eras in their brains
\__/ Lamya
Bosskey.net: Return to Wolfenstein / http://www.bosskey.net/rtcw/
A personal guide to Return to Castle Wolfenstein.
Eternal Vigilance
The current common languages have features that didnt exist when LISP was
created.
nanda wrote:
> How to start programming AI and what language usually use? Is Lisp only use
> for academic purpose?
> What about C or C++, are there AI implementation use these langauges?
Gerry Quinn
>Peter Cowderoy wrote:
>
>> While I'm a bit hazy on the details, I believe monadic I/O solves that
>> problem.
>
>You can certainly wrap I/O in mechanisms which make them more amenable
>to use in (strongly) function language, but still, I/O itself is a side
>effect, something which a _purely_ functional language can never
>perform, as a matter of definition.
What if a device outside the computer monitors RAM and deduces the
results of a computation? Is a language purely functional only when it
is switched off?
Gerry Quinn
--
http://bindweed.com
Entertainment software for Windows
Puzzles, Strategy Games, Kaleidoscope Screensaver
Download evaluation versions free - no time limits
Gerry Quinn
>"Gerry Quinn" <ger...@indigo.ie> wrote in message
>
>> place, changing code and seeing what happens is lousy programming
>> practice - it should be reserved for your genetic simulation module!
>
>I just read an article a few months back that proposes this and a number of
>other things in order to improve code quality, it was in CUJ. And they were
>talking about some hardcore stuff like recompiling and testing after each
>line of code. (I can find the article if your interested.) They had a method
>to make this meaninful, a variant of refactoring, but doing it first instead
>of "re". More time is spent in design where it should be than in late
>schedule bug chasing.
I'm not sure that this is quite the method that attracts those who are
fond of interpreters. The difference with what you describe is that the
line-by-line testing is a process of testing code that is supposed to
be right, not part of an iterative coding process.
>And secondly I agree wholeheartedly. I can easily test code line by line and
>know if I have tested each and every case. Whereas when I sit and program
>for half an hour my next run test has to test 100 or more cases of
>execution. What happens? I spend an hour debugging the 10 bugs I found, and
>only managed to hit 50 of the cases. The other 50 cases get checked in QA or
>after release and the remaining 10 bugs are then found. A long time from
>when they were coded and when the schedule is already filled with other
>things.
Testing every line does not necessarily test every case.
Brendan Guild
> Brendan Guild wrote:
>
> > So a function returns its I/O instead of having a side-effect. That
> > means that that function is acceptable in a purely functional program.
>
> But this sounds to me like a complete cop-out, from a purely functional
> perspective (again, a language in which there can be _no_ side effects,
> not one in which functional paradigms have strong influence).
>
> You could equally say that you have some environment with global
> variables, and it's just "returning the action of setting one of those
> global variables," and therefore it's not a side effect because you used
> the word _return_. That's just using semantics to rename side effect to
> mean something different; that's not avoiding the side effect.
You can do something that looks a lot like global variables, but the
global variables get passed in as arguments, and the change of value
is returned as an action, so no side effects are involved.
All function calls will always give the same return value if given the
same arguments. So, it's so its not side effects by a different name,
since the most important side effects are the ones that change the
return value for future calls.
When an action is returned, calling the function is not the same as
performing the action. With any purely functional language a function
call gives you only a return value. This value may them be returned or
not from whatever function made the call. It is only the value
returned by the entire program that is the action that is performed.
This is needed because if the calls themselves did the actions we
would have no way of specifying the order.
The entire program works to build up a long and complex action,
perhaps involving global variables, that does all the I/O that is
expected of the program. This is more than just a renaming.
Rainer Deyke
> The entire program works to build up a long and complex action,
> perhaps involving global variables, that does all the I/O that is
> expected of the program. This is more than just a renaming.
In other words, interaction is impossible, except when the returned
action is itself a complete computer program.
Brendan Guild
> Brendan Guild wrote:
> > The entire program works to build up a long and complex action,
> > perhaps involving global variables, that does all the I/O that is
> > expected of the program. This is more than just a renaming.
>
> In other words, interaction is impossible, except when the returned
> action is itself a complete computer program.
Interaction is not impossible; it just requires a little trick.
One of the great things about purely functional programming languages
is that the compiler gets to choose when things are evaluated, and
that choice doesn't affect the result. So part of one function call
may be evaluated, and then part of another. We can start using a
return value before it has been completely evaluated.
We can have variables that are bound to user input, and actions that
cause that input to be taken from the device involved. The compiler
calls the function that returns the action for the I/O, and start
evaluating it. At some point, the compiler will see that it needs to
evaluate a variable bound to an input, and that will cause it to stop
evaluating and execute the part of the action that it already has.
Actual input will be taken from a device as a result and the input
bound variable's value will be known. Now the compiler can continue to
evaluate the action and find out what it needs to do next.
It is not known what the actual I/O action will be until near the end
of performing the action, simply because the actual values of the
input bound variables are not known. Of course the values of the input
bound variables never change, they just become known. This is how it
works in Haskell, a very purely functional programming language. It
uses this technique for I/O because it has at least the appearance of
being purely functional.
Erik Max Francis
> What if a device outside the computer monitors RAM and deduces the
> results of a computation? Is a language purely functional only when
> it
> is switched off?
This is academic and silly, and you know it. If overuse of a purely
functional language results in a CPU overheating and the machine
failing, does that mean it's not purely functional because it had a side
effect?
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ A man can stand a lot as long as he can stand himself.
\__/ Axel Munthe
Lsystem / http://www.alcyone.com/pyos/lsystem/
A Lindenmayer systems explorer in Python.
Neil
> LISP is the language they use to program in Hell. (that and PROLOG )
I have never used LISP but I have used PROLOG and its an extremly powerful
language. Unfortunately its also damn hard to follow whats going on in a
prolog program unless you're a certain type of person who can think that way
(which I'm not). But I still think you're being a bit unfair.
>
> The current common languages have features that didnt exist when LISP was
> created.
Such as what , objects? Big deal. OO is the most overated concept ever in
computer science IMO as its simply an extension of procedural programming and
brings little of anything new to the AI table.
NJR
Gerry Quinn
>Gerry Quinn wrote:
>
>> What if a device outside the computer monitors RAM and deduces the
>> results of a computation? Is a language purely functional only when
>> it
>> is switched off?
>
>This is academic and silly, and you know it. If overuse of a purely
>functional language results in a CPU overheating and the machine
>failing, does that mean it's not purely functional because it had a side
>effect?
But I thought we were already moving towards academic silliness, in
discussing languages with absolutely no I/O...
Erik Max Francis
> But I thought we were already moving towards academic silliness, in
> discussing languages with absolutely no I/O...
Maybe you haven't read the thread you're responding to, but that was
precisely the point I was getting at with _purely_ functional
languages: They are entirely academic. In the real world where people
talk about "functional languages" and mean something outside of
academia, they mean non-pure functional languages.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ The doors of Heaven and Hell are adjacent and identical.
\__/ Nikos Kazantzakis
Alcyone Systems' Daily Planet / http://www.alcyone.com/planet.html
A new, virtual planet, every day.
Rom
> Such as what , objects? Big deal. OO is the most overated concept ever in
> computer science IMO as its simply an extension of procedural programming
and
> brings little of anything new to the AI table.
I don't disagree and I don't agree.
> I have never used LISP but I have used PROLOG and its an extremly powerful
> language.
I would like PROLOG to be a powerful language ....at least regarding logical
programming, but it isn't. The problem seems to be simple boolean logic
itself with no notion of unknowns, causing most languages into an "assign
all first" approach... otherwise rubbish values will be used ... or a
compiler error will be generated. And there are no languages yet that has
gone beyond "simple boolean" logic.
So I feel there is a need for new languages.
A immediate need is a definable language... where new datatypes and
operators for this new datatypes can be freely defined. That is not
supported today, but Eiffel/Q is moving in the right direction.
If I define a new datatype in Delphi, TNew... then I cannot use standard
operators like "+" or "-" opon this datatype...
a, b, c: TNew;
...
c := a + b;
... will not work, unless TNew is something simple like Integer or
Single....
I will need new operators for "+"/ "-".... which Delphi does not support....
And constructs like:
if a and b then ....
becomes rubbish if TNew is something complex like a record.... the "simple
boolean" logic is so embedded into todays languages that it becomes a
straitjacket.
I also feel there is a need for some standards about procedural languages,
something like IL (interdiate language), but at a higher level, so that any
new language should be responsible for:
1) how to translate this new language source into "common language" source
2) how to translate "common language" source into this new language source
Rom
Rainer Deyke
> If I define a new datatype in Delphi, TNew... then I cannot use
> standard operators like "+" or "-" opon this datatype...
>
> a, b, c: TNew;
> ...
> c := a + b;
>
> ... will not work, unless TNew is something simple like Integer or
> Single....
> I will need new operators for "+"/ "-".... which Delphi does not
> support.... And constructs like:
>
> if a and b then ....
>
> becomes rubbish if TNew is something complex like a record.... the
> "simple boolean" logic is so embedded into todays languages that it
> becomes a straitjacket.
C++ supports overloading of most operators, including operators '&&'
(aka 'and') and '||" (aka 'or').
Rom
"Rainer Deyke" <ro...@rainerdeyke.com>
> C++ supports overloading of most operators, including operators '&&'
> (aka 'and') and '||" (aka 'or').
I once tried to define streaming operators with C++ ... it became too low
level for me.
Could you give the simplest possible example here?
Regards
Rom
Pascal Bourguignon
> "Neil" <ne...@ogham.demon.co.uk>
>
> > Such as what , objects? Big deal. OO is the most overated concept ever in
> > computer science IMO as its simply an extension of procedural programming
> and
> > brings little of anything new to the AI table.
>
> I don't disagree and I don't agree.
>
> > I have never used LISP but I have used PROLOG and its an extremly powerful
> > language.
>
> I would like PROLOG to be a powerful language ....at least regarding logical
> programming, but it isn't. The problem seems to be simple boolean logic
> itself with no notion of unknowns, causing most languages into an "assign
> all first" approach... otherwise rubbish values will be used ... or a
> compiler error will be generated. And there are no languages yet that has
> gone beyond "simple boolean" logic.
>
> So I feel there is a need for new languages.
>
> A immediate need is a definable language... where new datatypes and
> operators for this new datatypes can be freely defined. That is not
> supported today, but Eiffel/Q is moving in the right direction.
>
> If I define a new datatype in Delphi, TNew... then I cannot use standard
> operators like "+" or "-" opon this datatype...
That's where OO comes to the rescue !
That is, OO is the way the procedural languages have to help us to
write abstrat data type (their operations!).
Pure OO languages like Smalltalk allow you to override operators like
"+" or "-" on your own objects (that are in no way different to the
predefined objects in Smalltalk!). Even C++ allow you to use these
operators on your own abstract data types (objects).
But in anycase, this is only syntactic suggar. The point is to be able
to define your own types and their operations, and this is something
that you can do with OO or with generic functions of LISP.
> a, b, c: TNew;
> ...
> c := a + b;
>
> ... will not work, unless TNew is something simple like Integer or
> Single....
> I will need new operators for "+"/ "-".... which Delphi does not support....
> And constructs like:
>
> if a and b then ....
>
> becomes rubbish if TNew is something complex like a record.... the "simple
> boolean" logic is so embedded into todays languages that it becomes a
> straitjacket.
Ok then Object-Pascal is somewhat limited here. If you're unhappy
about that, why not have a look at LISP or the other object oriented
languages?
> I also feel there is a need for some standards about procedural languages,
> something like IL (interdiate language), but at a higher level, so that any
> new language should be responsible for:
> 1) how to translate this new language source into "common language" source
> 2) how to translate "common language" source into this new language source
>
> Rom
Better have formal specifications of the languages.
The point of creating a new language is to introduce semantics that
are not available in other languages. Therefore expressing all these
semantics in a common languages would be very difficult unless that
common language is plain maths and you do it in Z or something like
that.
--
__Pascal_Bourguignon__ http://www.informatimago.com/
----------------------------------------------------------------------
There is a fault in reality. Do not adjust your minds. -- Salman Rushdie
Rainer Deyke
> "Rainer Deyke" <ro...@rainerdeyke.com>
>
>> C++ supports overloading of most operators, including operators
'&&'
>> (aka 'and') and '||" (aka 'or').
>
> I once tried to define streaming operators with C++ ... it became
too
> low level for me.
A reasonable response. C++ supports many powerful high-level
abstractions, but at its core it's still fairly low-level and not very
user-friendly.
> Could you give the simplest possible example here?
class trilogic {
private:
enum { _true, unknown, _false } state;
public:
trilogic(bool init)
: state(init ? _true : _false)
{
}
trilogic()
: state(unknown)
{
}
bool is_true() const
{
return state == _true;
}
bool is_false() const
{
return state == _false;
}
bool is_unknown() const
{
return state == _unknown;
}
}
trilogic operator&&(trilogic lhs, trilogic rhs)
{
if (lhs.is_true() && rhs.is_true()) return true;
if (lhs.is_false() || rhs.is_false()) return false;
return trilogic(); // returns unknown
}
trilogic operator||(trilogic lhs, trilogic rhs)
{
if (lhs.is_true() || rhs.is_true()) return true;
if (lhs.is_false() && rhs.is_false()) return false;
return trilogic(); // returns unknown
}
// example usage:
trilogic t(true), f(false), u;
assert((t && u).is_unknown());
assert((t || u).is_true());
assert((f && u).is_false());
assert((f || u).is_unknown());
Getting 'trilogic' to behave reasonably in other contexts requires
more effort.
Rom
"Pascal Bourguignon" <p...@informatimago.com>
> Better have formal specifications of the languages.
>
> The point of creating a new language is to introduce semantics that
> are not available in other languages. Therefore expressing all these
> semantics in a common languages would be very difficult unless that
> common language is plain maths and you do it in Z or something like
> that.
It should not be a big deal.
Emulation (CygWin) and NET are showing how easy it is.
I understand the Eiffel language compiles to C-code first.
Euphoria has a C-code compile option.
C++ can be reduced to C for sure (a lot of C-code) ... same with LISP and
PROLOG?
To produce a specific syntax output has alwas been easier than to read a
specific syntax.
The problem here is much simpler than natural language translations.
And the obvious solution is: If you can translate Spanish to-from English,
and Russian to-from English, then you can translate Spanish to-from Russian.
Regards
Rom
Rom
This example is worth hours of manual studying.
I will work on the code and respond.
Regards
Rom
Brendan Guild
> Gerry Quinn wrote:
>
> > But I thought we were already moving towards academic silliness, in
> > discussing languages with absolutely no I/O...
>
> Maybe you haven't read the thread you're responding to, but that was
> precisely the point I was getting at with _purely_ functional
> languages: They are entirely academic. In the real world where people
> talk about "functional languages" and mean something outside of
> academia, they mean non-pure functional languages.
But, you're not saying that pure functional languages have absolutely
no I/O. At the very least a functional program would have a return
value, which I would qualify as output, and almost certainly would
have some arguments for input.
That kind of I/O seems to me to be sufficient for some applications,
such as those simple UNIX programs like "diff", "sort", and "grep", or
anything that has an input stream and an output stream and just
performs operations on such streams.
Erik Max Francis
> C++ supports overloading of most operators, including operators '&&'
> (aka 'and') and '||" (aka 'or').
No, because of the short circuiting properties, C++ does not allow you
to overload && or ||.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ Divorces are made in Heaven.
\__/ Oscar Wilde
Computer science / http://www.alcyone.com/max/reference/compsci/
A computer science reference.
Erik Max Francis
> No, because of the short circuiting properties, C++ does not allow you
> to overload && or ||.
Er, my bad, I was misremembering that. You can indeed overload operator
&& and operator || in C++.
Rainer Deyke
> Rainer Deyke wrote:
>
>> C++ supports overloading of most operators, including operators
'&&'
>> (aka 'and') and '||" (aka 'or').
>
> No, because of the short circuiting properties, C++ does not allow
you
> to overload && or ||.
C++ does allow overloading of && and ||, but the overloaded operators
won't have the short-curuiting. For an example that overloads these
operators, look at the Boost lambda library.
Eternal Vigilance
Prolog is fine for a certain types of programimg, but then you have to combine it with some
other language to
do the other 70% of the application.
Eternal Vigilance
Given information, data associateted
by Tupples etc.. were what made it good for certain AI applications. I
remember 15 years ago reading the ACM AI periodical with the endless articles
(really really dry reading) of trying to modify prolog to handle 'pure'
logics and other stuff I dont even remember anymore.
About the ease of redefining operators etc, I always wished C++ had a
language feature that allowed you to name your own operators along the old
FORTRAN form .NE. .EQ. and let you define the name ie-
.VORTEX. etc... instead of only allowing you to overload the common &
boring && limited operators + - / == etc...
Gerry Quinn
>Erik Max Francis <m...@alcyone.com> wrote in message
> news:<3E1593A5...@alcyone.com>...
>> Gerry Quinn wrote:
>>
>> > But I thought we were already moving towards academic silliness, in
>> > discussing languages with absolutely no I/O...
>>
>> Maybe you haven't read the thread you're responding to, but that was
>> precisely the point I was getting at with _purely_ functional
>> languages: They are entirely academic. In the real world where people
>> talk about "functional languages" and mean something outside of
>> academia, they mean non-pure functional languages.
>
>But, you're not saying that pure functional languages have absolutely
>no I/O. At the very least a functional program would have a return
>value, which I would qualify as output, and almost certainly would
>have some arguments for input.
And one could even in principle implement an equivalent to sequential
I/O events in a functional language, by calculating responses to all
theoretical future inputs.
A chess program written in a functional language could output not only
the selected move, but a tree of all possible following sequences. This
output would be theoretically equivalent to the output of a program in
an imperative language playing an 'ordinary' game of chess with
repeated user input.
Rom
overload the not-operator... for stating: a && not (b))
Regards
Rom
// Using Borland C++Builder 6
class trilogic {
private:
enum { _true, _unknown, _false } state;
public:
trilogic( bool init) : state( init ? _true : _false) {}
trilogic() : state( _unknown) {}
bool is_true() const { return state == _true; }
bool is_false() const { return state == _false; }
bool is_unknown() const { return state == _unknown; }
void set_true() { state = _true; }
void set_false() { state = _false; }
void set_unknown() { state = _unknown; }
trilogic operator && ( trilogic &next)
{
trilogic result;
if ( is_true() && next.is_true()) result.set_true();
if ( is.false() || next.is_false()) result.set_false();
return result;
};
trilogic operator || ( trilogic &next)
{
trilogic result( false);
if ( is_true() || next.is_true()) result.set_true();
else if ( is_unknown() || next.is_unknown()) result.set_unknown();
return result;
};
};
void __fastcall TForm1::Button1Click(TObject *Sender)
{
// example usage:
trilogic t(true), f(false), u, result;
result = f || u;
if ( result.is_true()) ShowMessage( "True");
if ( result.is_false()) ShowMessage( "False");
if ( result.is_unknown()) ShowMessage( "Unknown");
}
Brendan Guild
> In article <70115772.03010...@posting.google.com>, bgu...@shaw.ca (Brendan Guild) wrote:
> >But, you're not saying that pure functional languages have absolutely
> >no I/O. At the very least a functional program would have a return
> >value, which I would qualify as output, and almost certainly would
> >have some arguments for input.
>
> And one could even in principle implement an equivalent to sequential
> I/O events in a functional language, by calculating responses to all
> theoretical future inputs.
>
> A chess program written in a functional language could output not only
> the selected move, but a tree of all possible following sequences. This
> output would be theoretically equivalent to the output of a program in
> an imperative language playing an 'ordinary' game of chess with
> repeated user input.
That's interesting. We could also make it practically equivalent by
passing in the opponent's moves as the arguments to the program and
have the program choose it's moves in response. It would return a list
of moves, but the compiler would be forced to wait until it knows the
opponent's next move before it could evaluate the next element in the
list.
Rainer Deyke
> I got this to work with C++Builder. Just now I cannot figure out how
> to overload the not-operator... for stating: a && not (b))
trilogic operator!() const
{
if (is_true()) return false;
if (is_false()) return true;
return trilogic();
Rom
"Rainer Deyke" <ro...@rainerdeyke.com>
> trilogic operator!() const
> {
> if (is_true()) return false;
> if (is_false()) return true;
> return trilogic();
> }
// C++Builder
trilogic operator ! ()
{
trilogic result;
if ( is_true()) result.set_false();
else if ( is_false()) result.set_true();
return result;
};
.... works for: result = !f;
but not for: result = t && !f; / result = t && !(f); / result = t
&& (!f);
because:
- 'operator &&' not implemented in type 'trilogic' for arguments of the same
type
Some lack of proper understanding of '&' is probably my (and others) problem
here.
Regards
Rom
Rainer Deyke
> // C++Builder
> trilogic operator ! ()
> {
> trilogic result;
> if ( is_true()) result.set_false();
> else if ( is_false()) result.set_true();
> return result;
> };
>
> .... works for: result = !f;
>
> but not for: result = t && !f; / result = t && !(f); /
> result = t && (!f);
> because:
> - 'operator &&' not implemented in type 'trilogic' for arguments of
> the same type
>
> Some lack of proper understanding of '&' is probably my (and others)
> problem here.
Ah, yes. Your operator&& accepts a 'trilogic&' (i.e. a reference),
which cannot be bound to a temporary. Either use 'trilogic' (i.e. a
copy), which should actually be faster in this case, or 'trilogic
const&' (i.e. a reference to const).
Rom
"Rainer Deyke" <ro...@rainerdeyke.com>
> Ah, yes. Your operator&& accepts a 'trilogic&' (i.e. a reference),
> which cannot be bound to a temporary. Either use 'trilogic' (i.e. a
> copy), which should actually be faster in this case, or 'trilogic
> const&' (i.e. a reference to const).
Just fine!
changing:
trilogic operator && ( trilogic &next)
--> trilogic operator && ( trilogic const &next)
trilogic operator || ( trilogic &next)
--> trilogic operator || ( trilogic const &next)
solved the problem. Thank you. Now I can make a basic demo here.
Regards
Rom
Pascal Bourguignon
"Rom" <nos...@please.com> writes:
The ultimate common language could be on a given platform the binary
of that processor!
So, let's imagine you have an Eiffel program, you translate it to
mc680x0 (or ix86 if you prefer), then you take this object code and
translate it to Pascal (or C). Then you'll have quite a surprize when
you'll see a lot of low level stuff programmed in this high level
language. Namely, you'll have an implementation of the classes,
objects and methods primitives in Pascal and this will be a lot of low
level details. Depending on the ration of run-time functions
vs. in-line coding done by the Eiffel compiler, you may even end up
with big spaghetti code pascal procedures!
Try to translate Lisp to C. Then you'll have to re-implement Lisp in
C, just because in Lisp code and data is the same and you need to
implement eval, that is the whole Lisp interpreter!
I note that you asked for a common language for _procedural_
languages. Why not for any and all language. Then the problem would
be more obvious. For example, translating Prolog to Pascal.
The point is that the domain of human languages is about the same
whatever the language. There may have some small cultural differences
which means that you may have difficulties to translate idiomatic
expressions, or just lexical differences that make translating puns
difficult (I don't say impossible because you can always "deconstruct"
any expression and explain it, but you won't get the same effect in
the audience, only an understanding of the same effect).
But in programming languages that are much more restricted, you can
have bigger differences of concepts between one language and the other
and you get more easily to the point where all you can do is explain
in excruciating details what was meant in the other language.
On the other hand, you have some "translators", like p2c, who try to
produce maintainable C code from Pascal code. The concequence is that
the produced code is not guaranted to work exactly the same (or even
to work at all), and that's for two languages so similar!
Pascal Bourguignon
Eternal Vigilance <wo...@oneeye.com> writes:
> Prolog can do more than simple binary logic , its ability to
> backtrack from Given information, data associateted by Tupples
> etc.. were what made it good for certain AI applications. I
> remember 15 years ago reading the ACM AI periodical with the
> endless articles (really really dry reading) of trying to modify
> prolog to handle 'pure' logics and other stuff I dont even
> remember anymore.
>
>
> About the ease of redefining operators etc, I always wished C++
> had a language feature that allowed you to name your own operators
> along the old FORTRAN form .NE. .EQ. and let you
> define the name ie- .VORTEX. etc... instead of only allowing
> you to overload the common & boring && limited operators
> + - / == etc...
Pure syntactic suggar. a->vortex(b) insteand of a vortex b
You could either use Objective-C (with a different syntactic suggar):
[a vortex: b] insteand of a vortex b
or write your own proprocessor...
Erik Max Francis
> Just fine!
>
> changing:
> trilogic operator && ( trilogic &next)
> --> trilogic operator && ( trilogic const &next)
>
> trilogic operator || ( trilogic &next)
> --> trilogic operator || ( trilogic const &next)
>
> solved the problem. Thank you. Now I can make a basic demo here.
Since your trilogic class only wraps around an enum, you're probably
better off simply passing it by value rather than by const reference.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ I never think of the future. It comes soon enough.
\__/ Albert Einstein
Maths reference / http://www.alcyone.com/max/reference/maths/
A mathematics reference.
Rom
> There is no native notion of rule in LISP (it's List Processing after
> all). You have to implement your own inference engine and rule logic.
> Compared to other languages, it seems much easier to do that in LISP.
Testing C++ overloading boolean operators .... it seems to work....
I guess the solution qualifies as forward chaining... with full program
control ... it is very fast .... and no interface problems....
Rom
(problem)
ESIE would only be recommended for situations in which the
developer did not have much computer experience, the size of the
system to be developed was very small, there was no required
software interface, user interface requirements were limited, and
there was the need for backward chaining only.
VP-Expert would be recommended for situations in which
developers'' computer experience ranged from high to low, the
size of the system to be developed ranged from small to large,
software interface with Lotus 1-2-3 or Dbase was required, user
interface requirements were not of paramount importance, and
there was the need for either backward or forward chaining.
M.1 would be recommended for situations in which developers''
computer experience ranged from high to average, the size of the
system to be developed ranged from small to large, software
interface with Lotus 1-2-3 or Dbase was not required, user
interface requirements were important, and there was the need for
mainly backward chaining.
GURU would be recommended for situations in which
developers'' computer experience was high, the size of the system
to be developed was large, software interface with Lotus 1-2-3 or
Dbase was needed, user interface requirements were of paramount
importance, and there was the need for either backward or forward
chaining.
(problem end)
// Using Borland C++Builder 6
class trilogic {
private:
enum { _true, _unknown, _false } state;
public:
trilogic( bool init) : state( init ? _true : _false) {}
trilogic() : state( _unknown) {}
bool is_true() const { return state == _true; }
bool is_false() const { return state == _false; }
bool is_unknown() const { return state == _unknown; }
void set_true() { state = _true; }
void set_false() { state = _false; }
void set_unknown() { state = _unknown; }
trilogic operator && ( trilogic const &next)
{
trilogic result;
if ( is_true() && next.is_true()) result.set_true();
if ( state == _false || next.state == _false) result.set_false();
return result;
}
trilogic operator || ( trilogic const &next)
{
trilogic result( false);
if ( is_unknown() || next.is_unknown()) result.set_unknown();
if ( is_true() || next.is_true()) result.set_true();
return result;
}
trilogic operator ! ()
{
trilogic result;
if ( is_true()) result.set_false();
else if ( is_false()) result.set_true();
return result;
}
};
TForm1 *Form1;
//--------------------------------------------------------------------------
-
__fastcall TForm1::TForm1(TComponent* Owner)
: TForm(Owner)
{
}
// facts ... all instantiated to unknown
trilogic
High_DeveloperExperience,
very_small_ProjectSize,
small_ProjectSize,
Large_ProjectSize,
Lotus_123_SoftwareInterface,
dbase_SoftwareInterface,
UIRequirements_is_important,
UIRequirements_is_paramount,
Backwards_Chaining,
Forwards_Chaining;
void Display( trilogic result, char* shell_name)
{
char s[100];
*s = 0;
strcat( s, shell_name);
if (result.is_true()) {
strcat( s, " is suitable");
Form1->RichEdit1->Lines->Add( s);
}
if (result.is_unknown())
{
strcat( s, " is maybe usable");
Form1->RichEdit1->Lines->Add( s);
}
}
void EvaluateShells()
{
trilogic result;
// ESIE
result = !High_DeveloperExperience &&
!small_ProjectSize &&
!Large_ProjectSize &&
!Lotus_123_SoftwareInterface &&
!dbase_SoftwareInterface &&
!UIRequirements_is_important &&
!UIRequirements_is_paramount &&
!Forwards_Chaining;
Display( result, "ESIE");
// VP-Expert
result = !very_small_ProjectSize &&
!UIRequirements_is_paramount;
Display( result, "VP-Expert");
// M-1
result = High_DeveloperExperience &&
!very_small_ProjectSize &&
!Lotus_123_SoftwareInterface &&
!dbase_SoftwareInterface &&
!UIRequirements_is_paramount &&
!Forwards_Chaining;
Display( result, "M-1");
// GURU
result = High_DeveloperExperience &&
!very_small_ProjectSize &&
!small_ProjectSize;
Display( result, "GURU");
}
void __fastcall TForm1::Button1Click(TObject *Sender)
{
very_small_ProjectSize.set_false();
small_ProjectSize.set_true();
Large_ProjectSize.set_false();
UIRequirements_is_important.set_false();
UIRequirements_is_paramount.set_false();
EvaluateShells();
/*
returns:
"VP-Expert is suitable"
"M-1 is maybe usable"
if everything is unknown then program returns:
"ESIE is maybe usable"
"VP-Expert is maybe usable"
"M-1 is maybe usable"
"GURU is maybe usable"
*/
}
Raffael Cavallaro
> So a function returns its I/O instead of having a side-effect. That
> means that that function is acceptable in a purely functional program.
> Taking this idea and applying it as many times as we want we can write
> any program in a purely functional language with the I/O as the return
> value of the program.
But in order to not be a side effect, this I/O could not change *any*
state visible to the program. But since any useful language would be
able to look at things like I/O buffers, screen buffers, etc., any
useful I/O changes state visible to the program, and is thus, side
effecting.
Just like OO, "functional" is a quality of languages that some
languages support better than others. "Funtional" is not an absolute,
although some languages are stricter about allowing side effects, and
some languages support the functional style better (by making
functions and closures first class objects in the language).
Common Lisp is fairly unique in that it provides very broad and very
deep support for *many* programming paradigms including:
* OO (real OO mind you, with multiple dispatch, generic methods,
mulitiple inheritance, a MOP, etc.)
* functional
* imperative
* aspect oriented
and most likely whatever buzz-words become popular in the future. If
you get the fundamentals right, it's easy to add the latest paradigm
in a layered fashion. If you get the fundamentals wrong (e.g., C++ and
introspection) you can labor for years, and the result will still be
broken.
Oh, and by the way, Lisp is not an "interpreted" language. All major
implementations have compilers, and the one I use most (MCL) even
natively compiles code entered interactively.
Rom
> The ultimate common language could be on a given platform the binary
> of that processor!
> So, let's imagine you have an Eiffel program, you translate it to
> mc680x0 (or ix86 if you prefer), then you take this object code and
> translate it to Pascal (or C). Then you'll have quite a surprize when
> you'll see a lot of low level stuff programmed in this high level
> language.
I think you are quite right here. Even going from the C code produced by
Eiffel (that is how Eiffel works I suppose) back to Eiffel will produce
something nasty... and much slower code.
> Try to translate Lisp to C. Then you'll have to re-implement Lisp in
> C, just because in Lisp code and data is the same and you need to
> implement eval, that is the whole Lisp interpreter!
Going that way should work, but you are right about copying major part of
Lisp interpreter as standard objects.
> The point is that the domain of human languages is about the same
> whatever the language.
There may be major problems with bi-directional translation ... the meaning
of the algoritms may have to be catched... something like functional
specifications ... that has little in common with C ...
You may say this is wish-thinking. My interest in the better language is a
bit fading ... because I feel it mostly is he same all over. The number of
comtempary languages is causing fragmentation of the programming community.
To get a job you have to have specific experience in Java ..or C++ ... or
Oracle ... or some of the 30+ other languages.... while cross language
translation capabilities could have changed everything....
Rom
Rom
> trilogic operator && ( trilogic const &next)
> {
> trilogic result;
> if ( is_true() && next.is_true()) result.set_true();
> if ( state == _false || next.state == _false) result.set_false();
> return result;
> }
A bit of obsolete code... better use:
trilogic operator && ( trilogic const &next)
{
trilogic result;
if ( is_true() && next.is_true()) result.set_true();
if ( is_false() || next.is_false()) result.set_false();
return result;
}
Rom
Kaz Kylheku
> created.
So what? Modern Lisp has features that weren't dreamed about when Lisp
was first invented. Who today cares about that programming language
which was called Lisp (or rather LISP) in 1958?
For nearly every feature of Common Lisp, you can find some other
language which has a similar feature, or at least a pale imitation.
But there is no *single* other language that has them all.
Kaz Kylheku
> Try to progfram LISP (especially an older version) and then come back.
Why would anyone write in an outdated dialect, when there is a
plethora of great implementations of the up to date standard?
Go back under the bridge, troll. And get a spelling and grammar
checker. You look like a moron in print.
Brendan Guild
> bgu...@shaw.ca (Brendan Guild) wrote in message news:<70115772.03010...@posting.google.com>...
>
> > So a function returns its I/O instead of having a side-effect. That
> > means that that function is acceptable in a purely functional program.
> > Taking this idea and applying it as many times as we want we can write
> > any program in a purely functional language with the I/O as the return
> > value of the program.
>
> But in order to not be a side effect, this I/O could not change *any*
> state visible to the program. But since any useful language would be
> able to look at things like I/O buffers, screen buffers, etc., any
> useful I/O changes state visible to the program, and is thus, side
> effecting.
I agree with all the rest of your post, but I don't think that this is
correct. The I/O is being returned; it's not happening. The I/O could
change all the state in the world and it would not be a side effect,
since that change of state does not happen as a result of a function
call. For example, we could call a function that returns some I/O, and
then throw that I/O away and no actual I/O would ever be performed.
Pure functional languages have no difficulty in dealing with changes
of state. A functional program can work with a device of changing
state as a list of all the states that device will ever have, in the
order that it will have them. This is no problem at all since time is
not represented in the fundamental idea of a purely functional
program. There is no notion of one thing happening before another or
how long something will take, unless it is specifically introduced in
the form of a time-stamp or something. If a part of the program
examines a state that will not happen until the future, then that part
waits until the information is available, and perhaps another part
executes.
To better understand I/O, I have found an article available on the
web:
http://citeseer.nj.nec.com/wadler95how.html
It's "How to Declare an Imperative" by Philip Wadler. It's kind of a
tutorial on monadic I/O in Haskell, but it may explain a few things
better than I can. Don't be fooled by how much monadic I/O looks like
a procedural programming language. That is just syntax. It is all
purely functional.
Erik Max Francis
> I agree with all the rest of your post, but I don't think that this is
> correct. The I/O is being returned; it's not happening.
You can keep saying this, but it is not what computer scientists mean
when they talk about functional languages and "returning" vs. "side
effects."
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ We'll have to make our own luck from now on.
\__/ Louis Wu
Bosskey.net: Quake III Arena / http://www.bosskey.net/q3a/
A personal guide to Quake III Arena.
Rainer Joswig
"Rom" <nos...@please.com> wrote:
> "Pascal Bourguignon" <p...@informatimago.com>
>
> > There is no native notion of rule in LISP (it's List Processing after
> > all). You have to implement your own inference engine and rule logic.
> > Compared to other languages, it seems much easier to do that in LISP.
>
>
> Testing C++ overloading boolean operators .... it seems to work....
> I guess the solution qualifies as forward chaining... with full program
> control ... it is very fast .... and no interface problems....
>
Come on, there is not a single bit of forward chaining going on.
Rom
"Rainer Joswig" <jos...@lispmachine.de>
> Come on, there is not a single bit of forward chaining going on.
It is a subject for discussion..... I said "I guess the solution qualifies
as forward chaining".
Look at this Prolog solution to the same problem case:
<Prolog code start>
% recommend(System, DeveloperExperience, ProjectSize,
SoftwareInterface,
% UIRequirements, Chaining)
%
recommend(esie, low, very_small, none, limited, backwards).
recommend(vp_expert, _, ProjSize, lotus_123, UIReqs, _) :-
ProjSize \= very_small,
UIReqs \= paramount.
recommend(m_1, DevExp, ProjSize, SI, important, backwards) :-
DevExp \= low,
ProjSize \= very_small,
SI \= lotus_123,
SI \= dbase.
recommend(guru, high, large, SI, paramount, _) :-
( SI = lotus_123
; SI = dbase
).
<Prolog code end>
This is the obvious approach of doing the same thing with backward chaining
rules.
But, and it is a big BUT, the output is something that cannot be used as
recommendations over the phone.... for instance.
You can see that when the operator don't know anything yet about customers
requirements (everything is unknown)... then the Prolog system recommends:
- esie
- vp_expert
- m_1
- guru
That is a conclusion that cannot be presented to the customer...why is that
so?
(not any Prolog programmer myself)
Regards
Rom
Brendan Guild
> Brendan Guild wrote:
>
> > I agree with all the rest of your post, but I don't think that this is
> > correct. The I/O is being returned; it's not happening.
>
> You can keep saying this, but it is not what computer scientists mean
> when they talk about functional languages and "returning" vs. "side
> effects."
What do they mean?
I don't know how many people consider FOLDOC a reliable source, but it
is what I use, so I looked up side effect.
FOLDOC:
SIDE EFFECT: "A language construct that modifies the state of the
system. The most common side-effects are assignment, input and output.
A language without side-effects is purely-functional - execution
consists of the evaluation of an expression and all subexpressions are
referentially transparent."
This is very annoying. If we take this literally, any input or output
even the input passed in by arguments, and the single output of the
return value qualify as side effects. And side effects have nothing to
do with function calls. And even the most academic "purely functional"
language is not. Crazy. I understood a side effect as being an effect
of calling a function except the return value, what else should it be?
I'll try to find a different definition.
Michael Schuerig
> Erik Max Francis <m...@alcyone.com> wrote in message
> news:<3E17E67E...@alcyone.com>...
>> Brendan Guild wrote:
>>
>> > I agree with all the rest of your post, but I don't think that this
>> > is correct. The I/O is being returned; it's not happening.
>>
>> You can keep saying this, but it is not what computer scientists mean
>> when they talk about functional languages and "returning" vs. "side
>> effects."
>
> What do they mean?
http://www.cs.nott.ac.uk/~gmh//faq.html#functional-languages
Michael
--
Michael Schuerig If at first you don't succeed...
mailto:schu...@acm.org try, try again.
http://www.schuerig.de/michael/ --Jerome Morrow, "Gattaca"