Lispyscript looks cool

[Chanwoo Yoo]

Hi. After survey of various lisp dialects compiled to javascript, I was happy to find out lispyscript.

It works well and has good amount of documents. I hope it will be more mature and there will be more users of it.

Although it looks cool, I have some questions about it.

First, without gensym or hygienic macros, does your approach guarantee for avoiding of variable capture?(Using three underscore for variables in macros and forbidding three underscores in code outside macros)

If I use the same macro as nested forms like this:

(mymacro some_code

    (mymacro some_code))

Can variable captures be avoided in that case?

Second, as you know, 'template and placeholder' approach for macros has its limitations. 

Only when your macros can return code as a data(usually a list), it is possible to write really powerful macros because you can generate arbitrary code from data manipulation.

If you read 'On Lisp', you already knew about it. 'Homoiconicity' is no more useful when your macro can't return your code as a data because you can't manipulate your code as a data.

I'm just curious why you decide to make lispyscript's macros not to manipulate its code arbitrarily.

Best regards

Chanwoo

[Santosh Rajan]

On Mon, Dec 24, 2012 at 2:45 PM, Chanwoo Yoo <chanw...@gmail.com> wrote:

First, without gensym or hygienic macros, does your approach guarantee for avoiding of variable capture?(Using three underscore for variables in macros and forbidding three underscores in code outside macros)

If I use the same macro as nested forms like this:

(mymacro some_code

    (mymacro some_code))

Can variable captures be avoided in that case?

In LispyScript macros can only expand to a single expression. Macros cannot expand to multiple expressions. If you need multiple expressions you need to wrap the expressions in a function. So you are forced to create a new scope. So nested macros will expand into their own scopes, so variable capture will not happen in this case. 

 

Second, as you know, 'template and placeholder' approach for macros has its limitations. 

Only when your macros can return code as a data(usually a list), it is possible to write really powerful macros because you can generate arbitrary code from data manipulation.

If you read 'On Lisp', you already knew about it. 'Homoiconicity' is no more useful when your macro can't return your code as a data because you can't manipulate your code as a data.

I'm just curious why you decide to make lispyscript's macros not to manipulate its code arbitrarily.

LispyScript macros can manipulate code arbitrarily using what in LispyScript is called "homoiconic expressions". However this feature is not documented yet, because I have not completed all the features yet. For now you will have to look at the macros source file to see the usage. See source for "cond" macro, "->" chaining macro, "m-bind" macro under monads.

Also LispyScript is not a Lisp dialect and therefore does not have List Processing. The objective of LispyScript is to write JavaScript in a Lispy manner, and to provide all the power available in a Lisp like language, in a much simpler fashion.

--

Santosh Rajan

@Twitter

@About.Me