Thought experiment: what would you remove from Lua

classic Classic list List threaded Threaded
100 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Dirk Laurie-2
2018-08-01 19:57 GMT+02:00 Phil Leblanc <[hidden email]>:

> On Tue, Jul 31, 2018 at 6:16 PM, Dibyendu Majumdar
> <[hidden email]> wrote:
>> Are there features in Lua that could be removed to create a simpler language?
>
> Thought experiment level 1:
>
> -- Remove all special metamethods keys ("__add" and friends, including
> __len),  excluding __index, __newindex and __gc
>
> Thought experiment level 2:
>
> -- Remove metatables
>
> i.e. less "object-oriented" things. Going more with plain functions,
> tables of functions and closures.
>
> Remember, this is NOT my wish list for a future Lua! :-)  and I don't
> know how much simpler it would make the language implementation

In fact, it is a nostalgia list for a previous Lua: 4.0 had no
metatables (but it did have tag methods).

Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Phil Leblanc
On Wed, Aug 1, 2018 at 2:46 PM, Dirk Laurie <[hidden email]> wrote:
[...]

>> Thought experiment level 1:
>>
>> -- Remove all special metamethods keys ("__add" and friends, including
>> __len),  excluding __index, __newindex and __gc
>>
>> Thought experiment level 2:
>>
>> -- Remove metatables
>>
>> i.e. less "object-oriented" things. Going more with plain functions,
>> tables of functions and closures.
>>
[...]
>
> In fact, it is a nostalgia list for a previous Lua: 4.0 had no
> metatables (but it did have tag methods).
>

Well, not nostalgia since I discovered Lua around the 5.0/5.1
transition.  And I really like many recent Lua features (mostly the
64-bit integer subtype, the bit operators and the built-in string
pack/unpack functions).

Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Dibyendu Majumdar
In reply to this post by Dirk Laurie-2
On 1 August 2018 at 19:46, Dirk Laurie <[hidden email]> wrote:

> 2018-08-01 19:57 GMT+02:00 Phil Leblanc <[hidden email]>:
>> Thought experiment level 2:
>>
>> -- Remove metatables
>>
>> i.e. less "object-oriented" things. Going more with plain functions,
>> tables of functions and closures.
>>
> In fact, it is a nostalgia list for a previous Lua: 4.0 had no
> metatables (but it did have tag methods).
>

Meta tables are indeed another problematic feature from optimization
point of view. Of course it seems grand that the table type is reused
to hold meta information too - wonderful unifying design! Except that
now an implementation detail has become user visible, and the
implementor has no way of knowing what the user might do.

The more you allow users to mess with 'meta' information, including
stacks, in uncontrolled ways, the harder it becomes to implement
efficient implementations (unless you are a genius called Mark Pall).

I guess every feature enacts a price. A beautiful coherent design from
one view may be a poor design from another point of view!

Regards
Dibyendu

Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Dirk Laurie-2
2018-08-01 21:19 GMT+02:00 Dibyendu Majumdar <[hidden email]>:

> The more you allow users to mess with 'meta' information, including
> stacks, in uncontrolled ways, the harder it becomes to implement
> efficient implementations (unless you are a genius called Mark Pall).

You don't by any chance mean Mike Pall?

Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Sean Conner
In reply to this post by Dibyendu Majumdar
It was thus said that the Great Dibyendu Majumdar once stated:

> On 1 August 2018 at 00:10, Coda Highland <[hidden email]> wrote:
> > On Tue, Jul 31, 2018 at 5:16 PM, Dibyendu Majumdar
> > <[hidden email]> wrote:
> >> Are there features in Lua that could be removed to create a simpler language?
> >>
> >> Of course 'simpler' needs to be defined.
> >>
> >> Simpler for users?
> >> Simpler for implementors?
> >>
> >> Often these are conflicting goals.
> >>
> >> I, for instance, never use co-routines ... and I know they add a bunch
> >> of complexity both from implementation and user point of view.
> >>
>
> > Coroutines are one of those things that are hard to understand and you
> > can go for years without ever having a use case for them, but then one
> > day you find a need for them and they make all the difference in the
> > world.
> >
>
> Maybe ...
>
> What triggered this thought experiment was a recent talk on Ruby:
>
> https://youtu.be/4vxIncIm2D4
>
> We also have Roberto's talk on the cost of adding features to Lua:
>
> https://youtu.be/EUvgoxBm7uc
>
> As someone trying to optimize Lua, I am very much aware of the
> implementation cost of some features.
>
> For instance:
>
> 1) upvalues in Lua are like pointers to stack locations.

  Upvalues are required if you want to support closures.  Drop closures, and
