Through Reddit I have found a link to some information about the Clay language, it wants to be (or it will be) a C++-class language, but it's not tied to C syntax. It shares several semantic similarities with D too. It looks like a cute language:
https://github.com/jckarter/clay/wiki/

Some small parts from the docs:

--------------------------

In Clay this: https://github.com/jckarter/clay/wiki/Syntax-desugaring

static for (a in ...b)
    c;

is equivalent to:

{
    ref a = <first element of b>;
    c;
}
{
    ref a = <second element of b>;
    c;
}
/* ... */

I have an enhancement request about this for D: http://d.puremagic.com/issues/show_bug.cgi?id=4085

--------------------

The part about Safer pointer type system is very similar to what I did ask for D, and it looks similar to what Ada language does (for Clay this is just a proposal, not implemented yet, but Ada is a rock-solid language):
https://github.com/jckarter/clay/wiki/Safer-pointer-type-system

--------------------

This is something that I want for D too, it's important:

>Jonathan Shapiro (of BitC) makes an excellent argument that, in a systems language, it is often undesirable to depend on the whims of an ill-specified optimizer to convert abstract code into efficient machine code. The BitC specification thus includes the idea of guaranteed optimizations, to allow code to be written in a high-level style with predictably low or nonexistent runtime cost (link). [...] Because Clay seeks to support systems programming with high-level abstraction, certain patterns should be guaranteed to be optimized in a certain way, instead of being left to the whims of LLVM or a C compiler. Additional optimizations should not be prevented, however. [...] It should be possible to specify that one or more of these optimizations is required, and have the compiler raise an error when they cannot be applied for some reason.<

https://github.com/jckarter/clay/wiki/Guaranteed-optimizations

Bye,
bearophile

On Mon, Dec 27, 2010 at 4:35 PM, bearophile <bearophileHUGS@lycos.com>wrote:

> Through Reddit I have found a link to some information about the Clay
> language, it wants to be (or it will be) a C++-class language, but it's not
> tied to C syntax. It shares several semantic similarities with D too. It
> looks like a cute language:
> https://github.com/jckarter/clay/wiki/
>
> Some small parts from the docs:
>
> --------------------------
>
> In Clay this: https://github.com/jckarter/clay/wiki/Syntax-desugaring
>
> static for (a in ...b)
>    c;
>
> is equivalent to:
>
> {
>    ref a = <first element of b>;
>    c;
> }
> {
>    ref a = <second element of b>;
>    c;
> }
> /* ... */
>
> I have an enhancement request about this for D: http://d.puremagic.com/issues/show_bug.cgi?id=4085
>
> --------------------
>
> The part about Safer pointer type system is very similar to what I did ask for D, and it looks similar to what Ada language does (for Clay this is just a proposal, not implemented yet, but Ada is a rock-solid language): https://github.com/jckarter/clay/wiki/Safer-pointer-type-system
>
> --------------------
>
> This is something that I want for D too, it's important:
>
> >Jonathan Shapiro (of BitC) makes an excellent argument that, in a systems
> language, it is often undesirable to depend on the whims of an ill-specified optimizer to convert abstract code into efficient machine code. The BitC specification thus includes the idea of guaranteed optimizations, to allow code to be written in a high-level style with predictably low or nonexistent runtime cost (link). [...] Because Clay seeks to support systems programming with high-level abstraction, certain patterns should be guaranteed to be optimized in a certain way, instead of being left to the whims of LLVM or a C compiler. Additional optimizations should not be prevented, however. [...] It should be possible to specify that one or more of these optimizations is required, and have the compiler raise an error when they cannot be applied for some reason.<
>
> https://github.com/jckarter/clay/wiki/Guaranteed-optimizations
>
> Bye,
> bearophile
>

+1 for static for and guaranteed optimizations. Can we put it in the wishlist?

-- 
Atenciosamente / Sincerely,
Guilherme ("n2liquid") Vieira

On Mon, 27 Dec 2010 13:42:50 -0700, Guilherme Vieira <n2.nitrogen@gmail.com> wrote:

