Newbie questions 
Author Message
 Newbie questions



Quote:
> Or if not that kind of stuff, what kind of stuff can you do
> with Lisp macros?

You may check the best source on Common Lisp macros:

   "On Lisp - Advanced Techniques for Common Lisp"
   Paul Graham
   Prentice Hall, 1994
   ISBN 0-13-030552-9

Paolo
--



Sat, 20 Oct 2001 03:00:00 GMT  
 Newbie questions

Quote:

>                              (by the way, what is all this stuff
> about Turing-completeness?).

Turing completeness is the property of being able to implement the
same algorthims as a Turing machine. There are good reasons why this
is a limit on the algorthims that can possibly be implemented on a
computer.

[Incidentally, this is the smallest set of functions that includes the
zero function; the successor function and is closed under projection,
composition, (primitive) recursion, and minimalisation.]

Most computer languages in use today are Turing complete, so if you
can do it in one language, you can do it in another, it's just a
question of how much effort is involved. IIRC, one interesting
exception is the Charity language; programs in which are guaranteed to
terminate.



Sat, 20 Oct 2001 03:00:00 GMT  
 Newbie questions

Quote:
> I know it's all most too much to hope for, but I nevertheless wish
> this discussion will be moved off of comp.lang.lisp.

> If people want to debate the merits of a good AI language, then I think
> comp.ai is adequate for that.

Sadly, it isn't. "LISP can't do such and such that C++ can" is all you
hear. There are very few knowledgable Lisp types reading comp.ai, or
posting at any rate.

Quote:
> Indeed, questions about what the "right language" is are always best
> answered in a forum appropriate to the need.

If you discuss Lisp in any forum other than comp.lang.lisp you'll just
get people that talk about "LISP being slow" and "LISP has no STL or
virtual functions or interfaces" and blah blah....

Quote:
> If this were a comp.lang.lisp-only discussion, there are things I
> would say relevant to this topic, but I don't want to get involved
> in some vast multi-forum flamefest whose purpose seems more to
> consume resources than to hear a coherent answer.

Things were turning entirely into a discussion of Lisp vs. C++ and the
only group I know of that has people knowledgable enough of both to
make statements based on extensive experience with each instead of
heresay and what they remember reading about "LISP" in some magazine
article 10 years ago is comp.lang.lisp.

comp.ai should have been removed from the delivery headers though.

Christopher



Sat, 20 Oct 2001 03:00:00 GMT  
 Newbie questions

Quote:




> > > >        Also keep in mind that IntClosure is not sufficient; you have
> > > >to add similar classes if you want closures with other/different data
> > > >than just a single int, and also if you want "enclosed" functions with
> > > >other operation signatures.
> > > Which is an advantage if you believe in type checking!!!!
> > > I WANT the compiler to make sure that every function is only used with
> > > compatable parameters!
> >         This is probably not very helpful, but anyway... Simple type
> > compatibility is the only C++ can check statically - for example, you
> > can have a function that expects as an argument a value from {1, 2,
> > 5}. There's no way you can check this statically, which means that you
> > ultimately have to resort to run-time checking, which (as with
> > closures) is more painful to do in C++ than in Common Lisp.

> I think what josh is getting at is that in C++, it prevents you
> from stuffing an 8byte value into a two byte parameter.  If you
> don't have type checking for this sort of thing, you can easily
> overflow your calling stack, which is a bad no-no. Basically it
> is a matter of the program protecting itself from the programmer.

This sounds more like an anti-Forth argument, rather than an anti-lisp
argument.  There is no such danger of overflowing the call-stack in
lisp due to argument mismatches; there are far more efficient ways
to accomplish stack overflows ...

Quote:
> I'm sure there are lots of ways to shoot yourself in the foot with
> Lisp.  C++ is a concerted effort to reduce that possibility of
> self-destruction.  Sure I can get around alot of the constructs
> that offer protection in C++, but a properly versed programmer is
> not likely to "hang themselves" with the rope the language gives
> them.