Lua becomes less useful as a language.

> 2) Debug api can manipulate values on the stack

  Yeah ... it's for debugging.

> 3) C api can mess with the stack

  Yes, needed if you want to interface with C.

> All of these features are nice I am sure but, you have to pay a heavy
> price in terms of the ability to optimize code.

  You don't do much with C based modules, do you?

> I am surprised no one mentioned dropping boolean type by the way ...

  You are aware that booleans were added to support a nil-like value in
sequences, right?

  -spc (If I want to program in a language that lacks closures, upvalues,
        and no booleans, then I'd stick with C ... )

Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Sean Conner
In reply to this post by Coda Highland
It was thus said that the Great Coda Highland once stated:
>
> 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
> VM/JIT/whatever doesn't have to worry about it. The Javascript
> 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.

  You would still need to inform the compiler what the blocking points are
and ... no.  Just no.  

  -spc (You can pry coroutines from my cold dead hands ... )


Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Sean Conner
In reply to this post by Dibyendu Majumdar
It was thus said that the Great Dibyendu Majumdar once stated:

> On 1 August 2018 at 19:46, Dirk Laurie <[hidden email]> wrote:
> > 2018-08-01 19:57 GMT+02:00 Phil Leblanc <[hidden email]>:
> >> Thought experiment level 2:
> >>
> >> -- Remove metatables
> >>
> >> i.e. less "object-oriented" things. Going more with plain functions,
> >> tables of functions and closures.
> >>
> > In fact, it is a nostalgia list for a previous Lua: 4.0 had no
> > metatables (but it did have tag methods).
> >
>
> Meta tables are indeed another problematic feature from optimization
> point of view.

  You *really* don't use C-based modules at all, do you?  Because without
metatables, userdata becomes rather useless.

> Of course it seems grand that the table type is reused
> to hold meta information too - wonderful unifying design! Except that
> now an implementation detail has become user visible, and the
> implementor has no way of knowing what the user might do.

  Can't trust those programmers, can you?

  -spc

Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Dibyendu Majumdar
In reply to this post by Dirk Laurie-2
On 1 August 2018 at 20:44, Dirk Laurie <[hidden email]> wrote:
> 2018-08-01 21:19 GMT+02:00 Dibyendu Majumdar <[hidden email]>:
>
>> The more you allow users to mess with 'meta' information, including
>> stacks, in uncontrolled ways, the harder it becomes to implement
>> efficient implementations (unless you are a genius called Mark Pall).
>
> You don't by any chance mean Mike Pall?
>

Indeed I meant Mike Pall (a certain Mark was on my mind as I had been
watching a talk on Java Stewards) - thank you for the correction!

Regards
Dibyendu

Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Dibyendu Majumdar
In reply to this post by Sean Conner
Hi Sean,

On 1 August 2018 at 21:04, Sean Conner <[hidden email]> wrote:

> It was thus said that the Great Dibyendu Majumdar once stated:
>> On 1 August 2018 at 19:46, Dirk Laurie <[hidden email]> wrote:
>> > 2018-08-01 19:57 GMT+02:00 Phil Leblanc <[hidden email]>:
>> >> Thought experiment level 2:
>> >>
>> >> -- Remove metatables
>> >>
>> >> i.e. less "object-oriented" things. Going more with plain functions,
>> >> tables of functions and closures.
>> >>
>> > In fact, it is a nostalgia list for a previous Lua: 4.0 had no
>> > metatables (but it did have tag methods).
>> >
>>
>> Meta tables are indeed another problematic feature from optimization
>> point of view.
>
>   You *really* don't use C-based modules at all, do you?  Because without
> metatables, userdata becomes rather useless.
>

Apologies I don't mean to argue. But maybe you are thinking of meta methods?

Regards
Dibyendu

Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Sean Conner
It was thus said that the Great Dibyendu Majumdar once stated:

> Hi Sean,
>
> On 1 August 2018 at 21:04, Sean Conner <[hidden email]> wrote:
> > It was thus said that the Great Dibyendu Majumdar once stated:
> >> On 1 August 2018 at 19:46, Dirk Laurie <[hidden email]> wrote:
> >> > 2018-08-01 19:57 GMT+02:00 Phil Leblanc <[hidden email]>:
> >> >> Thought experiment level 2:
> >> >>
> >> >> -- Remove metatables
> >> >>
> >> >> i.e. less "object-oriented" things. Going more with plain functions,
> >> >> tables of functions and closures.
> >> >>
> >> > In fact, it is a nostalgia list for a previous Lua: 4.0 had no
> >> > metatables (but it did have tag methods).
> >> >
> >>
> >> Meta tables are indeed another problematic feature from optimization
> >> point of view.
> >
> >   You *really* don't use C-based modules at all, do you?  Because without
> > metatables, userdata becomes rather useless.
>
> Apologies I don't mean to argue. But maybe you are thinking of meta methods?

  Yes, which require metatables to store.  You can also set the __index meta
method to said metatable to index methods other than the meta methods
without having to write a custom __index function (ore __newindex function
for that matter).  So you can do things like:

        data = file:read()

Yes, that is syntactic sugar for

        data = file.read(file)

but without the metatable on file containing __index pointing to itself, you
then have to do

        data = io.read(file)

and you lose the ability to pass in something that isn't the result of
io.open() to code but does have the ability to return data like io.read()
does, say, from, a socket or a mocked file.

  -spc


Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Dibyendu Majumdar
On 1 August 2018 at 21:18, Sean Conner <[hidden email]> wrote:
>> >> Meta tables are indeed another problematic feature from optimization
>> >> point of view.
>> >
>> >   You *really* don't use C-based modules at all, do you?  Because without
>> > metatables, userdata becomes rather useless.
>>
>> Apologies I don't mean to argue. But maybe you are thinking of meta methods?
>
>   Yes, which require metatables to store.

Sorry you didn't get my point at all. I was specifically talking about
using standard Lua tables as an implementation approach - its nothing
to do with the functional goal .

Regards

Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Sean Conner
It was thus said that the Great Dibyendu Majumdar once stated:

> On 1 August 2018 at 21:18, Sean Conner <[hidden email]> wrote:
> >> >> Meta tables are indeed another problematic feature from optimization
> >> >> point of view.
> >> >
> >> >   You *really* don't use C-based modules at all, do you?  Because without
> >> > metatables, userdata becomes rather useless.
> >>
> >> Apologies I don't mean to argue. But maybe you are thinking of meta methods?
> >
> >   Yes, which require metatables to store.
>
> Sorry you didn't get my point at all. I was specifically talking about
> using standard Lua tables as an implementation approach - its nothing
> to do with the functional goal .

  That was not clear at all.

  It also seems you have problems with the C API and the debug module and
would like to see those go away as well (or downplayed as much as possible
because they complicate the design of a JIT for Lua).

  -spc


Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Sean Conner
In reply to this post by Dibyendu Majumdar
It was thus said that the Great Dibyendu Majumdar once stated:

> On 1 August 2018 at 19:46, Dirk Laurie <[hidden email]> wrote:
> > 2018-08-01 19:57 GMT+02:00 Phil Leblanc <[hidden email]>:
> >> Thought experiment level 2:
> >>
> >> -- Remove metatables
> >>
> >> i.e. less "object-oriented" things. Going more with plain functions,
> >> tables of functions and closures.
> >>
> > In fact, it is a nostalgia list for a previous Lua: 4.0 had no
> > metatables (but it did have tag methods).
> >
>
> Meta tables are indeed another problematic feature from optimization
> point of view. Of course it seems grand that the table type is reused
> to hold meta information too - wonderful unifying design! Except that
> now an implementation detail has become user visible, and the
> implementor has no way of knowing what the user might do.
>
> The more you allow users to mess with 'meta' information, including
> stacks, in uncontrolled ways, the harder it becomes to implement
> efficient implementations (unless you are a genius called Mark Pall).

  So, how would you implement meta information then?  What, specifically, is
difficult with the current design?

  -spc


Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Dibyendu Majumdar
In reply to this post by Sean Conner
On 1 August 2018 at 21:27, Sean Conner <[hidden email]> wrote:
>> Sorry you didn't get my point at all. I was specifically talking about
>> using standard Lua tables as an implementation approach - its nothing
>> to do with the functional goal .
>
>   That was not clear at all.

Okay my bad then. I thought it was clear in the context of Dirk's
comment about how Lua 4.0 did it differently.

>
>   It also seems you have problems with the C API and the debug module and
> would like to see those go away as well (or downplayed as much as possible
> because they complicate the design of a JIT for Lua).
>

Just making my position clear if it hasn't been given my past posts
here. I am strongly against breaking backward compatibility. So I will
never argue for breaking changes in Lua.

This is an academic discussion - a thought experiment. It is not a
plea to change Lua.

Regards
Dibyendu

Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Phil Leblanc
In reply to this post by Sean Conner
On Wed, Aug 1, 2018 at 4:04 PM, Sean Conner <[hidden email]> wrote:

> It was thus said that the Great Dibyendu Majumdar once stated:
>> On 1 August 2018 at 19:46, Dirk Laurie <[hidden email]> wrote:
>> > 2018-08-01 19:57 GMT+02:00 Phil Leblanc <[hidden email]>:
>> >> Thought experiment level 2:
>> >>
>> >> -- Remove metatables
>> >>
>> >> i.e. less "object-oriented" things. Going more with plain functions,
>> >> tables of functions and closures.
>> >>
[...]
>>
Meta tables are indeed another problematic feature from optimization
>> point of view.
>
>   You *really* don't use C-based modules at all, do you?  Because without
> metatables, userdata becomes rather useless.

I wouldn't say "useless". Maybe more risky, or more inconvenient?

I think that Dibyendu's thought experiment objective is not to find
features that you can remove and get an as good and convenient
language as Lua is today.

My understanding is that the objective is to find a subset, or a
simplified dialect of Lua that could be more efficiently compiled (or
interpreted?). Such a dialect would be simpler, lower-level at some
places, maybe rougher for the developer. These would be trade-offs for
a higher execution speed (or a smaller implementation).

I find the exercise interesting :-)

Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Coda Highland
In reply to this post by Sean Conner
On Wed, Aug 1, 2018 at 3:02 PM, Sean Conner <[hidden email]> wrote:

