Newbie questions [Followup to comp.lang.lisp] 
Author Message
 Newbie questions [Followup to comp.lang.lisp]

Quote:

> Certainly within the freeware arena, they are no less painful to start
> than x windows is to get running on linux.  Some people might think
> starting a program from a shell instead of clicking with a mouse means
> it's not a "real" program, but by that argument, linux out of the box
> is such a system.  I still have to type startx manually because I haven't
> found the place to edit in the thing that says xdm should run by default
> at startup.  [hints by private e-mail are welcome].

I've gotten about two dozen replies to this by now and should be all set.
Thanks everyone!


Fri, 26 Oct 2001 03:00:00 GMT  
 Newbie questions [Followup to comp.lang.lisp]

Quote:

> Sometimes "which object is being operated upon?" is not a meaningful
> question. In my experience, it's not a meaningful question in any code
> which can be written in a "functional", side-effect-free style.

OK, I see your point here, but you yourself dictate it as a "functional"
style, not an object-oriented one.  The case you are referring to is one
where you have written a "function" that takes some arguments, does some
processing, and returns value with no side effects.  This is a useful
functionality to have, but is object-oriented?

Quote:
> Which object is being operated on in TYPE-INTERSECTION or TYPE-UNION?

Both are; these functions should be implemented as functions, not as
methods on an object.

Quote:
> Which is better, overloading the first argument or the second?

Overload neither; objects and classes are self-describing, so you can
easily write in a cond or case statement to perform special operations
in these cases.

Quote:
> Which of the methods below don't you like?
>   (DEFMETHOD TYPE-SUBTYPEP ((X MEMBER-TYPE) (Y TYPE))
>     (EVERY (LAMBDA (MEMBER) (TYPE-SUBTYPEP MEMBER Y)) (MEMBERS X)))
>   (DEFMETHOD TYPE-INTERSECTION ((X TYPE) (Y MEMBER-TYPE))
>     (MAKE-INSTANCE 'MEMBER-TYPE
>                    :MEMBERS
>                    (REMOVE-IF (LAMBDA (MEMBER)
>                                 (NOT (OBJECT-HAS-TYPE? MEMBER X)))
>                               (MEMBERS X))))
>   (DEFMETHOD TYPE-INTERSECTION ((X MEMBER-TYPE) (Y MEMBER-TYPE))
>     ..)
>   (DEFMETHOD TYPE-UNION ((X MEMBER-TYPE) (Y MEMBER-TYPE))
>     ..)

These are all poor methods, they are in every way functions.

Quote:
> When you have side effects, then often it does make sense to talk
> about what's *the* object and what's not. For example, if we say

>   (DEFGENERIC LEARN ((KB KNOWLEDGE-BASE) (F FACT) (TL TIME-LIMIT)))
>   (DEFGENERIC UNLEARN ((KB KNOWLEDGE-BASE) (F FACT) (TL TIME-LIMIT)))

And this is a case where you are working with object-orientation because
you are using a code/data abstraction.  The previous examples took
several objects, and probably would have used methods to get the
information they needed from it, while these specifically operate upon
one object.

Quote:
> then the KNOWLEDGE-BASE is likely to be the object.  However, (1)
> multiple inheritance can still be useful (consider different classes
> of FACTs..) and (2) I fail to see what CLOS loses by using general
> syntax.  Why is

>   kb->learn(f,tl)

> better than

>   (LEARN KB F TL)?

Because (LEARN KB F TL) rapidly loses its meaning when you are not
careful.  I do not know the intimates of CLOS, but say for example that
I write a method like:

(defmethod learn (kb (f my-fact) tl) ... )

This method specialises on the second object, but not the first.  While
initially this seems like it may be a feature because we can now
intercept any calls to "learn" our special type of fact.  On the other
hand, (LEARN KB F TL) is no longer equivalent to KB->(LEARN F TL), and
maybe instead decides to have side effects on F instead of KB (we don't
know, and there is no way to find out) while still using the same
generic function.  The other approach means that we do know, given an
object's API, whether it is that object or another that is most likely
to be operated on.  Rather than an inplementation or flexibility issue,
it is about readability and psychology.

Quote:
> I do see what I think are problems with CLOS, especially the large
> number of levels of indirection it imposes on the implementation even
> in the simplest cases. I can also understand other people who think
> weak static type checking or lack of enforced information hiding
> are problems. But criticizing CLOS for not imposing an asymmetric
> "this argument is the object, the others are along for the ride"
> semantics seems fairly silly.  

Perhaps my criticism there was tagged on for the ride, in response to
someone's trivialisation of it.  It is my personal belief that syntax
has more power over a programmer than anything else in a language, at
many levels.  Syntax decides how a programmer will use things,
regardless of how they CAN be used.  A syntax that places emphasis on a
particular object means that programmers will write in a way that uses
one object.  A syntax that places no emphasis leads to programs that use
any number of the objects, possibly in any number of ways.  The failure
to hide data means that programmers feel free to modify the data from
anywhere in their code, regardless of good practices etc.

