Re: Lua style guide ?

[Martin <eden_martin_fuhrspam@...>]

On 06/11/2017 11:15 PM, Russell Haley wrote:
> On Sun, Jun 11, 2017 at 11:10 PM, Sean Conner <sean@conman.org> wrote:
>> It was thus said that the Great Martin once stated:
>>> And by the way, are there good ways to test such formatter? Creating yet
>>> another rock with name like "lcf.experiments" looks like a bad idea.
>>
>>   I'm not sure what you are asking here.
> 
> Github would be my go-to.

Yes, the question was how better represent such narrow tool. Probably
yes, github project is best option. No installation script, but you have
to call "lua <script_name> <params>" by hand.


On 06/11/2017 11:10 PM, Sean Conner wrote:
> It was thus said that the Great Martin once stated:
>> Function in Lua may be defined in three ways:
>>
>> 1. "local function <name> (<args>)" //<name> can't contain ":" syntel
>> 2. "function <name> (<args>)"
>> 3. "function (<args>)"
>
>   Actually, you have:
>
> 	1. function <name>(<args>)
> 	2. local function <name>(<args>)
> 	3. function <name>.<name>(<args>) -- defined on a table
> 	4. function <name>:<name>(<args>) -- also defined on a table
> 	5. function (<args>) -- anonymous function

Looks like we're both incorrect. There are three ways of declaring
functions I know, yours cases 1. 3. and 4. may be united to
syntactically correct sample "t = {f = {}} function t.f:a() end". So
there are still three ways.

  name =  // alphanumeric word
  params = "(" list_of_parameters ")"  // not defined further
  local_function = "local" "function" <name> <params>  // (1)
  function_name = (<name> ".")* <name> [":" <name>]
  global_function = "function" <function_name> <params>  // (2)
  function_value = "function" <params>  // (3)


On 06/11/2017 11:14 PM, Russell Haley wrote:
> 1) undocumented code: Generate the headers to eliminate the
> mental/time barrier of "having to write all that". It would be far
> easier to fill it in then having to transcribe the @ soup.
> 2) To check the relevance or changes to existing comments. I would see
> such a parser "commenting out" entries that are no longer relevant and
> adding new ones, as well as being able to generate the headers in a
> seperate file.

Thank you for usage cases. I see that tool to be practical should parse
both lua code and ldoc comments.

Is there a formal grammar for ldoc comments? (In particular is there any
difference between "short" and "long" doc block representation? Where
whitespaces matters?)

-- Martin