Mailing List Archive

On Sat, Feb 17, 2024 at 9:36?AM <gilmagno@gilmagno.com> wrote:
>
> How feasible would be to make if's parens optional?, ie, to allow
>
> if 4 > 2 { say 'true' }
>
> I would just like to read some opinions. Is it easy to implement? Are
> there major problems?
>

Perl supports "trailing conditionals" for single conditional
expressions; would that work? E.g.

frobnicate() if $should_frobnicate;

Yep, I know. The example I gave was small, but I meant

if 4 > 2 {
this;
that;
that_other;
}

2024-02-17 09:42:31 -0600 Corwin Brust:
> On Sat, Feb 17, 2024 at 9:36?AM <gilmagno@gilmagno.com> wrote:
> >
> > How feasible would be to make if's parens optional?, ie, to allow
> >
> > if 4 > 2 { say 'true' }
> >
> > I would just like to read some opinions. Is it easy to implement? Are
> > there major problems?
> >
>
> Perl supports "trailing conditionals" for single conditional
> expressions; would that work? E.g.
>
> frobnicate() if $should_frobnicate;

On Sat, Feb 17, 2024 at 4:36?PM <gilmagno@gilmagno.com> wrote:

> Hi all,
>
> How feasible would be to make if's parens optional?, ie, to allow
>
> if 4 > 2 { say 'true' }
>
> I would just like to read some opinions. Is it easy to implement? Are
> there major problems?
>
> I know there are more important/necessary things to be done, but I'm
> asking out of curiosity
>
> Thanks :)
>
> gil
>

The challenge with that is not parsing the condition per se, but its end.
Take for example «if 4 > a { boo }», what does that even mean? That all
depends on the prototype of sub a. There's some subtle ambiguity with
making parentheses optional. That doesn't mean it isn't possible at all,
but it isn't without issues.

Leon

On 2024-02-17 16:36, gilmagno@gilmagno.com wrote:
> How feasible would be to make if's parens optional?, ie, to allow
>
>     if 4 > 2 { say 'true' }

Alternative:

  $x > 2 and say 'true';

with its sibling:

  $x > 2 or say 'false';


-- Ruud

On Sat, Feb 17, 2024 at 6:12?PM Leon Timmermans <fawaka@gmail.com> wrote:

>
>> How feasible would be to make if's parens optional?, ie, to allow
>>
>> if 4 > 2 { say 'true' }
>>
>
>
The challenge with that is not parsing the condition per se, but its end.
> Take for example «if 4 > a { boo }», what does that even mean? That all
> depends on the prototype of sub a. There's some subtle ambiguity with
> making parentheses optional. That doesn't mean it isn't possible at all,
> but it isn't without issues.
>


You've touched on an issue that https://metacpan.org/pod/standard could
address. While I understand the module might not be everyone's cup of tea,
I see it as a bridge to a more dynamic and robust Perl, without sacrificing
the essence that makes Perl unique to us.

This module ensures Perl aligns with "Standard Perl," offering a version
that is statically parseable when no warnings are detected. What's
beautiful about this is it maintains backwards-compatibility while opening
the door to numerous enhancements. Imagine a Perl where:


- Tooling support surpasses our expectations, facilitating a smoother
coding journey.
- IDE integration is much, much easier!
- Security can be improved, thanks to improved tooling.
- Macros become a seamless part of our toolbox, enhancing our coding
efficiency.
- The learning curve is more welcoming to newcomers.

I love Perl's flexibility and its unique character. This is not about
changing the heart of Perl or our community but about enriching it, making
it a language both for current and future developers.

Currently, it uses Marpa, so that's something that would have to be
addressed, but aside from that, we have a whole host of improvements which
could be realized if we were brave enough!

Best,
Ovid

On 17.02.24 16:36, gilmagno@gilmagno.com wrote:
> Hi all,
>
> How feasible would be to make if's parens optional?, ie, to allow
>
>     if 4 > 2 { say 'true' }
>
> I would just like to read some opinions. Is it easy to implement? Are
> there major problems?

It is impossible because `{` can appear in expressions, so you can't
reliably tell where the condition ends. Consider something as simple as

if $x > $y { say 'true' }

This would be parsed as `if ($x > $y{say 'true'})`, i.e. a hash lookup.

Leon Timmermans writes:

> On Sat, Feb 17, 2024 at 4:36?PM <gilmagno@gilmagno.com> wrote:
>
> > Hi all,
> >
> > How feasible would be to make if's parens optional?, ie, to allow
> >
> >      if 4 > 2 { say 'true' }
>
> The challenge with that is not parsing the condition per se, but its
> end. Take for example «if 4 > a { boo }», what does that even mean?
> That all depends on the prototype of sub a. There's some subtle
> ambiguity with making parentheses optional. That doesn't mean it isn't
> possible at all, but it isn't without issues.

This suggestion come up before, and I think that the conclusion is that
it's too confusing because spaces are allowed before hash keys.

So this:

  if ($foo) {
    bar();
  }
  {
    baz();
  }

is obviously different from:
 
  if ($foo{bar();}) {
    baz();
  }

But without the parens both become:

  if $foo { bar(); } { baz(); }

Admittedly, most people don't put spaces before hash keys. I would
gladly agree never to put spaces there in order to have if conditions
without parens. But it is syntax that has been valid for decades.

Even if a way could be found of making it unambiguous to the perl
interpreter, it would still be very confusing for humans: if you make a
typo, suddenly your code is trying to do something very different to
what you intended, and the error message may not help if it's, say,
referencing a hash that you can't even see in your source code.

It's a shame, but I don't think it's realistic.

Smylers

Hi there,

On Sat, 17 Feb 2024, Smylers   via perl5-porters wrote:
> Leon Timmermans writes:
>> On Sat, Feb 17, 2024 at 4:36?PM <gilmagno@gilmagno.com> wrote:
>>>
>>> How feasible would be to make if's parens optional? ...
>> ... Take for example «if 4 > a { boo }» ...
> ... it's too confusing because spaces are allowed before hash keys.
> ...
> It's a shame ...

I don't think it is. The very idea makes my flesh crawl.

And I wish curly braces weren't (sometimes) optional in C.

On the other hand:

On Sat, 17 Feb 2024, Ovid wrote:

> ... Imagine a Perl where:
> ...
> - Macros become a seamless part of our toolbox, enhancing our coding
> ...

That I *would* go for.

--

73,
Ged.

On 2024-02-17 7:36 a.m., gilmagno@gilmagno.com wrote:
> How feasible would be to make if's parens optional?, ie, to allow
>
>     if 4 > 2 { say 'true' }
>
> I would just like to read some opinions. Is it easy to implement? Are
> there major problems?

I can see how this might be attractive for parity with the postfix version that
doesn't require parenthesis, but I don't generally feel it would be worth having.

I would also ask a related question of people...

How do we feel about adding a "then" keyword to pair with your proposal? That
is, you can remove parenthesis but in exchange must use "then" to separate?

if x > 17 then
{
...
}
else if y < 15 then
{
...
}
else
{
...
}

-- Darren Duncan

To further explain, my modified proposal would mean parity with the symbolic
ternary ?: which has a keyword in both positions, and would then essentially be
a corresponding alpha rather than symbolic double-infix. -- Darren Duncan

On 2024-02-17 1:09 p.m., Darren Duncan wrote:
> On 2024-02-17 7:36 a.m., gilmagno@gilmagno.com wrote:
>> How feasible would be to make if's parens optional?, ie, to allow
>>
>>      if 4 > 2 { say 'true' }
>>
>> I would just like to read some opinions. Is it easy to implement? Are
>> there major problems?
>
> I can see how this might be attractive for parity with the postfix version that
> doesn't require parenthesis, but I don't generally feel it would be worth having.
>
> I would also ask a related question of people...
>
> How do we feel about adding a "then" keyword to pair with your proposal?  That
> is, you can remove parenthesis but in exchange must use "then" to separate?
>
> if x > 17 then
> {
>   ...
> }
> else if y < 15 then
> {
>   ...
> }
> else
> {
>   ...
> }
>
> -- Darren Duncan

Apologies, what I just said is actually wrong in several ways, but its still the
principle that having "then" would add some self-similarity in the language.

I'm not going to advocate for this change on its own, as I'm happy with how
things are now, but wanted to put it out there if the OP proposal was going to
be seriously considered.

-- Darren Duncan

