Re: Beyond CL?

Pascal Costanza wrote:
> Tron3k wrote:
> > I find the attitude that it is wrong to suggest improvements for Common
> > Lisp short-sighted and pathetic.
>
> Check out the HyperSpec. There are a number of issues listed that were
> discussed during the standardization of Common Lisp - see
> http://www.lispworks.com/documentation/HyperSpec/Front/X3J13Iss.htm
>
> Apparently, each issue had to follow a certain structure, containing
> details about things like: problem description, rationale, current
> practice, cost to implementors, cost to users, cost of non-adoption.
>
> A _good_ suggestion for improvement should cover such aspects in order
> to have some convincing power. Stuff like "switch from Lisp-n to Lisp-1"
> would have to objectively mention all the drawbacks of such a change.
> See for example the excellent discussion at
> http://www.nhplace.com/kent/Papers/Technical-Issues.html

Ah, I see your point here. In other words, my ideas are pretty
well-known and obvious, but they don't consider the practical problems.
I'll grant you that. Thankfully I am free of worrying about backwards
compatibility since I'm making my own Lisp. :-)

> Another example is the switch from converting identifiers to all upper
> case by default (as in ANSI Common Lisp) vs. keeping case (as in Allegro
> Common Lisp "modern" mode and as proposed for R6RS Scheme). There was
> recently a discussion at comp.lang.scheme about this issue, and in a
> chat at ILC'05, Steve Haflich explained Franz's reasons for the modern
> mode. Essentially, keeping case avoids all kinds of problems with
> characters that don't have unambiguous mappings between lower case and
> upper case, and since the whole world has decided to adopt Unicode, a
> switch to case sensitivity would solve a whole bunch of problems at
> once. I think that could be an actual improvement, but the more
> important point here is that the reasons are stronger than just "I would
> prefer it like that".

I decided a while ago my Lisp will be case-sensitive. It will be
created with Win32 game development in mind, and I don't want people
calling Win32 or OpenGL functions in all small case, that's just hard
to read.

> So essentially, if your arguments for or against a change are not
> convincing enough, it all just boils down to a matter of taste. And
> then, under those circumstances, it is really important to realize that
> there is no need at all to force others to agree to your personal
> aesthetical preferences. Contrary to other language, Lisp is flexible
> enough such that you can just build your own world in which things are
> just exactly like you want them to be. So why bother trying to inflict
> costs upon others that they don't want to bear?

Let's say I've given up on trying to change the Common Lisp standard,
heh. So I won't be forcing anything on anybody.

I'm wondering about 'taste' ... are some 'tastes' universal? For
example, I think everyone could agree on which one is nicer-looking:

(defun dec-list (lst)
(mapcar #'1- lst))

(def (dec-list lst)
(map 1- lst))

But then again, not being able to use 'list' as a variable name could
certainly leave a bad 'taste' in some people's mouths. (I guess I'm
different in that I purposely try not to give my variable names the
same names as functions even in Common Lisp, because it gets a bit
confusing.)

> For example, some time ago I have implemented a with-funcalls macro that
> allows you to embed a Lisp-1 programming style within Common Lisp. See
> http://groups-beta.google.com/group/comp.lang.lisp/msg/8fce6ead716e6501
>
> So if you prefer that programming style, there's noone stopping you from
> just using it.

That's very cool! I think it's a given that in general, just about
anything in possible in Common Lisp. In the absolute limit, you could
write your own reader and your own code-walker to transform any
language into Common Lisp.

> It seems to me that people have just been trained too much in not being
> able to change the language and therefore expecting features to be added
> by vendors (because they're the only ones that can actually do it).
> These restrictions simply don't exist in Lisp. So go ahead, just do what
> you want! ;)

Heh, one of the features in my new language is complicated to implement
in Common Lisp. I might need to write a whole new reader in order to do
it. Yes, I can do whatever I want, but it's kind of like saying you can
do whatever you want in C if you write a compiler that takes your new
language to C. ;)

.

Relevant Pages

  • Re: Oft-shared (perhaps?) Impressions of a Lisp Newbie
    ... by what I have heard about that language. ... as with Lisp and Java, ... That's Emacs-lisp, not Common Lisp, major differences, even ... If you like Emacs as ...
    (comp.lang.lisp)
  • Re: An Acceptable Lisp
    ... improvements that could be made to Common Lisp, ... By universal [Lisp] I mean the one, which will be accepted by all the ... Surely, I don't know, if such a language is at all possible, and, even ... Speaking about high-level, I know, that I've made an undersupported ...
    (comp.lang.lisp)
  • Re: A "killer" macro
    ... Or perhaps Lisp doesn't have one thing ultra- ... But it's true because of macros. ... indistinguishable from native Lisp - extend the language itself. ... it is because Common Lisp has extensibility at many points built in. ...
    (comp.lang.lisp)
  • Re: LISPPA
    ... >> do in Common Lisp with code that runs about as fast. ... Fortran or C or some such language. ... modern Pascal programming because I haven't written any Pascal ...
    (comp.lang.lisp)
  • Re: Im such a genius - either that, or...
    ... >> You might not like Lisp, then, since it's an imperative language. ... (defun rev (lst res) ... int square ...
    (comp.lang.lisp)