• Skip to main content
  • Skip to search
  • Skip to footer
Cadence Home
  • This search text may be transcribed, used, stored, or accessed by our third-party service providers per our Cookie Policy and Privacy Policy.

  1. Community Forums
  2. Custom IC SKILL
  3. nil IS a list...

Stats

  • Locked Locked
  • Replies 8
  • Subscribers 143
  • Views 17738
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

nil IS a list...

tweeks
tweeks over 10 years ago
ddGetObjChildren( 
b_objId 
) 
=> l_children | nil

When you say l_children, isn't it already implied that the list could be empty?  After all, if the object has no children, then you get nil, which is just a zero-length list of children.  So shouldn't the return type be simply l_children, like this:

ddGetObjChildren( 
b_objId 
) 
=> l_children

Just sayin'....

  • Cancel
Parents
  • tweeks
    tweeks over 10 years ago

    skillUser said:
    Well, yes, but it is clear enough to say that the return value is nil otherwise some folks might expect (nil) to indicate no children, so it doesn't hurt to be redundant in this case I think...


    That's a good point. 

    Curiously, I haven't encountered many SKILL functions that return a (nil) so as to distinguish the result from nil.  In fact, the only one that comes to mind is errset, so that you can distinguish a function that returns nil successfully from one that throws an error.

    It just so happens that today I thought about writing a macro exists1 that is just like exists except it takes the car of whatever exists returns, since I'm usually searching for the first thing matching the predicate, not the rest of the list starting with the first thing matching the predicate....  However, if I were searching for nil, I wouldn't know whether (exists1 x myList (p x)) => nil means nil is present in myList, or nil is not present!  (This is one disadvantage to not having a separate boolean type like Scheme.  Of course, even then I'd have the same issue if I were searching for a Scheme boolean false #f object... which is one disadvantage to not having a Maybe type like Haskell....)

    I could have exists1 return a wrapped result, so that I'd get (nil) if nil was in there, and nil if it wasn't, but that's what exists does... :)

    For me, it seems more convenient to live with the ambiguity and just return nil in either case, since I never search for nil using exists anyway -- I would use something like (apply (and ...)) or andmap for that.

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Reply
  • tweeks
    tweeks over 10 years ago

    skillUser said:
    Well, yes, but it is clear enough to say that the return value is nil otherwise some folks might expect (nil) to indicate no children, so it doesn't hurt to be redundant in this case I think...


    That's a good point. 

    Curiously, I haven't encountered many SKILL functions that return a (nil) so as to distinguish the result from nil.  In fact, the only one that comes to mind is errset, so that you can distinguish a function that returns nil successfully from one that throws an error.

    It just so happens that today I thought about writing a macro exists1 that is just like exists except it takes the car of whatever exists returns, since I'm usually searching for the first thing matching the predicate, not the rest of the list starting with the first thing matching the predicate....  However, if I were searching for nil, I wouldn't know whether (exists1 x myList (p x)) => nil means nil is present in myList, or nil is not present!  (This is one disadvantage to not having a separate boolean type like Scheme.  Of course, even then I'd have the same issue if I were searching for a Scheme boolean false #f object... which is one disadvantage to not having a Maybe type like Haskell....)

    I could have exists1 return a wrapped result, so that I'd get (nil) if nil was in there, and nil if it wasn't, but that's what exists does... :)

    For me, it seems more convenient to live with the ambiguity and just return nil in either case, since I never search for nil using exists anyway -- I would use something like (apply (and ...)) or andmap for that.

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Children
No Data

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.

© 2025 Cadence Design Systems, Inc. All Rights Reserved.

  • Terms of Use
  • Privacy
  • Cookie Policy
  • US Trademarks
  • Do Not Sell or Share My Personal Information