Re: [Proposal] Lua-y lambda syntax

[Jay Carlson <nop@...>]

On Apr 29, 2017 3:02 AM, "steve donovan" <steve.j.donovan@gmail.com> wrote:

On Sat, Apr 29, 2017 at 1:36 AM, Jay Carlson <nop@nop.com> wrote:
> My favorite method (but alas the one I use least) is to parse a string at runtime and turn it into a Lua function. So taking the Wikipedia LINQ C# example, it would look something like:
>
> results =  linq[[
>   from c in SomeCollection
>   where c.SomeProperty < 10
>   select new {c.SomeProperty, c.OtherProperty} ]]
>
> for result in ipairs(results) do
>   print(result)
> end

I did something like this for constructing queries for columnar data:

http://stevedonovan.github.io/Penlight/api/manual/06-data.md.html#Reading_Columnar_Data

I should just get used to glancing that manual again before opening my mouth. As usual with pl, It's In There.

BTW, I think there are two kinds of SQL[1] bindings for Lua: single-target, and ones with SQL mini parsers--because you can't do portable parameterized queries, and if you don't need parameterized queries in a program, why are you using SQL?

What's pl's compatibility profile these days? 5.1+5.2? I've been avoiding doing it seriously, but the still-on-rushing JSON juggernaut[2] suggests a need for jsom. 

As for macros, I was a believer. But experience suggests that ad-hoc
syntax has to be very carefully designed - harder than writing good
libraries.  Design sense is relatively rare in the universe.

Yeah. If there's something that needs curation, it's macros. Netrek had a Frequently Offered Clever Suggestions (FOCS) list which explained in detail why your idea wouldn't fit the game. (The temptation to bat away anything new helped kill netrek.)

Jay

[1]: SQL is pronounced "squeal".

[2]: Grumpy: JSON is for people who never really understood when in XML something is an attribute vs when it is PCDATA. If you wanna see it done right, go read the Atom RFC.[3]

Also, JSON has introduced a generation of programmers to how marshaling is the nearly most trivial of problems when designing specific network protocols for an app. What was that about design sense being rare?

Finally, for non-private protocols there will be a mismatch between the surface expressions and the internal models for it. So we're back to tearing down JSON trees to build our own trees, and you had to do that for XML too.

DTD-less XML should have been standardized and promoted. There have been hundreds of lifetimes lost to the DOM's mechanical _javascript_ binding, so I can sorta see the desire to run away, though...

W3C language-neutral DOM: when you need all the disadvantages of Java style, but none of the advantages either.

[3]: Atom has a significant misdesign: the base for relative URLs cannot be the Atom document itself. I know why it's there, but it means that Atom must be served from somewhere; you can't ship a tarball of your Atom goo without shipping a script to rewrite all the bases to absolute file:/// paths, which depends on where the tarball was extracted.