Scheme vs Common Lisp style in SKILL++

It's liberating that SKILL lets you adopt multiple styles, but it's also frustrating, because you can never follow any particular style completely. You can adopt some Scheme conventions, or Common Lisp conventions, or C conventions, but you can't use any one of them with complete consistency, even in a small program.

So what do you do?  When there are seven ways to define a procedure (actually more if you include putd), which one do you choose? 

I know def is a fossil from Franz Lisp, and is undocumented (although ironically it seems to be SKILL's primitive definitional construct that the others are built on), so one would not use that.  Besides, it's more verbose than the others.

procedure and setq (the equals sign operator) are for infix programmers, so they're out, because I want to use one of Emacs' Lisp modes.

defvar looks odd, and the forms with lambda are just needlessly verbose, so we're left with two practical contenders:

(defun square (x) (times x x))
(define (square x) (times x x))

I've spent way too much time thinking about which one to use, and I've flip-flopped back and forth several times over the years.  (Some wag will say, "you should use defgeneric or defmethod!" but I'm ignoring that level of abstraction for now.)

Choosing one or the other seems to be making a statement: "I am a Common Lisp programmer", or "I am a Scheme programmer". Of course it's not all-or-nothing, but once you choose one or the other, you naturally put Emacs in the mode that makes that particular keyword light up green, and then you're heading down that path.....  You choose whether to suffix your predicates with a "p" or a "?".  You choose whether to indicate destructive functions with an "n" or a "!".  You choose whether to use recursion or iteration, whether to embrace side-effects or to avoid them, whether to use keyword arguments liberally (like CL's core library) or prefer lots of smaller composable functions....

SKILL doesn't care what you do.  You can mix and match in the same program!  You can alternate, define, defun, define, defun...   You can throw in a procedure here and there for variety.  You can avoid defining procedures entirely, stuff all your code in .il files, and just load them to run them!

I like that SKILL is so supportive/apathetic about coding style, but at the same time it is a source of frustration, because there is no basis for choosing one way or the other on these stylistic issues, yet you must choose.  You must decide on conventions for your own code and stick to them, yet there's really no compelling reason to choose any particular one. 

If I read Scheme books, I lean towards define.  If I read CL books, I lean towards defun.  Scheme is great because it's simple.  CL is great because it's complete.  Scheme is missing many things I want.  CL has a lot of things I don't want.  SKILL strikes a nice balance, but at the same time it takes no firm stand on even trivial things like how to define a procedure. 

When should I use type-templates?  Are they always good?  Or can they be overdone?

When should I use @key?  Is it always good?  Or can it be overused?

Should I use docstrings?  Write Finder-compatible docs?  Should I include type information in a comment?  Should I include unit tests?  Specification-based tests?  Are there legitimate uses for go(to)?  When do I use error/errset and when do I use throw/catch?  When is it OK to define a macro?  When is it OK to define a macro-defining macro?

There is no vast SKILL community publishing books and blogs to answer these sorts of questions.  The SKILL docs are very thin.  The SKILL community is small, and doesn't share much (with the exception of this forum).

Basically SKILL programmers are given enough rope to hang themselves.  They're sent out into the world with very little guidance from the community at large as to how programs should be written, so they are free (good) to repeat others' mistakes over and over (bad).

Naturally I look to the Common Lisp and Scheme and even Haskell communities for help in answering these questions, but they have their differences (due to differing philosophical presuppositions), so I get conflicting answers. 

In the end, it seems human beings really can't agree on how programming ought to be done.  There is very little consensus on it, we just sort of make it up as we go.  The reason SKILL is such a big language with so much redudancy is no doubt because its developers were also making it up as they went.  Programmers worldwide cannot agree on how to use type information, unit tests, comments, macros, identifiers, and any other feature of a concrete programming language, simple or complex....  It is fitting that SKILL reflects humanity's confusion!

fsck it, I'll use defun.

It's liberating that SKILL lets you adopt multiple styles, but it's also frustrating, because you can never follow any particular style completely. You can adopt some Scheme conventions, or Common Lisp conventions, or C conventions, but you can't use any one of them with complete consistency, even in a small program.

So what do you do?  When there are seven ways to define a procedure (actually more if you include putd), which one do you choose? 

I know def is a fossil from Franz Lisp, and is undocumented (although ironically it seems to be SKILL's primitive definitional construct that the others are built on), so one would not use that.  Besides, it's more verbose than the others.

procedure and setq (the equals sign operator) are for infix programmers, so they're out, because I want to use one of Emacs' Lisp modes.

defvar looks odd, and the forms with lambda are just needlessly verbose, so we're left with two practical contenders:

(defun square (x) (times x x))
(define (square x) (times x x))

I've spent way too much time thinking about which one to use, and I've flip-flopped back and forth several times over the years.  (Some wag will say, "you should use defgeneric or defmethod!" but I'm ignoring that level of abstraction for now.)

Choosing one or the other seems to be making a statement: "I am a Common Lisp programmer", or "I am a Scheme programmer". Of course it's not all-or-nothing, but once you choose one or the other, you naturally put Emacs in the mode that makes that particular keyword light up green, and then you're heading down that path.....  You choose whether to suffix your predicates with a "p" or a "?".  You choose whether to indicate destructive functions with an "n" or a "!".  You choose whether to use recursion or iteration, whether to embrace side-effects or to avoid them, whether to use keyword arguments liberally (like CL's core library) or prefer lots of smaller composable functions....

SKILL doesn't care what you do.  You can mix and match in the same program!  You can alternate, define, defun, define, defun...   You can throw in a procedure here and there for variety.  You can avoid defining procedures entirely, stuff all your code in .il files, and just load them to run them!

I like that SKILL is so supportive/apathetic about coding style, but at the same time it is a source of frustration, because there is no basis for choosing one way or the other on these stylistic issues, yet you must choose.  You must decide on conventions for your own code and stick to them, yet there's really no compelling reason to choose any particular one. 

If I read Scheme books, I lean towards define.  If I read CL books, I lean towards defun.  Scheme is great because it's simple.  CL is great because it's complete.  Scheme is missing many things I want.  CL has a lot of things I don't want.  SKILL strikes a nice balance, but at the same time it takes no firm stand on even trivial things like how to define a procedure. 

When should I use type-templates?  Are they always good?  Or can they be overdone?

When should I use @key?  Is it always good?  Or can it be overused?

Should I use docstrings?  Write Finder-compatible docs?  Should I include type information in a comment?  Should I include unit tests?  Specification-based tests?  Are there legitimate uses for go(to)?  When do I use error/errset and when do I use throw/catch?  When is it OK to define a macro?  When is it OK to define a macro-defining macro?

There is no vast SKILL community publishing books and blogs to answer these sorts of questions.  The SKILL docs are very thin.  The SKILL community is small, and doesn't share much (with the exception of this forum).

Basically SKILL programmers are given enough rope to hang themselves.  They're sent out into the world with very little guidance from the community at large as to how programs should be written, so they are free (good) to repeat others' mistakes over and over (bad).

Naturally I look to the Common Lisp and Scheme and even Haskell communities for help in answering these questions, but they have their differences (due to differing philosophical presuppositions), so I get conflicting answers. 

In the end, it seems human beings really can't agree on how programming ought to be done.  There is very little consensus on it, we just sort of make it up as we go.  The reason SKILL is such a big language with so much redudancy is no doubt because its developers were also making it up as they went.  Programmers worldwide cannot agree on how to use type information, unit tests, comments, macros, identifiers, and any other feature of a concrete programming language, simple or complex....  It is fitting that SKILL reflects humanity's confusion!

fsck it, I'll use defun.