unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: David Kastrup <dak@gnu.org>
Cc: miles@gnu.org, snogglethorpe@gmail.com,
	Stefan Monnier <monnier@iro.umontreal.ca>,
	emacs-devel@gnu.org
Subject: Re: byte-opt.el addition - optimize list of compile-time constants
Date: Thu, 09 Dec 2004 10:20:18 +0100	[thread overview]
Message-ID: <x53byfygj1.fsf@lola.goethe.zz> (raw)
In-Reply-To: <87mzwoozgf.fsf@codesourcery.com> (Zack Weinberg's message of "Wed, 08 Dec 2004 20:41:36 -0800")

Zack Weinberg <zack@codesourcery.com> writes:

> Miles Bader <snogglethorpe@gmail.com> writes:
>
>>> >> I thought the whole point of (function ...) was to assert that the
>>> >> lambda expression it contains *will* be used by execution.
>>> >
>>> > Yes, but that only applies if it occurs in an evaluable context.
>>> > Anyplace else, all bets are off.
>>> 
>>> That strikes me as just plain silly.  What's the point of a hint if it
>>> doesn't always mean what it means?
>>
>> If there's a random arbitrary list constant in some code, how on
>> earth is the compiler supposed to tell what the intended meaning of
>> sub-components of the list are?!?
>
> By reference to the language definition.  That's really what we're
> quibbling about here - I'm saying the language should be defined
> such that (function (lambda ...)) should indicate a function
> constant even if arbitrarily nested within a (quote ...) form,
> you're saying it shouldn't.

Of course it shouldn't.  The purpose of quote is not to execute.
`function', when _executed_, creates a quoted function object, just
like `quote', when _executed_, creates a quoted data object.

If you write '(woozle '(woozle)), the inner `quote' gets retained and
does nothing, like I would expect from an inner `function'.

> In evidence for my position I would like to point out that it is
> silly for '(1 2 3 #'(lambda ...) 4 5 6) to mean something different
> than (list 1 2 3 #'(lambda ...) 4 5 6),

Says who?

> and the byte compiler compiles the embedded lambda in the second
> case, so logically it ought to in the first case as well.
>
> Also, in Common Lisp the situation is clearly that the compiler _is_
> entitled to compile (function ...) wherever it finds it

This would surprise me.

bash-3.00$ gcl
GCL (GNU Common Lisp)  Version(2.5.0) Wed Oct  9 10:33:12 CEST 2002
Licensed under GNU Library General Public License
Contains Enhancements by W. Schelter

>(setq zap '(1 2 3 (function (lambda (x) x))))

(1 2 3 #'(LAMBDA (X) X))

>(setq zap (list 1 2 3 (function (lambda (x) x))))

(1 2 3 (LAMBDA-CLOSURE () () () (X) X))


-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

  parent reply	other threads:[~2004-12-09  9:20 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-08  9:21 byte-opt.el addition - optimize list of compile-time constants Zack Weinberg
2004-12-08 16:56 ` Stefan Monnier
2004-12-08 18:59   ` Zack Weinberg
2004-12-08 19:27     ` Stefan Monnier
2004-12-08 19:45       ` Zack Weinberg
2004-12-08 19:56         ` Stefan Monnier
2004-12-08 20:14           ` Nick Roberts
2004-12-08 22:47       ` Zack Weinberg
2004-12-08 23:40         ` Stefan Monnier
2004-12-09  1:20           ` Zack Weinberg
2004-12-09  2:11             ` Stefan Monnier
2004-12-09  2:33               ` Zack Weinberg
2004-12-09  2:46                 ` Miles Bader
2004-12-09  3:08                   ` Zack Weinberg
2004-12-09  3:28                     ` Miles Bader
2004-12-09  3:48                       ` Zack Weinberg
2004-12-09  4:04                         ` Miles Bader
2004-12-09  4:41                           ` Zack Weinberg
2004-12-09  4:52                             ` Stefan Monnier
2004-12-09  5:33                               ` Zack Weinberg
2004-12-09  5:39                                 ` Miles Bader
2004-12-09  6:49                                   ` Zack Weinberg
2004-12-09 15:22                                     ` Thien-Thi Nguyen
2004-12-10  5:50                                       ` Richard Stallman
2004-12-09  9:22                                 ` David Kastrup
2004-12-09  4:54                             ` Miles Bader
2004-12-09  9:20                             ` David Kastrup [this message]
2004-12-09  4:35                 ` Stefan Monnier
2004-12-09  4:55                   ` Zack Weinberg
2004-12-09  5:13                     ` Stefan Monnier
2004-12-09  9:10           ` David Kastrup
2004-12-08 19:33     ` Paul Pogonyshev
2004-12-09 10:34       ` Andreas Schwab

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=x53byfygj1.fsf@lola.goethe.zz \
    --to=dak@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=miles@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=snogglethorpe@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).