On Sat, Oct 15, 2022 at 12:26:17AM +0000, Paul Backus via Digitalmars-d wrote:
> On Friday, 14 October 2022 at 22:48:51 UTC, Walter Bright wrote:
> > On 10/14/2022 2:07 PM, Max H wrote:
> > > D not using + for strings was something that helped sell me on it early on.
> > 
> > When I was working on that, I could not believe that other languages persisted in conflating add with concatenate, which continues to cause confusion.
> 
> Perhaps ironically, one of the languages that got this right was Perl: it used + for numeric addition and . (period) for string concatenation.

In spite of all the hate (and actual flaws), I actually quite like many
aspects of Perl.

Built-in AA's is one, which is also a draw for me in D, in spite of the flaws in the current implementation in D.  As is built-in regexes. D has std.regex, but not having direct language support does increase the friction a little. And the current implementation is a bit over-heavy on templates and so slows down compilation significantly for shell-script replacements, which detracts from an otherwise perfect niche for D.

Sigils is another feature that most people love to hate, but it's actually very useful: the variable namespace will never collide with keywords, and when glancing at code you can immediately tell which identifiers are variables are even if you don't know the definitions of the identifiers. Having said that, though, the quirky use of $ with arrays/hashes when referring to individual elements does detract from Perl's implementation of sigils.


T

-- 
The trouble with TCP jokes is that it's like hearing the same joke over and over.

On 10/15/22 00:44, Walter Bright via Digitalmars-d wrote:
> I've thought about it many times. It keeps coming back to "it's just too ugly."
> 
> Operator precedence is also a problem.

Raku (formerly Perl 6) is very interesting in that regard. They not only allow you to define custom operators, but also specify their precedence and associativity right in the function signature.

sub prefix:<Σ>(...)
sub infix:<!!>(...) is tighter(&infix:<+>)
sub infix:<§>(...) is assoc<right>
sub circumfix:<[ ]>(...)

And they go even further and allow you to combine these to form meta operators.

> my @a = 1, 2, 3
> @a Z @a    # zip infix operator
  ((1 1) (2 2) (3 3))
> @a Z+ @a
  (2 4 6)    # zip combined with +

If only the language wasn't dog slow. :)

On 10/14/2022 6:11 PM, rassoc wrote:
> Raku (formerly Perl 6) is very interesting in that regard. They not only allow you to define custom operators, but also specify their precedence and associativity right in the function signature.

Doing that means the code cannot be successfully parsed without semantic analysis. One goal of D was to be able to keep the lexing, parsing, and semantic analysis as distinct passes.

On 10/14/2022 5:58 PM, H. S. Teoh wrote:
> Built-in AA's is one, which is also a draw for me in D, in spite of the
> flaws in the current implementation in D.  As is built-in regexes. D has
> std.regex, but not having direct language support does increase the
> friction a little. And the current implementation is a bit over-heavy on
> templates and so slows down compilation significantly for shell-script
> replacements, which detracts from an otherwise perfect niche for D.

You can always use the D1 regexes, which are still around in the unDead library. They don't use templates.

> Sigils is another feature that most people love to hate, but it's
> actually very useful: the variable namespace will never collide with
> keywords, and when glancing at code you can immediately tell which
> identifiers are variables are even if you don't know the definitions of
> the identifiers. Having said that, though, the quirky use of $ with
> arrays/hashes when referring to individual elements does detract from
> Perl's implementation of sigils.

Syntax highlighting works delightfully in distinguishing keywords from identifiers.

On 15.10.22 08:59, Walter Bright wrote:
> On 10/14/2022 6:11 PM, rassoc wrote:
>> Raku (formerly Perl 6) is very interesting in that regard. They not only allow you to define custom operators, but also specify their precedence and associativity right in the function signature.
> 
> Doing that means the code cannot be successfully parsed without semantic analysis. One goal of D was to be able to keep the lexing, parsing, and semantic analysis as distinct passes.
> 

You can parse it as a single "operator expression" and resolve precedence during semantic analysis.

On Friday, 14 October 2022 at 21:15:12 UTC, H. S. Teoh wrote:
> [snip]
> For this specific example, though, I'd say just overload *. Matrix multiplication is called "multiplication" because it generally *does* behave like a multiplicative arithmetic operator. As opposed to like array manipulation or I/O.  So I'd call it an appropriate use of operator overloading in this case.
>
>
> T

D's built-in slices already have * as element-wise multiplication. It makes things a little more confusing to switch it up.

On 10/15/2022 5:41 AM, Timon Gehr wrote:
> You can parse it as a single "operator expression" and resolve precedence during semantic analysis.

The operator precedence drives the parse.

On 15.10.22 18:45, Walter Bright wrote:
> On 10/15/2022 5:41 AM, Timon Gehr wrote:
>> You can parse it as a single "operator expression" and resolve precedence during semantic analysis.
> 
> The operator precedence drives the parse.

It does not _have_ to work that way.

On 10/15/2022 10:42 AM, Timon Gehr wrote:
> On 15.10.22 18:45, Walter Bright wrote:
>> On 10/15/2022 5:41 AM, Timon Gehr wrote:
>>> You can parse it as a single "operator expression" and resolve precedence during semantic analysis.
>>
>> The operator precedence drives the parse.
> 
> It does not _have_ to work that way.

I know. The tokens can be "parsed" by just storing them in an array, deferring constructing the AST until the semantics are known.

But that isn't really parsing, and makes 3rd party tools much more complex.