Discussion:
Optional if's parens
(too old to reply)
g***@gilmagno.com
2024-02-17 15:36:21 UTC
Permalink
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
Darren Duncan
2024-02-17 21:09:21 UTC
Permalink
Post by g***@gilmagno.com
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
2024-02-17 21:14:22 UTC
Permalink
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
Post by Darren Duncan
Post by g***@gilmagno.com
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
2024-02-19 00:48:45 UTC
Permalink
... 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
2024-02-19 08:02:10 UTC
Permalink
    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
2024-02-19 08:10:43 UTC
Permalink
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
"Ruud H.G. van Tol" via perl5-porters
2024-02-19 12:13:34 UTC
Permalink
On Mon, 19 Feb 2024 01:48:45 +0100, Darren Duncan
Post by Darren Duncan
... 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

G.W. Haywood
2024-02-19 09:57:00 UTC
Permalink
Hi there,
...
... 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.
Loading...