Macros

[jasonkuhrt]

elixir macros offer a way for libraries to extend the language. For instance the range operator .. in elixir is a macro – anyone in userland could have created it.

The majority of elixir "syntax" is implemented using the same tools available to userland.

I think the benefits are obvious. For one thing, userland can try radical features and the things that stick can become integrated into core. DSLs become trivial...

I'm curious what you guys think. It's not obvious to me that livescript 1.x could adopt this and still be called, well, livescript, but at the same time I also get the impression things are still up for grabs (or at least, say, LS2 might be).

[jasonkuhrt]

More examples, but this time from something much closer to livescript: Gorillascript:

http://ckknight.github.io/gorillascript/#macros

[robotlolita]

While macros are awesome, their addition in a language that isn't homoiconic (and particularly one with a complex syntax like LiveScript) makes me a bit ambivalent towards them. Rust has them, and it has a C-style syntax, but I haven't had the time to analyse and play with Rust yet, so I can't comment on that.

My experience with macros come from Scheme, Emacs Lisp & Clojure (second-class macros) and Io & Kernel (first-class "macros"). They do fit well in those languages because they're homoiconic, and have a rather simple syntax — yet debugging macros in Clojure is the most painful thing ever. I'm not sure LiveScript could just "add macros" without rethinking a lot of its syntax and features.

If we can find a way to make them possible, I'm all for it, though. There are a few times where syntactical abstractions are an awesome thing to have.

[jasonkuhrt]

@killdream Gorillascript is not homoiconic and has convoluted syntax like livescript therefore proven prior-art exists.

Regarding:

I'm not sure LiveScript could just "add macros" without rethinking a lot of its syntax and features.

Rethining a lot of syntax and features would be a good thing #219.

Tangent

Linters #316 and styleguides https://github.com/gkz/LiveScript-style-guide should be considered possible language-design smells, simplicity can mean a compromise of fewer "options" in exchange for enhanced clarity. I'm skeptical of anyone who considers optional syntax a better feature than clarity. Maybe this goes into the ruby vs python camp, but I don't think so. Languages like lisp, exlixr, and haskell seem to expose an exceptional well considered toolset.

/tangent

Macros allow the community to engage in language design and help @gkz manage the language evolution by observing what popular userland macros are in use.

[vendethiel]

ref jashkenas/coffeescript#3171

[robotlolita]

So, I want to try something with bringing macros to LiveScript. I'm currently reading some papers on previous literature on this subject to see what would be the best way of bringing them. However, I'm not going for the overtly simplistic approach in (jashkenas/coffeescript#3171), but something that'll cover at least these points:

• Macros should be easy to be correctly written (i.e..: it's impossible or at least extremely difficult to violate the language's rules from a Macro).
• Macros should be easy to debug. Ideally, errors in a macro will make sense when debugging (macros in Clojure sucks because of this).
• Macros should be expressive. Ideally you would be able to write LS's features using mostly macros.
• It would be nice to have scoped macros, so you could choose which ones you want in a particular module (Similar to #lang in Racket).

Though what I'm thinking right now would be a multi-pass compiler where macros would add a new pass and modify the transformation rules (a macro is a Transformer AST → Transformer AST function, basically). Not sure how well it would work, but could simplify the compiler architecture if turns out to be solid. The idea for now is mostly based on OMeta, and I don't think it could be just a drop-in feature. But maybe something to consider for LS2 if it turns out to be worthwile.

Just throwing the idea here, but I still need to read some papers and draft most of it :P

[askucher]

I have already proposed apply macros before and don't remember what you
decided. But I have already solved my issue through next implementation: I
have wrapped livescript compiler with my own parser white takes 2
parameters : source and json. This json could contain everything and
available in compile time. So next question how I use it.
It is very simple I check content if it is contains any code string which
starts with single / (not double, because double is comment)

If yes it is compile time livescript which has access to input json.
Everything else is content. Which collects to output variable.

It allows me to generate livescript using livescrpt. And I am happy with
that. I can put common names in 1 configuration file and use them on client
and server scripts which became to have some visual binding because use
same input model.

But not I still not happy that livescript cannot use typescript interfaces
because I have runtime errors which can be prevented by using if them. It
will force to think about Haskell to JavaScript or Ocaml to JavaScript
compilers when my project will be published and supported by other people.
Easier to rewrite to mutual language them write module tests which will not
cover this gap completely. So I would choose between same languages where
first has macroses but doesn't have type and second visa versa I would
select second language. Static type has higher priority because provide
stability. Macroses provide extensibility. I think better to extend some
thing stable and controllable but in real life I choose what I want to do
but it was not always efficient.
On Oct 22, 2013 1:36 AM, "Quildreen Motta" notifications@github.com wrote:

So, I want to try something with bringing macros to LiveScript. I'm
currently reading some papers on previous literature on this subject to see
what would be the best way of bringing them. However, I'm not going for the
overtly simplistic approach in (jashkenas/coffeescript#3171jashkenas/coffeescript#3171),
but something that'll cover at least these points:

• Macros should be easy to be correctly written (i.e..: it's
  impossible or at least extremely difficult to violate the language's rules
  from a Macro).
• Macros should be easy to debug. Ideally, errors in a macro will make
  sense when debugging (macros in Clojure sucks because of this).
• Macros should be expressive. Ideally you would be able to write LS's
  features using mostly macros.
• It would be nice to have scoped macros, so you could choose which
  ones you want in a particular module (Similar to #lang in Racket).

Though what I'm thinking right now would be a multi-pass compiler where
macros would add a new pass and modify the transformation rules (a macro is
a Transformer AST → Transformer AST function, basically). Not sure how well
it would work, but could simplify the compiler architecture if turns out to
be solid. The idea for now is mostly based on OMeta, and I don't think it
could be just a drop-in feature. But maybe something to consider for LS2 if
it turns out to be worthwile.

Just throwing the idea here, but I still need to read some papers and
draft most of it :P

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/328#issuecomment-26763043
.

[askucher]

Example:

$scope
 ..get-list= (name)->
        /for list in radio-lists
         if name  is '{{list.name}}' then return {{JSON.stringify list.content}}
        []

where radio-lists is property of input json and {{ something }} is compile time livescript code

[naturalethic]

Some other projects, for reference.
http://sweetjs.org/
http://mrluc.github.io/macros.coffee/docs/macros.html

[ozra]

glanced at it - cool!

2014/1/8 Joshua Kifer notifications@github.com

http://sweetjs.org/

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/328#issuecomment-31873121
.