October 15, 2022
On Sat, Oct 15, 2022 at 12:01:54AM -0700, Walter Bright via Digitalmars-d wrote:
> 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.

But why aren't we improving Phobos regexes then?


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

I find syntax highlighting more distracting than helpful.  Especially when they make unfounded assumptions about the background color of my terminal, such that some items end up being unreadable or barely readable. (I know, it's configurable, etc., etc., but then I'm spending time struggling with a problem that didn't need to be there in the first place, rather than focusing on my programming problem.)


T

-- 
Life is unfair. Ask too much from it, and it may decide you don't deserve what you have now either.
October 16, 2022
On 10/16/22 02:56, H. S. Teoh via Digitalmars-d wrote:
> But why aren't we improving Phobos regexes then?

No takers yet, see: https://forum.dlang.org/post/thzswscbklnndbaeknvv@forum.dlang.org

I tried fixing a regex backtracking bug I encountered a while ago, but felt quite a bit lost in that code base. One of these days. :)

October 16, 2022
On 10/15/2022 5:56 PM, H. S. Teoh wrote:
> But why aren't we improving Phobos regexes then?

It requires someone taking the initiative to improve them.

October 16, 2022
On 10/15/2022 5:56 PM, H. S. Teoh wrote:
> I find syntax highlighting more distracting than helpful.  Especially
> when they make unfounded assumptions about the background color of my
> terminal, such that some items end up being unreadable or barely
> readable. (I know, it's configurable, etc., etc., but then I'm spending
> time struggling with a problem that didn't need to be there in the first
> place, rather than focusing on my programming problem.)

This is why it's configurable - some people like it, some don't. Personally, I prefer to use subtle colors for it.

The default is what most people seem to like.

October 16, 2022
On 10/15/22 20:22, Walter Bright wrote:
> 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,

You can parse everything except operator precedence, no need to store a token stream. In general, aspects of the AST that depend on semantic information should be resolved during semantic analysis, and if that is the case for operator precedence that's how you parse it. There's no need to have any feedback from semantic to the parser.

> and makes 3rd party tools much more complex.

Depends a bit on the tool. I guess it is true for a tool whose only purpose is to parenthesize expressions according to operator precedence. :) It's not adding much complexity to tools that already need to run full semantic.
October 16, 2022
On Saturday, 15 October 2022 at 01:11:02 UTC, 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.
>
> 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. :)

At least Σ is perfectly doable in D thanks to its unicode support (if I remember correctly)

```d
public double Σ(...) {
    //code goes here
}
```

Languages with custom operators will compile slow and will run even slower if they're scripting languages. My alternative for D would be just expand upon the currently existing number of operators with unicode characters, but also give them some alternative way to access them (e.g. having both an `⋃` operator and an `__opUnion` substitute), so people won't get a heart attack if they don't know how to get them on their keyboards.
October 24, 2022
On Friday, 14 October 2022 at 18:29:10 UTC, Walter Bright wrote:
> On 10/14/2022 12:54 AM, Atila Neves wrote:
>> As Bjarne said once in response to complaints that operator overloading lets people write code that doesn't do what you expect:
>> 
>> ```
>> // notice how the code and the docs lie
>> /**
>>   * Adds two numbers
>>   */
>> int sum(int i, int j) {
>>      return i - j;  // oops
>> }
>> ```
>
> True that documentation often (always?) lies about what the code actually does. But the causes of this are usually because of programmer laziness and/or error in documenting it correctly.
>
> But operating overloading for non-arithmetic purposes is *deliberately* doing the unexpected.

It depends. I don't think this is unexpected:


struct Path {
    string value;
    Path opBinary(string op)(in string path) if(op == "/") {
        import std.path : buildPath;
        return Path(buildPath(value, path));
    }
}

void main() {
    assert(Path("/foo") / "bar" == Path("/foo/bar"));
}

October 24, 2022
On Monday, 24 October 2022 at 11:25:58 UTC, Atila Neves wrote:
> It depends. I don't think this is unexpected:
>
>
> struct Path {
>     string value;
>     Path opBinary(string op)(in string path) if(op == "/") {
>         import std.path : buildPath;
>         return Path(buildPath(value, path));
>     }
> }
>
> void main() {
>     assert(Path("/foo") / "bar" == Path("/foo/bar"));
> }

version (Windows) {
    assert(Path("C:\Users") / "Paul" == Path("C:\Users\Paul"));
}

Better to just use ~ for concatenation and not try to be cute here, IMO.

(Also, if the inverse of division is multiplication, does that mean Path("/foo/bar") * "bar" == Path("/foo")?)
October 25, 2022
On Monday, 24 October 2022 at 14:16:57 UTC, Paul Backus wrote:
> On Monday, 24 October 2022 at 11:25:58 UTC, Atila Neves wrote:
>> It depends. I don't think this is unexpected:
>>
>>
>> struct Path {
>>     string value;
>>     Path opBinary(string op)(in string path) if(op == "/") {
>>         import std.path : buildPath;
>>         return Path(buildPath(value, path));
>>     }
>> }
>>
>> void main() {
>>     assert(Path("/foo") / "bar" == Path("/foo/bar"));
>> }
>
> version (Windows) {
>     assert(Path("C:\Users") / "Paul" == Path("C:\Users\Paul"));
> }

Yes? That's what I'd expect the result to be.

> Better to just use ~ for concatenation and not try to be cute here, IMO.

Also valid.

> (Also, if the inverse of division is multiplication, does that mean Path("/foo/bar") * "bar" == Path("/foo")?)

That'd be... horrible. The "it depends" I wrote would definitely be in favour of killing this with fire during code review.


October 26, 2022
On 10/16/2022 12:53 PM, Timon Gehr wrote:
> You can parse everything except operator precedence, no need to store a token stream.

Well, an array of terms.

Given a*b*c, is that (a*b)*c or a*(b*c)?

You'd have to wait for semantics to not only know precedence, but left and right associativity.

I can see how that's possible, but don't like it.


1 2 3 4
Next ›   Last »