Hello,
I'm italian boy and I'm not speak a beautiful english.
I send message here because there is not an italian news group of Lisp.
My request is:
Lisp is as C/C++ or Assembly? What's is application on the informatic world?
Can I insert it in my C++ source?
It is used for Artificial Intelligence? If so, it is the better language
for AI application or better of Assembly?
Thank you
--
Luigi
"Luigi" wrote:
> I'm italian boy and I'm not speak a beautiful english.
I hope the English I've written is easy to understand.
> Lisp is as C/C++ or Assembly? What's is application on the informatic world?
> Can I insert it in my C++ source?
> It is used for Artificial Intelligence? If so, it is the better language
> for AI application or better of Assembly?
Lisp is more like C++ than it is like C.
Lisp is more like C than it is like assembly language.
But Lisp is further away from assembly language than C and C++ are.
It is a "higher-level" language.
For instance:
- Integers in Lisp do not overflow. If you multiply
1000000000 by 1000000000, you get 1000000000000.
(In C++, you are more likely to get 3567587328.)
- Lisp does automatic memory management. If you
create an object and then stop using it, it will
automatically be deleted. (In C++, you have to
say "delete x;" explicitly.)
Another difference between Lisp and C++ is that Lisp is
"dynamically typed". This means that you do not have to
tell a Lisp system what kind of data each variable can
hold. In fact, the same variable can contain different
types of data at different times. This is one reason why
a Lisp program is usually shorter than a C++ program
that does the same thing. (There are other reasons.)
You cannot insert Lisp code into a C++ program,
but it is possible to get libraries that you can link with
to embed a Lisp system into your program.
However, there are two problems.
(1) Usually it's only a very small Lisp system.
(2) Usually it only interprets code, and does not compile it.
So, if you do this, your Lisp code will be slow.
Most Lisp systems allow you to use code written in C
inside them. This might be more useful than embedding
Lisp in C or C++.
Lisp is sometimes used for artificial intelligence.
It is a good language for doing artificial intelligence,
and a much better language for it than assembly language.
But Lisp is useful for many other things as well.
I think most Lisp programs are not artificial intelligence programs.
There is more information about Lisp at
http://www.alu.org/
--
Gareth McCaughan ················@pobox.com
.sig under construc
<················@pobox.com> replied to "Luigi":
+---------------
| - Integers in Lisp do not overflow. If you multiply
| 1000000000 by 1000000000, you get 1000000000000.
| (In C++, you are more likely to get 3567587328.)
+---------------
Actually, Luigi, I think Gareth left off a few zeros: ;-} ;-}
> (* 1000000000 1000000000)
1000000000000000000
>
But the basic point is valid. Lisp provides arbitrary-precision
"bignums" (big integers) and arbitrary-precision rational numbers
(a ratio of two integers), so integer arithmetic is neither truncated
at some arbitrary 32- or 64-bit boundary, nor are fractions forced to
"zero" or floating-point (unless you *tell* them to be):
> (/ 15.0 25.0)
0.6
> (/ 15 25)
3/5
> (defvar a 163477937096098716906480)
A
> (defvar b 83374438621927341066528)
B
> (* a b)
13629881232457981255816665236528107508034301440
> (/ a b)
4278751255/2182181218
> (gcd a b)
38206927057296
> (lcm a b)
356738483888492081107219718492640
> (+ 3/5 5/7)
46/35
> (+ 46/35 7/11)
751/385
> (float 751/385)
1.9506494
> (truncate 751/385)
1 ; ; integer quotient
366/385 ; rational remainder
>
It also provides floating point numbers (usually in several precisions)
and complex numbers (whose real and imaginary parts may be integers,
rationals, or floats).
> (* #c(5 2) #c(1 -1))
#C(7 -3)
> (+ #c(3/5 1/2) #c(5 2))
#C(28/5 5/2)
> (* #c(5.0 2.0) (sqrt -1))
#C(-2.0 5.0)
> (imagpart (/ #c(5.0 2.0) (sqrt -1)))
-5.0
>
-Rob
-----
Rob Warnock, 31-2-510 <····@sgi.com>
SGI Network Engineering <http://reality.sgi.com/rpw3/> [until 8/15]
1600 Amphitheatre Pkwy. Phone: 650-933-1673
Mountain View, CA 94043 PP-ASEL-IA
[Note: ·········@sgi.com and ········@sgi.com aren't for humans ]
Rob Warnock wrote:
> <················@pobox.com> replied to "Luigi":
> +---------------
> | - Integers in Lisp do not overflow. If you multiply
> | 1000000000 by 1000000000, you get 1000000000000.
> | (In C++, you are more likely to get 3567587328.)
> +---------------
>
> Actually, Luigi, I think Gareth left off a few zeros: ;-} ;-}
>
> > (* 1000000000 1000000000)
> 1000000000000000000
> >
Aargh. Actually the problem was extra 0s, not omitted 0s.
I'd intended the multiplicands to be 1000000 each.
This wouldn't have happened if I'd been implemented in Lisp. :-)
--
Gareth McCaughan ················@pobox.com
.sig under construc
I hope the English I've written is easy to understand.
Yes :)
>But Lisp is further away from assembly language than C and C++ are.
>It is a "higher-level" language.
When you compile a Lisp source, it is translated in an Assembly code?
> - Lisp does automatic memory management. If you
> create an object and then stop using it, it will
> automatically be deleted. (In C++, you have to
> say "delete x;" explicitly.)
As Java?
>Another difference between Lisp and C++ is that Lisp is
>"dynamically typed". This means that you do not have to
>tell a Lisp system what kind of data each variable can
>hold. In fact, the same variable can contain different
>types of data at different times. This is one reason why
>a Lisp program is usually shorter than a C++ program
>that does the same thing. (There are other reasons.)
Then I can't declare a variable before to use it?
> http://www.alu.org/
Thanks you for information!
Luigi
"Luigi" <········@hotmail.com> writes:
> I hope the English I've written is easy to understand.
> Yes :)
>
> >But Lisp is further away from assembly language than C and C++ are.
> >It is a "higher-level" language.
> When you compile a Lisp source, it is translated in an Assembly
> code?
Sometimes. Sometimes it is translated into some form of "bytecode."
The CMU/CL implementation supports both behaviours, which is valuable
because:
-> Machine code is often faster, but compiling consumes time and memory,
and machine code tends to be _larger_ than bytecode;
-> Bytecode doesn't execute as fast, but is more compact and easier to
generate, and if the code _isn't_ in a tight inside loop, speed may
not matter at all. [Sometimes the "bytecode is smaller" can win the
day, too... It consumes less memory, and so runs faster because of
_that_...]
> > - Lisp does automatic memory management. If you
> > create an object and then stop using it, it will
> > automatically be deleted. (In C++, you have to
> > say "delete x;" explicitly.)
> As Java?
That's actually backwards. Lisp was doing this thirty years ago; Java
is the newcomer doing what Lisp has (nearly) always done.
>>Another difference between Lisp and C++ is that Lisp is "dynamically
>>typed". This means that you do not have to tell a Lisp system what
>>kind of data each variable can hold. In fact, the same variable can
>>contain different types of data at different times. This is one
>>reason why a Lisp program is usually shorter than a C++ program that
>>does the same thing. (There are other reasons.)
> Then I can't declare a variable before to use it?
Often, you don't need to. You attach a value to a binding, and use
that binding as needed, and it Just Does The Right Thing.
In some cases, it _is_ valuable to declare the type of a slot in a
structure, as this allows the environment to either check data types
more carefully, or to generate code specifically for the required data
type. Thus there _are_ ways of declaring what type of data may be
stored in a structure/object.
But that tends to diminish the usefulness of the code and data
structures, so it is seldom done early in the process, and may not
even be done at all.
--
(reverse (concatenate 'string ········@" "enworbbc"))
http://vip.hex.net/~cbbrowne/oses.html
Rules of the Evil Overlord #21. "I will hire a talented fashion
designer to create original uniforms for my Legions of Terror, as
opposed to some cheap knock-offs that make them look like Nazi
stormtroopers, Roman footsoldiers, or savage Mongol hordes. All were
eventually defeated and I want my troops to have a more positive
mind-set." <http://www.eviloverlord.com/>
Luigi WhosesurnameIdon'tknow wrote:
[I said:]
> > But Lisp is further away from assembly language than C and C++ are.
> > It is a "higher-level" language.
>
> When you compile a Lisp source, it is translated in an Assembly code?
Most Lisp systems compile to machine code, yes.
Some Lisp systems compile Lisp into C, and then
use a C compiler to finish the job.
Some Lisp systems compile to a bytecode, like
Java does. There is even one that compiles to
Java bytecodes, which will run on a JVM.
Some Lisp systems (mostly very small ones) do not
compile at all. They have an interpreter but no
compiler.
On comp.lang.lisp, "Lisp" usually means "Common
Lisp". I think every Common Lisp implementation
in the world includes a compiler. There is one
Common Lisp system that compiles only to bytecode;
all the others I know about compile to machine code
(some of them do it via C).
> > - Lisp does automatic memory management. If you
> > create an object and then stop using it, it will
> > automatically be deleted. (In C++, you have to
> > say "delete x;" explicitly.)
>
> As Java?
Yes. I think most Lisp systems have better garbage collectors
than most Java virtual machines, because companies that
make Lisp systems have been doing it for longer and have
more useful experience.
> > Another difference between Lisp and C++ is that Lisp is
> > "dynamically typed". This means that you do not have to
> > tell a Lisp system what kind of data each variable can
> > hold. In fact, the same variable can contain different
> > types of data at different times. This is one reason why
> > a Lisp program is usually shorter than a C++ program
> > that does the same thing. (There are other reasons.)
>
> Then I can't declare a variable before to use it?
You can, but it's not quite the same as in C++.
Creating a variable ("establishing a binding" is
technically more correct) is a separate operation
from saying what type of objects it will name.
You do not have to do both, but sometimes it is
helpful to tell the compiler about types so that
it can generate better code.
Most variables in Lisp programs are created by
a construct called LET. The nearest equivalent in
C++ would be starting a new scope and declaring
some variables in it. So, instead of saying
{
int x = 123;
string foo = "Luigi";
// do something that uses x and foo
}
you say
(let ((x 123)
(foo "Luigi"))
;; do something that uses x and foo )
or, if for some reason you need to promise something
about the value of X, you might say
(let ((x 123)
(foo "Luigi"))
(declare ((type (integer 0 1000) x)))
;; do something that uses x and foo )
and that tells the compiler that X is always supposed
to be an integer between 0 and 1000. But when you are
writing the code for the first time, you would almost
always omit the declaration. Then, if the program is
not fast enough, you can start adding declarations to
help the compiler.
--
Gareth McCaughan ················@pobox.com
.sig under construc