> On Mon, Dec 27, 2010 at 4:35 PM, bearophile <bearophileHUGS@lycos.com>wrote:
>
>> Through Reddit I have found a link to some information about the Clay
>> language, it wants to be (or it will be) a C++-class language, but it's not
>> tied to C syntax. It shares several semantic similarities with D too. It
>> looks like a cute language:
>> https://github.com/jckarter/clay/wiki/
>>
>> Some small parts from the docs:
>>
>> --------------------------
>>
>> In Clay this:
>> https://github.com/jckarter/clay/wiki/Syntax-desugaring
>>
>> static for (a in ...b)
>>    c;
>>
>> is equivalent to:
>>
>> {
>>    ref a = <first element of b>;
>>    c;
>> }
>> {
>>    ref a = <second element of b>;
>>    c;
>> }
>> /* ... */
>>
>> I have an enhancement request about this for D:
>> http://d.puremagic.com/issues/show_bug.cgi?id=4085
>>
>> --------------------
>>
>> The part about Safer pointer type system is very similar to what I did ask
>> for D, and it looks similar to what Ada language does (for Clay this is just
>> a proposal, not implemented yet, but Ada is a rock-solid language):
>> https://github.com/jckarter/clay/wiki/Safer-pointer-type-system
>>
>> --------------------
>>
>> This is something that I want for D too, it's important:
>>
>> >Jonathan Shapiro (of BitC) makes an excellent argument that, in a  
>> systems
>> language, it is often undesirable to depend on the whims of an ill-specified
>> optimizer to convert abstract code into efficient machine code. The BitC
>> specification thus includes the idea of guaranteed optimizations, to allow
>> code to be written in a high-level style with predictably low or nonexistent
>> runtime cost (link). [...] Because Clay seeks to support systems programming
>> with high-level abstraction, certain patterns should be guaranteed to be
>> optimized in a certain way, instead of being left to the whims of LLVM or a
>> C compiler. Additional optimizations should not be prevented, however. [...]
>> It should be possible to specify that one or more of these optimizations is
>> required, and have the compiler raise an error when they cannot be applied
>> for some reason.<
>>
>> https://github.com/jckarter/clay/wiki/Guaranteed-optimizations
>>
>> Bye,
>> bearophile
>>
>
> +1 for static for and guaranteed optimizations. Can we put it in the
> wishlist?

If you followed the bug report, you'd find D already has a way of doing static foreach.

bearophile wrote:
> This is something that I want for D too, it's important:
> 
>> Jonathan Shapiro (of BitC) makes an excellent argument that, in a systems
>> language, it is often undesirable to depend on the whims of an
>> ill-specified optimizer to convert abstract code into efficient machine
>> code. The BitC specification thus includes the idea of guaranteed
>> optimizations, to allow code to be written in a high-level style with
>> predictably low or nonexistent runtime cost (link). [...] Because Clay
>> seeks to support systems programming with high-level abstraction, certain
>> patterns should be guaranteed to be optimized in a certain way, instead of
>> being left to the whims of LLVM or a C compiler. 
>> [...]
>> It should be possible to specify
>> that one or more of these optimizations is required, and have the compiler
>> raise an error when they cannot be applied for some reason.<

Frankly, this is meaningless. For example, while C does not specify what optimizations will be done, in practice you'd be very hard pressed to find one that didn't do:

1. replacing a*4 with a<<2
2. doing decent register allocation, obviating the role of the "register" keyword
3. dead assignment elimination
4. named return value optimization
5. etc.


>> Additional optimizations should not be prevented, however.

I.e. the same situation as today.

Walter:

>>> Additional optimizations should not be prevented, however.

> I.e. the same situation as today.

It's a different situation. See this part:

> It should be possible to specify
> that one or more of these optimizations is required, and have the compiler
> raise an error when they cannot be applied for some reason.<

