Syntax_rules in Skill++

Well, define_syntax is public since IC615 (and documented in the SKILL documentation - although there's a fairly poor description of what it does and the example isn't great). I've never used it. Bear in mind that SKILL only supports some features of Scheme, not everything (it's not based on Scheme, but borrows things from both Scheme and Common Lisp).

Personally I've never used it nor had a need to.

Andrew.

Hi Andrew, thanks for the reply.

Andrew Beckett said:

Well, define_syntax is public since IC615 (and documented in the SKILL documentation

I'm on IC616 (virtuoso version 6.1.6-64b according to the CIW) and it's not listed in the docs or the finder for me.

Good to hear that it was completed though.

Andrew Beckett said:

Bear in mind that SKILL only supports some features of Scheme, not everything (it's not based on Scheme, but borrows things from both Scheme and Common Lisp).

Fair enough then.

Andrew Beckett said:

Personally I've never used it nor had a need to.

The main attraction for me is the pattern matching. Take list comprehensions for example.

(lcmp (x + 2) for x in (list 1 2 3 4 5) if (odd x))

Some of the symbols in there don't do anything other than make it more readable for humans (for, in, if). If I was to use defmacro, then I'd have to manually check each symbol myself and throw custom errors if they deviated from the syntax otherwise the user could just type (lcmp (x + 2) foo x bar (list 1 2 3 4 5) baz (odd x)) and the compiler wouldn't complain.

Also, the pattern matching means making the predicate optional is very easy. If I was to use defmacro I would need conditionals to ensure that it handles both cases properly. For comparison my defmacro version (without any syntactic sugar) was 11 lines while my syntax_rules version was only 6 and was much more readable. The ability to have "useless" keywords lets me make very natural looking constructs.

Here's my two versions for comparison. I'm still new to lisp so there may be obvious improvements.

(Edit: Upon reading the code again, I could probably reuse the mapcar/setof method that I used for the syntax_rules version and shorten the defmacro version a lot)

defmacro style:

(defmacro lcmp (sexp loop-var lst &optional (pred nil))
  (let ((loop-inner (gensym))
        (result (gensym)))
    (setq loop-inner (if (equal pred nil)
                         `(push ,sexp ,result)
                         `(if ,pred
                              (push ,sexp ,result))))
    `(let ((,result nil))
        (for-each ,loop-var ,lst
            ,loop-inner)
        (reverse ,result))))

syntax-rules style

(define_syntax lcmp
    (syntax_rules (for in if)
        ((lcmp expression for element in list)
         (mapcar (lambda (element) expression) list))
        ((lcmp expression for element in list if predicate)
         (mapcar (lambda (element) expression) (setof element list predicate)))))

Thanks again for the reply.

Thanks Matthew. I made a mistake in my previous reply - it was IC617 that this was marked public (I think I misread 2015 as IC615 for some reason) - which is why you didn't find it in the docs.

I see from your example why it's useful although personally I tend to avoid the extra syntactic keywords - although that does help with making the human comprehension of the new form clearer. I have historically used defmacro - but I can see how this could be useful. That said, I generally advise against overuse of macros. Peter Norvig makes a good point in Paradigms of Artificial Intelligence Programming about this: "The first step in writing a macro is to recognize that every time you write one, you are defining a new language that is just like Lisp except for your new macro. The programmer who thinks that way will rightfully be extremely frugal in defining macros. Introducing a macro puts much more memory strain on the reader of your program than does introducing a function, variable or data type, so it should not be taken lightly. Introduce macros only when there is a clear need, and when the macro fits in well with your existing system."

Apologies to anyone who's seen me cite Peter Norvig before on this topic!

Regards,

Andrew.