Re: Metaprogramming

[Carlos Pita <carlosjosepita@...>]

If you do a lot of work with tables you will dislike the syntax:

table{ ....}end

and certainly won't consider {} syntax sugar.

Similarly, if your coding style relies a lot on higher order functions
you may find:

function()....end

too noisy in contexts like:

seq:foreach(....) or

seq:map(....) or, worst:

switch(
   ...., ....,
   ...., ....,
   ...
)

Lua semantics doesn't preclude this coding style at all (which, btw,
is not just about toy dsls). But it syntax discourages it.

I really can't see the ton of effort for a little return here.



On Sat, Jul 5, 2014 at 10:13 PM, William Ahern
<william@25thandclement.com> wrote:
> On Sat, Jul 05, 2014 at 12:41:19PM +0200, steve donovan wrote:
>> On Fri, Jul 4, 2014 at 9:16 PM, Carlos Pita <carlosjosepita@gmail.com> wrote:
>> > standard function calling syntax & semantics plus some lambda shortcut
>> > like | ... | could go a long way in the direction of implementing
>> > custom control structures or language constructs, without requiring
>> > macro support at all.
>>
>> I appreciate this point as well;  although I went to trouble to get
>> LuaMacro right, I no longer believe that ad-hoc syntax extension is
>> appropriate for code shared with other people[1]. I'm also a fan of
>> the |...| syntax that's enabled with GSL Shell - the author's
>> rationale is that it makes interactive experimentation less verbose.
>> But there doesn't seem much chance of it making into mainstream Lua.
>>
>> Another approach is to use a different but consistent notation for Lua
>> programs, for example Moonscript - this has a lightweight function
>> syntax. Together with the very low precedence of the call operator
>> this makes it an excellent candidate for implementing DSLs.  It
>> compiles to straightforward Lua and so access to the Lua ecosystem
>> (and LuaJIT) is straightforward.
>>
>> For instance, defining a function is straightforward:
>>
>> sqr = (x) -> x^2
>>
>> Table sorting (note the low call operator precedence)
>>
>> table.sort t, (x,y) -> x.name > y.name
>>
>> You could argue that this isn't Lua any more, but then neither would
>> be any customized dialect... one sacrifices the syntactical simplicity
>> of Lua for a gain in expressiveness. [2]
>>
>> steve d.
>
> I never understood DSLs which did little more than add syntactic sugar and
> some object management automation. The last DSL I wrote for Lua was an
> event-oriented, declarative language for a mail server. Using a simple
> declarative syntax which wrapped small blocks of plain Lua code, I could
> easily introspect the filtering code to optimize execution of events
> including automatic short-circuiting, parallelization, and conflict
> detection. And the declarative syntax made it incredibly easy to define
> rules which previously had grown (over a decade of feature accretion) into a
> horrendous mess of parameters and configuration tables.
>
> When I think of DSLs that's the kind of power I see; not the ability to code
> more efficiently in the exact same paradigm. That's a ton of effort and
> expense for comparatively little return.
>
> Depending on one's preferences I can understand the desire to tweak various
> elements of Lua. But if someone is just tweaking things so they can more
> easily implement precisely the same solution, just a little more
> elegantly... I don't get that.
>