Re: RFC: Increment and Decrement (was Re: GDL Notice: ArithmeticOperators / Quasi-Formulae)

[Eric McDonald <mcdonald at phy dot cmich dot edu>]

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