[#70252] Re: [ruby-cvs:58640] nobu:r51492 (trunk): node.c: NODE_ALLOCA for ALLOCV — Eric Wong <normalperson@...>
Besides possible backwards compatibility, can we drop volatile
3 messages
2015/08/05
[#70257] [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI — ko1@...
Issue #11420 has been reported by Koichi Sasada.
11 messages
2015/08/06
[#70337] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— Eric Wong <normalperson@...>
2015/08/11
Nice. Thank you guys for looking into this.
[#70349] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— Eric Wong <normalperson@...>
2015/08/12
Btw, did you consider using flexible array to avoid extra malloc
[#70355] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— Юрий Соколов <funny.falcon@...>
2015/08/12
I thought to suggest to embed hash_id_table directly into places when it is
[#70356] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— SASADA Koichi <ko1@...>
2015/08/12
On 2015/08/13 4:29, Юрий Соколов wrote:
[#70358] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— Eric Wong <normalperson@...>
2015/08/12
SASADA Koichi <ko1@atdot.net> wrote:
[#70509] [Ruby trunk - Misc #11276] [RFC] compile.c: convert to use ccan/list — ko1@...
Issue #11276 has been updated by Koichi Sasada.
3 messages
2015/08/21
[#70639] the undefined behavior of an iterator if it is modified inside of the block to which it yields — Daniel Doubrovkine <dblock@...>
(this is my first time e-mailing list list, so apologies for any misstep :)
4 messages
2015/08/31
[ruby-core:70511] [Ruby trunk - Feature #11475] AST transforms
From:
nobu@...
Date:
2015-08-21 10:45:14 UTC
List:
ruby-core #70511
Issue #11475 has been updated by Nobuyoshi Nakada. Project changed from CommonRuby to Ruby trunk Do you have any ideas for the API? ---------------------------------------- Feature #11475: AST transforms https://bugs.ruby-lang.org/issues/11475#change-53912 * Author: Josep M. Bach * Status: Open * Priority: Normal * Assignee: ---------------------------------------- Even though Ruby is in many ways an acceptable Lisp, extending the language itself is a hard endeavour. By using reflection/meta-programming and taking advantage of its rich grammar, it's certainly possible to bend the language in extreme ways (believe me, I've done it), but there are a couple of serious limitations: * Everything must be done at run-time, incurring in necessary overhead, sometimes unacceptably so. * The resulting code must be valid Ruby not only syntactically, but also semantically. That forbids the introduction of new semantic constructs by users themselves. Now, some people might argue in favour of a special DSL for compile-time macro-building, possibly augmenting the grammar and introduce all sorts of new tricks to do that. But I think that wouldn't be the most general solution, nor the most desirable. The alternative: a simple, object-oriented AST transforms API. By building an AST transforms API and making it available to users, I argue that we could kill many birds with one stone: * A rich macro system (or many!) could be implemented as a simple library, with no changes to core ruby. * Some micro-optimizations could be implemented as a library, which may find their way into core ruby later. * Experimental, new semantic constructs could be made available to users through simple libraries, and when time has proven their usefulness, maybe they could be implemented natively, if needed. I'd be up for the task if there is enough interest -- what are people's thoughts on this? -- https://bugs.ruby-lang.org/