On Saturday, 14 December 2013 at 04:09:18 UTC, Walter Bright wrote:
> On 12/13/2013 12:06 PM, deadalnix wrote:
>> I'm reinventing it right now for SDC, so it indeed make sense.
>
> Reinventing EH or inline asm?

EH. Still very similar to what LDC does (which is understandable as it uses LLVM as well).

Am 13.12.2013 18:34, schrieb H. S. Teoh:
> On Fri, Dec 13, 2013 at 03:30:21PM +0100, Paulo Pinto wrote:
> [...]
>> Maybe the best way to fix this issue is to follow what other
>> language standards do (C++, Ada) and only define that inline
>> assembly is possible and how the entry point, e.g. asm () looks
>> like.
>>
>> The real inline assembly syntax is then left implementation
>> specific.
>
> But isn't this what Walter was arguing against? He wanted to standardize
> inline assembly syntax for x86 because leaving it up to implementation
> resulted in the current mess of Intel syntax vs. GNU syntax (which can
> be extremely confusing if you're not well-versed in both syntaxes, since
> the order of operands are swapped and there are some subtle notational
> differences).
>
>
> T
>

Yeah, but it is an easier path to have something standardized that corresponds to reality, than making all frontends agree on the same syntax and semantics for inline assembler.

If I understood correctly the current issues, that is.


--
Paulo

> The alt-compilers have an attribute... if only we could alias attributes
> (or groups of attributes). Another thing we need... :/

With GDC you can already do this:

import gcc.attribute;

@attribute("forceinline") foo()
...

> @attribute("forceinline") foo()

should be

@attribute("forceinline") ReturnType foo()

of course.

On 14 December 2013 04:08, Walter Bright <newshound2@digitalmars.com> wrote:
> On 12/13/2013 11:07 AM, David Nadlinger wrote:
>>
>> LDC in fact implements DMD-style inline assembly (occasionally there are
>> bugs,
>> though, as it's a complete reimplementation).
>
>
> Thank you! That's awesome!
>

The implementation of which existed in GDC first, and was released as dual GPL/BSD license to allow into LDC devs to use and improve (they added 64bit assembler support for instance, years before DMD got 64bit support), and then subsequently dropped from GDC for a number of valid reasons:

1) Transition towards making a platform/target agnostic frontend implementation.

2) Don't and will never implement the DMD-style calling convention, so all inline assembly in druntime and phobos actually doesn't work with GDC - there's actually a bug report about GDC incorrectly pre-defining D_InlineAsm and friends because of this.

3) It is a really big WAT on having two conflicting styles, one for x86, another for everything else.

4) This and other x86 hacks were a problem with code reviewers from GCC.

Though saying that, whilst DMD-style was not ideal, neither is GDC-style either, as it requires parser changes, and adds a new class to handle them in the frontend.

Dicebot:

>> 2. dependable sizes of basic types
>
> Not a real issue as your platform SDK always includes some kind of "stdint.h"

On the other hand in D you have less noise. Most D modules you find around use and will use the built-in types, instead of choosing every time different ones. This uniformity is an improvement.


> Would have called this a feature if one could actually use something instead out of the box. But there is no way to control symbol visibility right now so templates / CTFE are often out of the toolset. And what to do without those?

This should be fixed.


>> 9. modules
>
> Other than (1) it is also more a problem than help in current implementation

Despite their flaws, D modules are quite handy, and better than C way of managing source code files.


> you need to care also about emitted ModuleInfo.

I think LDC2 has a pragma to disable module info generation. Can't something like that be standardized for all D compilers, including D? Have you opened well reasoned enhancement requests for your desires?


> Not an issue. C programmers are not tired from typing.

That's a silly answer. When it works (and it's working more and more), the freedom it gives is handy.


> Nice but just a syntax sugar yet again.

Having less cluttered code is an improvement.


>> 16. struct alignment as a language feature rather than an ugly extension kludge
>
> Same as (11)