The idea is to allow the code (I presume with the help of some annotations) to require certain optimizations (some are listed here, and they are more complex than replacing a*4 with a<<2:https://github.com/jckarter/clay/wiki/Guaranteed-optimizations ), if the compiler doesn't perform a specific optimization (that I presume an annotation asks for), a compilation error is raised, and the programmer is forced to change the code, removing the annotation or doing something else. This also means that a conforming Clay compiler must perform a certain number of not simple optimizations (further optimizations are accepted. So the point is for a specific piece of code to have a common level of optimization).

I don't know if all this is possible (this meta-feature is in the wish list of Clay), but if it's doable then it sounds like a very good thing to add to D3.

Bye,
bearophile

bearophile wrote:
> The idea is to allow the code (I presume with the help of some annotations)
> to require certain optimizations (some are listed here, and they are more
> complex than replacing a*4 with
> a<<2:https://github.com/jckarter/clay/wiki/Guaranteed-optimizations ), if the
> compiler doesn't perform a specific optimization (that I presume an
> annotation asks for), a compilation error is raised, and the programmer is
> forced to change the code, removing the annotation or doing something else.
> This also means that a conforming Clay compiler must perform a certain number
> of not simple optimizations (further optimizations are accepted. So the point
> is for a specific piece of code to have a common level of optimization).


Like I said, this is meaningless wankery. There's a minimum bar of acceptability of the generated code for every widely used compiler, specified or not.

Do you really want to annotate code with which optimizations should be performed? Frankly, you and everyone else will get it wrong. Look at the register keyword in C - every non-trivial piece of code I've seen that tried to carefully annotate declarations with "register" got it wrong, which is why every C/C++ compiler today ignores the "register" keyword, and now the "inline" keyword is ignored as well.

Let the compiler implementors do their job. If they don't, file bug reports, use another compiler, etc. You don't specify how UPS gets a package to your door, if you tried you'd get it wrong; you simply expect them to do it.

On 12/28/2010 12:48 AM, bearophile wrote:
> Walter:
>
>>>> Additional optimizations should not be prevented, however.
>
>> I.e. the same situation as today.
>
> It's a different situation. See this part:
>
>> It should be possible to specify
>> that one or more of these optimizations is required, and have the compiler
>> raise an error when they cannot be applied for some reason.<
>
> The idea is to allow the code (I presume with the help of some annotations) to require certain optimizations (some are listed here, and they are more complex than replacing a*4 with a<<2:https://github.com/jckarter/clay/wiki/Guaranteed-optimizations ), if the compiler doesn't perform a specific optimization (that I presume an annotation asks for), a compilation error is raised, and the programmer is forced to change the code, removing the annotation or doing something else. This also means that a conforming Clay compiler must perform a certain number of not simple optimizations (further optimizations are accepted. So the point is for a specific piece of code to have a common level of optimization).
>
> I don't know if all this is possible (this meta-feature is in the wish list of Clay), but if it's doable then it sounds like a very good thing to add to D3.
>

Frankly, I'd warmly back Walter on this one. "Requiring" optimizations is similar to asking a compiler to do something it's not supposed to. In the end, optimization is a means compiler uses to make generated code more "efficient", which is a subjective term and can only be approximated by e.g. instruction count per operation, memory request rate, overall code size, etc. But it's not a "conuer-the-world" means. On one hand, demanding a certain optimization means that programmer knows it's possible (e.g, programmer can do it herself with, e.g., inline asm), but on the other hand it must mean that it's applicable to used language instructions (but language or compiler may not be smart enough to figure out "optimizable" spot).
I can't think of a way to blame the compiler if it can't optimize code the way you want (and blaming in this context means forcing error message instead of using another code generation path) - this, in effect, is like asking compiler to reject perfectly valid code. It also "narrows" (is this a verb in English?) selection of compilers for your code (because optimization is at the very least a thing a compiler may or may not have).

I think that what *would* be useful is *disallowing* optimizations for certain parts of code. I mean, (if we talk about dmd or many C/C++ compilers), with -O flag, the compiler is given carte blanche on code generation, which may or may not lead to certain "unexpected" differences between unoptimized and optimized code. For example, several times I ran across nasty spots with optimized-out temporaries in C++ (think of relying on constructor calls). I can't remember the exact cases (shame on me, I haven't thought about storing a test-case database at that point), but I do remember well the frustration.
This disallowing is not so easy as it seems (not to talk about requiring), because optimizing compiler can employ certain assumptions on overall code generation strategy, which may not fit well this "external control". But overall, asking *not* to do certain things is a lot more liberal than asking to *do the things in the exact way*.

Stanislav Blinov wrote:
> Frankly, I'd warmly back Walter on this one. "Requiring" optimizations is similar to asking a compiler to do something it's not supposed to. In the end, optimization is a means compiler uses to make generated code more "efficient", which is a subjective term and can only be approximated by e.g. instruction count per operation, memory request rate, overall code size, etc. But it's not a "conuer-the-world" means. On one hand, demanding a certain optimization means that programmer knows it's possible (e.g, programmer can do it herself with, e.g., inline asm), but on the other hand it must mean that it's applicable to used language instructions (but language or compiler may not be smart enough to figure out "optimizable" spot).

Another problem with specified optimizations is that computer architectures change, and the right optimizations to use can change dramatically (and has).


> I think that what *would* be useful is *disallowing* optimizations for certain parts of code. I mean, (if we talk about dmd or many C/C++ compilers), with -O flag, the compiler is given carte blanche on code generation, which may or may not lead to certain "unexpected" differences between unoptimized and optimized code. For example, several times I ran across nasty spots with optimized-out temporaries in C++ (think of relying on constructor calls). I can't remember the exact cases (shame on me, I haven't thought about storing a test-case database at that point), but I do remember well the frustration.
> This disallowing is not so easy as it seems (not to talk about requiring), because optimizing compiler can employ certain assumptions on overall code generation strategy, which may not fit well this "external control". But overall, asking *not* to do certain things is a lot more liberal than asking to *do the things in the exact way*.

This is the issue with "implementation defined" behavior. D tries to minimize that.

On 12/27/10 12:35 PM, bearophile wrote:
> Through Reddit I have found a link to some information about the Clay language, it wants to be (or it will be) a C++-class language, but it's not tied to C syntax. It shares several semantic similarities with D too. It looks like a cute language:
> https://github.com/jckarter/clay/wiki/
[snip]

FWIW I just posted a response to a question asking for a comparison between Clay and D2.

http://www.reddit.com/r/programming/comments/es2jx/clay_programming_language_wiki/


Andrei

On 12/28/2010 03:49 AM, Walter Bright wrote:
> Stanislav Blinov wrote:
>> Frankly, I'd warmly back Walter on this one. "Requiring" optimizations
>> is similar to asking a compiler to do something it's not supposed to...
>
> Another problem with specified optimizations is that computer
> architectures change, and the right optimizations to use can change
> dramatically (and has).
>
>
>> I think that what *would* be useful is *disallowing* optimizations for
>> certain parts of code...
>
> This is the issue with "implementation defined" behavior. D tries to
> minimize that.

Damn. What defines a distance between knowledge and wisdom is often the ability to say everything with one word (well, at least one sentence) :)