[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Chicken-hackers] [PATCH 0/2] Fix #t being "not always-true"
From: |
Evan Hanson |
Subject: |
[Chicken-hackers] [PATCH 0/2] Fix #t being "not always-true" |
Date: |
Sun, 19 Apr 2015 15:03:04 +1200 |
Hi hackers,
This morning I tried to figure out why treating #t as `always-true` in
the scrutinizer breaks bootstrapping (after ddb2b63 and noted by Peter
in <address@hidden>), and it turns out it's
simply because we're (mis)using the "-local" flag when building the
system's compiler objects (so, compiler.c, batch-driver.c, etc.).
Basically, there are a handful of global variables that are redefined by
other units during normal use (mostly those in the compiler namespace
such as `first-analysis`, `emit-profile-info`, and so on). However, by
compiling the files in which they're defined (mostly compiler.scm) with
"-local" we're indicating that those variables won't change value
outside those files and giving the scrutinizer permission to drop
conditional branches based on those values being #t or #f.
So, this is the compiler doing what we tell it to -- it just seems to me
that what we're telling it to do is wrong. I see three ways to address
this:
1. We remove "-local" from $(CHICKEN_COMPILER_OPTIONS). This is the
simplest option, and the attached patch does just this.
2. We add type annotations for the variables in question, declaring
them to be booleans rather than simply true or false. This works in
practice and seems like a good idea to me, but it would also be a
much larger change and introducing type annotations to the core
probably deserves some discussion first.
3. We convert any variables that are meant to be redefined into
SRFI-39 parameters.
Thoughts?
Evan
0001-Don-t-use-local-for-bootstrap-compiler-objects.patch
Description: Text Data
0002-Don-t-consider-t-not-always-true.patch
Description: Text Data
signature.asc
Description: Digital signature
- [Chicken-hackers] [PATCH 0/2] Fix #t being "not always-true",
Evan Hanson <=