• 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 17735
  • 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
  • skillUser
    skillUser over 10 years ago

    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...

    Just my $0.02 worth.

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • Andrew Beckett
    Andrew Beckett over 10 years ago

    Lawrence, I agree. The redundancy doesn't do any harm. My £0.02 ;-)

    Andrew 

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • 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
  • tweeks
    tweeks over 10 years ago
    Andrew Beckett said:

    My £0.02 ;-)

    That's "two pence", or "toppence", right?  (Sorry: ignorant American!)

    WOAH I just realized that "pence" sounds just like the French pense ("think"), hence "pence for your pense" is a little pun that fails to make sense when you s/penny/pence/ ...

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • Andrew Beckett
    Andrew Beckett over 10 years ago

    If looking for any nils present in the list, I would use:

    (forall elem lst elem)

    as that's probably more expressive than (apply or ...). 

    In general I always advise against overuse of macros. Peter Norvig makes a good point in Paradigms of Artificial Intelligence Programming about this. "The first step in writing a macro is to recognize that every time you write one, you are defining a new language that is just like Lisp except for your new macro. The programmer who thinks that way will rightfully be extremely frugal in defining macros. Introducing a macro puts much more memory strain on the reader of your program than does introducing a function, variable or data type, so it should not be taken lightly. Introduce macros only when there is a clear need, and when the macro fits in well with your existing system."

    And yes, that is two pence or "tuppence" (with a u rather than an o)!

    Andrew 

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • tweeks
    tweeks over 10 years ago
    Andrew Beckett said:

    If looking for any nils present in the list, I would use:

    (forall elem lst elem)

    as that's probably more expressive than (apply or ...). 

    Oh yeah.... and forall would handle longer lists too, due to the arglist length limitations of apply.

    Andrew Beckett said:

    In general I always advise against overuse of macros. Peter Norvig makes a good point in Paradigms of Artificial Intelligence Programming about this.

    Ha I just got that book!  Judging from my preliminary skimming, it looks truly hardcore.  I like that Norvig explains the true origins of lambda on p.20, going all the way back to Russel & Whitehead's caret notation in Principia Mathematica. 

    Andrew Beckett said:

    And yes, that is two pence or "tuppence" (with a u rather than an o)!

    Reminds me of the "feed the birds" song from Mary Poppins, which is one of my primary sources for information on life in the UK, along with Top Gear and Doctor Who. 

    Is your hometown pronounced like "berk-shy-er" or "berk-sure"?

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • Andrew Beckett
    Andrew Beckett over 10 years ago

    tweeks said:
    Is your hometown pronounced like "berk-shy-er" or "berk-sure"?

     

    Berkshire (full name "The Royal County of Berkshire")is a county (not a town), and it's pronounced bark-sheer (sort of).

    Regards,

    Andrew.

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

    Thanks for the link!

    Such a beautiful place, with such a long and fascinating history....  I absolutely must visit before I die.

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel

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