• 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
  • tweeks
    tweeks over 11 years ago

    Thanks Andrew.

    Andrew Beckett said:

    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.

    In that case, I understand if you want to remove this thread.

     

      --tom

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

    Thanks Andrew.

    Andrew Beckett said:

    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.

    In that case, I understand if you want to remove this thread.

     

      --tom

    • 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