From: Yehuda Katz Date: 2009-02-24T14:29:01+09:00 Subject: [ruby-core:22403] Re: On the consideration of macros --0015174c0f86cf4b270463a34ae8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Matz has repeatedly and explicitly expressed that he did not want Ruby to have macros. That might have changed, but I believe he repeated it recently at LoneStar RubyConf. I believe Matz has argued that macros are too complex for the average programmer... -- Yehuda 2009/2/23 Charles Oliver Nutter > James M. Lawrence wrote: > >> After looking at a few ruby_parser examples, in just 40 lines of code >> I was able to write a transformer which allowed me to define the >> seamless locals_to_hash I wanted. This runs on 1.8, 1.9, and jruby -- >> anything which runs ruby_parser (and limited to syntax supported by >> ruby_parser). >> > > Very intriguing! I think the use of ruby_parser is probably the best part, > since it will run anywhere. > > The lack of a formal macro system in Ruby seems more and more to be a > serious gap. Most people end up using eval as a poor-man's macro. > Unfortunately, even on the fastest implementations eval is too slow for > critical code (and on some, it's even slower since there's a compile cycle > involved in addition to parsing). Also, because it's parsed at runtime, > you're unlikely to catch syntax errors early enough. > > A formal macro system, especially one built upon Ruby's own syntax and > using a preprocessor, would make it possible to have a syntax-checked and > fast macro implementations. > > I wonder if there might not be some affordance for a cleaner syntax that's > not entirely "pure Ruby" but reduces some of the overhead imposed by Ruby > syntax? ruby_parser itself may likely be the most hackable parser > implementation, so building a better macro syntax on top of it shouldn't be > difficult. And if it works out, perhaps there could be "fast macro > preprocessing" eventually built into Ruby proper. > > - Charlie > > > > > -- Yehuda Katz Developer | Engine Yard (ph) 718.877.1325 --0015174c0f86cf4b270463a34ae8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Matz has repeatedly and explicitly expressed that he did not want Ruby to h= ave macros. That might have changed, but I believe he repeated it recently = at LoneStar RubyConf. I believe Matz has argued that macros are too complex= for the average programmer...

-- Yehuda

2009/2/23 Charles Oliver Nu= tter <charle= s.nutter@sun.com>
James M. Lawrence wrote:
After looking at a few ruby_parser examples, in just 40 lines of code
I was able to write a transformer which allowed me to define the
seamless locals_to_hash I wanted. =A0This runs on 1.8, 1.9, and jruby -- anything which runs ruby_parser (and limited to syntax supported by
ruby_parser).

Very intriguing! I think the use of ruby_parser is probably the best part, = since it will run anywhere.

The lack of a formal macro system in Ruby seems more and more to be a serio= us gap. Most people end up using eval as a poor-man's macro. Unfortunat= ely, even on the fastest implementations eval is too slow for critical code= (and on some, it's even slower since there's a compile cycle invol= ved in addition to parsing). Also, because it's parsed at runtime, you&= #39;re unlikely to catch syntax errors early enough.

A formal macro system, especially one built upon Ruby's own syntax and = using a preprocessor, would make it possible to have a syntax-checked and f= ast macro implementations.

I wonder if there might not be some affordance for a cleaner syntax that= 9;s not entirely "pure Ruby" but reduces some of the overhead imp= osed by Ruby syntax? ruby_parser itself may likely be the most hackable par= ser implementation, so building a better macro syntax on top of it shouldn&= #39;t be difficult. And if it works out, perhaps there could be "fast = macro preprocessing" eventually built into Ruby proper.

- Charlie







--
Yehuda Katz
Develope= r | Engine Yard
(ph) 718.877.1325
--0015174c0f86cf4b270463a34ae8--