skill: strange symbolic assignment

[Camelot]

Hello,
I noticed that if I do this assignment:

x = ‘pPar(“x”)

the interpreter translate it in:

x => enter => (pPar “x”)

This cause me problem because this format is not correctly treated in
CDF parameter.
Is there a way to maintain the original assignment pPar(“x”) ?
I also noticed that the interpreter maintains the original assignment
if it recognize an existing function, that is:

x = ‘print(“x”)

x=> enter => printf(“x”)

So, it treat pPar as an unknown function…

Thank you for possible clarification

Regards,

Camelot

 

[Andrew Beckett]

Camelot wrote, on 01/26/11 06:48:

Hello,
I noticed that if I do this assignment:

x = ‘pPar(“x”)

the interpreter translate it in:

x => enter => (pPar “x”)

This cause me problem because this format is not correctly treated in
CDF parameter.
Is there a way to maintain the original assignment pPar(“x”) ?
I also noticed that the interpreter maintains the original assignment
if it recognize an existing function, that is:

x = ‘print(“x”)

x=> enter => printf(“x”)

So, it treat pPar as an unknown function…

Thank you for possible clarification

Regards,

Camelot

Camelot,

There is nothing wrong here. This is all to do with the two modes of the SKILL
parser - "infix" (which is the C-like syntax), and "non-infix" (which is the
LISP syntax).

What happens is that when any list is pretty-printed, it checks to see if it
appears to be a SKILL function name at the head of the list, and if so, it
displays it in C-like syntax by default. The parsing is always done the same
way. So for example:

x='pPar("x")
(pPar "x")
car(x)
pPar
cadr(x)
"x"
y='println("x")
println("x")
car
println
cadr
"x"

If you do:

sstatus(printinfix nil)

And then look at variable y, you'll see it now shows as:

(println "x")

So, put another way, the SKILL parser will always parse an expression into the
LISP functional form - but the pretty print will convert it back to C-like
syntax, provided that the printinfix flag is set to t (the default), and the
head of the list looks like a function. Since pPar() is not a SKILL function
(it's an AEL function), this isn't surprising behaviour.

Regards,

Andrew.

--
Andrew Beckett
Senior Solution Architect - Cadence Design Systems Ltd (UK)