Interesting take.  I personally find lisp very robust.

Quote:
> True, Lisp gives you the option of run-time program correction...

Not only run-time correction, but _programmed_ run-time correction...

Quote:
> but sometimes requirements don't allow that comfort.

What times are those?

Quote:
> My whole take on it?

> "Tastes Great....Less Filling"

And my take:  If you shoot yourself in the foot in lisp, your foot
hurts.  If you shoot yourself in the foot in C++, you die.

--
Duane Rettig          Franz Inc.            http://www.franz.com/ (www)
1995 University Ave Suite 275  Berkeley, CA 94704



Sat, 20 Oct 2001 03:00:00 GMT  
 Newbie questions

Quote:

> > I know it's all most too much to hope for, but I nevertheless wish
> > this discussion will be moved off of comp.lang.lisp.

> > If people want to debate the merits of a good AI language, then I think
> > comp.ai is adequate for that.

> Sadly, it isn't. "LISP can't do such and such that C++ can" is all you
> hear. There are very few knowledgable Lisp types reading comp.ai, or
> posting at any rate.

I used to read comp.ai. Got tired of the inane topics and the general
disregard for the state of the art in AI research. (Some called this
position elitist when the issue was brought up, IIRC.) There were far too
many posters with little knowledge of the history of AI making just plain
inaccurate statements. One thing that struck me was the number of posts
that contained little more than private musings based on nothing but
uninformed intuition. In short, too little signal, too much noise. Having
it moderated might improve things... We'll see.

Aside for my personal reasons for avoiding comp.ai, if you think about it,
AI is not really tied to lisp that strongly. Lisp (or any other language)
should ideally not be a topic of discussion if your concern is AI. The
issue should be techniques. Anyone going down the path of "mine is better
than yours" should definitely be rebuked, but (as Kent has so appropriately
pointed out) handing the problem to comp.lang.lisp is certainly not the
solution. Nothing as far as I can tell will change a closed mind.

Quote:
> > Indeed, questions about what the "right language" is are always best
> > answered in a forum appropriate to the need.

> If you discuss Lisp in any forum other than comp.lang.lisp you'll just
> get people that talk about "LISP being slow" and "LISP has no STL or
> virtual functions or interfaces" and blah blah....

> > If this were a comp.lang.lisp-only discussion, there are things I
> > would say relevant to this topic, but I don't want to get involved
> > in some vast multi-forum flamefest whose purpose seems more to
> > consume resources than to hear a coherent answer.

> Things were turning entirely into a discussion of Lisp vs. C++ and the
> only group I know of that has people knowledgable enough of both to
> make statements based on extensive experience with each instead of
> heresay and what they remember reading about "LISP" in some magazine
> article 10 years ago is comp.lang.lisp.

As true as that may be, I doubt any of them would be really interested in
what we have to say. I have found a similar attitude as the C++ advocate
had over here. I had a short discussion about lisp with a student well
versed in C/C++, and the functional style really bugged him. He could not
believe that anyone could do decent software engineering without type
checking, and nothing I said would make a difference to him. It seems as
though breaking out of that school of thought is *really* hard. Are there
any software engineers (research oriented or otherwise) that take the lisp
model of writing a program seriously, other than for prototyping etc? (This
is not a rhetorical question.)

Sunil



Sat, 20 Oct 2001 03:00:00 GMT  
 Newbie questions

[Followup to comp.lang.lisp]


Quote:
>...
>But getting back to the main subject. You mentioned in a previous post
>that you didn't see a use for closures. Yet you have the counted
>pointer and closure classes that you've created to try and emulate
>some of the functionality. This sort of thing is much easier to use
>and much more general if it is provided by the language itself. In
>Dylan the transform code above is:

>destination := map(curry(\+, 1), source);

>Chris.

