unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Dirk Herrmann <dirk@sallust.ida.ing.tu-bs.de>
Cc: guile-devel@gnu.org
Subject: Re: memoization and conditional defines
Date: Sat, 9 Nov 2002 09:19:09 +0100 (CET)	[thread overview]
Message-ID: <Pine.GSO.4.05.10211090801080.22059-100000@sallust.ida.ing.tu-bs.de> (raw)
In-Reply-To: <0211072024311M.07034@locke.free-expression.org>

On Thu, 7 Nov 2002, Lynn Winebarger wrote:

> On Thursday 07 November 2002 19:46, Bruce Korb wrote:
> > 
> > It will be a bit of a nuisance when the (if <test> (define <foo> <bar>))
> > stuff chokes, but I would expect a sensible error message that will
> > lead me to wrapping that stuff in an eval once its encountered, yes?
> 
>      Depends on how it's implemented.  It doesn't have to be an error
> per se, but the _binding_ (as opposed to the side-effecting) of the
> variable would happen before the test was evaluated.  That's probably 
> _not_ the behaviour you'd expect from that construct.  
>      If it's made an error, I don't know what the actual error message 
> would be.  There are only a few types of places defines are really
> legitimate:  at the top level, at the head of a body, inside a begin
> clause in any other legitimate location (recursively) - but only
> before non-defines in a body occurence (following macro expansion).

If we are going to disallow defininitions except when on the real top
level, then it is easy to issue an error message when something like
  (if <test> (define <foo> <bar>))
is encountered.  Guile could, for example, issue an error message like
  "bad define placement"
or even
  "bad define placement.  Read guile's documentation about definitions to
understand why this is not allowed."
or something similar.  I hope this would be good enough for Bruce's
purposes.

Best regards,
Dirk Herrmann



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel


  reply	other threads:[~2002-11-09  8:19 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-11-07 17:52 memoization and conditional defines Dirk Herrmann
2002-11-07 19:08 ` Bruce Korb
2002-11-07 20:54   ` Clinton Ebadi
2002-11-07 23:22   ` Lynn Winebarger
2002-11-08  0:46     ` Bruce Korb
2002-11-08  1:24       ` Lynn Winebarger
2002-11-09  8:19         ` Dirk Herrmann [this message]
2002-11-09 22:39           ` Bruce Korb
2002-11-08  3:11 ` Rob Browning
2002-11-09  9:00   ` Dirk Herrmann
2002-11-09  9:41     ` tomas
2002-11-09 17:08     ` Rob Browning
2002-11-17 20:41 ` Marius Vollmer
2002-11-17 21:42   ` Bruce Korb

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/guile/

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

  git send-email \
    --in-reply-to=Pine.GSO.4.05.10211090801080.22059-100000@sallust.ida.ing.tu-bs.de \
    --to=dirk@sallust.ida.ing.tu-bs.de \
    --cc=guile-devel@gnu.org \
    /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.
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).