> It was thus said that the Great Coda Highland once stated:
>>
>> 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
>> VM/JIT/whatever doesn't have to worry about it. The Javascript
>> 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.
>
>   You would still need to inform the compiler what the blocking points are
> and ... no.  Just no.
>
>   -spc (You can pry coroutines from my cold dead hands ... )
>

You misunderstand: The recommendation is to PRESERVE the coroutine
syntax and do a preprocessing pass to translate that into something
more amenable to efficient VM implementation. As mentioned, this is
what the Javascript community has been doing for a couple years. The
yield statement gets transformed behind the scenes into returning some
sort of state object that can be used to resume execution.

Under no circumstances would I want to remove coroutines from the
actual language syntax, because they are far too useful.

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Andrew Starks-2
In reply to this post by Coda Highland


On Wed, Aug 1, 2018 at 1:25 PM, Coda Highland <[hidden email]> 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
VM/JIT/whatever doesn't have to worry about it. The Javascript
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 meta-programming. JavaScripts lack of a concurrency framework requires 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
Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Coda Highland
On Wed, Aug 1, 2018 at 4:01 PM, Andrew Starks <[hidden email]> wrote:

>
>
> On Wed, Aug 1, 2018 at 1:25 PM, Coda Highland <[hidden email]> 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
>> VM/JIT/whatever doesn't have to worry about it. The Javascript
>> 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
> meta-programming. JavaScripts lack of a concurrency framework requires
> 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

