skill: strange symbolic assignment

Wed Jan 26, 2011 8:48 am   

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

Tue Feb 22, 2011 1:58 pm   

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

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:



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)