On Monday, 8 April 2019 at 18:59:25 UTC, Abdulhaq wrote:
> On Monday, 8 April 2019 at 18:45:24 UTC, jmh530 wrote:
>>
>> I think some people have discussed on the forums before about how AST macros could be used to implement this (after all, C++'s metaclass proposal could probably also be implemented with AST macros). However, even if AST macros might be used to implement OOP as a library, I think the burden of proof is on those in favor of library solutions to show that they can get similar performance, both run-time and compile-time, and quality of error messages as the current implementation.
>>
>> Another option would be to keep classes, but implement other OOP features like interface
>> and abstract as libraries, with AST macros if needed. Perhaps less disruption.
>
> The problem with AST macros, and Walter seems to agree with this POV, is that every medium to large project will have its own private language that ripples throughout the code. Only a few of the developers will really understand this new language and how it can safely be used and where its pitfalls are. It will be poorly documented and a nightmare for new developers.

That's a valid criticism. It's also odd coming from a language like D where "good code" is generic on steroids and extremely hard to work with. I've been using D for six years and still struggle to use Phobos at times.

On Monday, 8 April 2019 at 22:49:10 UTC, bachmeier wrote:
> On Monday, 8 April 2019 at 18:59:25 UTC, Abdulhaq wrote:
>> On Monday, 8 April 2019 at 18:45:24 UTC, jmh530 wrote:
>>>
>>> I think some people have discussed on the forums before about how AST macros could be used to implement this (after all, C++'s metaclass proposal could probably also be implemented with AST macros). However, even if AST macros might be used to implement OOP as a library, I think the burden of proof is on those in favor of library solutions to show that they can get similar performance, both run-time and compile-time, and quality of error messages as the current implementation.
>>>
>>> Another option would be to keep classes, but implement other OOP features like interface
>>> and abstract as libraries, with AST macros if needed. Perhaps less disruption.
>>
>> The problem with AST macros, and Walter seems to agree with this POV, is that every medium to large project will have its own private language that ripples throughout the code. Only a few of the developers will really understand this new language and how it can safely be used and where its pitfalls are. It will be poorly documented and a nightmare for new developers.
>
> That's a valid criticism. It's also odd coming from a language like D where "good code" is generic on steroids and extremely hard to work with. I've been using D for six years and still struggle to use Phobos at times.

And ironically nothing is stopping one from creating a language within D anyway.

You can basically just create a parser for your language and then omit D code into a mixin.

Now that would be nasty and way worse than a custom language using AST macros; and that's possible using D now.

On Mon, Apr 8, 2019 at 3:45 PM Atila Neves via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Monday, 8 April 2019 at 17:20:00 UTC, Manu wrote:
> > On Mon, Apr 8, 2019 at 4:25 AM Atila Neves via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> >> [...]
> >
> > That would eject me from the boat.
> > That said, I think classes as a discreet feature might be
> > unnecessary.
> > classes could be removed if the language were able to express
> > class
> > semantics in a struct as a library. That's tricky as hell
> > without ANY
> > compiler support though. I can't imagine a way to add concepts
> > like
> > `virtual` and `override` as library. It would probably require
> > AST
> > macros.
>
>
> I wonder if virtual and override could be done with UDAs.

Probably not without AST macros ;)

On 2019-04-08 22:42, jmh530 wrote:

> Numeric range literals are a nice feature in Matlab and some other languages for some tasks.

Yeah, I like it too. But 1..10 could be a generic range type that can be used everywhere and the foreach statement would need a specialized syntax.

-- 
/Jacob Carlborg

On Monday, 8 April 2019 at 18:59:25 UTC, Abdulhaq wrote:
> On Monday, 8 April 2019 at 18:45:24 UTC, jmh530 wrote:
>>
>> I think some people have discussed on the forums before about how AST macros could be used to implement this (after all, C++'s metaclass proposal could probably also be implemented with AST macros). However, even if AST macros might be used to implement OOP as a library, I think the burden of proof is on those in favor of library solutions to show that they can get similar performance, both run-time and compile-time, and quality of error messages as the current implementation.
>>
>> Another option would be to keep classes, but implement other OOP features like interface
>> and abstract as libraries, with AST macros if needed. Perhaps less disruption.
>
> The problem with AST macros, and Walter seems to agree with this POV, is that every medium to large project will have its own private language that ripples throughout the code. Only a few of the developers will really understand this new language and how it can safely be used and where its pitfalls are. It will be poorly documented and a nightmare for new developers.

Every medium to large project in a language *without* AST macros already has its own private language that is poorly documented and only a few of the developers really understand. It's just that this DSL is in the syntax of the host language.

On Tuesday, 9 April 2019 at 09:45:15 UTC, Jacob Carlborg wrote:
> On 2019-04-08 22:42, jmh530 wrote:
>
>> Numeric range literals are a nice feature in Matlab and some other languages for some tasks.
>
> Yeah, I like it too. But 1..10 could be a generic range type that can be used everywhere and the foreach statement would need a specialized syntax.

Yep could be similar to Python's range.

import std.stdio;

struct RangeImpl(T)
{
    T from;
    T to;
    bool reversed;

    @property bool empty()
    {
        return reversed ? from == to : from >= to;
    }

    T front()
    {
        return from;
    }

    void popFront()
    {
        if (reversed)
        {
            from--;
        }
        else
        {
            from++;
        }
    }
}

auto range(T)(T from, T to)
{
    return RangeImpl!T(from, to, from > to);
}

void main()
{
    foreach (i; range(0, 10))
    {
        writeln(i);
    }

    // Same as foreach_reverse
    foreach (i; range(10, 0))
    {
        writeln(i);
    }
}

Output:
0
1
2
3
4
5
6
7
8
9
10
9
8
7
6
5
4
3
2
1

On Tuesday, 9 April 2019 at 12:19:20 UTC, bauss wrote:
> 
>
> Yep could be similar to Python's range.
>
> [snip]

Or...

import std.range;
import std.stdio : writeln;

void main()
{
    foreach (i; iota(10))
    {
        writeln(i);
    }

    foreach (i; iota(10, 0, -1))
    {
        writeln(i);
    }
}

On Monday, 8 April 2019 at 09:46:06 UTC, adam77 wrote:
> but almost every language out there (maybe with the exception of C)

C adds a lot of features on a regular basis too.

But no, D doesn't have too many language features. Each one is useful for some case and what makes D so nice is that it is useful for so many cases.

On Monday, 8 April 2019 at 22:15:52 UTC, Julian wrote:
> On Monday, 8 April 2019 at 21:52:37 UTC, Alex wrote:
>> Personally, I might suggest you go learn Haskell.
>
> I would interpret this as a request to take a long walk on a short pier.
> It probably depends on the receiver's feelings for Haskell.
>
lol, ok. Well. Again, one can't make an informed decision about something without being informed. Even if one doesn't like something they can learn from it.

People are so controlling of their time that they do more harm than good. Much of what Haskell does is the same as what D does. Haskell does typing far better(since it is formally based off of category theory and so deals with higher levels of typing that D doesn't even come close to). Haskell has it's own problems of course... but how do you know this stuff if you don't use it?

>> Or better, you could learn both. Every language will have it's pro's and con's. Language features are never a con.
>
> Some examples of cons:
>
> - Perl's Java-style new. Never used in favor of ->new(), but since it's
> in the language we have this top-voted SO question:
>
> https://stackoverflow.com/questions/11695110/why-is-this-program-valid-i-was-trying-to-create-a-syntax-error
>
> - Perl's single-quote "dot syntax". Never used in favor of ::, but since it's
> in the language you have to escape single quotes in cases like "$who's"
> so that doesn't look like an invocation of an 's' method.
>
> - Perl's @ interpolation of arrays into strings. Almost never used
> deliberately, but since it's in the language you have to escape email
> addresses in strings.
>
> - Perl's scalar/list context system. It's super cute, and it also means
> that blah("hi") either returns "hi" or "ih" ... depending on the call.
>
>   sub blah {
>     my $x = shift;
>     reverse($x)
>   }
>
> It's not all Perl, but the more common 'con' is a feature that opens
> a window while closing a hallway of doors for a language's future
> development.


These are not language features but language design choices. There is a huge difference.

The only con to a language feature is that if one person doesn't like it and reads someone else's code that does then they will not like the code.

Again, if you have the option not to use it then you are not forced to use it(except he case just cited). The only language feature that is bad is the language feature you want but don't have.

Language features are independent of grammatical construction/syntax. (any syntax can be given to a language feature to do something, it doesn't change what the language feature is, which is an abstract pattern to simplify work)

Remember, Language features add something on top of something else. If they take something else away in the process they are not language features. They are not providing an option but a mutation.

This is how language features work:

class LanguageFeature : Language


in essence, meaning that one can always use the base "class" to do their work in. It it doesn't work this way then it is not a feature. [Of course, it is true that in implementation of the feature it can cause problems, but that is not a problem of the feature itself but the implementation]

On Tuesday, 9 April 2019 at 11:39:33 UTC, Atila Neves wrote:
> On Monday, 8 April 2019 at 18:59:25 UTC, Abdulhaq wrote:
>> On Monday, 8 April 2019 at 18:45:24 UTC, jmh530 wrote:

>>
>> The problem with AST macros, and Walter seems to agree with this POV, is that every medium to large project will have its own private language that ripples throughout the code. Only a few of the developers will really understand this new language and how it can safely be used and where its pitfalls are. It will be poorly documented and a nightmare for new developers.
>
> Every medium to large project in a language *without* AST macros already has its own private language that is poorly documented and only a few of the developers really understand. It's just that this DSL is in the syntax of the host language.

Yes, and writing those DSLs for that big project is often the most fun part. However, those DSLs are normally tucked away in a specific functional area, whereas when the developer can create AST macros, the DSL can do crazy stuff and can be present or even required in every source file.

For instance, take the named parameters proposals. With AST macros each person can implement their own ideas. We could end up with one library having them one way, another library having them implemented a very different way with different behaviour. It would be very annoying if you wanted to use both libraries. Then multiply that by all the other unapproved DIPs.