September 18

On Sunday, 18 September 2022 at 12:15:17 UTC, Max Samukha wrote:

>

On Sunday, 18 September 2022 at 11:00:12 UTC, Loara wrote:

>

Because it seems that some people really needs binary literals and can't work without them although there are many higher level alternatives.

Yes, we need them because they have use cases where alternatives are not justifiable. For example, we have a simple communication protocol that defines just a handful of commands with additional information encoded in the bits (command length, flags, etc). It would be unreasonable to complicate the code with bit ops, parsers, etc., which would make it less readable. Having to replace the literals with bin!... would be tolerable, though.

You can use hex literals behind an high level interface that hides them behind enums/aliases, in this way users won't need to know the position of each bit when they'll use your library.

Also if you need to change the order of two bits for some reason you'll just change 2/3 enums and your code will work anyway. In general it's better to hide constants behind an alias instead of copy them in several places.

September 18

On Sunday, 18 September 2022 at 12:47:03 UTC, Don Allen wrote:

>

On Sunday, 18 September 2022 at 04:26:45 UTC, Preetpal wrote:

>

On Sunday, 18 September 2022 at 01:55:35 UTC, Don Allen wrote:

>

On Saturday, 17 September 2022 at 22:11:35 UTC, Preetpal wrote:

>

[...]

Haskell does not have binary integer literals. See the 2010 language report and

Prelude> 0x10
16
Prelude> 0o10
8
Prelude> 0b10

<interactive>:8:2: error: Variable not in scope: b10

"The language extension BinaryLiterals adds support for expressing integer literals". So you need to use a language extension to use it.

ps@DESKTOP:~$ ghci
GHCi, version 8.8.4: https://www.haskell.org/ghc/  :? for help
Prelude> :set -XBinaryLiterals
Prelude> 0b0010
2
Prelude>

An extension offered by one compiler, off by default, is not the same as inclusion in the official language definition. The official Haskell language does not include binary literals.

Well if you use that as your definition, you can technically remove it off the list. The language extensions in Haskell are probably candidates for the next official standard though.

September 19
On 18.09.22 14:47, Don Allen wrote:
> ...
> 
> An extension offered by one compiler, off by default, is not the same as inclusion in the official language definition. The official Haskell language does not include binary literals.

In practice, this is just not how Haskell works. It's really common for Haskell code to rely on at least some GHC extensions (including GHC itself).
September 20

On Sunday, 18 September 2022 at 11:00:12 UTC, Loara wrote:

>

Binary literals aren't efficient (too many digit to represent relatively small numbers) and aren't essential to the language itself (hex literals are far more efficient). If you need to set flags an enum approach makes code much more readable:

enum MyFlag {A = 0, B, C}

T asFlag(T)(in T f) pure @safe nothrow @nogc{
  return (1 << f);
}

...

int field = MyFlag.A.asFlag & MyFlag.B.asFlag;

You made an error right away.

September 21

On Wednesday, 14 September 2022 at 05:58:53 UTC, Walter Bright wrote:

>

On 9/13/2022 7:56 PM, Steven Schveighoffer wrote:

>

But it doesn't disprove the fact that sometimes, hex digits aren't as clear.

Does sometimes justify a language feature, when there are other ways?

People often complain that D has too many features. What features would you say are not worth it?

Function types. I don’t mean types like int function(string) (that is a function pointer type); I mean int(string). They are nowhere documented (as far as I can tell) and make some meta-programming tasks nasty.

void F(T)(T* ptr)
{
    pragma(msg, T); // prints void()
}
void main()
{
    void function() f = { };
    F(f);
}

If you try making f a delegate, the call F(f) cannot resolve T (obviously).

In C++, I can at least make use of them when a lot of functions should have the same signature and I don’t want to bother the reader making sure that is actually the case; I can typedef (via using) the function type and declare the functions to have exactly the same signature without repeating it:

// file.h
using F = void(int, double);
F f1, f2; // look like variables, but are function declarations.

// file.cpp
void f1(int i, double d) { }
void f2(int i, double d) { }