On 2024-02-17 1:14 p.m., Darren Duncan wrote:
> To further explain, my modified proposal would mean parity with the symbolic
> ternary ?: which has a keyword in both positions, and would then essentially be
> a corresponding alpha rather than symbolic double-infix. -- Darren Duncan
>
> On 2024-02-17 1:09 p.m., Darren Duncan wrote:
>> On 2024-02-17 7:36 a.m., gilmagno@gilmagno.com wrote:
>>> How feasible would be to make if's parens optional?, ie, to allow
>>>
>>>      if 4 > 2 { say 'true' }
>>>
>>> I would just like to read some opinions. Is it easy to implement? Are
>>> there major problems?
>>
>> I can see how this might be attractive for parity with the postfix version
>> that doesn't require parenthesis, but I don't generally feel it would be worth
>> having.
>>
>> I would also ask a related question of people...
>>
>> How do we feel about adding a "then" keyword to pair with your proposal?  That
>> is, you can remove parenthesis but in exchange must use "then" to separate?
>>
>> if x > 17 then
>> {
>>    ...
>> }
>> else if y < 15 then
>> {
>>    ...
>> }
>> else
>> {
>>    ...
>> }
>>
>> -- Darren Duncan
>

the

if EXPR then BLOCK

form should be possible to do with a macro, if we had macros.

something like

MACRO if EXPR then BLOCK BECOMES
if (EXPR) BLOCK
END_MACRO



On Sat, Feb 17, 2024 at 9:36?AM <gilmagno@gilmagno.com> wrote:

> Hi all,
>
> How feasible would be to make if's parens optional?, ie, to allow
>
> if 4 > 2 { say 'true' }
>
> I would just like to read some opinions. Is it easy to implement? Are
> there major problems?

That's a good idea, I was also thinking about that, Raku and Go already
allow this syntax.

It might be difficult to implement but it will definitely make coding
easier and prettier.

On Sat, Feb 17, 2024 at 4:36?PM <gilmagno@gilmagno.com> wrote:

> Hi all,
>
> How feasible would be to make if's parens optional?, ie, to allow
>
> if 4 > 2 { say 'true' }
>
> I would just like to read some opinions. Is it easy to implement? Are
> there major problems?
>
> I know there are more important/necessary things to be done, but I'm
> asking out of curiosity
>
> Thanks :)
>
> gil
>

>
>
>
> The challenge with that is not parsing the condition per se, but its end.
> Take for example «if 4 > a { boo }», what does that even mean? That all
> depends on the prototype of sub a. There's some subtle ambiguity with
> making parentheses optional. That doesn't mean it isn't possible at all,
> but it isn't without issues.
>
>
another example:

if $a { true } { true }

what it is ?
- if ($a) { true } { true }
- if ($a{true}) { true }



> Leon
>

On Sun, 18 Feb 2024 16:32:36 +0100, Elvin Aslanov <rwp.primary@gmail.com> wrote:

> That's a good idea, I was also thinking about that, Raku and Go already
> allow this syntax.

Raku and go are not perl. I think it is a bad idea.

I also do some raku and I always use parens. Readability and
consistency matter and it makes it easier for me to keep the perl- and
raku versions of the same module in sync.

> It might be difficult to implement but it will definitely make coding
> easier and prettier.

Both of the opinions are not facts but the eye of the beholder

Easier: not if the rest of the code does not follow the newer syntax
not if the rest of the team does not like it
not if your code has to support 20 year old perl
...

Prettier: not if you like consistency
not if you like parens

Personally I do like the parens in

if ($a < $b) { action (); }

if I do not want them

$a < $b and action ();
or
action () if $a < $b;

I've seen way to many people say something is "easier" just because
*they* *like* it, but even if you do *not* like it, *ALL* code is
easier to parse when the indent, style and use if syntax and variable
names is *consistent*.


> On Sat, Feb 17, 2024 at 4:36?PM <gilmagno@gilmagno.com> wrote:
>
> > Hi all,
> >
> > How feasible would be to make if's parens optional?, ie, to allow
> >
> > if 4 > 2 { say 'true' }
> >
> > I would just like to read some opinions. Is it easy to implement? Are
> > there major problems?
> >
> > I know there are more important/necessary things to be done, but I'm
> > asking out of curiosity
> >
> > Thanks :)
> >
> > gil

