• 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. SKILL namespaces vs SKILL++ environments

Stats

  • Locked Locked
  • Replies 3
  • Subscribers 143
  • Views 14168
  • 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

SKILL namespaces vs SKILL++ environments

tweeks
tweeks over 11 years ago

I've been playing around with namespaces and environments recently, and have observed the following
pros and cons:

  • SKILL++ Environments
    • Pros:
      • Easy to use.
      • Well-documented in the SKILL++ manual and the Scheme literature.
      • No need to enumerate the names to be hidden (as with addToNamespace).
      • Low-impact on the global environment.
      • Can use toplevel('ils theEnvironment(myFunc)) to set the toplevel evaluation context inside an environment.
      • Implementation is mature.
      • Can programmatically get a list of all symbols in an environment.
    • Cons:
      • Can't put a macro in an environment.
      • No builtins for importing, exporting, and shadowing.
      • Can't put a class or a generic function in an environment.
  • SKILL Namespaces
    • Pros:
      • Works for all kinds of names, including macros.  (But not classes and generic functions, which are always global.)
      • Comes with builtins for importing, exporting, and shadowing.
    • Cons:
      • Confusing to use, because it works by altering how the reader maps textual names to symbol objects.
      • Does not currently interact smoothly with infix operator conversion.
        • E.g. Define your own "plus" in a namespace, shadowImport it, and read("1 + 1").  You will get the builtin plus primop rather than your redefined plus.  But if you read("(plus 1 1)"), you will get the redefined plus!
      • Heavy impact on global environment due to useNamespace().  Need to use unwindProtect() to ensure namespaces are unused if there is a load() error, lest other SKILL developers on the other side of the world (who don't even know about namespaces) become very confused.
      • Need to enumerate every single name that goes in the namespace.  If you forget one, that name will be in the global namespace!  No Lint check for this either, unlike the ERRGLOBAL for let()/prog().
      • Can't change the "current namespace": there is no equivalent to Common Lisp's in-package().  The global namespace is always the current one, which makes SKLL namespaces significantly less pleasurable to use than CL packages.
      • Implementation is immature: it's easy to make Virtuoso core dump when playing around with namespace functions.
      • Can't programmatically get a list of all symbols in a namespace.
  • Name Prefixing
    • Pros:
      • Time-tested, traditional "solution" to the namespacing problem.
      • Easy to understand.
      • Well documented in the SKILL manual and the Emacs Lisp info docs (Emacs Lisp uses a similar convention.)
      • No risk of crashing Virtuoso.
      • Works for all kinds of names, including macros.
    • Cons:
      • Doesn't really solve the name collision problem: names can still collide if two programmers happen to choose the same prefix.
      • Names become longer and harder to read than with namespaces or environments.
      • Need to take care to enumerate local names in a let() or prog(), though Lint is available to check if you forgot any.
      • No builtins for importing, exporting, and shadowing, though you can roll your own.
Discuss. :)
  • Cancel
Parents
  • Andrew Beckett
    Andrew Beckett over 11 years ago

    Tom,

    As I said in reply to your earlier post about namespaces, in my opinion they are not ready for the prime time yet. I did some investigation of them prior to the release of IC616, and have also given some feedback to R&D about some of the issues with them. My preference would have been that we'd not released them in IC616 because I don't think they're yet in a state that they can really be used to solve real-world problems, and that would have given us more time to mature the implementation prior to making it public.

    Because of this, it needs further discussion and probably not in a public forum because we need to come to a concensus on what we actually need to do.

    You've also directly contacted a few of us directly. Jim (who is in my team) has also been looking at namespaces in more detail over the last couple of weeks and will reply to your private email.

    Kind Regards,

    Andrew.

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Reply
  • Andrew Beckett
    Andrew Beckett over 11 years ago

    Tom,

    As I said in reply to your earlier post about namespaces, in my opinion they are not ready for the prime time yet. I did some investigation of them prior to the release of IC616, and have also given some feedback to R&D about some of the issues with them. My preference would have been that we'd not released them in IC616 because I don't think they're yet in a state that they can really be used to solve real-world problems, and that would have given us more time to mature the implementation prior to making it public.

    Because of this, it needs further discussion and probably not in a public forum because we need to come to a concensus on what we actually need to do.

    You've also directly contacted a few of us directly. Jim (who is in my team) has also been looking at namespaces in more detail over the last couple of weeks and will reply to your private email.

    Kind Regards,

    Andrew.

    • 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