Mailing List Archive

On 2/19/24 02:39, 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.
>
> Best regards,
> Brano

So since the topic has come up, I have to ask: what part of perl syntax
is preventing the normal C idiom of

    if (condition) action();

It seems odd to move toward Pascal's 'then' keyword when the first thing
every new-to-perl developer finds missing is the C if-without-block syntax.

-Mike C

>
> while reading this, some idea came through my brain:
>
> $a < $b then action ();
> $a < $b then { action () };
>


well this is getting fun. Does inline "or" get an alias too, perhaps
"otherwise?"
Are there subtle differences, like the expression following then/otherwise
is not guaranteed to execute immediately but rather gets queued on an
asynchronous stack, like with Promises? Can we have the first language with
a "notwithstanding" keyword or does Intercal get to keep that one?

>
>
> So since the topic has come up, I have to ask: what part of perl syntax is
> preventing the normal C idiom of
>
> if (condition) action();
>
> It seems odd to move toward Pascal's 'then' keyword when the first thing
> every new-to-perl developer finds missing is the C if-without-block syntax.
>
> -Mike C
>

I think most critical part will be implementation of:
if (my $foo ...) say $foo;

then also related readability.

keyword 'then' is discussed only in relation to parens-less condition - to
enable it we need leading token of "then branch".

On Mon, 19 Feb 2024 at 21:20, David Nicol <davidnicol@gmail.com> wrote:

> while reading this, some idea came through my brain:
>>
>> $a < $b then action ();
>> $a < $b then { action () };
>>
>
>
> well this is getting fun. Does inline "or" get an alias too, perhaps
> "otherwise?"
> Are there subtle differences, like the expression following then/otherwise
> is not guaranteed to execute immediately but rather gets queued on an
> asynchronous stack, like with Promises? Can we have the first language with
> a "notwithstanding" keyword or does Intercal get to keep that one?
>
>
>

in this case it will be just simple else

$a < $b else return 0;

Good point!

On Mon, Feb 19, 2024 at 2:23?PM Branislav Zahradník <happy.barney@gmail.com>
wrote:

>
>
> On Mon, 19 Feb 2024 at 21:20, David Nicol <davidnicol@gmail.com> wrote:
>
>> while reading this, some idea came through my brain:
>>>
>>> $a < $b then action ();
>>> $a < $b then { action () };
>>>
>>
>>
>> well this is getting fun. Does inline "or" get an alias too, perhaps
>> "otherwise?"
>> Are there subtle differences, like the expression following
>> then/otherwise is not guaranteed to execute immediately but rather gets
>> queued on an asynchronous stack, like with Promises? Can we have the first
>> language with a "notwithstanding" keyword or does Intercal get to keep that
>> one?
>>
>>
>>
>
> in this case it will be just simple else
>
> $a < $b else return 0;
>
>
>
>


--
"Lay off that whiskey, and let that cocaine be!" -- Johnny Cash

On 19.02.24 21:07, Michael Conrad wrote:
> So since the topic has come up, I have to ask: what part of perl syntax
> is preventing the normal C idiom of
>
>     if (condition) action();
>
> It seems odd to move toward Pascal's 'then' keyword when the first thing
> every new-to-perl developer finds missing is the C if-without-block syntax.

That's deliberate to avoid the "dangling else" problem:

if (cond1)
if (cond2)
foo();
else bar();

Which 'if' does the 'else' go with? Perl entirely avoids that ambiguity
in its grammar by making { } mandatory.

On Sun, Feb 18, 2024 at 4:32?PM 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 gets away with it because it actually is whitespace sensitive in ways
that perl isn't.
Go gets away with it by having a syntax that is a lot less contextual.
Ruby gets away with it because it doesn't use braces to delimit if blocks

Honestly, this is not the sort of syntactic feature that you change at a
late stage. This whole discussion is misguided.

Leon

Hi there,

On Tue, 20 Feb 2024, Leon Timmermans wrote:

> ... This whole discussion is misguided.

+1

--

73,
Ged.

> $a < $b and action ();

I don't like this syntax. I always try converting this to regular if's
whenever possible.

I think whatever could be optional should be optional :-)

I enjoy seeing the lack of parens when I check Raku and Go code.

That's just my personal thoughts as a user.

On Mon, Feb 19, 2024 at 8:32?AM <perl5@tux.freedom.nl> wrote:

> 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
>
>

On 2024-02-21 16:09, Elvin Aslanov wrote:
> >  $a < $b and action ();
>
> I don't like this syntax. [...]

In specific context it is useful. For example:

  my $r = shift() or die "...";

-- Ruud

On Wed, 21 Feb 2024 16:09:54 +0100, Elvin Aslanov <rwp.primary@gmail.com> wrote:

> > $a < $b and action ();
>
> I don't like this syntax. I always try converting this to regular if's
> whenever possible.

This is why perl is perl and not raku or go or java or whatever
This is also why *I* love perl: you can write code the way *you* like
it best and how it best reflects your line of thinking. There is no
rule to the language to tell you one is better than the other.

I really hate

$a = 42 if $b < $a;

and will rewrite that to

$b < $a and $a = 42;

whenever I will be the only maintainer of that code.

> I think whatever could be optional should be optional :-)

I do not see the relation to the code being discussed
Currently parens are not optional and I think they won't be optional in

if ($b < $a) { $a = 42; }

if you don't want parens, write either one of the two examples above

> I enjoy seeing the lack of parens when I check Raku and Go code.

Then use that when coding for fun.

> That's just my personal thoughts as a user.
>
> On Mon, Feb 19, 2024 at 8:32?AM <perl5@tux.freedom.nl> wrote:
>
> > 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*.

