Stats

  • Locked Locked
  • Replies 18
  • Subscribers 144
  • Views 23192
  • 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

Scheme vs Common Lisp style in SKILL++

tweeks

 While you can write your SKILL++ code like it is C, Maclisp, Scheme, or Common Lisp (or none of the above...), I've been experimenting with Common Lisp style lately.

Trying to write Common Lisp style code in SKILL++ can lead to curious situations like this:

(defvar first car)

The intention is to define FIRST as another name for CAR, as in Common Lisp.  In Scheme, we would write

(define first car)

which seems pretty natural, but using DEFVAR to define a function just feels.... wrong... somehow... :)

I guess I should use ALIAS:

 (alias second cadr)

 except ALIAS has weird limitations:

ILS-> (foo = first)
primop:car
ILS-> (foo '(1 2 3))
1
ILS-> (foo = second)
macro:evalalias
ILS-> (foo '(1 2 3))
*Error* evalalias: unknown alias - foo

Parents
  • theopaone

     As kind of one of the "old" guys, having seen the development of EDA CAD from the 70's, user languages like SKILL were initially for the users, the programs were written by non programmers, layout designers and engineers who may have learned on Fortran (4 not 77) or pascal. We made it up as we went along, SKILL was a much more powerful language than its competitors but had to also cater to the layout designer who could barely use notepad or VI. As I lincreased my software engineering knowledge, I adopted certain styles and methodologies (Always used @key for optional arguments, extract the docStrings to create Finder docs, Unit tests - what's that? )

    Since I retired, I've been collecting what I think are the best practices of EDA programming, from the layout designer who wants to make a quick command to the developer writing a big application. I've considered writing a book, doing webinars on code quality, etc. I've looked at code written in multiple languages by hundreds of developers and it is so much easier to understand and debug when it adheres to a standard (any standard but is consistent).This is most important for maintainance, I had a customer developer from Moscow show up at my office in Austin with code I had written almost 12 years before and it was still readable and debuggable, except where they had made changes (and inserted the bug).  In another incarnation, I worked as part of a programming team where we all adopted the same style and you could not tell who wrote what, even the local variable naming was consistent. We all got the blame for any bugs.

    Adopt a style, document it (to share with others) and be consistent.

    Ted

Reply
  • theopaone

     As kind of one of the "old" guys, having seen the development of EDA CAD from the 70's, user languages like SKILL were initially for the users, the programs were written by non programmers, layout designers and engineers who may have learned on Fortran (4 not 77) or pascal. We made it up as we went along, SKILL was a much more powerful language than its competitors but had to also cater to the layout designer who could barely use notepad or VI. As I lincreased my software engineering knowledge, I adopted certain styles and methodologies (Always used @key for optional arguments, extract the docStrings to create Finder docs, Unit tests - what's that? )

    Since I retired, I've been collecting what I think are the best practices of EDA programming, from the layout designer who wants to make a quick command to the developer writing a big application. I've considered writing a book, doing webinars on code quality, etc. I've looked at code written in multiple languages by hundreds of developers and it is so much easier to understand and debug when it adheres to a standard (any standard but is consistent).This is most important for maintainance, I had a customer developer from Moscow show up at my office in Austin with code I had written almost 12 years before and it was still readable and debuggable, except where they had made changes (and inserted the bug).  In another incarnation, I worked as part of a programming team where we all adopted the same style and you could not tell who wrote what, even the local variable naming was consistent. We all got the blame for any bugs.

    Adopt a style, document it (to share with others) and be consistent.

    Ted

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.