Scoped variable *toclose syntax

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Scoped variable *toclose syntax

Lorenzo Donati-3
On 25/04/2019 14:51, Roberto Ierusalimschy wrote:

>> I would suggest that the syntax should be:
>>
>> <special character><optional name><optional table with only literal
>> keys and values>
>>
>> So assuming your choice of !, we could have:
>>
>> local a!
>> local b !go_to_space { when=true }
>> local c !array { 20 }
>>
>> By allowing an optional table after the name would enable a whole host
>> of possibilities without breaking the lexer / parser I hope.
>
> Personal tastes aside, I fail to see how this differ from the current
> status. These variations would work there, too:
>

I didn't follow Lua 5.4 development threads closely, so mine is just an
opinion on the specific choice of the "sigil": I find the "*" character
in that role very distracting.

I would prefer something that didn't interfere with my "embedded parser"
for current Lua (multiplication operator) and C
(multiplication/pointers). Using something like "@" would, IMO, reduce
short-term memory overload when parsing declarations. [1]

This would be more so if, as discussed in other parts of this thread,
the syntax will be adopted for other "annotations" in the future.

[snip]
> -- Roberto
>
>

Just my 2 EURcent.

Cheers!

-- Lorenzo

[1] On a related note I'm lately in the process of reading an
interesting book [2] available online who analyzes the C99 standard
clause by clause.

One of its purposes is to develop rational and scientific grounds for
creating coding guidelines that reduce the cost of SW ownership written
in C.

It contains extensive sections on perception and cognitive psychology in
which the author [3] analyzes the impact of developer "brain
characteristics" when performing code-related activities (e.g. the
different modes in which a developer reads code). Although it focuses on
C and makes some remarks about applicability to C++ (and in minor ways
to other languages like Java and Ada), I think its general approach
could be applied to any language.

Indeed, my comment to the current thread in this message was actually
influenced by the content of this book.


[2] http://www.knosof.co.uk/cbook/cbook.html

[3] Derek M. Jones (a former head of the UK delegation at WG14 C
language committee and compiler writer himself).

12