--
H.Merijn Brand https://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.37 porting perl5 on HP-UX, AIX, and Linux
https://tux.nl/email.html http://qa.perl.org https://www.test-smoke.org

>
> $a < $b and action ();
> or
> action () if $a < $b;
>
>
while reading this, some idea came through my brain:

$a < $b then action ();
$a < $b then { action () };

same for else, that can be allowed.

Best regards,
Brano

On 2024-02-18 11:39 p.m., Branislav Zahradník wrote:
>  $a < $b and action ();
> or
>  action () if $a < $b;
>
> while reading this, some idea came through my brain:
>
> $a < $b then action ();
> $a < $b then { action () };
>
> same for else, that can be allowed.

So you also like the "then" keyword that I suggested adding as an amendment to
the optional-parens proposal? -- Darren Duncan

So you also like the "then" keyword that I suggested adding as an amendment
> to
> the optional-parens proposal? -- Darren Duncan
>
>
Honestly I missed that :-)

but yes, I'd even add optional then keyword to current conditions.

Brano

Hi there,

On Mon, 19 Feb 2024, Darren Duncan wrote:

> On 2024-02-18 11:39 p.m., Branislav Zahradník wrote:
>> ...
>> ... idea ...
>>
>> $a < $b then action ();
>> $a < $b then { action () };
>>
>> same for else, that can be allowed.
>
> So you also like the "then" keyword that I suggested ...

You'd have needed to get Schwartz and Wirth to write a new book.
Sadly you've just missed your chance.

--

73,
Ged.

Hi there,

On Mon, 19 Feb 2024, Branislav Zahradn?k wrote:

> question is not about books and their authors, question is about how to
> parse if condition if parens are omitted.
> ...

Something as fundamental as this changes the language.

To me it makes no sense.

By all means create a new language, but please don't call it Perl.

--

73,
Ged.

On Mon, 19 Feb 2024 at 11:32, G.W. Haywood <perl5porters@jubileegroup.co.uk>
wrote:

> Hi there,
>
> On Mon, 19 Feb 2024, Branislav Zahradník wrote:
>
> > question is not about books and their authors, question is about how to
> > parse if condition if parens are omitted.
> > ...
>
> Something as fundamental as this changes the language.
>

no one will force you to use it ...

you can use same argument against every change: defer, try/catch, class,
....

Hi there,

On Mon, 19 Feb 2024, Branislav Zahradník wrote:
> On Mon, 19 Feb 2024 at 11:32, G.W. Haywood wrote:
>> On Mon, 19 Feb 2024, Branislav Zahradník wrote:
>>
>>> question is not about books and their authors, question is about how to
>>> parse if condition if parens are omitted.
>>> ...
>>
>> Something as fundamental as this changes the language.
>
> no one will force you to use it ...

If you mean that you would have this implemented as a feature which
would have to be used, my objection would stand but be less strong.

> you can use same argument against every change: defer, try/catch, class,
> ....

No, that's not even close to the truth. Adding a new feature doesn't
invalidate all the (in many cases decades old) documentation for the
existing language syntax. To do that on this whim would be insane.

--

73,
Ged.

> If you mean that you would have this implemented as a feature which
> would have to be used, my objection would stand but be less strong.
>

IMHO every new part of language should be feature so definitely yes.

FYI: I'd use pattern (toke.c):

case KEY_then:
return FEATURE ? BAREWORD : KW_THEN

so rest can be part of grammar without any harm (requiring leading token
KW_THEN will eliminate those rules)

but of course in long run it will require implementation of "unlimited"
feature bits (I sent here poc ~3 years ago)


> > you can use same argument against every change: defer, try/catch, class,
> > ....
>
> No, that's not even close to the truth. Adding a new feature doesn't
> invalidate all the (in many cases decades old) documentation for the
> existing language syntax. To do that on this whim would be insane.
>

nor should this, it should only add new possibility


>
> --
>
> 73,
> Ged.

Op 19-02-2024 om 08:39 schreef Branislav Zahradník:
>
>
>  $a < $b and action ();
> or
>  action () if $a < $b;
>
>
> while reading this, some idea came through my brain:
>
> $a < $b then action ();
> $a < $b then { action () };


$a < $b and action ();

$a < $b and do { action () };


> same for else, that can be allowed.


$a < $b or action ();

$a < $b or do { action () };


HTH,

M4