By that definition, working on the interpreter itself isOn Wed, Aug 1, 2018 at 4:01 PM, Andrew Starks <firstname.lastname@example.org> wrote:
> On Wed, Aug 1, 2018 at 1:25 PM, Coda Highland <email@example.com> wrote:
>> Well, given that coroutines CAN be implemented in terms of other
>> language features, you could implement them at a higher level -- some
>> sort of automated source transformation at parse time so that the
>> community has done this for quite a while now in order to work around
>> lack of browser-side support, and while the generated code is really
>> hard to read it's definitely just mechanical.
>> /s/ Adam
> I think that meta-programming is a useful boarder. Whenever you're adding
> language features into the language that you're programming, you're
> immense amounts of meta-programming and complexity.
> Lua has this too, but mostly for extending existing mechanisms in particular
> directions: cqueues, object libraries and ad hoc type systems.
> I think that wherever there is meta programming, it's good to ask why and
> evaluate whether it's not needed or should be part of the language.
> Andrew Starks
metaprogramming. And while that's technically true -- and other things
like building a source-to-source transpilation tool are also
metaprogramming -- that makes the distinction much less useful for
figuring out what should or shouldn't be part of a language. Because
at some point, SOMEONE has to do some metaprogramming, or else you're
never going to be able to use the language in the first place.
Likewise, it's really not fair to judge a feature by which compiler
pass it's implemented in. That's just an implementation detail and the
design of the language shouldn't have to be concerned about it.
Conversely, a different perspective: If it requires metaprogramming
hackery to be able to do something, isn't that a sign that it's
something that SHOULD be considered for addition to the language, so
that you don't have to do the hacky thing?