Reasons for rejecting Lisp (was Re: Newbie questions [Followup to comp.lang.lisp]) 
Author Message
 Reasons for rejecting Lisp (was Re: Newbie questions [Followup to comp.lang.lisp])


| But there is precedance to the CADR being a list, namely DEFSTRUCT.

  don't forget (DEFUN (SETF ...) ...)

#:Erik



Wed, 24 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".

OK I didn't express myself clearly. I know that you can modify the
default definition of defun, but I meant for the above to be valid in
the absence of such modification.


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

| Being able to build an executable program which can run on different
| computers that don't have Lisp is not just a commercial concern.

  but if you want to run it on such computers, won't they _get_ a Lisp?

  please remember that C executable are _not_ standalone unless you go to a
  very serious effort and bloat your executables tremendously.  the whole
  idea with shared libraries is to capitalize on common parts of what was
  once in a number of executables, and it has made life seriously simpler
  for large libraries.  the idea is no different than what was once done on
  mainframes, with massive amounts of good stuff in the operating system so
  each program wouldn't need it.

  I regard the .fasl files as Lisp's "executables", and the fact that I
  might need to run them from inside a "real" Lisp executable that does
  what would otherwise be shared libraries is a meaningless quibble --
  people seem to accept having to run multiple programs to start their
  applications already.  if it really is such a big deal, making a .fasl
  file become an .exe file that did this on its own seems like such a
  no-brainer I really wonder why people think it's a show-stopper that
  others haven't done it for them.  (yes, I assume this is under Windows
  -- Unix people are used to so much weird shit being "executable", in
  practice whatever the system call execve(2) is happy with.)

#:Erik



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

| 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.

  this assumes that the issue in question is sufficiently important that
  the open market will be where the decisions are made.  I'm wary of the
  call for the market to decide issues that are generally irrelevant -- it
  would mean I had to choose from a million different products and would
  spend more time figuring out which irrelevant feature was supported by
  which miniscule vendor's product than it would take to build it on my own
  -- sort of like how the Microsoft third-party market works for people who
  cannot or legitimate refuse to program the incredible insanity Microsoft
  calls products.  to get to the point where the market can satisfy all
  sorts of small issues would mean such a huge demand for stupid things
  that _any_ small issue would get attention.  I don't want a world like
  that.  it's one of the many reasons I don't subscribe to the Microsoft
  world view and its model of competition between ump{*filter*} broken things
  that have to be so cheap to make because of the fierce competition they
  could not possibly be of any quality.

  neither competition nor the market are any better than the customers and
  their decisions.  I think the Jenny Jones case is relevant in this regard
  -- to pick randomly from the current news.  there's a _huge_ market for
  talk shows that drag people's personal life into the public despite the
  many bad consequences and the many good reasons not to air such shows.
  the people who ensure that this market exists are ultimately the viewers
  who buy the products that are advertised during those shows, which means
  that the shows exist because of business decisions of the advertisers.
  there are similar remote relationships between most products and their
  markets, and most of the interrelationships between market and marketing
  are amazingly unpalatable and even downright ugly, and the more mass
  market you get, the uglier it gets.

  I'm frankly not sure it's a good idea to call forth these forces without
  a very good grasp of the repercussions.  I prefer to work with the people
  who have already done some significant amount of good work over going off
  and do my own thing (create a new market), or choose somebody else.  only
  if my current vendor does something really stupid that I cannot live with
  will I feel like going elsewhere.  this obviously holds only for products
  whose acquisition carries a meaningful investment with them -- like
  learning to use them or the relationship with the developers.  should the
  acquisition be free of such investment, the cost of choosing something
  else will be low enough that the market will begin to work for small
  issues.  otherwise, it will work only for issues larger than the cost of
  changing product.  and do we really want a competition between products
  so similar that any small issue will be bigger than the cost of changing?

#:Erik



Wed, 24 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) ...)

What about the

 (defun foo (list x)
   (declare (type cons list)
            (type integer x)
            (values integer))
   <body>)

I have always wondered why this is not an accepted solution (modulo
syntax of course). I sort of understand that having simply VALUES as a
'declaration identifier' (3.3.3 ANSI CL) may cause some problems at
the DECLAIM/PROCLAIM level (it wouldn't be clear what the declaration
would apply to), but the idea seems correct.  CMUCL has an
implementation of this scheme.

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

