www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Compiler hints, inlining and syntax consistency

reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
I think it would be useful to have a dedicated syntax for symbols 
that a naive compiler can ignore, that is, for compiler hints. 
I'd consider " disable" and "pragma" a compiler hint, but not 
" property"

I don't grasp the motivation for the naming of keywords in D. I 
think the syntax would be more clear if " " was reserved for 
compiler hints.

Suggestions for compiler-hints that are useful and empowering:

 inline(fuzzylogic-expression){ }

Examples:

 inline some_function(){...}

 inline{
    while(...){ ...inline_all_inner_loop_statements... }
}

 inline(0) never-inline-this...
 inline(1) always-inline-this...
 inline(0.5) inline-if-compiled-to-not-conserve-memory-footprint


 warningonuse "some text"

length()  warningonuse "in this class the length-function is 
O(n), consider xyz instead"

The " warningonuse" keyword enables text editors to emit symbols 
on the side of the text with helpful warnings about possible 
bottlenecks when using libraries.
Dec 28 2013
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Ola Fosheim Grøstad:


  warningonuse "some text"

 length()  warningonuse "in this class the length-function is 
 O(n), consider xyz instead"

 The " warningonuse" keyword enables text editors to emit 
 symbols on the side of the text with helpful warnings about 
 possible bottlenecks when using libraries.


A  warningonuse("some text") used for editors is just a 
convention, it needs no language changes.

Bye,
bearophile
Dec 28 2013
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Saturday, 28 December 2013 at 11:42:58 UTC, bearophile wrote:

 A  warningonuse("some text") used for editors is just a 
 convention, it needs no language changes.


All compiler-hints are conventions:  assert(), 
 suppresswarnings{} etc. Compilers should be able to ignore all 
compiler hints they don't support without affecting a progam 
which is sound. (  assert() should never be used to test input, 
only to assert that the logic is correct ).

It needs grammar-support if you want to avoid making comments 
"magic". It also needs compiler support if you want to support 
advanced IDEs or features such as 
compile-should-fail-on-any-warning.

Ola.
Dec 28 2013
prev sibling next sibling parent reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Saturday, 28 December 2013 at 11:38:38 UTC, Ola Fosheim 
Grøstad wrote:

 I think it would be useful to have a dedicated syntax for 
 symbols that a naive compiler can ignore, that is, for compiler 
 hints. I'd consider " disable" and "pragma" a compiler hint, 
 but not " property"


 disable is definitely not something a compiler should be allowed 
to ignore.


 length()  warningonuse "in this class the length-function is 
 O(n), consider xyz instead"


This is a terrible example - in D it's generally accepted that 
such a `length` function should NOT be provided at all. If it 
provides anything that standard algorithms like `walkLength` 
don't, then it must at least be named something other than 
`length`.

With this philosophy in mind and with the lack of any good 
examples, I think it's possible that  warningonuse is in fact 
undesirable.
Dec 28 2013
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Saturday, 28 December 2013 at 11:58:48 UTC, Jakob Ovrum wrote:

 This is a terrible example - in D it's generally accepted that 
 such a `length` function should NOT be provided at all.


Correction: in the D-community it is generally accepted.

But the reasoning behind this is not sound, it puts the burden on 
the programmer when you can afford to use O(N). The reasoning is 
also flawed in general because the amortized/average performance 
of algorithms depends on the structure of the input. If you know 
that N tends to be below K on average then the performance hit is 
O(1) even if the complexity is O(N) on unbounded input on a 
turing-machine. And if we are going to be pedantic: all 
algorithms that terminates on a von Neuman-computing device are 
O(1) because you can always come up with a constant upper bound 
that holds for all physical computing devices.

 disable and ( obsolete) etc can safely be ignored for a sound 
program, it is a hint for the compiler to check the integrity of 
the logic, but it does not affect the semantics of a sound 
program. The same goes for unittests, pre conditions and post 
conditions etc.
Dec 28 2013
next sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Saturday, 28 December 2013 at 13:03:30 UTC, Ola Fosheim 
Grøstad wrote:

  disable and ( obsolete) etc can safely be ignored for a sound 
 program, it is a hint for the compiler to check the integrity 
 of the logic, but it does not affect the semantics of a sound 
 program. The same goes for unittests, pre conditions and post 
 conditions etc.


