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

Parents

  • 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 

Reply

  • 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 

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.