Well, also the

        (defmethod zut :after ((....

wrecks havoc in cl-indent in Emacs.

Cheers

--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa



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

Quote:
> I believe I remember seeing someone use an infix syntax package (in
> this group?) and it looked something like #I(2 + foo * pi ...).

Yes; the package INFIX written by Mark Kantrowitz supports the obvious
infix notation, as well as a bunch of extensions.  For instance:

Quote:
> '#I( x^^2 + y^^2 )

(+ (EXPT X 2) (EXPT Y 2))

Quote:
> '#I(if x<y<=z then f(x)=x^^2+y^^2 else f(x)=x^^2-y^^2)

(IF (AND (< X Y) (<= Y Z))
    (SETF (F X) (+ (EXPT X 2) (EXPT Y 2)))
    (SETF (F X) (- (EXPT X 2) (EXPT Y 2))))

Unfortunately, the license for use is apparently non-commercial:

;;; Copyright (c) 1993 by Mark Kantrowitz. All rights reserved.
;;;
;;; Use and copying of this software and preparation of derivative works
;;; based upon this software are permitted, so long as the following
;;; conditions are met:
;;;      o no fees or compensation are charged for use, copies,
;;;        distribution or access to this software
;;;      o this copyright notice is included intact.
;;; This software is made available AS IS, and no warranty is made about
;;; the software or its performance.
[... warranty disclaimer ...]



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

Quote:

>   But there is precedance to the CADR being a list, namely DEFSTRUCT.

DEFSTRUCT is always an editing disaster IMO when it is a list, not because
it's a list but because the list is not the name.

Quote:
> (Didn't one of the New/Old Flavors also have the CADR to defmethod being a
> list at times?

I haven't said anything about the problem being that it is a list.
Indeed flavors did have (defmethod (frob foo) ...) and
(defmethod (frob foo :after) ...)
but that was *better* than what we have now becuase the name was the
whole list.  It's actually more confusing now where the name is spliced
into the top level of the defmethod.  But at least with the present
defmethod, foo is also arguably a name.

Quote:
> Seems like I remember it having somethingto do with specifying
> before or after methods. Gnuemacs didn't like them either but a
> simple hack to ctags fixed that.)

But at least it was a general-purpose hack to the notion of names that
allows the cadr to be the name, even if it takes list syntax to jump over
it and find the other end.  (There is some problematic part if whitespace
has multiple spaces or tabs, and they have to be canonicalized by editors
that use textual representations, but that can also be dealt with.) My
point is that the same single fix makes it work for (defun (setf foo) ...)
where (setf foo) is in the cadr and is the name.

This is all just a personal opinion, mind you, not a law.  But it's a
personal opinion I know others hold as well and I have not seen
written down anywhere in recent times, though we all talked about it
long ago.  It is not something you can't violate--it's just something
I personally recommend you don't and I won't vote in favor of when it
comes to that in committees.

(I'd like to see old-style DEFSTRUCT syntax flushed, but I won't vote
to flush it without first deprecating it and providing a long
transition period.  But in the creation of new operators, where there
is no compatibility issue involved, I'll push for things that make
life simpler, not because it's impossible to do the other way but
because it introduces needless and avoidable pain to do it the other
way.  As such, this particular piece of simplicity is one I think is
important and worth pushing for where possible.)



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

Quote:

> Well, also the

>    (defmethod zut :after ((....

> wrecks havoc in cl-indent in Emacs.

> Cheers

They seem to have gotten a fix for this in xemacs. I was *quite* pleased
:-) (Though I wonder if it will deal with arbitrary method combinations
correctly...)

Sunil



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

Quote:

> OK I didn't express myself clearly. I know that you can modify the
> default definition of defun, but I meant for the above to be valid in
> the absence of such modification.

Maybe I didn't express myself well either.  Just about nothing you can do
in the language is valid in the absence of accomodation by other programs.
You can't do (defun foo ...) without assuring you are in a namespace that
doesn't have FOO already there.  Saying that (defun foo ...) is valid always
assumes you have done this check.  Sometimes you "implement" this by
saying (shadow 'foo) and sometimes by (in-package "SOMETHING-ELSE") and
sometimes by (fmakunbound 'foo) but always you do something, even if
the something is the null thing because nothing is required.  

Even to bind a variable as in (let ((x 3)) ...) is invalid if the "..."
needs to access an outer x.   But we don't say you can't access both
x's at once without a change to the language, we just write
 (let ((x 2))
   (flet ((outer-x () x))
     (let ((x 3))
       (+ x (outer-x)))))
and suddenly we are on our way again without a need to involve the
language design committee.

You didn't merely say "for this to be valid you'd have to add a call
to shadow" you made the following claim (quoting whole paragraph):

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

Had you not made your statement this strong, I would not have bothered
to reply at all.

I just want to make it very clear that the language is a lot more
accomodating than that, and as a rule, I doubt there's much of anything
for which the above statement is true, in the sense that the language
permits you to build whole new languages inside it (unlike many other
languages).  And I get frustrated when people push back on the language to
solve problems they could solve themselves, especially when the "solution"
is about 1-line long.



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

Quote:

> What about the

>  (defun foo (list x)
>    (declare (type cons list)
>             (type integer x)
>             (values integer))
>    <body>)

> I have always wondered why this is not an accepted solution (modulo
> syntax of course). I sort of understand that having simply VALUES as a
> 'declaration identifier' (3.3.3 ANSI CL) may cause some problems at
> the DECLAIM/PROCLAIM level (it wouldn't be clear what the declaration
> would apply to), but the idea seems correct.  CMUCL has an
> implementation of this scheme.

So does Genera.  It's not valid CL, because you're not naming what you're
declaring.  VALUES is intended for use in FTYPE declarations and in
THE expressions.  But it was commonplace in Genera to see both this and
ARGLIST declarations, which were both very handy for Control-Shift-A,
the thing that tells you the args and values of a function.

 (defun my-open (frob &rest open-args)
   (declare (arglist frob &key element-type direction)
            (values stream))
   (apply #'open (frob->filename frob) open-args))

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

> Well, also the
>    (defmethod zut :after ((....
> wrecks havoc in cl-indent in Emacs.

I don't like this defmethod syntax, but I don't think it would be a problem
for cl-indent if they implemented indent the way I implemented it in Teco.
They ported a lot of my and others' Teco libraries to gnu-emacs when they
brought it up, but they left behind a lot of features.  The Teco-based
indenter assumed anything starting with (def... ) should do body-indent
on the first line after the (def...) that was not a continuation line of
a subform that started on the first line.  [There were ways to override
this if you had definitions that didn't match the default, but this was
not a problem. def expressions vary widely in the number of forms they
have, and having a rule like "body starts at 2nd or 3rd form" is a bad one.
The right DEFAULT rule is "definitions have junk on the first line and
body on the rest of the lines".  Incidentally, this rule even accomodates
defstruct in its full-blown form.

I think I might have the code somewhere to the old teco-based indenter.
Maybe sometime for grins I'll publish it.  Teco was a wonder to behold.



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

Quote:

> On Fri, 7 May 1999 23:01:39 GMT, Kent M Pitman

> >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".

> Being able to build an executable program which can run
> on different computers that don't have Lisp is not just a
> commercial concern.  Even if you just want to write
> educational software for your kids, you want them to be
> able to run it on their own computer.  The reason why most
> people never even bother to learn Lisp is because they
> perceive it as being an elephant when they want a tiger.
> Having to pay $3000 to be able to build simple executable
> programs is part of that perception.

This supposes that you have to pay $3000 to build a simple executable.
You do not.  This is WILDLY far off the mark and grossly misleading to
suggest as a straw man. I can think of almost no commercial
implementations full of goodies that cost this much.  Most
high-quality commercial implementations have at least one offering in
the $500-600 range, and those implementations usually have an
accompanying free version [in which you cannot dump images not because
it wouldn't be fun but becuase they NEED the revenue to be able to
continue supplying cheapskates (not saying that's you, but I believe
they're out there) with free implementations becuase they never want
to ever pay a dime in support of whowever brought them
happiness/success].  Vendors have to feed themselves.  But there are
numerous smaller/freer lisps out there, probably most of which have
the capability you ask for and don't cost a dime.  If you really think
that it costs $3000 to build a simple executable, I suggest the
possibility that you have not done your homework before speaking.  And
if you don't think it does, I SUGGEST YOU CONSIDER THE POSSIBILITY
THAT EXTREME STATEMENTS LIKE THE ONE YOU MADE ABOVE ARE AS MUCH OR
MORE THE CAUSE OF A PERPETUATED BELIEF THAT LISP IS TOO EXPENSIVE FOR
PERSONAL USE THAN THE ACTUAL FACT OF THE MATTER.

It does cost more to make a commercial redistributable app, and I think
there are some real issues there. But you have specifically said that
is not your issue.  And I just don't think that in the space of "for
personal use" Lisps, your criticism is even remotely fair.

People can, with their kids, teach them to click on the "lisp" icon
and then teach them to type (load "...").  That's all that's needed.
If that is not a fair exchange for a free implementation, I have to
say your public awaits your contribution of something better.  If kids
don't have the attention span required to do a two-step loadup instead
of a one-step loadup, they are not candidates to ever be lisp
programmers.  I daresay the path to being a serious programmer
involves more than just a few such steps, and anyone not willing to
take them might as well start lining up right now for a job in another
industry with fewer steps leading to it rather than diving in on the
mistaken assumption that everything will be handed to them on a silver
platter for free with no burden that they do even the slightest thing.
Geez, even getting my linux to run at my house (and it wasn't wholly
free-there was a substantial media cost) took me a billion (ok, only
probably a hundred) recompiles of the kernel (which I should remember
to go delete sometime :-).  Was THAT a barrier to linux success?
I just don't think so.



Wed, 24 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