D has extensive compile-time introspection. If  disable was 
ignored it would change the result of some static if statements, 
including template constraints, changing the meaning of code. 
Even worse, this change could appear silently. The same goes for 
anything else that can be tested for at compile-time.
Dec 28 2013
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Saturday, 28 December 2013 at 13:47:48 UTC, John Colvin wrote:

 D has extensive compile-time introspection. If  disable was 
 ignored it would change the result of some static if 
 statements, including template constraints, changing the 
 meaning of code. Even worse, this change could appear silently. 
 The same goes for anything else that can be tested for at 
 compile-time.


Thanks for this perspective, this makes the distinction between 
integrity and functionality fuzzy. I am not sure if I like that 
or the effect it has on debugging/programming-in-large… I prefer 
languages that conceptually and visually try to separate 
different layers (e.g. the job of "lint" and the job of 
"code-generation").
Dec 28 2013
parent reply "Dicebot" <public dicebot.lv> writes:
On Saturday, 28 December 2013 at 15:27:36 UTC, Ola Fosheim 
Grøstad wrote:

 Thanks for this perspective, this makes the distinction between 
 integrity and functionality fuzzy. I am not sure if I like that 
 or the effect it has on debugging/programming-in-large… I 
 prefer languages that conceptually and visually try to separate 
 different layers (e.g. the job of "lint" and the job of 
 "code-generation").


This is a solid approach and rationale behind trying to minimize 
warnings in D as much as possible (and potentially remove at all 
once standard lint-like tool will appear).

However it looks like you are mistaken in considering elements 
from your examples belonging to additional analysis layer. 
Anything that directly impacts basic semantical correctness of 
program is business of compiler core. Defining additional tokens 
that are invisible to introspection and supposed to be used only 
by lints may be useful but is not worth discussing until at least 
on such tool will mature.

Usage of " " for new keywords is just a matter of avoiding name 
clashes with existing user code.
Dec 28 2013
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Saturday, 28 December 2013 at 15:40:41 UTC, Dicebot wrote:

 This is a solid approach and rationale behind trying to 
 minimize warnings in D as much as possible (and potentially 
 remove at all once standard lint-like tool will appear).


Not sure what "This" refers to, but if you can change semantics 
by adding a new function to a class without using it yourself, 
then you have potential for debugging hell when using large 
frameworks written by others. Therefore I dislike  disable, I 
thought it worked like a  forbid would.


 Anything that directly impacts basic semantical correctness of 
 program is business of compiler core.


Invariants should not impact correctness. They detect lack of 
correctness.


 used only by lints may be useful but is not worth discussing 
 until at least on such tool will mature.


The language/compiler should do the job of lint. Having a 
separate tool just makes IDE integration more troublesome and few 
programmers will bother with it.
Dec 28 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-12-28 16:40, Dicebot wrote:


 Usage of " " for new keywords is just a matter of avoiding name clashes
 with existing user code.


That worked until we got UDA's with the same syntax.

-- 
/Jacob Carlborg
Dec 28 2013
parent reply "Dicebot" <public dicebot.lv> writes:
On Saturday, 28 December 2013 at 20:09:36 UTC, Jacob Carlborg 
wrote:

 On 2013-12-28 16:40, Dicebot wrote:


 Usage of " " for new keywords is just a matter of avoiding 
 name clashes
 with existing user code.


 That worked until we got UDA's with the same syntax.


I have deja vu - remember talking with you about exactly this 
topic in NG several months ago :) (My point was that it will 
still work if we make built-in attributes qualified with a 
reserved module name which is backwards-compatible change)
Dec 28 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-12-28 22:07, Dicebot wrote:


 I have deja vu - remember talking with you about exactly this topic in
 NG several months ago :)


Perhaps :)


 (My point was that it will still work if we
 make built-in attributes qualified with a reserved module name which is
 backwards-compatible change)


