From: Dirk Herrmann <dirk@dirk-herrmanns-seiten.de>
Cc: guile-devel@gnu.org, Marius Vollmer <mvo@zagadka.de>
Subject: Re: typechecking
Date: Sun, 30 May 2004 10:40:09 +0200 [thread overview]
Message-ID: <40B99DE9.8010005@dirk-herrmanns-seiten.de> (raw)
In-Reply-To: <16564.54949.13882.819772@localhost.localdomain>
Han-Wen Nienhuys wrote:
>dirk@dirk-herrmanns-seiten.de writes:
>
>
>>Code like the following:
>>
>>void f (SCM obj)
>>{
>> if (obj) {
>> /* do something */
>> }
>>}
>>
>>is almost always wrong, since what the user typically wants to check is,
>>whether obj is SCM_BOOL_F or not:
>>
>>
>
>It would be interesting to see if we could map the Scheme semantics
>(true = !SCM_BOOL_F) to C. That would require mapping SCM_BOOL_F to
>(void*)0x0. Is this desirable, and does anyone see a possibility for this?
>
SCM values, where the 3 least significant bits are zero indicate
non-immediates. That is, the SCM value can without any modification be
used as a pointer to a scm_t_cell object on the heap. This works, since
scm_t_cell has at least 8 bytes and thus the heap is constructed such
that all scm_t_cell objects are placed on an address that is a multiple
of 8.
SCM_BOOL_F on the contrary is an immediate value. To make SCM_BOOL_F ==
0x00 would require either to introduce it as a special case and leave
otherwise the definitions of non-immediates the same, or to change the
type system such that non-immediates are characterised differently. Both
solutions, however, would require to perform some operation on every
access to the heap. On the contrary, they would make all comparisons
against SCM_BOOL_F very simple and also help to avoid some errors.
The effects of such a change are difficult to predict. It may be that it
is not too much effort to try it out (at least the special case
solution), if everywhere the correct access macros are used (SCM_IMP,
SCM_FALSEP, ...). Then, for a try you would only have to change those.
Best regards
Dirk
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
next prev parent reply other threads:[~2004-05-30 8:40 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-28 13:04 typechecking Han-Wen Nienhuys
2004-05-10 21:34 ` typechecking Marius Vollmer
2004-05-10 21:47 ` typechecking Dale P. Smith
2004-06-10 16:16 ` typechecking Marius Vollmer
2004-05-10 22:57 ` typechecking Han-Wen Nienhuys
2004-05-15 9:16 ` typechecking Dirk Herrmann
2004-05-16 15:11 ` typechecking Han-Wen Nienhuys
2004-05-17 18:31 ` typechecking Marius Vollmer
2004-05-26 17:40 ` typechecking Han-Wen Nienhuys
2004-05-30 8:40 ` Dirk Herrmann [this message]
2004-05-30 8:28 ` typechecking Han-Wen Nienhuys
2004-05-31 7:05 ` typechecking Dirk Herrmann
2004-06-10 16:22 ` typechecking Marius Vollmer
2004-05-30 14:00 ` typechecking Andy Wingo
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=40B99DE9.8010005@dirk-herrmanns-seiten.de \
--to=dirk@dirk-herrmanns-seiten.de \
--cc=guile-devel@gnu.org \
--cc=mvo@zagadka.de \
/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).