Stats

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

  • Your mistake is that 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. So whilst defvar and define both exist in SKILL, (defvar is nominally for SKILL mode rather than SKILL++ mode, although it works in both), in SKILL++ variables and functions are not distinct - it's an object bound to a name. So there's really no way that it can treat them differently.

    Aliases are different again - they are a very old mechanism in SKILL to alias two functions. They predate SKILL++ (or ils mode) by some considerable time, and they are not intended to be copied by assignment. In fact all aliases share the same definition - they are all calling the evalalias macro, which actually looks for the alias property on the symbol to find out what it is aliased to. So they are not "weird", but you are assuming that they can be assigned, which is not the case.

    So you'd have to do:

    foo=second
    foo.alias=second.alias

    And then it would work. However, this is an undocumented implementation detail which you should not rely upon (in case it changes in future).

    Regards,

    Andrew.

     

Reply

  • Your mistake is that 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. So whilst defvar and define both exist in SKILL, (defvar is nominally for SKILL mode rather than SKILL++ mode, although it works in both), in SKILL++ variables and functions are not distinct - it's an object bound to a name. So there's really no way that it can treat them differently.

    Aliases are different again - they are a very old mechanism in SKILL to alias two functions. They predate SKILL++ (or ils mode) by some considerable time, and they are not intended to be copied by assignment. In fact all aliases share the same definition - they are all calling the evalalias macro, which actually looks for the alias property on the symbol to find out what it is aliased to. So they are not "weird", but you are assuming that they can be assigned, which is not the case.

    So you'd have to do:

    foo=second
    foo.alias=second.alias

    And then it would work. However, this is an undocumented implementation detail which you should not rely upon (in case it changes in future).

    Regards,

    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.