By that definition, working on the interpreter itself is
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?

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Andrew Starks-2


On Wed, Aug 1, 2018 at 4:50 PM, Coda Highland <[hidden email]> wrote:
On Wed, Aug 1, 2018 at 4:01 PM, Andrew Starks <[hidden email]> wrote:
>
>
> On Wed, Aug 1, 2018 at 1:25 PM, Coda Highland <[hidden email]> 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
>> VM/JIT/whatever doesn't have to worry about it. The Javascript
>> 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
> meta-programming. JavaScripts lack of a concurrency framework requires
> 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

By that definition, working on the interpreter itself is
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?

/s/ Adam


I can't help but think we're saying exactly the same thing. Meta programming isn't bad. It does happen and it just is. Another way to look at it is attempted growth or mutations to the language. The ones that stick and have wide use are either sufficient as libraries or big red flags that demark potential areas for change that might result in more simplicity.

Type is a great example. Lua has a little type but not a lot. It's tempting to want to extend type in the core language, but then you realize that testing takes care of a lot of the reasons why you want to check for object type. And so a type library does not come to be a required library to download in order to "really use Lua". Often you might find yourself looking in a `._class` field or something. But people do this and while there may be benifits to providing such features  or enforcing limitations in the language, those decisions cut off possibilities. And that's pretty much what designing a language must come down to.
--
Andrew Starks
612 840 2939
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Thought experiment: what would you remove from Lua