Having built-in standard features save you troubles and work.


>> 19. no need for global variables when qsorting
>
> Doesn't matter

Why?


>> 20. no global locale madness
>
> (no idea what this means)

I think Walter refers to this kind of stuff:
http://www.cplusplus.com/reference/clocale/


> `auto` has no real value in C world because there are not crazy template types.

"auto" can be handy in C-like code too (but it's less needed because the types are simpler), to avoid repeating struct names, to avoid repeating types two times when you call malloc, etc.


> @safe is a joke for barebone, you almost never be able to apply it :)

I think you can have some safe functions in C-style code too :-)


> - Allocation for stuff like array literals making those unusable once you remove runtime away

There is hope to remove this problem:
https://github.com/D-Programming-Language/dmd/pull/2952
https://github.com/D-Programming-Language/dmd/pull/2958


> - No internal linkage or reliable LTO  - no way to take care of unused symbols and control binary size / layout

This could be worked on.

And now instead of negatives, let's talk about missing positive features. A future replacement for the C language should allow the kind of low level code you use in C, and also offer ways to express more semantics to the compiler, that will be verified and enforced, to make the code safer. Currently the only language I know that is a bit like this is the ATS2 language (http://www.ats-lang.org/ ), and it's partially a failure. (D and Rust are more replacements for C++ than for C). There's still plenty of work to do in the design of low-level languages. A compiler for such (probably imperative) language will probably need to contain a SAT solver, and more inference skills.

Bye,
bearophile

On 12/11/2013 12:46 AM, Walter Bright wrote:
> On 12/10/2013 3:04 PM, Timon Gehr wrote:
>> Malloc is part of the language runtime. Everything needed is known
>> about it, in
>> particular that it is pure (in the D sense). Also, the source code of
>> malloc
>> will not be standard C code.
>
> All right, so write your own storage allocator. How are you going to
> tell the C compiler that it's pure?

How about the D compiler?

On Saturday, 14 December 2013 at 17:12:16 UTC, bearophile wrote:
> Dicebot:
>
>
>
>> @safe is a joke for barebone, you almost never be able to apply it :)
>
> I think you can have some safe functions in C-style code too :-)

Yes, given my experience in Turbo Pascal and Oberon, there are lots of places in C-style code that code be safe as well.

For example, there are very few places where dark magic pointer tricks are really essential.

Only those code sections really need to be unsafe.

--
Paulo

On Fri, Dec 13, 2013 at 06:01:10PM -0800, Walter Bright wrote:
> On 12/13/2013 6:52 AM, Dicebot wrote:
[...]
> >>3. unicode
> >
> >Number one my list of advantages. Does not apply to plenty of projects though.
> 
> It applies more than you might think. Most D apps will be inherently unicode correct. Very, very few C programs are unless the programmer went to some effort to make it so. And, take a look at all those miserable UNICODE macros in windows.h.

Yeah, in C, you have to proactively write code to be unicode-compatible. And I daresay a very large percentage of C code are *not*, and it's a major effort to make them compatible.


> >>4. wchar_t that is actually usable
> >
> >Same as (3)
> 
> Almost nobody uses wchar_t in C code because it is unusable. Windows uses it for the "W" api functions, but surrogate pairs are broken in just about every C program, because C has no idea what a surrogate pair is. Furthermore, you're just fscked if you try to port wchar_t code from Windows to Linux, you're looking at line-by-line rewrite of all of that code.

