On 13/09/2022 6:11 AM, Kagamin wrote:
> On Monday, 12 September 2022 at 18:05:14 UTC, rikki cattermole wrote:
>> Escapes require extra processing, more memory usage to display, which is unnecessary for this this type of data.
> 
> Hex strings require extra processing too, they aren't WYSIWYG.

They require very little processing and only in the compiler.

> And there being lots of small code points I suspect you can even save space by using short escapes compared to hex strings.

Keep in mind that hex strings use case is not for string data. It is a method of getting a whole load of raw bytes directly into the binary which can be cast to the appropriate type before usage (i.e. struct).

The direct comparison is to array literal syntax ``[123, 14, 72]`` for which you still have the comma, which adds extra processing to the editor...

On 13/09/2022 6:19 AM, rikki cattermole wrote:
> Keep in mind that hex strings use case is not for string data. It is a method of getting a whole load of raw bytes directly into the binary which can be cast to the appropriate type before usage (i.e. struct).

The example I used for bin2d[0] was shared library dependencies that get extracted out at runtime. It generated hex strings for the file contents.

https://github.com/rikkimax/Bin2D

On Monday, 12 September 2022 at 18:19:19 UTC, rikki cattermole wrote:
> They require very little processing and only in the compiler.

Escapes are processed by the compiler too. In fact, only combining and control characters need to be escaped, all others can appear literally for best compression and minimal processing except for transcoding from utf-8 to utf-32.

On 13/09/2022 6:47 AM, Kagamin wrote:
> On Monday, 12 September 2022 at 18:19:19 UTC, rikki cattermole wrote:
>> They require very little processing and only in the compiler.
> 
> Escapes are processed by the compiler too. In fact, only combining and control characters need to be escaped, all others can appear literally for best compression and minimal processing except for transcoding from utf-8 to utf-32.

Which is great for textual data. Not useful if you have binary data of any fixed sized type.

On Monday, 12 September 2022 at 18:34:04 UTC, rikki cattermole wrote:
> The example I used for bin2d[0] was shared library dependencies that get extracted out at runtime. It generated hex strings for the file contents.
>
> https://github.com/rikkimax/Bin2D

Tar format is the standard unix workaround for the case where you can't have folder hierarchy and need to have everything as one file.

On Tue, Sep 13, 2022 at 06:05:14AM +1200, rikki cattermole via Digitalmars-d wrote:
> 
> On 13/09/2022 5:50 AM, Kagamin wrote:
> > Can't you use escapes there?
> 
> Every character you add, increases the file size and slows down your editor.
>
> Escapes require extra processing, more memory usage to display, which is unnecessary for this this type of data.

Yes, but isn't this a bit making mountains out of molehills?  Unless you're talking about hundreds of thousands of extra characters, the difference likely to be unnoticeable.

If something on the order of a few hundred extra characters can cause a noticeable performance hit in your editor, you need to find a new editor. :-P

Not to mention, it sounds a bit disingenuous to be complaining about memory usage when DMD carefreely allocates huge amounts of memory (and never frees it) just to compile a program, such that on a low-memory system it can't even compile anything except trivial programs before running out of memory and crashing. A few thousand extra characters in a source file isn't going to make much of a difference here.



T

-- 
If blunt statements had a point, they wouldn't be blunt...

On Mon, Sep 12, 2022 at 06:08:21PM +0000, Adam D Ruppe via Digitalmars-d wrote:
> On Monday, 12 September 2022 at 17:56:42 UTC, Kagamin wrote:
> > If I were to simplify D, I'd slay delimited strings, IIRC there are dozens of them.
> 
> There's three forms. All trivial lexer features that haven't changed for ages and not caused bugs in any other language component. While some editors might not support them properly, it isn't hard to add then forget about it.

+1.  I thoroughly enjoy D's delimited strings; they make code-generating code more readable. Long snippets of code in a language being generated would be utterly horrendous if I had to manually escape every line of it. Heredoc syntax is ideal for this sort of thing.


T

-- 
It only takes one twig to burn down a forest.

On 13/09/2022 7:07 AM, H. S. Teoh wrote:
> Yes, but isn't this a bit making mountains out of molehills?

I'm complaining about it here, as it was basically an ideal way to handle a set of specific use cases. It basically had no cost to keep. Just like binary literals.

It is an identical scenario that I regret not speaking up about at the time and I don't want the same thing to happen again.

