let-in statements and anonymous variables

[Vicente J. Botet Escriba]

 Lastly there have been some discussion about RAII constructions. A Java language-like synchronized macro was suggested

   synchronized(expression) statement

The library solution (no macros) is based on RAII factories. This needs to declare a variable on the scope on which the destructor must be called.


   { const auto&& v1 =synchronize(mtx);  statement }


I was wondering if we couldn't extend the language with two features so that the library solution is close to the specific language extension even if we introduce some noise.

The idea is to extend the standard with a statement that introduce a variable (anonymous variable) on a given scope, something as

  let <declaration> in <statement>

In order to avoid new keywords I think that separating the declaration and the statement with ':' could be clear enough.

    statement :
      | <declaration> : <statement>


The following

  auto  = expression : statement

will be equivalent to

  {
    const auto&& __uid__= expression; statement
  }

where __uid__ is a new unique identifier generated by the compiler.
 
With this new statement the preceding change proposals on the language will be solved as

auto&&  = synchronize(mtx) : { ... }

 
Of course the question is if it is worth making minor changes on the language to replace a pure library solution

    {
      const auto&& lk = synchronize(mtx) :
      f();
    }

by
    auto&& = synchronize(mtx) : f();


and
    {
      auto&& lk = synchronize(mtx) :
      // more than one statement
    }

by

    auto&& = synchronize(mtx) :
    {
      // more than one statement
    }


Vicente

[grigor...@gmail.com]

: is bad for that purpose - we have labels that are introduced with similar syntax. I do not think that we should go in that direction - we'd better fix lambdas.

Anyway the solution with lambdas or this one rarely do not need curly braces. I have written that code in c# - the C language family simply do not suit for lambdas inside lambdas inside lambdas style. And the proposed solution leads to similar style. With anonymous variables we may not need new pair of braces.

Regards,
Gregory

[grigor...@gmail.com]

Edit: while using anonymous variables alone - we sometimes do not need new pair of braces.

[Vicente J. Botet Escriba]

Le 28/11/12 20:42, grigor...@gmail.com a �crit :

> : is bad for that purpose - we have labels that are introduced with similar syntax.

I have no problem using another syntax.

> I do not think that we should go in that direction - we'd better fix lambdas.

What would you want to fix?

>
>
> Anyway the solution with lambdas or this one rarely do not need curly braces.

And?

> I have written that code in c# - the C language family simply do not suit for lambdas inside lambdas inside lambdas style. And the proposed solution leads to similar style. With anonymous variables we may not need new pair of braces.
>

I'm completely lost here. Could you be more explicit?

Vicente

[grigor...@gmail.com]

Sorry for incoherence.

 

On fixing lambdas. For example, we could allow single expression lambdas to be declared without curly braces. That would give us most of the benefits that let-in bindings give us.

It will be a little bit more noisy, but much. Consider

 

synchronized(mt, []() .... );

 

Or another variant:

 

synchronized(mt) << [] () ..... ;

 

On the style. The solutions with lambdas or let-in bindings instead of pure RAII have a drawback, that there appears to be a lot more braces than in pure RAII, which results in syntactic noise.

Imagine you need 3 or 4 RAII objects in the function. So, you create let binding for the first, then inside it create let binding for the second and so on...

And now the code is much less readable. With RAII you sometimes need to put additional braces, and sometimes it looks ugly, but IMHO with let-bindings everywhere code would be much more ugly than without them.

 

Regards,

 Gregory

 

 

Пʼятниця, 30 листопада 2012 р. 20:30:31 UTC+2 користувач viboes написав:

Le 28/11/12 20:42, grigor...@gmail.com a �crit :

[Vicente J. Botet Escriba]

Le 01/12/12 15:17, grigor...@gmail.com a écrit :

Sorry for incoherence.

 

On fixing lambdas. For example, we could allow single expression lambdas to be declared without curly braces. That would give us most of the benefits that let-in bindings give us.

It will be a little bit more noisy, but much. Consider

 

synchronized(mt, []() .... );

 

Or another variant:

 

synchronized(mt) << [] () ..... ;

 

On the style. The solutions with lambdas or let-in bindings instead of pure RAII have a drawback, that there appears to be a lot more braces than in pure RAII, which results in syntactic noise.

Imagine you need 3 or 4 RAII objects in the function. So, you create let binding for the first, then inside it create let binding for the second and so on...

And now the code is much less readable.

Take in account that we have also the possibility to lock several mutex at once using make_unique_locks. Could you give an example where it is less readable?

With RAII you sometimes need to put additional braces, and sometimes it looks ugly, but IMHO with let-bindings everywhere code would be much more ugly than without them.

Why do you want to use let-bindings everywhere?

-- Vicente

[Vicente J. Botet Escriba]

Le 01/12/12 15:17, grigor...@gmail.com a écrit :

Sorry for incoherence.

 

On fixing lambdas. For example, we could allow single expression lambdas to be declared without curly braces. That would give us most of the benefits that let-in bindings give us.

It will be a little bit more noisy, but much. Consider

 

synchronized(mt, []() .... );

 

Or another variant:

 

synchronized(mt) << [] () ..... ;

 

Using lambdas has the drawback of not allowing to return from the lambda. This case needs by itself an alternative.

-- Vicente

[grigor...@gmail.com]

If it only for locks - then why bother?

For locks there's no need for a language feature, something like with_lock function would be just fine.

Indeed, if we're talking about locks then you would rarely need to use synchronized (or with_lock) inside synchronized.

 

My impression was that your idea is to replace RAII with let-bindings in most of the places not only for locking. My objections were against that approach.

Субота, 1 грудня 2012 р. 17:13:13 UTC+2 користувач viboes написав:

[grigor...@gmail.com]

Indeed it is not possible to use return in lambda to return from an enclosing function, but does that justify a new language feature?

 

Regards,

Gregory

 

[Vicente J. Botet Escriba]

Le 01/12/12 16:29, grigor...@gmail.com a écrit :

> If it only for locks - then why bother?
> For locks there's no need for a language feature, something like
> with_lock function would be just fine.
> Indeed, if we're talking about locks then you would rarely need to use
> synchronized (or with_lock) inside synchronized.
> My impression was that your idea is to replace RAII with let-bindings
> in most of the places not only for locking. My objections were against
> that approach.

I'm yet waiting for the example with several RAIIs. The example will be
useful to make comparisons.

-- Vicente

[Vicente J. Botet Escriba]

Le 01/12/12 16:41, grigor...@gmail.com a �crit :

> Indeed it is not possible to use return in lambda to return from
> an enclosing function, but does that justify a new language feature?
>

IMHO, yes as the new features are not complex at all.

-- Vicente

[Vicente J. Botet Escriba]

Le 01/12/12 17:14, Vicente J. Botet Escriba a �crit :

Well it seems you were right, and there is not interest at all for these
two minor features.

I can live with the status-quo: looking for a name for the guard and put
it inside an artificial block when only one statement needed to be
protected.

Best,
Vicente