I tried writing wchar_t code before. I tried making it portable by following only the wchar_t functions described in official C standards. I discovered that the C standards are incomplete w.r.t. wchar_t: there are many unspecified and underspecified areas, such as, to take a major example, the non-commitment to providing some means to ensure a Unicode locale. In every official doc that I can find, it depends on setting locale strings, the interpretation of which is "implementation- dependent" (i.e., you're on your own). There isn't even a way to reliably check whether you're currently in a Unicode locale (y'know, when you give up on trying to set the locale string yourself and (questionably) rely on the user to do it, but your code assumes UTF-8 and you need a way to detect an incompatible locale setting). And the semantics of many wchar_t functions are vague and underspecified ("depends on locale setting"), and some key functions are missing, or wrapped behind very inconvenient APIs (*ahem*mbtowcs*wcstomb*cough*).

Long story short, let's just say that even writing wchar_t code from scratch is a royal pain in the neck, *and* there's no guarantee the end product will actually work correctly. Unless you reinvent the wheel, disregard wchar_t, and rewrite your own UTF-8 implementation. Don't even speak of converting an existing C program to wchar_t.

I was so scarred from the experience that when I saw that D supported unicode natively, I was totally sold.


[...]
> >>6. no global errno being set by the math library functions
> >This has made me smile :) It shows how different applications we have in mind speaking about "C domain".
> 
> Do you mean people don't do math in C apps?

Weird. Most of my personal projects (originally C/C++, now D) are
math-related. :)


[...]
> >>12. forward referencing (no need to declare everything twice)
> >Not an issue. C programmers are not tired from typing.
> 
> C programs tend to be written "bottom up" to avoid forward references. This is not convenient.

I still do that even in D programs, because DMD's handling of forward references is, shall we say, quirky? It works most of the time, but sometimes you get odd errors because certain symbol resolution algorithms used by dmd will produce unexpected results if you don't declare certain symbols beforehand. So it's not completely order-free, but also not completely order-dependent, but something nebulous in between. Me, I play it safe and just write things the C way, so that I never run into these kinds of issues.


[...]
> >>20. no global locale madness
> >(no idea what this means)
> 
> strtod's behavior (for example) is dependent on the current locale. The fact that you didn't know this is indicative of its problems. This is not the only locale-dependent behavior. C has a number of issues with global state.

Yeah, like errno, one of the ugliest hacks to be made an official standard.

And the entire wchar_t train-wreck, every bit of which is officially declared "locale-dependent", meaning they change their behaviour depending on the locale string you set, and of course the locale strings themselves are "implementation-dependent", so there's basically zero commitment to make portable code possible at all. Sure, to make your program truly portable you do have to invest some effort into it, but given the amount of ugliness you have to endure to work with wchar_t in the first place, you might as well just reinvent your own UTF implementation from scratch (the API would be cleaner, for one thing).

And that's not even scratching the surface of things like strtod, like Walter mentioned, that almost everyone *assumes* works a certain way, but may have unexpected results once you insert a setlocale() call into your program. Action-at-a-distance FTW.


T

-- 
Do not reason with the unreasonable; you lose by definition.

On 12/14/2013 6:08 AM, Iain Buclaw wrote:
> The implementation of which existed in GDC first, and was released as
> dual GPL/BSD license to allow into LDC devs to use and improve (they
> added 64bit assembler support for instance, years before DMD got 64bit
> support),

I didn't know this, thanks for telling me.

> and then subsequently dropped from GDC for a number of valid
> reasons:
>
> 1) Transition towards making a platform/target agnostic frontend implementation.
>
> 2) Don't and will never implement the DMD-style calling convention, so
> all inline assembly in druntime and phobos actually doesn't work with
> GDC - there's actually a bug report about GDC incorrectly pre-defining
> D_InlineAsm and friends because of this.

dmd's works on multiple platforms and uses version statements to account for ABI differences. It's still easier than having a different syntax.


> 3) It is a really big WAT on having two conflicting styles, one for
> x86, another for everything else.

gcc gets them wrong for everything else, too :-)


> 4) This and other x86 hacks were a problem with code reviewers from GCC.

I can understand that.

> Though saying that, whilst DMD-style was not ideal, neither is
> GDC-style either, as it requires parser changes, and adds a new class
> to handle them in the frontend.
>