On Monday, 12 September 2022 at 14:48:12 UTC, jmh530 wrote:
> On Sunday, 11 September 2022 at 07:24:03 UTC, Max Samukha wrote:
>> On Saturday, 10 September 2022 at 19:05:38 UTC, Don Allen wrote:
>>>
>>> I couldn't agree more with this. I've made it clear that I've done some very successful work with D and have been very pleased with the outcome. But this work involved porting C code I wrote 10 years ago that had become ugly (or maybe it always was) and difficult to maintain. The D version is a big improvement.
>>
>> Removing the binary literals does not mean reduction in complexity, neither in the compiler, nor in the user code.
>
> There are multiple ways that complexity has been used on this thread, which I think contributed to a lot of disagreements. It might be better in the future if people make clear whether they refer to compiler-complexity or user-complexity (or call it developer-complexity, same idea).
>
> I don't have the knowledge to comment on how they impact compiler-complexity.
>
> I think most people would agree that removing binary literals would not meaningfully reduce user-complexity. I haven't heard of a new D programmer struggling with understanding about how binary literals interact with some other feature in a complex way.  They aren't that frequently used, but people can look up how they work if you need them. However, there's also an asymmetry. The more a user makes use of them, the larger the potential cost to them for the removal. So, even if there is a minor reduction of user-complexity, the people who make use of them face a larger cost. I think this is what frustrates some on the thread.
>
> I would echo the comments of others about the importance of automated tools to reduce the burden on users of these kinds of changes. I don't recall anyone mentioning the removal of complex/imaginary numbers, but the issues are the same.

On Monday, 12 September 2022 at 14:48:12 UTC, jmh530 wrote:
> On Sunday, 11 September 2022 at 07:24:03 UTC, Max Samukha wrote:
>> On Saturday, 10 September 2022 at 19:05:38 UTC, Don Allen wrote:
>>>
>>> I couldn't agree more with this. I've made it clear that I've done some very successful work with D and have been very pleased with the outcome. But this work involved porting C code I wrote 10 years ago that had become ugly (or maybe it always was) and difficult to maintain. The D version is a big improvement.
>>
>> Removing the binary literals does not mean reduction in complexity, neither in the compiler, nor in the user code.
>
> There are multiple ways that complexity has been used on this thread, which I think contributed to a lot of disagreements. It might be better in the future if people make clear whether they refer to compiler-complexity or user-complexity (or call it developer-complexity, same idea).
>
> I don't have the knowledge to comment on how they impact compiler-complexity.
>
> I think most people would agree that removing binary literals would not meaningfully reduce user-complexity. I haven't heard of a new D programmer struggling with understanding about how binary literals interact with some other feature in a complex way.  They aren't that frequently used, but people can look up how they work if you need them. However, there's also an asymmetry. The more a user makes use of them, the larger the potential cost to them for the removal. So, even if there is a minor reduction of user-complexity, the people who make use of them face a larger cost. I think this is what frustrates some on the thread.
>
> I would echo the comments of others about the importance of automated tools to reduce the burden on users of these kinds of changes. I don't recall anyone mentioning the removal of complex/imaginary numbers, but the issues are the same.

I was talking about language complexity, as was Walter. I thought that was quite clear and still do.

While I expressed agreement with Walter regarding his desire to simplify D, I don't have a strong opinion about the possibility of removing binary literals, because this is not where I see D's complexity problems.

I don't use binary literals myself. A recent use case for me was defining various flag bits that are part of  integer columns in several Sqlite tables. I define them with enums like so:
````
enum AccountFlags
{
    descendents_are_marketable_bit = 0,
    descendents_are_marketable = 1,
    hidden_bit = 1,
    hidden = 1 << hidden_bit,
    descendents_are_assets_bit = 2,
    descendents_are_assets = 1 << descendents_are_assets_bit,
    placeholder_bit = 3,
    placeholder = 1 << placeholder_bit,
...
````
It's nice that the shifting takes place at compile-time in D.

Hardware registers usually are similar to the above -- a collection of bits each having its own meaning and a specific bit number. If I were doing this sort of work in D, I would most likely deal with those register bits in the same way I describe above. Creating masks for multi-bit fields can be dealt with similarly.

So while I don't have a personal use for binary literals, clearly others have. But Walter sees an internal cost to the compiler. So while most of us can weigh in on the perceived benefit of retaining binary literals or not, few of us can understand the cost and therefore the tradeoff.

I'd mention that Rust has binary literals as does Nim. Haskell does not, though it has both octal and hex literals.

On Saturday, 10 September 2022 at 02:22:53 UTC, Walter Bright wrote:
> Hex values are far easier to read, too. Have you ever put the tip of your pencil on the screen to count the number of 1's? I have. Binary literals are user unfriendly.

That's true only if you're working with hex values.

Besides, I've had to use the tip of a pencil to count Fs in hex values.
Are you saying that hex is user friendlier when dealing with decimal values, too ?

Because I've always used decimal for that - and I think the most user friendly way to go about binary values is binary literals.

Converting something else to hex and then back to something else is the opposite of user friendly. IMO.