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

Quote:


> > Unless I'm mistaken, it's already possible to declare everything in
> > lisp.

> Yes, I have pointed this out a few times already. I am not asking for a
> language change, only for implementations to make USE of this
> information to warn me about problems earlier rather than later.

Right.  But it is long-established that the newsgroup is not a good place
to report bugs in individual implementations.  And you're basically saying
that this is an implementation bug.  The right place to report implementation
deficiencies is to your vendor, not to the world.


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

Quote:




> > > Nothing in CL forbids you from type-declaring every variable.

> > It might be nice to have some standard, succinct syntax for this.
> > Maybe something like:

> > (defun  foo\integer (lyst\cons x\integer ...)
> >   ...)

> I don't think we need a new standard for that.  The DEFMETHOD
> syntax: ``(parameter class)'' can be reused, so that the above
> example becomes:

>   (defun (foo integer) ((lyst cons) (x integer) ...)
>     ...)

For this to be valid surely the standard would need to be modified?

I agree that your example is more in keeping with the style of CL and
therefore probably better. I was, however deliberately vague about
exactly what the syntax given should be equivalent to. There are a
number of things that might be desirbale, and you might what different
syntaxes (is that the plural form of syntax?) for these and
combinations thereof.

Quote:

> And the really good thing is that one doesn't have to change
> the implementation to do that (if one wants that syntax): the
> _user_ can do their own version of DEFUN which expands the above
> into something like:

>   (progn
>     (declaim (ftype (cons integer ...) integer) foo)
>     (cl:defun foo (lyst x ...)
>       (declare (type cons lyst)
>                (type integer x))
>       ...))

Yes, picking your own syntax is fine up to a point, but other code may
have used the same syntax for a differnt purposes and you then run
into problems if you want to combine your code with such.


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

Quote:


> [ a _lot_ of ignorant {*filter*}deleted ]

>   in all my years on USENET, I have seen a lot of destructive idiots post
>   their favorite drivel in the guise of facts, and some even manage to look
>   like they have a clue, but I cannot recall anyone quite so destructive or
>   quite so willing to lie and misrepresent as Dobes Vandermeer of the aptly
>   named MINDLESS.COM.  _nothing_ he says is true or even relevant to what
>   Lisp can offer today or why this offer is not widely accepted.

>   Lisp does have a problem: it doesn't come with a big enough stick with
>   which to hit the ignorant {*filter*}s so they get out of their retarded state.

Fire it up.

CU
Dobes



Tue, 23 Oct 2001 03:00:00 GMT  
 Newbie questions [Followup to comp.lang.lisp]
Quote:

>>>> On the subject of "Re: Newbie questions [Followup to comp.lang.lisp]"
>>>> Sent on Fri, 07 May 1999 18:32:11 GMT


 >>
 >> I don't think we need a new standard for that.  The DEFMETHOD
 >> syntax: ``(parameter class)'' can be reused, so that the above
 >> example becomes:
 >>
 >>   (defun (foo integer) ((lyst cons) (x integer) ...)
 >>     ...)

what about optional arguments with default values?

--
Sam Steingold (http://www.goems.com/~sds) running RedHat6.0 GNU/Linux
Micros**t is not the answer.  Micros**t is a question, and the answer is Linux,
(http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation.
Trespassers will be shot.  Survivors will be prosecuted.



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

Quote:


> > LISP's object-oriented paradigm is powerful and yet... It's essentially
> > dynamic operator overloading, which is about as interesting to an object
> > modeller as a stack of bricks.  Although this is certainly only an
> > opinion and perhaps a trend, object orientation is centered on message
> > passing, while LISP's object orientation is based on function calls
> > (still).  I won't say its not USEFUL, but its not attractive, and its
> > not a step forward unless you are writing "toy" applications.

> Sorry, but this doesn't make much sense to me, I must be missing your
> point. Perhaps you should explain what you mean? CLOS generic
> functions offer everything that C++ virtual methods, Java methods,
> Eiffel features, etc. give you. What is it that makes generic
> functions less useful than their more primitive counterparts in most
> other OO languages?

CLOS provides a world view where we have extended functions to overload
based on the class of its operators.  The object abstraction of data and
methods has been lost; CLOS methods are not methods, but functions, and
CLOS does not protect encapsulated data from the "outside world" of
functions and methods.  

A "better" object world view would allow for only acessing fields in the
object directly inside of methods for the object, thus providing the
mystical "encapsulation" that is currently underpromoted in CLOS.  I
hesitate to say that CLOS does not allow you to think in this way, yet I
will assert that typical examples I have encountered make no effort to
do so.

The syntax, although it is often trivialized by many people, is also
fairly important.  In a LISP function call, all arguments are weighted
equally, and so you are led to think about specialising based on any or
all of the parameters.  And object-oriented version, i.e. "(send-msg-to
obj (do-something a b c d))" shows you which object is being operated
upon, and although you could (easily) still specialize on the remaining
variables (i.e. a b c and d) to call a different method, the
message-passing paradigm is preserved.

CU
Dobes



Tue, 23 Oct 2001 03:00:00 GMT  
 Reasons for rejecting Lisp (was Re: 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.


Tue, 23 Oct 2001 03:00:00 GMT  
 Reasons for rejecting Lisp (was Re: Newbie questions [Followup to comp.lang.lisp])

Quote:





> > > > Nothing in CL forbids you from type-declaring every variable.

> > > It might be nice to have some standard, succinct syntax for this.
> > > Maybe something like:

> > > (defun  foo\integer (lyst\cons x\integer ...)
> > >   ...)

> > I don't think we need a new standard for that.  The DEFMETHOD
> > syntax: ``(parameter class)'' can be reused, so that the above
> > example becomes:

> >   (defun (foo integer) ((lyst cons) (x integer) ...)
> >     ...)

> For this to be valid surely the standard would need to be modified?

I'm not sure this was meant to be a question, but if so, the answer is,
I think, "no".

(shadow 'defun)
(defmacro defun ... stuff involving cl:defun ...)

Making the syntax be (foo integer) is bad, though.
There is an issue a lot of people don't talk about but that many of
us old-timers know which is that Meta-. (definition lookup in Emacs/Zmacs)
really wants the cadr position of definition forms to be "names".
Unless you're planning to make dispatch dependent on the return value
(which you can really only do in a strongly typed language and which
I'd argue is conceptually ill-defined even then), then (foo integer)
is not the name.  A better syntax is
 (defun foo ((list cons) (x integer) ... &return integer) ...)

Btw, DEFSTRUCT violates the rule about the CADR being just a name
and causes lots of problems in text editors.



Tue, 23 Oct 2001 03:00:00 GMT  
 Reasons for rejecting Lisp (was Re: 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".
;-)

I agree. Quite a lot of Lisp implementations address this issue, some
in more turnkey ways than others.  That some implementations don't is
merely a commercial choice--if those implementations find a following,
their users presumably are able to cope without this.  At some point
maybe they'll add the feature too, or maybe they'll lose customers.
That's the way the market works.  The market is intentionally and
appropriately pluralistic.  Saying that some implementation doesn't
suit your need is just saying you should be shopping; saying no
implementation suits your need is just saying there's a market
opportunity waiting for you.



Tue, 23 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