Jump to page: 1 25  
Page
Thread overview
Which language constructs could be done as a library if we accept some breaking changes?
Nov 28, 2021
Elronnd
Nov 29, 2021
user1234
Nov 29, 2021
user1234
Nov 29, 2021
user1234
Nov 28, 2021
Alexandru Ermicioi
Nov 29, 2021
zjh
Nov 29, 2021
bauss
Nov 29, 2021
Nick Treleaven
Nov 29, 2021
Alexandru Ermicioi
Nov 29, 2021
Nick Treleaven
Nov 29, 2021
Paul Backus
Nov 29, 2021
Alexandru Ermicioi
Nov 29, 2021
bauss
Nov 29, 2021
rumbu
Nov 29, 2021
jmh530
Nov 30, 2021
Guillaume Piolat
Nov 30, 2021
zjh
Nov 30, 2021
Guillaume Piolat
Dec 01, 2021
12345swordy
Dec 02, 2021
12345swordy
Dec 02, 2021
12345swordy
Dec 02, 2021
Paul Backus
November 28, 2021

If there was a majority in favour of D3, with breaking changes, and a strong focus on meta-programming, then it would make a lot of sense to streamline the language.

What would that consist of? I would say:

  1. Figuring out what the missing bits for meta-programming are.

  2. Taking out all language constructs that can be implemented as a library feature.

  3. Add some syntactical sugar where necessary (mapping to library features).

Which features that are currently in the language could with some adjustments be done as a library feature?

Hashtable?

Dynamic array?

Slices?

Shared?

Class?

Others language features…?

(I think all these could be done if meta-programming facilities were strengthened.)

What do you think?

November 28, 2021
On Sunday, 28 November 2021 at 20:47:28 UTC, Ola Fosheim Grøstad wrote:
> Which features that are currently in the language could with some adjustments be done as a library feature?
>
> Class?

Classes should be a language feature in any case, for performance reasons
November 28, 2021

On Sunday, 28 November 2021 at 20:47:28 UTC, Ola Fosheim Grøstad wrote:

>

If there was a majority in favour of D3, with breaking changes, and a strong focus on meta-programming, then it would make a lot of sense to streamline the language.

What would that consist of? I would say:

  1. Figuring out what the missing bits for meta-programming are.

  2. Taking out all language constructs that can be implemented as a library feature.

  3. Add some syntactical sugar where necessary (mapping to library features).

Which features that are currently in the language could with some adjustments be done as a library feature?

Hashtable?

Dynamic array?

Slices?

I think these could've been implemented as structs, then the only change would be to rewrite any T[] to Array!T, given structs are able completely replicate their behavior.

This in turn can lessen the coupling between compiler and the implementation, and allow other potential implementations. For example using custom gc, or making them rc counted (given rc problems are solved), or having a backing store location implementation hidden by interface allowing you to use different storing methods. There might be some compatibility problems though.

I.e. you won't have any breakage here, though you might consider removing them as language constructs, and have the said breakage.

Best regards,
Alexandru.

November 29, 2021

On Sunday, 28 November 2021 at 21:01:53 UTC, Elronnd wrote:

>

On Sunday, 28 November 2021 at 20:47:28 UTC, Ola Fosheim Grøstad wrote:

>

Which features that are currently in the language could with some adjustments be done as a library feature?

Class?

Classes should be a language feature in any case, for performance reasons

A good compiler will detect standard library features and use a fast-path/optimized-path for those. So there should be no performance impact.

November 29, 2021

On Sunday, 28 November 2021 at 21:56:37 UTC, Alexandru Ermicioi wrote:

>

I think these could've been implemented as structs, then the only change would be to rewrite any T[] to Array!T, given structs are able completely replicate their behavior.

Yes, that should be the goal. Improve on meta-programming facilities and extending structs with more capabilities to make the language both smaller and more powerful.

And exactly right, "T[…]" could be syntactical sugar that maps onto a standard library type, making the language more uniform and adaptable.

>

I.e. you won't have any breakage here, though you might consider removing them as language constructs, and have the said breakage.

I think one has to accept breakage in order to streamline the language, so it would require D3, but the resulting language should be equally expressive!

(I think that ought to be possible.)

November 29, 2021

On Sunday, 28 November 2021 at 20:47:28 UTC, Ola Fosheim Grøstad wrote:

>

If there was a majority in favour of D3, with breaking changes, and a strong focus on meta-programming, then it would make a lot of sense to streamline the language.

What would that consist of? I would say:

  1. Figuring out what the missing bits for meta-programming are.

  2. Taking out all language constructs that can be implemented as a library feature.

  3. Add some syntactical sugar where necessary (mapping to library features).

Which features that are currently in the language could with some adjustments be done as a library feature?

Hashtable?

Dynamic array?

Slices?

Shared?

Class?

Others language features…?

(I think all these could be done if meta-programming facilities were strengthened.)

What do you think?

Pretty much anything can be solved in a library, except for things that requires AST/macros.

November 29, 2021

On Sunday, 28 November 2021 at 20:47:28 UTC, Ola Fosheim Grøstad wrote:

>

If there was a majority in favour of D3, with breaking changes, and a strong focus on meta-programming, then it would make a lot of sense to streamline the language.

What would that consist of? I would say:

  1. Figuring out what the missing bits for meta-programming are.

  2. Taking out all language constructs that can be implemented as a library feature.

  3. Add some syntactical sugar where necessary (mapping to library features).

Which features that are currently in the language could with some adjustments be done as a library feature?

Hashtable?

Dynamic array?

Slices?

Shared?

Class?

Others language features…?

(I think all these could be done if meta-programming facilities were strengthened.)

What do you think?

And consequentely we can rename it "!" instead of "D".

November 29, 2021

On Monday, 29 November 2021 at 11:38:17 UTC, rumbu wrote:

>

And consequentely we can rename it "!" instead of "D".

I understand your concern, but the crux is to provide syntactical sugar. D already does this for user-defined operators, so it is a matter of coming up with something equally useful for other constructs than operators.

The advantage is that in meta-programming you can ignore all the syntactical sugar and deal only with the minimal core language.

(Syntactical sugar disappears after the AST has been built.)

November 29, 2021

On Monday, 29 November 2021 at 11:22:44 UTC, Ola Fosheim Grøstad wrote:

>

I think one has to accept breakage in order to streamline the language, so it would require D3, but the resulting language should be equally expressive!

(I think that ought to be possible.)

for D better,tolerence breakage is OK.

November 29, 2021

On Monday, 29 November 2021 at 11:12:16 UTC, Ola Fosheim Grøstad wrote:

>

On Sunday, 28 November 2021 at 21:01:53 UTC, Elronnd wrote:

>

On Sunday, 28 November 2021 at 20:47:28 UTC, Ola Fosheim Grøstad wrote:

>

Which features that are currently in the language could with some adjustments be done as a library feature?

Class?

Classes should be a language feature in any case, for performance reasons

A good compiler will detect standard library features and use a fast-path/optimized-path for those. So there should be no performance impact.

static casts, devirtualization, are reasons for built-in classes.
Things for classes that can be done in the library are already done there, e.g dynamic casts.

« First   ‹ Prev
1 2 3 4 5