And my answer to that was probably something like: that module name 
could already be in use today. Also, then we get a third way of naming 
keywords:

 property nothrow  reserved.foobar int bar ();

-- 
/Jacob Carlborg
Dec 29 2013
parent "Dicebot" <public dicebot.lv> writes:
On Sunday, 29 December 2013 at 11:02:33 UTC, Jacob Carlborg wrote:

 And my answer to that was probably something like: that module 
 name could already be in use today.


Can't remember :) It won't if such modules will used a common 
reserved package name (__dmd.attributes or __compiler.attributes).


 Also, then we get a third way of naming keywords:

  property nothrow  reserved.foobar int bar ();


Is it bad? Why would anyone want to qualify it explicitly?

My proposal to resolve such name clash was to use existing symbol 
resolution rules and add explicit symbol import in such cases:

import __compiler.attributes : property; // takes precedence over 
"silent" import AFAIK
Dec 29 2013
prev sibling parent reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Saturday, 28 December 2013 at 13:03:30 UTC, Ola Fosheim 
Grøstad wrote:

 On Saturday, 28 December 2013 at 11:58:48 UTC, Jakob Ovrum 
 wrote:

 This is a terrible example - in D it's generally accepted that 
 such a `length` function should NOT be provided at all.


 Correction: in the D-community it is generally accepted.


No.

I have *no* idea where you got this idea from. D and its standard 
library follows in the footsteps of STL when it comes to the 
algorithmic complexity of primitives, and this has been an 
important tenet from *at least* the early days of D2. A few 
examples include std.container's maximum complexity requirement 
for primitives (including `length`) and the existence of 
std.range.walkLength. A recent example of enforcement includes 
the rejection of adding binary `in` functionality for 
non-associative arrays.


  disable and ( obsolete) etc can safely be ignored for a sound 
 program, it is a hint for the compiler to check the integrity 
 of the logic, but it does not affect the semantics of a sound 
 program.


You could say this about any restriction in the type system.

(` obsolete`? Did you mean `deprecated`?)
Dec 28 2013
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Saturday, 28 December 2013 at 16:35:41 UTC, Jakob Ovrum wrote:

 I have *no* idea where you got this idea from. D and its 
 standard library follows in the footsteps of STL when it comes 
 to the algorithmic complexity of primitives


STL is not great, has never been great, and probably will never 
be great. Cool idea, bad execution for the language it was 
implemented in. So they had to change C++ to support i better! :-P

How much time does a committee need to agree on a hash-table 
implementation? Or should I say decades? STL is so 
designed-by-a-committee that it hurts. It is not a shining star! 
Not at all.

STL is ok for early prototyping with C++11, but if you care about 
performance you roll your own.


 an important tenet from *at least* the early days of D2. A few 
 examples include std.container's maximum complexity requirement 
 for primitives (including `length`) and the existence of


Single linked lists is very useful for situations where you want 
lists that are mostly empty or short, but where you do not want 
to impose an upperbound. O(N) on length() does not matter much in 
many real-world scenarios.