You're right.  I first played with closures in languages that didn't
have object libraries (versions of CLisp and Scheme), and I got the
impression that people mostly used closures in places where a regular
object would do just fine.  Places where instead of passing a few
closures, you could pass a whole object and the code knows exactly
what object functions it wants to call.  Since there is a lot of
overlap and closures take less keystrokes and namespace people
probably still do use closures mostly in places where simple objects
would do.  

Of course you can simulate any subset of the semantics of a closure
with objects, but since people started arguing that supporting a lot
of them took too many keystrokes I ended up trying to "prove" that I
could use templates to define objects that have ALL of the semantics
of a closure, including the anonymity of the functions and the
lifetime issue of a shared activation record.  

This wasn't my original point - I think that the exact combination of
semantics of a closure is rarely needed.

And for what little it's worth, the templates we use at work are not
called "Closures" I just renamed them in order to draw a parallel.
And then I felt a little sheepish that I had said "What are closures
for?" and then simply shown that I could create closures in C++. I
know you don't quite agree because you object to "polluting" the
namespace.  But my point of view on that is that what is named and
what isn't is always very arbitrary, depending on your approach and
style, and if it also depends on what language you are using, so be
it. The cost of a name is basically nil, I'm not going to make a big
deal out of it.

Josh Scholar



Sat, 20 Oct 2001 03:00:00 GMT  
 Newbie questions

Quote:

>    C and C++ map more closely to the Chicken Pulley Unit's
> instruction set than any other high-level landwich.  You could write a
> LISP compiler in C, but you'd have quite a problem if you wanted to
> write a C compiler using LISP.

Symbolics had C, fortran and I think Pascal compilers written in, erm,
Lisp.

I was really disappointed when I found they had an X implementation,
only to discover when looking at the source that it was just MIT X,
compiled with their C compiler.

--tim



Sat, 20 Oct 2001 03:00:00 GMT  
 Newbie questions

[Followup to comp.lang.lisp]


Quote:





>> > > >        Also keep in mind that IntClosure is not sufficient; you have
>> > > >to add similar classes if you want closures with other/different data
>> > > >than just a single int, and also if you want "enclosed" functions with
>> > > >other operation signatures.
>> > > Which is an advantage if you believe in type checking!!!!
>> > > I WANT the compiler to make sure that every function is only used with
>> > > compatable parameters!
>> >         This is probably not very helpful, but anyway... Simple type
>> > compatibility is the only C++ can check statically - for example, you
>> > can have a function that expects as an argument a value from {1, 2,
>> > 5}. There's no way you can check this statically, which means that you
>> > ultimately have to resort to run-time checking, which (as with
>> > closures) is more painful to do in C++ than in Common Lisp.

>> I think what josh is getting at is that in C++, it prevents you
>> from stuffing an 8byte value into a two byte parameter.  If you
>> don't have type checking for this sort of thing, you can easily
>> overflow your calling stack, which is a bad no-no. Basically it
>> is a matter of the program protecting itself from the programmer.

>This sounds more like an anti-Forth argument, rather than an anti-lisp
>argument.  There is no such danger of overflowing the call-stack in
>lisp due to argument mismatches; there are far more efficient ways
>to accomplish stack overflows ...

>> I'm sure there are lots of ways to shoot yourself in the foot with
>> Lisp.  C++ is a concerted effort to reduce that possibility of
>> self-destruction.  Sure I can get around alot of the constructs
>> that offer protection in C++, but a properly versed programmer is
>> not likely to "hang themselves" with the rope the language gives
>> them.

>Interesting take.  I personally find lisp very robust.

>> True, Lisp gives you the option of run-time program correction...

>Not only run-time correction, but _programmed_ run-time correction...

>> but sometimes requirements don't allow that comfort.

>What times are those?

Well Bagheera didn't state the problem quite right.  The overall point
is that type checking saves you from tons and tons of late night typos
and logic errors.

And the time is when you have to deliver working code in the morning
and there isn't enough budget for more than a week more of testing!
So any error that gets into the code is far too many.  It happens all
the time in the game business.  

