lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]




On Nov 7, 2007 2:33 PM, David Given <dg@cowlark.com> wrote:
steve donovan wrote:
> The variable match syntax is nice and very general. My only concern is
> that the pipe character tends to have other associations. Is it
> Lua-ish?

It looks stolen from functional languages

It is, it's directly taken from OCaml actually, except for the "end" keyword and the use of "if" rather than "when" (Just to avoid reserving yet another keyword, when "if" is very readable).

You're right that it's not extremely luaish, this is a matter regularly raised by users. This syntax has the visual advantage of letting patterns stand out visually. The main improvement of this extension is the improved readability: patterns are easy to read and can replace several line long tests; moreover, in most cases when doing struture manipulations, you have to choose a matching pattern among a dozen or so, having them all nicely lined up helps doing so.

A possible alternative syntax is:

match k
with 10, 11               do return 1 end
with 12                   do return 2 end
with i if 13<=i and i<=16 do return 3 end

This is quite close to your proposal, except that the "end" keyword usages is slightly more idiomatic IMO. But I don't find this as readable, and I'm not sure what's the optimal readability/idiomaticity compromize. And anyway, as stated here and there in my mailing list rants, I think people tend to give more importance than required to superficial syntax matters.

Steve wrote:
My only concern is that the pipe character tends to have other associations

To people coming from a functional programming background, where this construct is most important, it's quite as intuitive an association as it comes :)

Steve wrote:
> a table matches if [many arcane conditions involving a full moon the the captain's age]

That's starting to get complicated.  The rules must be obvious. And
what if that table redefined equality properly, and we matched it
against an instance of the same class?
 
Again, the design is driven by pragmatic needs. The current semantics is adapted to the use of tables as algebraic datatypes (mainly ASTs). I must admit that my formulation is a bit scary, and the "official" doc is outdated IIRC, but that semantics quickly feels intuitive and appropriate when used for the intended purpose. That's by far the metalua extension I use the most, and therefore probably the most used metalua extension ever, and it's been really fine tuned to actual use cases. That's one of the reasons why the doc is out of sync with the code.

If you can think of actual, significant situations where you'd need a different or extended semantics, I'm eager to know about them.