order of argument evaluation in equal()

[fogh]

Is it safe to use this syntax
unless(x==(x=SomeNewValue()) info("we have a brand new x"))
This spares me the definition of an xOld variable but feels a bit risky.

 

[fogh]

Reb, Dave,

So, the order is guarantied left-to-right in macros unquotes and in the second to last arguments of let , prog and such places where one expects a chronology of side effects. Nowhere else ?

Too bad. I found this syntax to be rather intuitive. But Dave has a point that some people write the test like
constant == expression
even if I would be more inclined to write it
expression == constant


reb@cypress.com wrote:

fogh <cad_support@skipthisandunderscores.catena.nl> wrote in message news:<4177899f$0$30037$e4fe514c@dreader13.news.xs4all.nl>...

Is it safe to use this syntax
unless(x==(x=SomeNewValue()) info("we have a brand new x"))
This spares me the definition of an xOld variable but feels a bit risky.


(defmacro equalOrdered (first second)
`(apply 'equal (mapcar 'eval '(,first ,second))))

Another variety. Doing the eval's yourself to guarantee the order.
mapcar is useful for that. Sometimes (prog1 x x=...) is also useful
for returning a previous value for more operations on it. (When
writing such a macro, just like cpp macros in C, beware of triggering
evaluations of the arguments more than once, since as here they can
have side effects).

Still, unless(equalOrdered(x x=SomeNewValue())) ... is likely less
obvious to most folks than using the extra variable:

(let ((nextx SomeNewValue()))
(unless x == nextx
x = nextx
info(...)))

Some lisp's do document that arguments are evaluated left to right
(apparently not skill, though is there really any specific disclaimer
in the doc's not to rely on ordering?). Would be nice if list() at
least guaranteed (documented) left to right evaluation.

 

[David Cuthbert]

fogh wrote:

Is it safe to use this syntax
unless(x==(x=SomeNewValue()) info("we have a brand new x"))
This spares me the definition of an xOld variable but feels a bit risky.

Although it works (today), it is neither guaranteed to work nor is it
good style (IMHO).

The order of argument evaluation in SKILL (and most languages) is not
documented -- intentionally. Constraining the order of argument
evaluation reduces the ability to optimise the resulting code. SKILL
doesn't do anything like this today, but it could in the future.

The style is suspect because most people expect:
a == b
and
b == a
to mean the same thing.

Perhaps a defining and using a macro to detect changes would better
suffice? It certainly conveys the intent better:

(defmacro changedp (condition @rest body)
`(let ( (__prevalue ,condition) )
,@body
(nequal __prevalue ,condition)))

when(changedp(x x=SomeNewValue())
info("we have a brand new x"))

--
David Cuthbert (dacut@cadence.com) Tel: (412) 599-1820
Cadence Design Systems R&D

 

fogh <cad_support@skipthisandunderscores.catena.nl> wrote in message news:<4177899f$0$30037$e4fe514c@dreader13.news.xs4all.nl>...

Is it safe to use this syntax
unless(x==(x=SomeNewValue()) info("we have a brand new x"))
This spares me the definition of an xOld variable but feels a bit risky.

(defmacro equalOrdered (first second)
`(apply 'equal (mapcar 'eval '(,first ,second))))

Another variety. Doing the eval's yourself to guarantee the order.
mapcar is useful for that. Sometimes (prog1 x x=...) is also useful
for returning a previous value for more operations on it. (When
writing such a macro, just like cpp macros in C, beware of triggering
evaluations of the arguments more than once, since as here they can
have side effects).

Still, unless(equalOrdered(x x=SomeNewValue())) ... is likely less
obvious to most folks than using the extra variable:

(let ((nextx SomeNewValue()))
(unless x == nextx
x = nextx
info(...)))

Some lisp's do document that arguments are evaluated left to right
(apparently not skill, though is there really any specific disclaimer
in the doc's not to rely on ordering?). Would be nice if list() at
least guaranteed (documented) left to right evaluation.