If I wanted something like that in D, my take would not be to add function types, but to do this:

alias F = void function(int, double);
enum F f1 = (i, d) { }
enum F f2 = (i, d) { }

If needed, just add a language rule that enum function pointers are an alternative syntax for free or static member functions and that enum delegates are an alternative syntax for non-static member functions (aka. methods).

Currently, function types are “needed” to apply __parameters to. Not only should __parameters work with function pointer types and delegate types, it should not work with function types because function types should not exist.

September 21

On Wednesday, 21 September 2022 at 11:50:16 UTC, Quirin Schroll wrote:

>

On Wednesday, 14 September 2022 at 05:58:53 UTC, Walter Bright wrote:

>

[...]

void F(T)(T* ptr)
{
    pragma(msg, T); // prints void()
}
void main()
{
    void function() f = { };
    F(f);
}

If you try making f a delegate, the call F(f) cannot resolve T (obviously).

[...]

alias F = void function(int, double);
enum:F{ f1 = (i, d) { writeln("f1"); }}
enum:F{ f2 = (i, d) { writeln("f2"); }}

or

alias F = void function(int, double);
enum:F {
    f1 = (i, d) { },
    f2 = (i, d) { }
}

so i'd say this should work too

enum:F f1 = (i, d) { };
September 21

On Wednesday, 21 September 2022 at 12:12:52 UTC, Zealot wrote:

>
alias F = void function(int, double);
enum : F
{
    f1 = (i, d) { },
    f2 = (i, d) { }
}

This is big. You can do

enum : void function(int, double)
{
    f1 = (i, d) { },
    f2 = (i, d) { },
}
>

so i'd say this should work too

enum : F f1 = (i, d) { };

Why do you think this is good? Just use a space instead of :.

September 21
On Sunday, 18 September 2022 at 22:45:17 UTC, Timon Gehr wrote:
> On 18.09.22 14:47, Don Allen wrote:
>> ...
>> 
>> An extension offered by one compiler, off by default, is not the same as inclusion in the official language definition. The official Haskell language does not include binary literals.
>
> In practice, this is just not how Haskell works. It's really common for Haskell code to rely on at least some GHC extensions (including GHC itself).

You are missing my point. In any language -- C, Haskell, what have you -- some compilers will implement extensions, such as the nested functions in C introduced by gcc. The essential point is that just because some compiler implements an extension, there is no guarantee that extension will make it into the official language definition, therefore you use that extension at the risk of writing non-portable, non-future-proofed code. Haskell is no different in that respect from any other language. That is true can be found in a number of hits you turn up when you search for 'haskell language extensions'.

Whether it is common or not for "Haskell code to rely on *at least some* GHC extensions" is not the issue. The issue is whether those extensions eventually become an official part of the language. Some do, some don't, or some do in revised form.

You can have the last word if you like; I'm done with this thread, which has long since crossed the ad nauseam threshold.
September 22

On Wednesday, 21 September 2022 at 19:22:00 UTC, Don Allen wrote:

>

On Sunday, 18 September 2022 at 22:45:17 UTC, Timon Gehr wrote:

>

[...]

You are missing my point. In any language -- C, Haskell, what have you -- some compilers will implement extensions, such as the nested functions in C introduced by gcc. The essential point is that just because some compiler implements an extension, there is no guarantee that extension will make it into the official language definition, therefore you use that extension at the risk of writing non-portable, non-future-proofed code. Haskell is no different in that respect from any other language. That is true can be found in a number of hits you turn up when you search for 'haskell language extensions'.

Whether it is common or not for "Haskell code to rely on at least some GHC extensions" is not the issue. The issue is whether those extensions eventually become an official part of the language. Some do, some don't, or some do in revised form.

You can have the last word if you like; I'm done with this thread, which has long since crossed the ad nauseam threshold.

Yeah, I guess an extreme version of this could be saying that Haskell has refinement types because Liquid Haskell exists

A lot of C's flaws could be accounted for if we were willing to consider GNU C rather than ISO C

10 11 12 13 14 15 16 17 18 19 20
Next ›   Last »