This is the mail archive of the
xconq7@sources.redhat.com
mailing list for the Xconq project.
Re: RFC: Increment and Decrement (was Re: GDL Notice: ArithmeticOperators / Quasi-Formulae)
On Tue, 2004-06-22 at 08:50, Jim Kingdon wrote:
> > So, I guess the choices for increment and decrement are:
> > (++ n) (-- n)
> > (inc n) (dec n)
> > (1+ n) (1- n)
>
> I'd say "1+" and "1-". Dice specs contain a "d", so they don't look
> all *that* confusable to me.
I will add "1+" and "1-" at a later point. They need to be defined as
new operators, and it seems that they might work a bit differently than
the basic four.
With "+", the lengths of the list operands must be the same:
(+ 1 (2 3) (4 5))
But, it would seem reasonable that this constraint need not apply with
"1+" and "1-":
(1+ (1 2 3) (4 5))
since each operand is operated on independently of the others. The
current structure of 'eval_arithmetic_expression' does not allow this
behavior to be easily integrated; I would have to write a new logic
branch in the function to deal with this.
For the time being, I will leave the increment and decrement
functionality out.
I did address Juergen's suggestion about reflection and negation:
(+ 5)
now evaluates to 5, and
(- 5)
now evaluates to -5.
I also added the seemingly useless feature of "+" returning the additive
identity (0) and "*" returning the multiplicative identity (1), to
comply with Common Lisp.
As far as the dice spec argument goes, I admit that is was lame. I was
in a hurry to get out the door this morning when I wrote it. The real
reason for my reluctance with that notation is because I didn't want to
hack the "el cheapo" Lisp reader (as it is referred to in the comments
introducing it) again, if I didn't have to. As it turns out, my concern
was somewhat justified, after I made the horrific discovery this evening
that I had broken negative number tokenization a few days ago. I have
now fixed this, _but it shows that even the simplest hacks can produce
big bugs.
Eric