Re: NIL is not of type CONS

On 19 dic, 04:05, Kent M Pitman <pit...@xxxxxxxxxxx> wrote:
If you make () and #f different, then you
have to have both (member? x y) and (member x y), or you have to write
(not (null (member x y))) when you want to coerce the latter to the
former. If you're someone who just thinks "it's good for people to do
this extra work", they probably have a job for you in the government
somewhere making forms for people to fill out. But one thing I like
about Lisp, and it goes hand in hand with dynamic typing, is the
general meta-principle of not having to write an excess amount of text
to get the effect you want. And I write things like
(do ((x something (cdr x)))
((not x))
...)
[in those cases where I use DO at all, which isn't a lot these days]
not because I don't know that x is a list and I should be writing NULL,
but rather because I happen to like thinking of a shrinking list as
receding into nothingness. And for nothing, I use NOT, not NULL.
I also happen not to like doing
(if (not (null x)) y z)
and generally I just write
(if x y z)
meaning "if x is something then y else z". Your preference in this
might differ, and that's ok; I don't assert mine is the only possible
preference. But I assert that mine is as valid as yours, and therefore
that while I understand you don't like this, I don't deny that you have
a valid point; I merely believe that I also have a valid point. And
so the language isn't incoherent for what it does, it's just not the
same language as you might have designed.

The choice of what to regard as true or false is not something that
logic can dictate. It is an arbitrary choice, and one that leads to
issues almost no matter what you do.

NIL is actually three things: a symbol, the empty list, and false.

I personally find it a minor nuisance that it's a symbol; I'd rather
not have the symbol space have a hole in it that way. It would work
for me if the empty list and false were the same, but neither was the
symbol NIL. But it wouldn't be compatible, and it's so easy to
overcome that it's hardly worth mentioning. Just shadowing NIL gets
you out of most of the problem.

Personally, I've never had a problem with, and have always been a
little annoyed with, the decision of Scheme to separate #f and ().
It's a fine experiment to have tried, and their community seems happy
with it, but I'm glad it wasn't our CL community that tried it. The
CL community is more "pluralistic" than the Scheme community, and I
think it would not have been successful for us.

Btw, I think what makes NIL as a symbol wrong is not the invading of the
symbol space, it's the choice of the string "NIL" as the base case.
It looks ok visually in simple examples but it's really pretty dumb.
I wouldn't have been bothered if || (the symbol that had no characters)
were a false value, nor probably even if it were _the_ false value.
It's a bit ugly to look at, but it could have had some other syntax, #f
or #n some such, to mark it better.

But I would not have thrust my preference on someone else by
suggesting the language should change incompatibly to suit my personal
whims or interests in experimentation. If I were going to experiment,
I'd get my own language where people could voluntarily join up if they
liked what I was doing. My problem with changing standards in general
is not that I'm anti-change, I'm anti-forced-change. The world is too
big and complicated and unsynchronized to work that way these days.

Your point of view is of course valid (and I am no one to judge it),
but this is rather extrange. I ear a lot of time that a language
should encourage good programming practices, to be clear, and, at the
same time, practical. I thought that CL was such a language when I
started up to learn it some years ago. But found some "paricularities"
I still dislike, some of them are, for example:
- funcall and apply, when the direct syntax of scheme seems to be
easier and more practical (yes, I know the implications of having
separete symbol tables for functions and variables, but still think
that the scheme aproach is better).
- dinamic scope (with defvar, etc), which is an easy way to introduce
bugs.
- the nil behavior
- the arbitrarity in the order and the way that some standard funtion
takes their parameter
- the way the variables types are declares, etc
- asdf

But Scheme lacks some of the features I like from CL, like CLOS, AMOP,
deftype, setf functions, a huge standard library, etc...

.

Relevant Pages

  • Re: seperation of function namespace
    ... Yes, but name clashes still happen and idiotic naming ... Because the way the English language graphemically conflates verbs and nouns ... PLT scheme and related publications). ...
    (comp.lang.lisp)
  • Dissecting the electorate
    ... Scheme needs *no* additional modularization ... would be quite a bit more painful to use than the language we ... Now, getting the module system *right* is not necessarily easy, ... from the core semantics and into the library - the C stdio libraries ...
    (comp.lang.scheme)
  • Re: Batch conversion of files
    ... tried writing those other languages in Scheme. ... one would want to do in GIMP is a procedural task. ... cleaner code that would have been written in another language more ... Let's take that simple batch mode script that caused all the fuss to ...
    (comp.graphics.apps.gimp)
  • Re: Ideas for an SICP?
    ... language at the same time. ... I don't believe it is impossible either, but I do believe the scheme ... If Clojure can solve these problems, ... For the purposes of the original topic of this thread, a new SICP ...
    (comp.lang.scheme)
  • Re: Scheme went one direction, Haskell went another: Why?
    ... these sorts of language features, ... Scheme, the current Haskell situation may be considered an anti-goal. ... a feature of the Glasgow Haskell Compiler ...
    (comp.lang.scheme)
Loading