Coda Highland
On Wed, Aug 1, 2018 at 5:07 PM, Andrew Starks <[hidden email]> wrote:

>
>
> On Wed, Aug 1, 2018 at 4:50 PM, Coda Highland <[hidden email]> wrote:
>>
>> On Wed, Aug 1, 2018 at 4:01 PM, Andrew Starks <[hidden email]>
>> wrote:
>> >
>> >
>> > On Wed, Aug 1, 2018 at 1:25 PM, Coda Highland <[hidden email]>
>> > 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
>> >> VM/JIT/whatever doesn't have to worry about it. The Javascript
>> >> 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
>> > meta-programming. JavaScripts lack of a concurrency framework requires
>> > 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
>>
>> By that definition, working on the interpreter itself is
>> 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?
>>
>> /s/ Adam
>>
>
> I can't help but think we're saying exactly the same thing. Meta programming
> isn't bad. It does happen and it just is. Another way to look at it is
> attempted growth or mutations to the language. The ones that stick and have
> wide use are either sufficient as libraries or big red flags that demark
> potential areas for change that might result in more simplicity.
>
> Type is a great example. Lua has a little type but not a lot. It's tempting
> to want to extend type in the core language, but then you realize that
> testing takes care of a lot of the reasons why you want to check for object
> type. And so a type library does not come to be a required library to
> download in order to "really use Lua". Often you might find yourself looking
> in a `._class` field or something. But people do this and while there may be
> benifits to providing such features  or enforcing limitations in the
> language, those decisions cut off possibilities. And that's pretty much what
> designing a language must come down to.
> --
> Andrew Starks
> 612 840 2939
> [hidden email]

Oh, I see. I had interpreted your proposed border as being a rubric
for acceptance instead of a sign of where further consideration is
needed. Especially since I'm a C++ programmer, I get a lot of
"metaprogramming bad!" responses from people when the subject comes
up.

I can certainly agree that tasks that require metaprogramming should
be looked at as informative use cases for language design. The need
should be addressed one way or the other, whether by "there's already
a simpler way to do that" on the one hand or "that's useful enough to
be incorporated" on the other.

/s/ Adam

12345