--
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

I think making things optional, and coding for fun is one of the things
that define Perl as a language.

For instance Perl let's function calls omit parentheses where other
languages such as C might be strict about.

I'm not against "and", just wouldn't prefer it, but someone else may of
course, that's why it's being used and suggested in some docs.

Making if parens optional means you can use them if you want, while I may
omit them if I like it this way. So it's a win-win situation. If you'd like
to be strict, then you can create and enforce a policy on coding style
instead.

On Wed, Feb 21, 2024, 5:12?PM <perl5@tux.freedom.nl> wrote:

> On Wed, 21 Feb 2024 16:09:54 +0100, Elvin Aslanov <rwp.primary@gmail.com>
> wrote:
>
> > > $a < $b and action ();
> >
> > I don't like this syntax. I always try converting this to regular if's
> > whenever possible.
>
> This is why perl is perl and not raku or go or java or whatever
> This is also why *I* love perl: you can write code the way *you* like
> it best and how it best reflects your line of thinking. There is no
> rule to the language to tell you one is better than the other.
>
> I really hate
>
> $a = 42 if $b < $a;
>
> and will rewrite that to
>
> $b < $a and $a = 42;
>
> whenever I will be the only maintainer of that code.
>
> > I think whatever could be optional should be optional :-)
>
> I do not see the relation to the code being discussed
> Currently parens are not optional and I think they won't be optional in
>
> if ($b < $a) { $a = 42; }
>
> if you don't want parens, write either one of the two examples above
>
> > I enjoy seeing the lack of parens when I check Raku and Go code.
>
> Then use that when coding for fun.
>
> > That's just my personal thoughts as a user.
> >
> > On Mon, Feb 19, 2024 at 8:32?AM <perl5@tux.freedom.nl> wrote:
> >
> > > 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*.
>
> --
> 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
>
>

Elvin Aslanov writes:

> I think making things optional, and coding for fun is one of the
> things that define Perl as a language. ... Making if parens optional
> means you can use them if you want, while I may omit them if I like it
> this way. So it's a win-win situation.

Several people have given examples of how omitting parentheses around if
conditions would create ambiguities with other Perl syntax. This is not
something that can be reasonably changed, and more people wanting it (or
the same people giving more reasons for it) doesn't affect that.

Those with the ability to improve the Perl language are already busy
working on other features.

Let's not clutter the mailing list with further advocacy for (or
against) this suggestion.

Smylers

I just replied to a post quoting my comment, I don't intend to clutter
anything or do advocacy about.

On Thu, Feb 22, 2024 at 12:59?AM Smylers via perl5-porters <
perl5-porters@perl.org> wrote:

> Elvin Aslanov writes:
>
> > I think making things optional, and coding for fun is one of the
> > things that define Perl as a language. ... Making if parens optional
> > means you can use them if you want, while I may omit them if I like it
> > this way. So it's a win-win situation.
>
> Several people have given examples of how omitting parentheses around if
> conditions would create ambiguities with other Perl syntax. This is not
> something that can be reasonably changed, and more people wanting it (or
> the same people giving more reasons for it) doesn't affect that.
>
> Those with the ability to improve the Perl language are already busy
> working on other features.
>
> Let's not clutter the mailing list with further advocacy for (or
> against) this suggestion.
>
> Smylers
>

>
> Those with the ability to improve the Perl language are already busy
> working on other features.


I think the best solution for now is if the OP could create a PPC about
this idea in:
https://github.com/Perl/PPCs (as a pull request)

And perhaps in the future this could be addressed by someone able to
implement it in C.


On Thu, Feb 22, 2024 at 12:59?AM Smylers via perl5-porters <
perl5-porters@perl.org> wrote:

> Elvin Aslanov writes:
>
> > I think making things optional, and coding for fun is one of the
> > things that define Perl as a language. ... Making if parens optional
> > means you can use them if you want, while I may omit them if I like it
> > this way. So it's a win-win situation.
>
> Several people have given examples of how omitting parentheses around if
> conditions would create ambiguities with other Perl syntax. This is not
> something that can be reasonably changed, and more people wanting it (or
> the same people giving more reasons for it) doesn't affect that.
>
> Those with the ability to improve the Perl language are already busy
> working on other features.
>
> Let's not clutter the mailing list with further advocacy for (or
> against) this suggestion.
>
> Smylers
>

On Thu, 22 Feb 2024 at 12:39, Elvin Aslanov <rwp.primary@gmail.com> wrote:

> Those with the ability to improve the Perl language are already busy
>> working on other features.
>
>
> I think the best solution for now is if the OP could create a PPC about
> this idea in:
> https://github.com/Perl/PPCs (as a pull request)
>
> And perhaps in the future this could be addressed by someone able to
> implement it in C.
>

with current syntax when you don't want parens you need starting token of
"then-clause"

Simple implementation in form:
if $a > b then { block }

is easy to implement, you need:
- copy parser rule: KW_IF PERLY_PAREN_OPEN remember mexpr PERLY_PAREN_CLOSE
mblock else
- remove paren open
- replace paren close with KW_THEN
- add keyword into toke.c
- hide it behind feature (that may be most challenging)

Brano

>
>
> is easy to implement, you need:
> - copy parser rule: KW_IF PERLY_PAREN_OPEN remember mexpr
> PERLY_PAREN_CLOSE mblock else
> - remove paren open
> - replace paren close with KW_THEN
> - add keyword into toke.c
> - hide it behind feature (that may be most challenging)
>
> Brano
>

constantly forgetting to mention - plus solving bison errors