Scheme vs Common Lisp style in SKILL++

What's great about SKILL/SKILL++ is that there's so many ways to do things.

What's annoying about SKILL/SKILL++ is that there's so many ways to do things.

Define a procedure:

(def square (lambda (x) (times x x)))
(defun square (x) (times x x))
(procedure square(x) (times x x))
(define (square x) (times x x))
(define square (lambda (x) (times x x)))
(defvar square (lambda (x) (times x x)))
(setq square (lambda (x) (times x x)))

Define a global value:

(define zero 0)
(defvar zero 0)
(setq zero 0)

On the one hand, do we really need three semantically-identical ways to define a global variable, and seven to define a procedure?

On the other hand, why not provide multiple redundant syntaxes if it helps make programmers from other languages feel more at home?

On the third hand, SKILL is not Scheme or Common Lisp, so define, defun, and defvar only superficially resemble their namesakes: they are really very different animals. A Scheme programmer may feel at home with SKILL++'s define for a few minutes, but then be surprised later on by the differences. Likewise, a Common Lisp programmer will soon find that defun and defvar behave quite differently from CL. So in the short-run, the syntactic borrowing makes the language friendlier, but in the long-run these borrowings are "false-friends": familiar-looking words in a foreign language that actually mean quite different things from what you would expect.

The differences are myriad: plus and append require two or more arugments; strings are immutable; improper and circular lists do not exist; the cdr of a cons must be a list; nil is not a symbol; environments are first-class; all free variable references are evaluated dynamically or lexically within a given block of code, depending on whether it's SKILL-mode or Scheme-mode; arithmetic with integers is inexact; rationals do not exist (but complex numbers are available in Virtuoso), and on and on and on.....

What is SKILL/SKILL++'s philosophy? Scheme is minimalist and favors a functional style. Common Lisp is large and favors iteration over recursion. SKILL is large like Common Lisp, and seems to favor iteration like Common Lisp (foreach's default is mapc rather than mapcar; the gdmSpec interface is stateful; tail call optimization was not added until quite recently, and it still doesn't work reliably (for me anyway)...), but its documentation makes a big deal about being compatible with Scheme, and SKILL++ (with the plus-plus suggesting incremental improvement over the original) moved in the direction of Scheme's evaluation semantics rather than Common Lisp's, yet it added an object system patterned after CLOS!

So what is SKILL/SKILL++'s philosophy? Is it trying to please everyone by pretending to be their favorite dialect? I like to think it is trying to create something new by taking the best features from both dialects. Scheme is the smallest, and CL is the biggest, so SKILL/SKILL++ is somewhere between. It's not as minimal and elegant as Scheme, and not as kitchen-sink and design-by-committee as CL. It has good support for pure functional programming like Scheme, but also good support for stateful iteration like CL. It supports unhygienic macros (which are widely regard as more powerful), while slowly adding support for hygienic macros (which are widely regard as much safer). It has an object system, but you are free to ignore it. It supports infix syntax, but you are free to (mostly) ignore that too.

So SKILL appears to be a devil-may-care, happy-go-lucky language, lightheardedly doing its own thing rather than slavishly following the crowds. If Lisp is a language for non-conformists, SKILL is a dialect for non-comformists who refuse to conform to the other non-conformists! In this way it's a lot like Perl. If it had been free and open source back in the mid-80's, people might be using SKILL now instead of Perl, and Cadence might be a lot richer. :) But, like Xerox, Cadence wasn't in the software business (at least not that sort of software....)

SKILL is so flexible, though, that it makes Perl look like Pascal. You can embed your own DSL's in SKILL very easily, because it's a Lisp.... Or you can pretend it's not Lisp (like my coworkers do) and write FORTRAN programs. It even has GOTO! SKILL just doesn't care. If Perl's motto is "there's more than one way to do it," and Python's is "there's only one (obvious) way to do it", then SKILL's motto is "whatever".

Is SKILL supportive, or apathetic? Is it eager to please, or so code-weary that it can't even be bothered to care how you write your program?

