Optional if's parens

[gilm...@gilmagno.com]

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

[Ruud H.G. van Tol via perl5-porters]

On 2024-02-17 16:36, gilm...@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

[G.W. Haywood]

Hi there,

On Sat, 17 Feb 2024, Smylers   via perl5-porters wrote:
> Leon Timmermans writes:
>> On Sat, Feb 17, 2024 at 4:36 PM <gilm...@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.

[Darren Duncan]

On 2024-02-17 7:36 a.m., gilm...@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

[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

[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

[Darren Duncan]

On 2024-02-18 4:00 p.m., David Christensen wrote:
> On 2/17/24 09:36, Ovid wrote:
>> ... https://metacpan.org/pod/standard ...
> How do "standard" and related compare to RPerl?
>
> https://metacpan.org/dist/RPerl/view/script/rperl

All I know of "standard" is what you just said and what I read at
https://metacpan.org/pod/standard . I have a small familiarity with RPerl from
having read about it but not having actually used it.

As I can see it, "standard" basically is a restricted subset of normal Perl that
excludes maybe 1-2% or at most 5%, where this gains greater ease in having
alternate implementations of Perl. It is mainly about making parsing less
complicated, but at runtime its essentially the same.

In contrast, as I understand it, RPerl is basically C++ in Perl clothing. It
has different levels of support depending on how you write your Perl. If you
write "low magic Perl" which basically cuts out 50% of the language, and also
add a lot of type annotations resembling C++ or hardware-level types, then your
code can be transpiled to C++ and run as fast as a C++ program, which is orders
of magnitude eg 100X faster than the Perl otherwise would be. So you make more
changes but get a huge speed boost, which is the main point of RPerl, speed. In
contrast if you write "medium or high magic Perl", then RPerl would do less for
you, if it works at all, still linking in the standard Perl interpreter. The
main difference between "low magic" and higher is the non-use or use of generic
types that are resolved at runtime, such as what Perl scalars or Perl's type
system in general supports. Or something, I'm not an expert here, but that's
the vague idea I have.

In a nutshell, they are very different things.

-- Darren Duncan

[David Christensen]

On 2/18/24 23:18, Darren Duncan wrote:
> On 2024-02-18 10:10 p.m., Ovid wrote:

>> On Mon, Feb 19, 2024 at 1:48 AM Darren Duncan wrote:
>>     In contrast, as I understand it, RPerl is basically C++ in Perl
>> clothing.  It
>>     has different levels of support depending on how you write your
>> Perl.  If you
>>     write "low magic Perl" which basically cuts out 50% of the
>> language, and also
>>     add a lot of type annotations resembling C++ or hardware-level
>> types, then your
>>     code can be transpiled to C++ and run as fast as a C++ program,
>> which is orders
>>     of magnitude eg 100X faster than the Perl otherwise would be.

>> Correct me if I'm wrong (I very well might be), but RPerl really
>> doesn't let you do much of anything, does it? Last I've heard, for
>> example, you couldn't even read from a database, making it pretty
>> useless to just about anyone doing serious work.
>
> Well, lots of useful functionality including reading from a database
> ALSO can't be done by the language itself with regular Perl or C++
> either, and instead is enabled by other code used WITH the language.  So
> in that sense, RPerl is at the same level.
>
> I was speaking more to the core language as I understand it rather than
> the whole ecosystem.
>
> So RPerl is not a replacement for the whole Perl ecosystem, but rather
> is its own language that is inspired by Perl and C++ bringing a kind of
> hybrid of both, and which lacks a comprehensive mature ecosystem, so
> what you can do with it is more limited to problem spaces that can be
> solved using a core language, like algorithm type problems.
>
>> I've also asked if any companies use it, but I've received no
>> response. I don't think it's used anywhere. I've heard of one project
>> where someone was hired to see if they could make RPerl useful for a
>> company, but failed.
>>
>> RPerl looks to me an awful lot like a beginning comp-sci transpiler
>> project that got out of control. I also understand that RPerl doesn't
>> let you use most of C++, either. So you have a crippled subset of
>> Perl—with a bunch of werid annotations layered on top—being used as a
>> scripting language to write a crippled subset of C++. I can't
>> understand why anyone would find that compelling.
>>
>> If, however, it could do everything Perl (or C++) could do, it might
>> be worth looking into. I would love to see /any/ evidence that it's
>> useful for business.
>
> I'm not going to argue that RPerl is actually useful as is for most
> business cases that currently are handled by either Perl or C++.  I was
> just trying to answer the asked question on how "standard" Perl and
> RPerl compared.
>
> My bottom line in my original response still stands, that "standard" and
> RPerl are very different from each other, and do not just have small
> differences.
>
> -- Darren Duncan


Thank you both for the discussion. :-)


I recall evaluating RPerl several years ago and coming to the conclusion
that it was too restricted for my coding style (functional) and goals
(concurrent, distributed).


Are "standard" and related any better?


Do "standard" and related have an ecosystem that is sufficient for "real
work"?


Will "standard" and related lead to a compiler?


David

[Darren Duncan]

On 2024-02-19 12:02 a.m., David Christensen wrote:
> I recall evaluating RPerl several years ago and coming to the conclusion that it
> was too restricted for my coding style (functional) and goals (concurrent,
> distributed).
>
> Are "standard" and related any better?
>
> Do "standard" and related have an ecosystem that is sufficient for "real work"?
>
> Will "standard" and related lead to a compiler?

What I've gleaned about "standard" by itself from
https://metacpan.org/pod/standard is that it is effectively just like a perl
critic policy, in that all it does is prevent you from using 1-2% of the
available Perl syntax in your own codebase.

But then a consequence of this is that it is easier for alternate
implementations of Perl to run your codebase, where they otherwise couldn't with
the presence of that 1-2%.

So with "standard" you still have all the same functionality as regular Perl,
and that is compatible with regular Perl.

This means that in principle it is easier to make a compiler for that Perl code,
but I'm not aware that a compiler actually exists for it today.

-- Darren Duncan

[G.W. Haywood]

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.

[Ruud H.G. van Tol via perl5-porters]

On 2024-02-19 11:37, Christian Walde wrote:

> On Mon, 19 Feb 2024 01:48:45 +0100, Darren Duncan
> <dar...@darrenduncan.net> wrote:
>> On 2024-02-18 4:00 p.m., David Christensen wrote:
>>> On 2/17/24 09:36, Ovid wrote:
>>>> ... https://metacpan.org/pod/standard ...
>>> How do "standard" and related compare to RPerl?
>>> https://metacpan.org/dist/RPerl/view/script/rperl
>>
>> All I know of "standard" is what you just said and what I read at
>> https://metacpan.org/pod/standard .  I have a small familiarity with
>> RPerl from
>> having read about it but not having actually used it.
>>
>> As I can see it, "standard" basically is a restricted subset of
>> normal Perl that
>> excludes maybe 1-2% or at most 5%,
>

> It may exclude little of the syntax, but those exclusions also block
> like 90% of existing Perl code, so i don't think is of any use but a
> curiosity.
>
> Kind of annoying to see those folks spend time on that instead of
> trying to help me improve PPI, which is actively used in production.

To me it doesn't look hard to migrate existing code to what "standard"
requires,
and I know a lot of Perl code, from many origins.

Having PPI rules to flag the "standard" issues, will of course help with
that.
Also with the automated part of such a migration!

What it comes down to, is that "standard" should use PPI,
to make any migration of some decently sized code base to "standard"
feasible.
PPI doesn't need standard, but will certainly facilitate it.

-- Ruud