Stats

  • Locked Locked
  • Replies 4
  • Subscribers 143
  • Views 14319
  • 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

Seeking Closest Lisp dialect to Skill (not Skill++)

rcs0

I am interested what 'Custom IC Skill' readers consider the closest FOSS Linux compatible Lisp dialect to Skill? As the title states, I'm interested Skill, not Skill++. (1)

Why?
My company's Linux/Cadence environment is top notch. The windows loaded hardware, vpn, remote access software, passwords, and surveys required to enter that environment are prohibitive. I'd like to develop functions for coordinate number crunching, layer mapping, etc., in a Linux Lisp environment, and move debugged code to Cadence Skill.

"SKILL and SKILL++ are distinct dialects of LISP and are not either Scheme or Common Lisp or any of the others. They may share similar syntax to the other dialects, but they have different semantics." -- A. Beckett

I don't expect 100% compatibility. I'd like opinions on a good starting point-- e.g. Guile vs SBCL-- minimizing changes when moving to Skill. A Lisp expert colleague suggested (define)ing a familiar dialect to be Skill-like. I like that idea, though I'd like to pick a good starting point.

(1) 'Skill' seems more oft used than 'Skill++' in my area, so I'd like to stick with Skill. I prefer the CL coding style (setq a 0), so I'm not interested in procedural support (a=0).

Thank you for any guidance.

Parents

  • I think you'll struggle to find a dialect that is especially close, partly because SKILL derives from Franz Lisp which has been discontinued for some time, and most common current LISPs are either based on ANSI Common Lisp or Scheme (yes, there are a few other flavours) - see the timeline of dialects on the Wikipedia page I just linked to. Also, SKILL has itself been extended quite a bit over the years, adding a number of features from a variety of other LISPs, including Common Lisp and Scheme, plus having functions inspired by C, Python, Pascal and numerous other languages. New data structures have been added in the language too (many of which have existed for 25- 30 years, but are not in Franz Lisp).

    I'm also unsure as to how valuable it would be, because you tend to soon move away from just using the core language to using the application programming interfaces to Virtuoso itself for example. I suspect you'd spend quite a lot of time emulating other functions and this is going to be quite a bit of effort.

    Whatever dialect you pick, you're going to have to do a fair bit of work to come up with a similar dialect, so it probably doesn't matter too much whether you start from SBCL, Racket or Guile. I guess it depends how much core language stuff you're going to be doing as to whether it's worthwhile.

    Note that more of SKILL++ is inspired by Scheme and Common Lisp so you might actually find writing for SKILL++ easier. There's generally no downside, as you can call existing SKILL functions from SKILL++, and SKILL++ has lexical scoping which is generally safer and less prone to errors.

    Andrew.

  • in reply to Andrew Beckett

    Totally off-topic. Sorry for this.

    I wish Cadence had chosen TCL/Python as interface language. All the skills I have in SKILL is not much useful outside Cadence environment. I know these languages are younger compared to LISP but still...

    -Ramakrishnan 

  • in reply to RK56

    We'd have needed a time machine, since these languages didn't exist when SKILL was first used in the Cadence tools.

    I do cover this to some extent in my Writing Good SKILL Code (Video) - to some extent, what matters most is the application interfaces you're using, and knowing how to program. The details of the language is  the simplest part to translate (obviously Python has a very large set of available open source extension libraries, which makes it particularly attractive though). However, legacy and years of code developed around Virtuoso is something you wouldn't be able to apply arbitrary libraries for other languages to those kinds of problems.

    So I understand the sentiment, but I think it's not so important in practice.

    Andrew.

Reply
  • in reply to RK56

    We'd have needed a time machine, since these languages didn't exist when SKILL was first used in the Cadence tools.

    I do cover this to some extent in my Writing Good SKILL Code (Video) - to some extent, what matters most is the application interfaces you're using, and knowing how to program. The details of the language is  the simplest part to translate (obviously Python has a very large set of available open source extension libraries, which makes it particularly attractive though). However, legacy and years of code developed around Virtuoso is something you wouldn't be able to apply arbitrary libraries for other languages to those kinds of problems.

    So I understand the sentiment, but I think it's not so important in practice.

    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.