[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Save `nil' from the mutant void, preserve the truth of falsehood, pr

From: Stefan Monnier
Subject: Re: Save `nil' from the mutant void, preserve the truth of falsehood, prevent the falsehood of truth
Date: Tue, 14 Sep 2010 13:14:51 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

>> In source code, they are.
> No doubt this is true for "top-level" shared/circular structure.
> But what of lisp source code that evaluates to the non-preferred format?

If it's the result of some evaluation, then it's not source code any more.

>>> Indeed, they are quite prevalent in byte-code files and the language
>>> would be hamstrung without them.
>> Which language?
> The one comprised of s-expressions Printed for Read to Evaluate ad nauseam.

sexpressions are just a syntax for data.  For code you need an
additional layer of syntax which decides which s-expression mean what.

I.e. Elisp is not just "any S-expression" but a particular subset.

>> Note that AFAIC .el and .elc files use 2 different languages.
> Is there a know non-lisp interpreter for the non-lisp one?

There is "Lisp interpreter for the byte-code", just like there is no
Lisp interpreter for assembly code.  A Lisp interpreter interprets Lisp,
by definition.  And byte-code is not Lisp, even if it was designed
specifically as the output of a byte-compiler whose input is Lisp.

>>> No, the argument to `unintern' can be a symbol or string.
>> Who cares, it's still not a boolean.
> So would you agree then that where `fboundp' shouldn't take a boolean neither
> should `unitern'?

I'm not sure what you mean.  Among other things it's very unclear what
you mean by "shouldn't" and by "take a boolean".

>>>> - calling unintern without an obarray arg is a bad idea.
>>> Yeah,
> This elision conveniently ignores my caveats w/re the current use value of
> Emacs "other" obarrays...

I've just installed a change in emacs-23 which makes the obarray arg
mandatory (well, old uses still work, but the byte-compiler will
complain about them).

>> So: why do you do it?
> Why do i do what, unintern? To unintern a symbol of course :P
> More specifically, redefining button-types and faces are good uses.

If you need to unintern them to do that, it's a bug.

>>> Yeah, but again there is the weird corner case of interning the 0
>>> length string.
>> What's weird about it?

> Whats not?

> (identity (intern ""))
> ;=>

> (put (identity (intern-soft ""))
>      (identity (intern-soft ""))
>      (identity (intern-soft "")))
> ;=>

> (get (identity (intern-soft ""))
>      (identity (intern-soft "")))
> ;=>

> (setq 0len (symbol-plist (identity (intern-soft ""))))
> ;=> ( )

> (symbol-value '0len)
> => ( )

> (car (symbol-value '0len))
> =>

> More specifically, what is the utility?

None of this seems weird at all.  The only problem I see is that we
don't have a valid printed (and readable) representation for it.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]