What's great about SKILL/SKILL++ is that there's so many ways to do things.

What's annoying about SKILL/SKILL++ is that there's so many ways to do things.

Define a procedure:

(def square (lambda (x) (times x x)))
(defun square (x) (times x x))
(procedure square(x) (times x x))
(define (square x) (times x x))
(define square (lambda (x) (times x x)))
(defvar square (lambda (x) (times x x)))
(setq square (lambda (x) (times x x)))

Define a global value:

(define zero 0)
(defvar zero 0)
(setq zero 0)

On the one hand, do we really need three semantically-identical ways to define a global variable, and seven to define a procedure?

On the other hand, why not provide multiple redundant syntaxes if it helps make programmers from other languages feel more at home?

On the third hand, SKILL is not Scheme or Common Lisp, so define, defun, and defvar only superficially resemble their namesakes: they are really very different animals. A Scheme programmer may feel at home with SKILL++'s define for a few minutes, but then be surprised later on by the differences. Likewise, a Common Lisp programmer will soon find that defun and defvar behave quite differently from CL. So in the short-run, the syntactic borrowing makes the language friendlier, but in the long-run these borrowings are "false-friends": familiar-looking words in a foreign language that actually mean quite different things from what you would expect.

The differences are myriad: plus and append require two or more arugments; strings are immutable; improper and circular lists do not exist; the cdr of a cons must be a list; nil is not a symbol; environments are first-class; all free variable references are evaluated dynamically or lexically within a given block of code, depending on whether it's SKILL-mode or Scheme-mode; arithmetic with integers is inexact; rationals do not exist (but complex numbers are available in Virtuoso), and on and on and on.....

What is SKILL/SKILL++'s philosophy? Scheme is minimalist and favors a functional style. Common Lisp is large and favors iteration over recursion. SKILL is large like Common Lisp, and seems to favor iteration like Common Lisp (foreach's default is mapc rather than mapcar; the gdmSpec interface is stateful; tail call optimization was not added until quite recently, and it still doesn't work reliably (for me anyway)...), but its documentation makes a big deal about being compatible with Scheme, and SKILL++ (with the plus-plus suggesting incremental improvement over the original) moved in the direction of Scheme's evaluation semantics rather than Common Lisp's, yet it added an object system patterned after CLOS!

So what is SKILL/SKILL++'s philosophy? Is it trying to please everyone by pretending to be their favorite dialect? I like to think it is trying to create something new by taking the best features from both dialects. Scheme is the smallest, and CL is the biggest, so SKILL/SKILL++ is somewhere between. It's not as minimal and elegant as Scheme, and not as kitchen-sink and design-by-committee as CL. It has good support for pure functional programming like Scheme, but also good support for stateful iteration like CL. It supports unhygienic macros (which are widely regard as more powerful), while slowly adding support for hygienic macros (which are widely regard as much safer). It has an object system, but you are free to ignore it. It supports infix syntax, but you are free to (mostly) ignore that too.

So SKILL appears to be a devil-may-care, happy-go-lucky language, lightheardedly doing its own thing rather than slavishly following the crowds. If Lisp is a language for non-conformists, SKILL is a dialect for non-comformists who refuse to conform to the other non-conformists! In this way it's a lot like Perl. If it had been free and open source back in the mid-80's, people might be using SKILL now instead of Perl, and Cadence might be a lot richer. :) But, like Xerox, Cadence wasn't in the software business (at least not that sort of software....)

SKILL is so flexible, though, that it makes Perl look like Pascal. You can embed your own DSL's in SKILL very easily, because it's a Lisp.... Or you can pretend it's not Lisp (like my coworkers do) and write FORTRAN programs. It even has GOTO! SKILL just doesn't care. If Perl's motto is "there's more than one way to do it," and Python's is "there's only one (obvious) way to do it", then SKILL's motto is "whatever".

Is SKILL supportive, or apathetic? Is it eager to please, or so code-weary that it can't even be bothered to care how you write your program?