Quote:
> CLOS evolved from systems which imposed
> that asymmetry, it dropped that asymmetry in order to gain some very
> useful generality (multiple inheritance), and (as above) it retains
> the ability to describe algorithms which have that asymmetry. So I
> just don't see the problem -- it honestly is a feature, not a bug.

I fail to see how multiple inheritance is affected by the syntax in this
case.. perhaps I use the word in a different way than you do?

Quote:
> (Others have pointed out that Bjarne Stroustrup himself has said that
> multiple inheritance is very nice. I'll also point out that Scott
> Meyers, in _Effective C++_ or _More Effective C++_, I forget which,
> also spends a lot of time showing how to do some of this in C++.  You
> write you could "easily" specialize on the other variables, but I
> actually wouldn't characterize it as all that easy. It's obviously
> doable, but it's also tedious and messy.)

You would specialise on the other variables exactly as CLOS does, I
don't see how it could possibly be any more messy than that.  You would
not even require a code change.

Another message has pointed out about 10 lines of code that change
functional syntax into message-passing syntax.  Its easy, and so are
other changes to make CLOS more object-oriented-ish.  The issue is not
difficulty of implementation, the difficulty is that its not in th
standard, and nobody is going to implement it unless there is something
driving them to do so.  With the reputation of LISP as it is, nobody who
would complain about these things (except maybe me, for some reason)
even bothers with LISP, so I suspect word never reaches the ears of the
LISP publishers and standard-setters.

CU
Dobes



Fri, 26 Oct 2001 03:00:00 GMT  
 Newbie questions [Followup to comp.lang.lisp]

Quote:


> > More important issues are things like packaging; many lisp environment
> > do not compile executables

> Huh?  Both major commercial Common Lisp vendors (for Windows and UNIX)
> have compilers that produce executables.  At least one of them can also
> produce DLLs.

Huh?  There are more than two Common Lisp vendors, and Allegro only
started producing executables under Windows late last year when they
released Allegro 5.0.  Allegro 3.0.2 which I have been using at school
for the last term does not.  I suspect that it is not alone in this
bracket.

CU
Dobes



Fri, 26 Oct 2001 03:00:00 GMT  
 Newbie questions [Followup to comp.lang.lisp]

Quote:



> > > More important issues are things like packaging; many lisp environment
> > > do not compile executables

> > Huh?  Both major commercial Common Lisp vendors (for Windows and UNIX)
> > have compilers that produce executables.  At least one of them can also
> > produce DLLs.

> Maybe he only meant to say "many lisp environments produced for casual
> use are suitable only for casual use, and only those lisp environments
> that intend to be commercial quality address this commercial concern".

Which LISP environments are those?

Surf to the Allegro 5.0 for UNIX site; it doesn't even mention the
ability to generate executables, only the Windows version does.

LispWorks suffers from the same symptoms, perhaps.  It could be that
they assume that you know they generate executables, but LispWorks only
has a brief note in the Windows LispWorks FAQ regarding the ability to
generate DLLs.

Do they really generate executables?  I was under the impression they
didn't.

CU
Dobes



Fri, 26 Oct 2001 03:00:00 GMT  
 Newbie questions [Followup to comp.lang.lisp]
Well you can "suspect" anything you want, but please don't waste
everbody's time by insisting that your ignorance is our problem.
Personally, I'm solving your problem by excluding your messages from
my news feed from now on.


Fri, 26 Oct 2001 03:00:00 GMT  
 Newbie questions [Followup to comp.lang.lisp]

Quote:

> OK, I see your point here, but you yourself dictate it as a "functional"
> style, not an object-oriented one.

This presupposes a particular definition of object-oriented.

I claim that the original and proper definition of object-oriented
means "organized in a way such that an object's identity matters"
and is wholly neutral as to how objects are implemented.

Lisp was object-oriented before it had ANY way to program objects.
That other latter-day people have come in and added a new way to
define objects and have co-opted the term "object-oriented" for
that is a rude irrelevance.

I think a better name for this notion that Smalltalk and Java and
other systems have of everything being about messages to single
objects would be "object-centric" or even "self-centric".



Fri, 26 Oct 2001 03:00:00 GMT  
 Newbie questions [Followup to comp.lang.lisp]

Quote:



> > > More important issues are things like packaging; many lisp environment
> > > do not compile executables

> > Huh?  Both major commercial Common Lisp vendors (for Windows and UNIX)
> > have compilers that produce executables.  At least one of them can also
> > produce DLLs.

> Huh?  There are more than two Common Lisp vendors,

As far as I know (though I don't use it myself),
MCL has been producing executables for many years.

Harlequin LispWorks has been producing executables for years.
It doesn't let you do this in its free version.
One can hardly blame them.

I suspect that Eclipse CL can produce executables, since the way it works
it would be hard for it not to.

I'm pretty sure Corman CL can produce executables.

I don't know about CLISP or GCL.

Still, all told, I think it's not as bad as you suggest.

Quote:
> and Allegro only
> started producing executables under Windows late last year when they
> released Allegro 5.0.

Because of being at Harlequin for so long, I didn't have much access
to Allegro for a long time, so I don't know for sure about this.
Maybe a Franz person will comment.  But even if it is true, your
statement "do not compile" was in the present tense.  If you know they
are presently doing so, your statement would be factually in error if
you meant it to apply to this implementation.

Quote:
> Allegro 3.0.2 which I have been using at school
> for the last term does not.

There is an unaccounted-for Allegro 4 in here, I assume.

Quote:
> I suspect that it is not alone in this bracket.

Old versions of things often don't do things.  You have some ethical
obligation to be up-to-date before you start disparaging existing
implementations.  The vendors have been working on cleaning up their
act on this over the last several years and deserve credit for this.

Can you in fact name any commercial CL (i.e., one that charges you to
purchase it) that does not produce executables?  Presently I mean--not
"at some time in the past". I'm not saying there isn't one.  I'm just
curious if there is such a one.  I don't know of one.



Fri, 26 Oct 2001 03:00:00 GMT  
 Newbie questions [Followup to comp.lang.lisp]
[...]

Quote:
> It is my personal belief that syntax
> has more power over a programmer than anything else in a language, at
> many levels.  Syntax decides how a programmer will use things,
> regardless of how they CAN be used.

So, when the language hands you have a syntactic hammer, you then feel
obliged to look at everything as a nail?  That doesn't sound like a very
winning argument for syntax to me.

[...]

Quote:
> Another message has pointed out about 10 lines of code that change
> functional syntax into message-passing syntax.  Its easy, and so are
> other changes to make CLOS more object-oriented-ish.  The issue is not
> difficulty of implementation, the difficulty is that its not in th
> standard, and nobody is going to implement it unless there is something
> driving them to do so.

You are complaining that Lisp provides too powerful of a model?

Quote:
> With the reputation of LISP as it is, nobody who
> would complain about these things (except maybe me, for some reason)
> even bothers with LISP, so I suspect word never reaches the ears of the
> LISP publishers and standard-setters.

Yeah, thanks, you're all heart.  Very kind of you to talk to us
benighted lispers.

-matt



Fri, 26 Oct 2001 03:00:00 GMT  
 Newbie questions [Followup to comp.lang.lisp]

Quote:




> > > > More important issues are things like packaging; many lisp environment
> > > > do not compile executables

> > > Huh?  Both major commercial Common Lisp vendors (for Windows and UNIX)
> > > have compilers that produce executables.  At least one of them can also
> > > produce DLLs.

> > Huh?  There are more than two Common Lisp vendors,

> As far as I know (though I don't use it myself),
> MCL has been producing executables for many years.

> Harlequin LispWorks has been producing executables for years.
> It doesn't let you do this in its free version.

I wouldn't expect that, although it probably deserves mention on the
feature list?  It is easy to assume that because it is listed as an
interpreter, it typically is not also a compiler (to executable)

Quote:
> Still, all told, I think it's not as bad as you suggest.

GCL compiles to ANSI C code, like Eclipse.
CLISP does not compile to executable, but it will compile to a .fas
format which may or may not be machine-code (?)

Typical "major" features of LISP environments look like:

Some generate to C:
Eclipse (although it also has an interpreter)
ECoLisp
GCL
Star Sapphire Common LISP (lists a "beta" lisp-to-C system)
CLiCC (minimal free system)

Non-compiling interpreters:
(most small shareware apps)
Star Sapphire Common LISP (commercial)
RefLISP (minimal free system)
jlisp (minimal free system)
CLISP (supports both modes)
PowerLISP (I think supports both modes)
CMUCL (supports both modes)

Dynamic compiler:
Gold Hill
Allegro CL
LispWorks
Mac CL
Corman LISP
Medley 2.0 (Xerox)*
CLISP(?)
PowerLISP
CMUCL

Compiles to exe:
Gold Hill
Allegro CL
LispWorks
Mac CL
CMUCL (?)
[ Corman LISP* ]

Software Engineer (by Raindrop Software)

Interestingly, Corman LISP does NOT generate actual executables, but
rather plays a clever game by creating an image file and copying the
lisp environment's .exe to the same basename as the image, which causes
it to load that image on startup instead of the standard one.  (Unless
this changed very recently without me noticing)  I actually think this
merits mention as almost generating an executable, because at least the
implementation has concern for packaging issues.  Ideally it would have
done a "self-executing" image approach, like WinZip does, by embedding
its executable in the top of the image.

I cant find out without mailing Xerox whether Medley 2.0 can generate
executables, so you could include that in the last category as well.

I omitted a few incomplete or non-CL entries from the list.  You can
take a look at it yourself if you want to really research the topic:
http://www.elwood.com/alu/table/systems.htm

Regardless, there are about 4 commercial implementations that do in fact
appear to generate actual executables, out of a list of about 10 total
(commercial) vendors, and 5 total implementations out of a total
(listed)

Correct me if I am wrong!

CU
Dobes



Fri, 26 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