Re: Proposals that didn't work (was Re: Proposal: allow @, $, !, and ? in Lua identifiers)

[Andrew Starks <andrew.starks@...>]

On Fri, Apr 25, 2014 at 2:18 PM, Sean Conner <sean@conman.org> wrote:
> It was thus said that the Great Andrew Starks once stated:
>>
>> [1] For me, there are a couple of things I'd like to try: some kind of
>> ability to adorn structured objects with type information being the
>> one that pops to my mind. I've done that already and I like it. Once I
>> go all of the way with the idea, I'll see if it's useful or not. So
>> far, given the handful of experiments that I've tried, only two have
>> survived:
>>
>> "Hello, %s!"  % {"world"}
>> --and
>> local my_table = type.new({}, "foo_type")
>>
>> print(type.tostring(my_table), type(my_table, "foo_type"))
>> --> "foo_type", true
>>
>> The rest of my "holy crap wouldn't it be awesome if..." ideas are in
>> the garbage dump. Be glad nobody listened to me, either. :)
>
>   I, for one, would like to know what you proposed, tried out, rejected and
> why it was rejected.  Yes, it was a failure, but if you document it, then
> others can learn why that "cool idea" might not have been such a "cool
> idea".
>
>   -spc (Please?)
>
>

One that I tried was:

local function foo{a = 3, y = {key = my_value, z = {"hello", "foo"}}
  --do stuff
end

When I had posted this idea to the mailing list I thought it was
genius. It was pointed out that there was ambiguity with nested
values, but that didn't seem like a big issue. So I poked at the
parser for a while, got signs of life, which helped me see the really
obvious problem.

What I hoped wanted the above to translate to was:

local function foo(a, y)
  local a = a or 3
  local y = y or --the above table..

end

Seems easy enough, except,this isn't really what it should translate
to. Instead:

local function foo(arg? or what?)
  arg.a = arg.a or 3
  arg.y = arg.y or --the above table

end

Understanding this, the question of nested defaults seemed more
important, as it seemed inconsistent to only do those defaults on the
first level, given that I'm making up fields for this new anonymous
table that I'm naming "arg", a name which would never fly with
existing codebases. But that didn't seem pragmatic because, where
would it end? Some of the above was an experiment and much of it was
also me hyperventilating on this list that it would be "awesome if
Lua..." There, I was told by Roberto to "use comments instead." Seemed
like sage advice.


Second experiment: Making corotables.

I had adorned the coroutine library to support receiving a table with
a "__coroutine" (for create) and "__thread" field set in the
metatable. If it got that, it would basically treat it as it would a
function. Then, the __call method on that table basically forwarded to
the __thread, such that it acted as "coroutine.wrap". I think that I
also made it work so you could also use the coroutine methods on the
actual table, like string does:

my_thread:resume(args, go, here)

 [at least that's how I remember it...]

It all worked fine, until I realized that it was stupid because the
real motivation was to allow other threads to inspect state variables
and coroutines with exposed data in tables never seemed to work out as
a great idea.

When I'm using coroutines, I like my data declared as locals, right in
the coro, not hidden in a table that I now need to check to see if
someone somewhere else had messed with those values. Had I made the
table's values read-only, it might have been fine, but then to update
the state from within the coro, I needed to use some kind of special
magic..

At the end of the day, it was just overhead that was solving a
non-problem that could be not solved with other facilities.

I could go on some more, but meh. Those are two of the most recent. I
do have some other minor patches to math, but again, meh. They work
well for me but I'm not everyone else and I can't say whether or not
they'd generally work well for others. I do know they'd be slightly
slower. :)

Lua is so flexible that it promotes these kinds of tangents. They are
fun and they are great exercises to endeavor upon. I learned quite a
lot in the process, actually. So in that sense, they were completely
worth it, even if the efforts are nothing more than tuition paid
towards my experience in expressing solutions to problems using stored
programs on binary digital computing equipment.

-Andrew