[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] %define boolean variables
From: |
Joel E. Denny |
Subject: |
Re: [PATCH] %define boolean variables |
Date: |
Mon, 29 Jan 2007 16:05:05 -0500 (EST) |
On Mon, 29 Jan 2007, Paolo Bonzini wrote:
> > As a compromise, if you keep the current behavior of empty being true, and
> > `%define FOO' aliasing `%define FOO ""', it's ok for me to complain on
> > anything but empty/"true"/"false", including making "0" or "1" invalid.
>
> Here's my concrete proposal.
Thanks.
> [m4_fatal([invalid %define variable passed to
> b4_percent_define_flag_if: ]$1)])])
Shouldn't skeleton authors also benefit from translation? That is,
shouldn't this be b4_fatal? Just a thought.
> # b4_public_if(TRUE, FALSE)
> # -------------------------
> -b4_percent_define_default([public], 0)
> +b4_percent_define_default([public], [false])
> m4_define([b4_public_if],
> [b4_percent_define_flag_if([public], [$1], [$2])])
[public] and [false] are underquoted. Imagine if a skeleton author
m4_define's public or false for some reason. Maybe they shouldn't, but we
should be robust, I think.
> # b4_single_class_if(TRUE, FALSE)
> # -------------------------------
> -b4_percent_define_default([single_class], 0)
> +b4_percent_define_default([single_class], [false])
> m4_define([b4_single_class_if],
> [b4_percent_define_flag_if([single_class], [$1], [$2])])
Likewise.
> Index: doc/bison.texinfo
> ===================================================================
> RCS file: /sources/bison/bison/doc/bison.texinfo,v
> retrieving revision 1.225
> diff -u -r1.225 bison.texinfo
> --- doc/bison.texinfo 29 Jan 2007 10:54:42 -0000 1.225
> +++ doc/bison.texinfo 29 Jan 2007 12:15:59 -0000
> @@ -4696,10 +4696,10 @@
> Define a variable to adjust Bison's behavior.
> The list of available variables and their meanings depends on the selected
"variables" should probably be "DEFINE-VARIABLEs" especially since the
remaining text now does that. My mistake. Would you fix this for me
since you're already working on this?
Actually, isn't "DEFINE-VARIABLE" a little redundant here? Maybe just
"VARIABLE"? Just a thought, but I don't care much.
More importantly, we need quotes in the synopsis here. So, I'm
thinking:
%define VARIABLE
%define VARIABLE "VALUE"
> -The @var{value} can be omitted for boolean variables; for
> -boolean variables, the skeletons will treat a @var{value} of @samp{0}
> -or @samp{false} as the boolean variable being false, and anything else
> -as true.
> +Some @var{define-variable}s may be used as boolean values: in this case,
> +the skeleton will conventionally treat a @var{value} of @samp{false}
> +as the boolean variable being false; a value of @samp{true}, or @var{value}
`a value of' --> `a @var{value} of'
> +%define public "maybe"
:-)
Re: %define boolean variables, Paolo Bonzini, 2007/01/29