Is there a function for mathematics constant PI?

richardyuan said:

You're right. No class is instantiated when use defMathConstants. But it behaves like a instance of a class.

Well, sure, in the sense that it has named fields you can read/write using the dot operator....  But it has no parent class, so no generic function specializers, no reader/writer slot definitions, etc.  So you could just as well say, "it behaves like an instances of a defstruct".

Just feel not quite comfortable.

Maybe a little fussy, hah...

I feel the same, though it's because I'm a functional programmer. :)  It's very odd to have a built-in that stuffs properties on a symbol's property list, even if it lets you specify which symbol.  I'd prefer a stateless interface:

getMathConstant('pi) => 3.14159.....

Or (returning a DPL):

getMathConstants().pi => 3.14159....

I'm not an object-oriented fan, but I'd even prefer a singleton class with constant attributes, like you suggested.  At least that would be a stateless interface!

Too many SKILL APIs are unnecessarily stateful.  For example, consider the awful gdm interface for copying Virtuoso cellviews requires stateful calls to create and manipulate a black-boxed "gdmSpecList" object.  You do gdmCreateSpecList() to create one, then you call gdmAddSpecToSpecList() to put things in it, and THEN (this is the nasty part) you need to do gdmNextFromSpecList() to iterate through.  It's like a port on a file: there is an invisible pointer in the gdmSpecList object that you are incrementing when you call gdmNextFromSpecList().  If you want to iterate again, you need to call gdmResetSpecList() to reset the pointer.  Why?  Why not just use normal lists of gdmSpec objects?  Why does this need to be an abstract data type?  Maybe there is a good reason -- perhaps it covers some corner case I haven't thought of.  Even if that is true, it would still be nice to have an optional stateless interface for us functional programmers.  I can roll my own, but it's just annoying.

richardyuan said:

You're right. No class is instantiated when use defMathConstants. But it behaves like a instance of a class.

Well, sure, in the sense that it has named fields you can read/write using the dot operator....  But it has no parent class, so no generic function specializers, no reader/writer slot definitions, etc.  So you could just as well say, "it behaves like an instances of a defstruct".

Just feel not quite comfortable.

Maybe a little fussy, hah...

I feel the same, though it's because I'm a functional programmer. :)  It's very odd to have a built-in that stuffs properties on a symbol's property list, even if it lets you specify which symbol.  I'd prefer a stateless interface:

getMathConstant('pi) => 3.14159.....

Or (returning a DPL):

getMathConstants().pi => 3.14159....

I'm not an object-oriented fan, but I'd even prefer a singleton class with constant attributes, like you suggested.  At least that would be a stateless interface!

Too many SKILL APIs are unnecessarily stateful.  For example, consider the awful gdm interface for copying Virtuoso cellviews requires stateful calls to create and manipulate a black-boxed "gdmSpecList" object.  You do gdmCreateSpecList() to create one, then you call gdmAddSpecToSpecList() to put things in it, and THEN (this is the nasty part) you need to do gdmNextFromSpecList() to iterate through.  It's like a port on a file: there is an invisible pointer in the gdmSpecList object that you are incrementing when you call gdmNextFromSpecList().  If you want to iterate again, you need to call gdmResetSpecList() to reset the pointer.  Why?  Why not just use normal lists of gdmSpec objects?  Why does this need to be an abstract data type?  Maybe there is a good reason -- perhaps it covers some corner case I haven't thought of.  Even if that is true, it would still be nice to have an optional stateless interface for us functional programmers.  I can roll my own, but it's just annoying.