What you want is a (mild) warning if you use a templated 
algorithm and that algorithm use a O(N) primitive where it is 
invisible to the library user. A warning you should be able to 
suppress (basically telling the compiler "trust me, this is 
deliberate").


 std.range.walkLength. A recent example of enforcement includes 
 the rejection of adding binary `in` functionality for 
 non-associative arrays.


Why is that?  If your non-associative array on average is of 
length 3-4 then it might outperform an associative array.

Just like insertion sort will outperform other sorts for 
mostly-sorted arrays where the elements are offset by jitter (so 
they are 3-4 elements out-of-place). O(N*N) can easily beat O(N) 
if the dataset is a good fit. If not, everybody would use 
radix-sort and nobody would even consider quicksort.

Worst case analysis assuming unbounded arbitrary input is only of 
theoretical interest, in the real world you care about the 
average cost over the dataset you actually run the algorithm on. 
Unless you write hard realtime systems (life-support, weapon 
systems, etc).


 You could say this about any restriction in the type system.

 (` obsolete`? Did you mean `deprecated`?)


(sure, or " forbid" or " notimplemented" etc)
Dec 28 2013
next sibling parent reply "Chris Cain" <clcain uncg.edu> writes:
On Saturday, 28 December 2013 at 17:23:38 UTC, Ola Fosheim 
Grøstad wrote:

 What you want is a (mild) warning if you use a templated 
 algorithm and that algorithm use a O(N) primitive where it is 
 invisible to the library user. A warning you should be able to 
 suppress (basically telling the compiler "trust me, this is 
 deliberate").


How is that significantly different than the current situation?

If you use walkLength, then that's you telling the compiler 
"trust me, this is deliberate". The only difference is that the 
current behavior doesn't use a warning, it just errors out with 
"this thing doesn't define a length", which is reasonable 
behavior.

FYI, if your thing defines length, then walkLength calls it. So 
it's effectively as fast to use when your thing has length 
defined, otherwise it suggests that you understand that a relaxed 
constraint of O(N) is acceptable and will do that for you if 
length doesn't exist.
Dec 28 2013
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Saturday, 28 December 2013 at 17:53:31 UTC, Chris Cain wrote:

 How is that significantly different than the current situation?


It is different in the sense that if your lengths are short you 
either have to write your own container or your own algorithm 
because the algorithm designer assumed that walkLength would be 
too slow in all cases? In the case of phobos you probably could 
just change the algorithm to use walkLength yourself and include 
it with your source. In a more complex framework it might be more 
difficult?


 FYI, if your thing defines length, then walkLength calls it. So 
 it's effectively as fast to use when your thing has length 
 defined, otherwise it suggests that you understand that a 
 relaxed constraint of O(N) is acceptable and will do that for 
 you if length doesn't exist.


Yes, but I still think that all containers should have length() 
regardless of efficiency because that is more intuitive, and then 
you might either provide properties that can be used to assess 
performance or define a lengthFast() for those algorithms that 
require O(1).
Dec 28 2013
parent reply "Chris Cain" <clcain uncg.edu> writes:
On Saturday, 28 December 2013 at 18:38:55 UTC, Ola Fosheim 
Grøstad wrote:

 It is different in the sense that if your lengths are short you 
 either have to write your own container or your own algorithm 
 because the algorithm designer assumed that walkLength would be 
 too slow in all cases? In the case of phobos you probably could 
 just change the algorithm to use walkLength yourself and 
 include it with your source. In a more complex framework it 
 might be more difficult?


struct LengthWrapper(T) {
    T wrapped;
    size_t length()  property {
        return wrapped.walkLength();
    }
    alias wrapped this;
}

LengthWrapper!T assumeWalkLengthOK(T)(T thing) {
    return LengthWrapper!T(thing);
}

There you go. Use it like:

```
someGenericAlgorithm(assumeWalkLengthOK(myContainer));
```

Squelches the error message and documents the intent. Could be 
better, but it saves us writing a language feature for it.
Dec 28 2013
parent reply "Chris Cain" <clcain uncg.edu> writes:
On Saturday, 28 December 2013 at 18:47:52 UTC, Chris Cain wrote:

 ...snip...

 There you go. Use it like:

 ```
 someGenericAlgorithm(assumeWalkLengthOK(myContainer));
 ```

 Squelches the error message and documents the intent. Could be 
 better, but it saves us writing a language feature for it.


I keep forgetting to use voldemort types, and in this case it 
really makes sense:

     import std.range;
     auto assumeWalkLengthOK(T)(T thing)
     if(isInputRange!T)
     {
         struct Result
         {
             T wrapped;
             size_t length()
             {
                 return wrapped.walkLength();
             }
             alias wrapped this;
         }
         return Result(thing);
     }

Same usage, 
`someGenericAlgorithm(assumeWalkLengthOK(myContainer));` (I 
didn't actually run this through dmd, but it should work in 
theory)
Dec 28 2013
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Saturday, 28 December 2013 at 18:55:31 UTC, Chris Cain wrote:

 Same usage, 
 `someGenericAlgorithm(assumeWalkLengthOK(myContainer));` (I 
 didn't actually run this through dmd, but it should work in 
 theory)


Not too bad. Being able to create adaptors like this is a nice 
workaround for overruling library design decisions, at least if 
it is simple enough for the compiler backend is able to "undo" 
any overhead.
Dec 28 2013
prev sibling parent reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Saturday, 28 December 2013 at 17:23:38 UTC, Ola Fosheim 
Grøstad wrote:

 STL is not great, has never been great, and probably will never 
 be great. Cool idea, bad execution for the language it was 
 implemented in. So they had to change C++ to support i better! 
 :-P

 How much time does a committee need to agree on a hash-table 
 implementation? Or should I say decades? STL is so 
 designed-by-a-committee that it hurts. It is not a shining 
 star! Not at all.

 STL is ok for early prototyping with C++11, but if you care 
 about performance you roll your own.


Nice tirade, but I only referenced STL for its take on 
algorithmic complexity requirements. If it makes the concept more 
palatable, you could instead imagine it as the anti-thesis of 
Java's collection interfaces.


 Single linked lists is very useful for situations where you 
 want lists that are mostly empty or short, but where you do not 
 want to impose an upperbound. O(N) on length() does not matter 
 much in many real-world scenarios.


In these cases you can use `walkLength` which is in itself the 
very warning you want.


 What you want is a (mild) warning if you use a templated 
 algorithm and that algorithm use a O(N) primitive where it is 
 invisible to the library user. A warning you should be able to 
 suppress (basically telling the compiler "trust me, this is 
 deliberate").


You could define a wrapper type to explicitly attach O(n) 
primitives onto ranges and/or containers, but generally the 
response is that you're using the wrong container, so this 
probably won't find its way to Phobos.

However, it should be noted that D supports flexible 
metaprogramming which has resulted in algorithms with looser 
requirements, such as Andrei's 
`std.algorithm.levenshteinDistance` which doesn't require random 
access, circumventing the problem entirely.


 Why is that?  If your non-associative array on average is of 
 length 3-4 then it might outperform an associative array.


In terms of advantages, it is only a minor syntactical benefit 
over using std.algorithm.among/canFind/find.

But the disadvantages are serious, most notably generic code that 
uses `in` and assumes it has some complexity guarantee would 
experience a blow-up in complexity when an array is passed.

Further, adding syntax sugar to such an operation sends the wrong 
signal and is thus asking for trouble during code maintenance - 
initially the array might have been small and use of `in` 
judicious, but later down the line the array grows while the use 
of `in` is preserved because it *looks* low-cost (after all, it 
looks identical to AA lookup). Alternatively, it can be a 
teaching problem; by having the scalable AA lookup and the 
non-scalable array lookup use the same syntax, a beginner could 
produce really bad code as a result of the hidden but vital 
difference.

(Also, for many typical element types, a length of 3-4 is an 
extremely conservative measure. The number where an array starts 
to be slower can be much, much higher than that, but the idea is 
that scalability is initially more important than 
micro-optimization [unless it's a C program, in which case using 
anything but an array is often not even worth the effort])
Dec 28 2013
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Saturday, 28 December 2013 at 18:18:57 UTC, Jakob Ovrum wrote:

 algorithmic complexity requirements. If it makes the concept 
 more palatable, you could instead imagine it as the anti-thesis 
 of Java's collection interfaces.


Anything that isn't Java sounds palatable… Except for 
Objective-C, which is worse.


 However, it should be noted that D supports flexible 
 metaprogramming which has resulted in algorithms with looser 
 requirements, such as Andrei's 
 `std.algorithm.levenshteinDistance` which doesn't require 
 random access, circumventing the problem entirely.


Nice. Yes, that kind of illustrate the real issue, what you 
really want in the ideal world is to specify the basic properties 
of your dataset and the algorithms you want to apply to it.  Then 
let the compiler choose the best fit in the available set of 
container- and algorithm- implementations. (or achieve the same 
through profiling)

But that is kind of difficult to achieve for library level ADTs 
with just basic templates, so the algorithm implementor has to 
predict usage patterns instead.


 But the disadvantages are serious, most notably generic code 
 that uses `in` and assumes it has some complexity guarantee 
 would experience a blow-up in complexity when an array is 
 passed.


Ok, I agree with this for simple operators like +, -, * etc. 
Whether 'in' is a simple operator probably depends on what you 
are used to from other languages.


 Further, adding syntax sugar to such an operation sends the 
 wrong signal and is thus asking for trouble during code 
 maintenance - initially the array might have been small and use 
 of `in` judicious, but later down the line the array grows 
 while the use of `in` is preserved because it *looks* low-cost


Depends on where you come from. I think it is quite common in 
Python code to test 'in' for short immutable (literal) arrays, 
e.g. "if action in ['say','talk','shout']:"

I think it is reasonable to accept that, because the code becomes 
much easier to read if you do lots of text processing. So it 
depends on what kind of programs you tend to write. It has no 
place in a 3D engine, but is useful in text based adventure games.
Dec 28 2013
parent reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Saturday, 28 December 2013 at 19:11:14 UTC, Ola Fosheim 
Grøstad wrote:

 But the disadvantages are serious, most notably generic code 
 that uses `in` and assumes it has some complexity guarantee 
 would experience a blow-up in complexity when an array is 
 passed.


 Ok, I agree with this for simple operators like +, -, * etc. 
 Whether 'in' is a simple operator probably depends on what you 
 are used to from other languages.


That's fair enough. I think the safe choice is to wait and see 
how it unfolds in libraries to come.


 Further, adding syntax sugar to such an operation sends the 
 wrong signal and is thus asking for trouble during code 
 maintenance - initially the array might have been small and 
 use of `in` judicious, but later down the line the array grows 
 while the use of `in` is preserved because it *looks* low-cost


 Depends on where you come from. I think it is quite common in 
 Python code to test 'in' for short immutable (literal) arrays, 
 e.g. "if action in ['say','talk','shout']:"

 I think it is reasonable to accept that, because the code 
 becomes much easier to read if you do lots of text processing. 
 So it depends on what kind of programs you tend to write. It 
 has no place in a 3D engine, but is useful in text based 
 adventure games.


For array literals it's not such a bad idea, and was recently 
topical in the assessment of `std.algorithm.among`[1]. However, 
as elaborated upon in the linked PR, I think the library solution 
is superior for D.

[1] https://github.com/D-Programming-Language/phobos/pull/1787
Dec 28 2013
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Saturday, 28 December 2013 at 19:20:15 UTC, Jakob Ovrum wrote:

 For array literals it's not such a bad idea, and was recently 
 topical in the assessment of `std.algorithm.among`[1]. However,


It is not a bad idea for sorted arrays either, when you think 
about it: O(log n)
Dec 28 2013
parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Saturday, 28 December 2013 at 19:24:19 UTC, Ola Fosheim 
Grøstad wrote:

 On Saturday, 28 December 2013 at 19:20:15 UTC, Jakob Ovrum 
 wrote:

 For array literals it's not such a bad idea, and was recently 
 topical in the assessment of `std.algorithm.among`[1]. However,


 It is not a bad idea for sorted arrays either, when you think 
 about it: O(log n)


It could be added to `std.range.SortedRange`. For element type T, 
it could return T* when the underlying range has write access, 
and bool otherwise.

SortedRange needs work anyway; for one, I always wanted `find` on 
a sorted range to do binary search seamlessly...
Dec 28 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-12-28 12:38, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:


 I don't grasp the motivation for the naming of keywords in D. I think
 the syntax would be more clear if " " was reserved for compiler hints.


Originally   was added for some new keywords to get a new "namespace" 
for keywords. There was no risk of conflict with existing symbol names 
since   wasn't allowed in symbol names. Since UDA's were introduces this 
isn't the case anymore.

-- 
/Jacob Carlborg
Dec 28 2013
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Saturday, 28 December 2013 at 14:32:20 UTC, Jacob Carlborg 
wrote:

 Originally   was added for some new keywords to get a new 
 "namespace" for keywords. There was no risk of conflict with


Understand. Objective-C and Python also suffers from the 
arbitrary " " syntax. Basically what I would like to see is 
" keyword" on stuff that can be hidden without making the 
semantics less clear (so you could have a "hide/show" button in 
your editor). I think it also would make the language easier for 
newbies if they can easily separate 
advanced-stuff-I-don't-need-to-understand-yet from more vital 
constructs.

It is easy to come up with many potentially useful "compiler 
hints" for programmers that care about performance:

// allocate simd-aligned and 0-padded string by sacrificing 
memory for efficiency,
// if supported

 simd string

// force loop-unrolling modulo 4 in order to trigger SIMD 
optimizations

 unroll(4) for(…) {}

etc...
Dec 28 2013
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Saturday, 28 December 2013 at 15:36:56 UTC, Ola Fosheim 
Grøstad wrote:

 On Saturday, 28 December 2013 at 14:32:20 UTC, Jacob Carlborg 
 wrote:

 Originally   was added for some new keywords to get a new 
 "namespace" for keywords. There was no risk of conflict with


 Understand. Objective-C and Python also suffers from the 
 arbitrary " " syntax. Basically what I would like to see is 
 " keyword" on stuff that can be hidden without making the 
 semantics less clear (so you could have a "hide/show" button in 
 your editor).


It should be #keyword than, as existing #line is closest thing to 
what you describe


 // allocate simd-aligned and 0-padded string by sacrificing 
 memory for efficiency,
 // if supported

  simd string


Bad example - it impacts program semantics a lot.


 // force loop-unrolling modulo 4 in order to trigger SIMD 
 optimizations

  unroll(4) for(…) {}


Same here. Such stuff is done by compiler-specific attributes or 
pragmas. It has no similarities with stuff like #foldregion and 
should not be treated same.
Dec 28 2013
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Saturday, 28 December 2013 at 15:45:16 UTC, Dicebot wrote:

 It should be #keyword than, as existing #line is closest thing 
 to what you describe


Does it matter? I don't think #line is particularly close, it is 
just an annotation.


 // allocate simd-aligned and 0-padded string by sacrificing 
 memory for efficiency,
 // if supported

  simd string


 Bad example - it impacts program semantics a lot.


Not if done properly. Why would it?


 // force loop-unrolling modulo 4 in order to trigger SIMD 
 optimizations

  unroll(4) for(…) {}


 Same here. Such stuff is done by compiler-specific attributes 
 or pragmas. It has no similarities with stuff like #foldregion 
 and should not be treated same.


Pragmas and compiler-specific attributes suck and makes code less 
readable. Inlining and unrolling is common enough to warrant 
support, otherwise programmers will do manual unrolling in 
inner-loops in order to get portable code.
Dec 28 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-12-28 16:36, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:


 Understand. Objective-C and Python also suffers from the arbitrary " "
 syntax.


I don't think Objective-C suffers from this. In Objective-C   is used 
for every new keyword and other stuff that's not available in standard 
C. Sure, you can do all that in plain C but it's very cumbersome and 
verbose.

-- 
/Jacob Carlborg
Dec 28 2013
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Saturday, 28 December 2013 at 20:07:46 UTC, Jacob Carlborg 
wrote:

 I don't think Objective-C suffers from this. In Objective-C   
 is used for every new keyword and other stuff that's not 
 available in standard C.


Yes, well what I meant was that they used   to avoid keyword 
clashes with the existing grammar. I personally feel like I am 
suffering when using Objective-C, it's like talking to a compiler 
with a split personality disorder.
Dec 28 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-12-28 21:12, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:


 Yes, well what I meant was that they used   to avoid keyword clashes
 with the existing grammar. I personally feel like I am suffering when
 using Objective-C, it's like talking to a compiler with a split
 personality disorder.


Yeah, but it has a though behind it and it's consistent at least.

-- 
/Jacob Carlborg
Dec 29 2013