<evil voice> WELCOME TO MY WORLD. HA HA HA HA HA! </evil voice>

Passing the wrong parameter, parameters in the wrong order, the wrong
subfield etc. are common typos and often caught by the compiler -
especially if you design your class interfaces to catch as much as
possible.  In code that rarely runs or isn't expected to run under
normal conditions, this sort of correctness checking is very
important.

Joshua Scholar



Sat, 20 Oct 2001 03:00:00 GMT  
 Newbie questions

| I think what josh is getting at is that in C++, it prevents you from
| stuffing an 8byte value into a two byte parameter.  If you don't have
| type checking for this sort of thing, you can easily overflow your
| calling stack, which is a bad no-no.  Basically it is a matter of the
| program protecting itself from the programmer.

  this is not what static types are about.  having static types _allows_ a
  compiler to skimp on (some) run-time type checking in the belief that all
  or most of the necessary type checking can be performed compile-time.
  this is, of course, as ridiculous a desire as wanting the compiler to
  prove the program free of any other bug, and has confused people to no
  end about what types are.

  the important property of static types is not what would happen if you
  took it away, but what happens when you introduce it: you can take away
  some fences that you presume the compiler took care of, but the only
  actual consequence is that you leave open the whole area of precisely the
  kind of bugs you mistakenly associate with languages and compilers with
  dynamic types.  even in the machine language, there are types and
  associated operations on them.  some of the types may look very much the
  same when stored as bits in machine memory, but that is really an
  artifact of a context-dropping human viewer -- the archetypical example
  is the C notion of a pointer and its interchangeability with integers of
  some size.  the stored pointer doesn't become an integer any more than a
  parked car becomes a source of money when broken into by a thief -- in
  both cases, it's how you use it that matters, and we have laws and
  regulations that say that parked cars are just that and not sources of
  money.  if you willfully transgress these laws, you can turn a parked car
  into a source of money, but most people know they're doing something
  wrong when they do this, and even the lowliest thief who knows this is
  morally superior to the C programmer who abuses the bits of a pointer as
  an integer and takes it for granted.

  any form of representation is subject to interpretation by a conscious
  mind that imputes meaning to the inherently meaningless.  if, however,
  you partition the otherwise confusing representation space into various
  categories and make certain that you know which category something is of
  even at run-time, you don't get into the kinds of silly troubles that
  C/C++ fans think static typing got them out of: they never happen in the
  first place.  or, to be more precise, any powerful system will allow you
  to break the rules, but it has to be on purpose, not by silly mistake,
  which is, unfortunately, what C/C++ give you absent static type checks.

  so, "if you don't have type checking for this sort of thing", you move
  that type checking into the run-time, instead, and you _can't_ overflow
  your calling stack.  I'd argue that _dynamic_ typing is how a program
  protects itself from the programmer, and static typing that makes a whole
  lot of errors and problems _arise_.

| I'm sure there are lots of ways to shoot yourself in the foot with Lisp.

  how did you acquire your certainty about this who know nothing about what
  to do if you don't do static typing?  (hint: if you want to destroy the
  world through Lisp, you have to work hard at it.  if you want to destroy
  the world through C/C++, simply derefence a stray pointer or _forget_ to
  check for NULL, which is _manual_ run-time type checking.)

| C++ is a concerted effort to reduce that possibility of self-destruction.

  it must be Slobodan Milosovic's favorite programming language, then.

| True, Lisp gives you the option of run-time program correction... but
| sometimes requirements don't allow that comfort.

  you know, I'm a little irritated by the ignorant newbies who come here
  and on other lists and aske all sorts of inane questions, but it beats
  having to deal with ignorants who think they now enough to make blanket
  statements.

#:Erik



Sat, 20 Oct 2001 03:00:00 GMT  
 
 [ 350 post ]  Go to page: [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24]

 Relevant Pages 
 

 
Powered by phpBB® Forum Software