Re: D compile time algorithms implementation

[khurshid]

On Saturday, 20 April 2013 at 20:12:18 UTC, Walter Bright wrote:

On 4/20/2013 2:27 AM, Peter Alexander wrote:
If possible, could you file an enhancement request? It would 
also be great if

you could add your improvement as a pull request on github!

http://d.puremagic.com/issues/enter_bug.cgi?product=D
https://github.com/D-Programming-Language/phobos


Yes, please do so.


I just have create issue: 
http://d.puremagic.com/issues/show_bug.cgi?id=9976

Re: Attribute inference for auto functions?

[Zach the Mystic]

On Tuesday, 16 April 2013 at 15:22:56 UTC, Andrei Alexandrescu 
wrote:
There's a discussion that may be of interest to the larger 
community: 
https://github.com/D-Programming-Language/dmd/pull/1877


Andrei


I just want to say I'm pretty gung-ho about the idea of attribute 
inference. If the interface files are blown up to their full 
explicit attributes, then the big problem of the PIMPL idiom 
could be solved, with modular programs getting all the info they 
need and the original source code still quite trim and easy to 
write. In the discussion of the possible uses of the 'scope' 
parameter attribute, and 'ref' safety in general, there's a lot 
of subtleties. One solution to the subtleties is additional 
attributes, which might be cumbersome to write individually, but 
easier if inference were on the table.

Re: DIP 36: Rvalue References

[Zach the Mystic]

On Sunday, 21 April 2013 at 22:16:14 UTC, Timon Gehr wrote:
What does 'scope' bind to? How to make it bind to something 
else (if at all)?


I agree this is an issue. We need to enumerate the use cases. Is 
'scope' transitive or does it only apply to the first thing it 
hits?



Passing an r-value by ref is disallowed for arbitrary reasons.


Reasons not closely related to lack of 'scope'. So why bind the 
new rule to scope?


I think that it's possible to consider binding it as a convenient 
benefit of what 'scope' is generally meant to do anyway. I think 
the crossover of the two features is quite high. But it is a 
judgment call. Sometimes you may want to allow rvalue refs 
without prohibiting escaping them, or prohibit escaping them 
without allowing rvalues refs. But the point of 'scope' is that 
it safely takes stack references, which is exactly what rvalue 
temps are.


Maybe getting the two features separate is good, but since it 
will require another parameter attribute, it suggests a need for 
increased reliance on attribute inference to spare the programmer 
the trouble. The main reason to consider combining is that it 
saves on syntax.


If I read the ambiguous wording of the proposal correctly, the 
following code will be disallowed:


void foo1(scope ref int x) { }

void main(){
foo1(1); // error
}


My impression is that this would be allowed, not disallowed.


But this will be fine:

void foo1(scope ref int x) { }
int bar(){ return 1; }

void main(){
foo1(bar());
}


I think this would also be allowed.

Re: Stable D version?

[Jesse Phillips]

On Sunday, 21 April 2013 at 19:58:14 UTC, Tourist wrote:

Hi guys,

I've been following the forums for a while. I'm interested in 
looking into D, but I understand that currently it changes 
often, and is not very reliable.
I've also read that there's a new release model planned, where 
a stable version of the language is released every year or two. 
Is that so? When would it take place?


What's holding you from releasing a version now and declaring 
it stable for e.g. a year?


The year long support is not going to be put in place at this 
time. Several took issue with that plan considering it to provide 
limited/no benefit.


The core dev team is currently getting use to using a staging 
branch to prepare a release.


Eventually we may see a release get patched up until the point of 
the next release, but this has not yet been adopted by the core 
team or those writing patches. Having a clear understanding of 
what goes where has been a big point of discussion which again no 
one could agree on the specifics.

Re: DIP 36: Rvalue References

[Timon Gehr]

On 04/21/2013 10:38 PM, Manu wrote:

...

That's not what scope does. Scope promises that the variables
will not
escape the scope.


That is the intention, but this formulation is awfully imprecise.
Hence nothing has been implemented.

void foo(scope ref int x){ ... }
void foo(scope int* x){ ... }
void foo(scope ref int* x){ ... }


What's the problem here?



What does 'scope' bind to? How to make it bind to something else (if at 
all)?


Does the proposal lock down 'scope' to always refer to every single 
pointer in the argument?




// ???

struct S{
 scope S* x; // ???
}


I don't think scope on a struct member makes a lot of sense.


void main()@safe{
S s;
auto t = S(&t);
}


scope on a local variable declaration makes sense though, it would be
able to be assigned from another scope variable.


'scope' shouldn't restrict the abstraction capability of structs.


Although I would say the same about ref on a local variable declaration,
which is disallowed for completely unknown reasons.


And as such, just happens to make passing a temporary
by ref safe.
...


But this is not about safety! Passing an rvalue by ref is disallowed
even in @system code. Hence 'scope' is assigned a meaning different
from its intention. The DIP also aims to add more special behaviour
to built-in literals.


Passing an r-value by ref is disallowed for arbitrary reasons.


Reasons not closely related to lack of 'scope'. So why bind the new rule 
to scope?



It can easily create a temporary on the spot, but it doesn't, because it's not
considered good form to pass a temp to a function by ref.  ...


Yet this is what everyone appears to want to do.


Explain to me what meaning 'scope' has been assigned that is different
from it's intention?


Implicit binding of (some) rvalues to ref.


And what 'special behaviour'?



If I read the ambiguous wording of the proposal correctly, the following 
code will be disallowed:


void foo1(scope ref int x) { }

void main(){
foo1(1); // error
}

But this will be fine:

void foo1(scope ref int x) { }
int bar(){ return 1; }

void main(){
foo1(bar());
}


I honestly can't understand the objections, by you or deadalnix. Can
someone actually explain the problem clearly?


Having a lot of ad-hoc programming language rules leads to a clumsy 
design. Eg. see the evolution of C++.

template mixin function name mangling

[John Colvin]

Apologies for another question so short after the previous one.

tempmix.d:

mixin template Foo()
{
extern(C) void foo() {}
}

mixin Foo!();

extern(C) void bar() {}


$dmd -c tempmix.d
$nm tempmix.o
 t
 T bar
 D _D7tempmix12__ModuleInfoZ
 T _D7tempmix15__unittest_failFiZv
 T _D7tempmix7__arrayZ
 T _D7tempmix8__assertFiZv
 W _D7tempmix8__T3FooZ3fooUZv
 U _d_array_bounds
 U _d_assertm
 w _d_dso_registry
 U _Dmodule_ref
 U _d_unittestm

foo gets mangled D-style, bar is left bare. Is this deliberate? I 
was under the impression that they should both be left bare.


I tried moving the extern(C) around to various other places, 
including extern(C): at the top of the file. No success.

Re: DIP 36: Rvalue References

[Manu]

On 22 April 2013 04:23, Timon Gehr  wrote:

> On 04/21/2013 06:27 AM, Zach the Mystic wrote:
>
>> ...
>>
>> Yeah, that's kind of what I meant when I said it's a two-for-one deal.
>> You get to pass temps, and you get safety checking too.
>>
>
> I prefer to buy separate products separately.
>

I'm confused, what 2 products are you getting? Which of said products do
you actually object to?

Re: DIP 36: Rvalue References

[Manu]

On 22 April 2013 03:39, Timon Gehr  wrote:

> On 04/21/2013 02:51 AM, Manu wrote:
>
>> On 21 April 2013 06:51, Timon Gehr > > wrote:
>>
>> On 04/20/2013 05:56 PM, Dicebot wrote:
>>
>> You miss quite an important point - DIP36 does not add new
>> feature. It
>> partially defines existing feature (scope) to replace an
>> existing but
>> broken solution (auto ref). Nothing new is really added to the
>> language,
>> only existing stuff better defined.
>>
>>
>> _New meaning_ is assigned to existing grammar whose original purpose
>> is at most loosely related to the _new_ features.
>>
>> I do not think that making 'scope' indicate an rvalue reference is
>> particularly future proof.
>>
>>
>> That's not what scope does. Scope promises that the variables will not
>> escape the scope.
>>
>
> That is the intention, but this formulation is awfully imprecise. Hence
> nothing has been implemented.
>
> void foo(scope ref int x){ ... }
> void foo(scope int* x){ ... }
> void foo(scope ref int* x){ ... }
>

What's the problem here?


// ???
>
> struct S{
> scope S* x; // ???
> }
>

I don't think scope on a struct member makes a lot of sense.
scope on a local variable declaration makes sense though, it would be able
to be assigned from another scope variable.
Although I would say the same about ref on a local variable declaration,
which is disallowed for completely unknown reasons.


 And as such, just happens to make passing a temporary
>> by ref safe.
>> ...
>>
>
> But this is not about safety! Passing an rvalue by ref is disallowed even
> in @system code. Hence 'scope' is assigned a meaning different from its
> intention. The DIP also aims to add more special behaviour to built-in
> literals.
>

Passing an r-value by ref is disallowed for arbitrary reasons. It can
easily create a temporary on the spot, but it doesn't, because it's not
considered good form to pass a temp to a function by ref.
This offers the possibility to pass a temp safely, and consequently, the
compiler may generate the temp for you.

Explain to me what meaning 'scope' has been assigned that is different from
it's intention? And what 'special behaviour'?

I honestly can't understand the objections, by you or deadalnix. Can
someone actually explain the problem clearly?

Re: Abstract syntax tree manipulation

[Jacob Carlborg]

On 2013-04-21 12:36, Belzurix wrote:


Hi!

As far as I can remember, macros have been deferred to D3 because it has
mixins and templates, so one can easily manipulate code in D. However,
it's been long time since there was serious discussion about the
implementation details. I'm happy to see that the topic emerged again
just before DConf - maybe the discussion will continue there.
Several non-lispy languages introduced macros long ago so the developers
may learn from others mistakes and they will avoid the pitfalls. These
languages include Groovy,
Scala, Nimrod and Rust.


There's also Nemerle which lets you create new syntax for your AST macros.

http://nemerle.org/wiki/index.php?title=Macros

--
/Jacob Carlborg

Stable D version?

[Tourist]

Hi guys,

I've been following the forums for a while. I'm interested in 
looking into D, but I understand that currently it changes often, 
and is not very reliable.
I've also read that there's a new release model planned, where a 
stable version of the language is released every year or two. Is 
that so? When would it take place?


What's holding you from releasing a version now and declaring it 
stable for e.g. a year?

Re: alias symbols in object files

[John Colvin]

On Sunday, 21 April 2013 at 19:22:27 UTC, Peter Alexander wrote:

On Sunday, 21 April 2013 at 18:54:27 UTC, John Colvin wrote:
Surely the aliased symbol should appear in the object file, or 
am I missing something?


What would you expect it to look like in the object file? A 
duplicate of the foo function?


Something like that, yes.

I have a templated function and need particular instantiations of 
it in a library. If aliases cannot be used for this, I suppose 
the most reasonable option is to write wrapper functions.

Re: alias symbols in object files

[Peter Alexander]

On Sunday, 21 April 2013 at 18:54:27 UTC, John Colvin wrote:
Surely the aliased symbol should appear in the object file, or 
am I missing something?


What would you expect it to look like in the object file? A 
duplicate of the foo function?

Re: alias symbols in object files

[John Colvin]

On Sunday, 21 April 2013 at 18:54:27 UTC, John Colvin wrote:

test.d:

extern (C):
void foo(){}
alias foo bar;

$dmd -c test.d

$nm test.o
 t
 D _D11test12__ModuleInfoZ
 w _d_dso_registry
 U _Dmodule_ref
 T foo


Surely the aliased symbol should appear in the object file, or 
am I missing something?


Just to avoid any confusion for non-linux guys:

nm is a linux utility for listing the symbols in an object file.

Re: alias symbols in object files

[Andrej Mitrovic]

On 4/21/13, John Colvin  wrote:
> Surely the aliased symbol should appear in the object file, or am
> I missing something?

Aliases are a purely compile-time feature. Wherever they're used it's
as if the compiler rewrote the alias with the aliased symbol.

alias symbols in object files

[John Colvin]

test.d:

extern (C):
void foo(){}
alias foo bar;

$dmd -c test.d

$nm test.o
 t
 D _D11test12__ModuleInfoZ
 w _d_dso_registry
 U _Dmodule_ref
 T foo


Surely the aliased symbol should appear in the object file, or am 
I missing something?

Re: DIP 36: Rvalue References

[Timon Gehr]

On 04/21/2013 06:27 AM, Zach the Mystic wrote:

...
Yeah, that's kind of what I meant when I said it's a two-for-one deal.
You get to pass temps, and you get safety checking too.


I prefer to buy separate products separately.

Re: DIP 36: Rvalue References

[Timon Gehr]

On 04/21/2013 02:51 AM, Manu wrote:

On 21 April 2013 06:51, Timon Gehr mailto:timon.g...@gmx.ch>> wrote:

On 04/20/2013 05:56 PM, Dicebot wrote:

You miss quite an important point - DIP36 does not add new
feature. It
partially defines existing feature (scope) to replace an
existing but
broken solution (auto ref). Nothing new is really added to the
language,
only existing stuff better defined.


_New meaning_ is assigned to existing grammar whose original purpose
is at most loosely related to the _new_ features.

I do not think that making 'scope' indicate an rvalue reference is
particularly future proof.


That's not what scope does. Scope promises that the variables will not
escape the scope.


That is the intention, but this formulation is awfully imprecise. Hence 
nothing has been implemented.


void foo(scope ref int x){ ... }
void foo(scope int* x){ ... }
void foo(scope ref int* x){ ... }

// ???

struct S{
scope S* x; // ???
}


And as such, just happens to make passing a temporary
by ref safe.
...


But this is not about safety! Passing an rvalue by ref is disallowed 
even in @system code. Hence 'scope' is assigned a meaning different from 
its intention. The DIP also aims to add more special behaviour to 
built-in literals.

Re: DIP 36: Rvalue References

[deadalnix]

On Sunday, 21 April 2013 at 16:02:35 UTC, Zach the Mystic wrote:

On Sunday, 21 April 2013 at 02:50:02 UTC, deadalnix wrote:
If that is your concern then the DIP36 is a very bad answer to 
it :
- It require extra anotation, which wont be added most of the 
time.


It's possible to make it an error to pass a stack variable to a 
non-'scope' ref parameter. Or to make it an error in @safe code 
only. But those may be extreme measures.


No they aren't.

This also raises the issue that some types of escape are more 
dangerous than others.


This is why the notion of lifetime is needed.

'scope' is also the kind of thing which might be better as the 
default than as something you must specifically add. But then 
we'd need an attribute '@noscope' or something like that. Ugh.




Inference is always a solution.

- It is inferior, and impair the introduction of lifetime. 
This isn't even discussed.


You've mentioned lifetime a couple times. Can you show what 
lifetime is and show how it contrasts with the current 
proposal, particularly DIP25?


Here is a good link to start :
http://smallcultfollowing.com/babysteps/blog/2012/07/17/borrowed-pointer-tutorial/

Re: DIP 36: Rvalue References

[Zach the Mystic]

On Sunday, 21 April 2013 at 16:08:55 UTC, Zach the Mystic wrote:
Would there be a difference between the type of o and o2, or of 
o2 and o3? There is inconsistency, but it would be nice to find 
use cases which make this inconsistency truly unworkable with 
other things in the language.


('nice' in the sense that it would prove the suggestion to be 
unworkable as opposed to nice that it actually is unworkable...)

Re: DIP 36: Rvalue References

[Zach the Mystic]

On Sunday, 21 April 2013 at 10:55:37 UTC, Dicebot wrote:
The DIP for instance, consider that const scope ref is 
semantically equivalent to pass by value, when it isn't (and 
not only for performance reasons, but for aliasing reasons). 
Nothing is considered about it.


At least some objections that make sense and I'd love to see in 
the very first announcement. If you see any issues that prevent 
treating "const scope int" as "const scope ref int", please 
tell about them and they will be addressed in DIP. Because it 
is the intention. I don't understand what aliasing are you 
speaking about.


The only thing I could think of was if you want to 'ref' a 
reference type.


void func(ref Object o, scope Object o2, scope ref Object o3) {}

Would there be a difference between the type of o and o2, or of 
o2 and o3? There is inconsistency, but it would be nice to find 
use cases which make this inconsistency truly unworkable with 
other things in the language.

Re: DIP 36: Rvalue References

[Zach the Mystic]

On Sunday, 21 April 2013 at 02:50:02 UTC, deadalnix wrote:
If that is your concern then the DIP36 is a very bad answer to 
it :
 - It require extra anotation, which wont be added most of the 
time.


It's possible to make it an error to pass a stack variable to a 
non-'scope' ref parameter. Or to make it an error in @safe code 
only. But those may be extreme measures. This also raises the 
issue that some types of escape are more dangerous than others.


ref T func(ref T a) {
  return a; // Escape by return, @safe if tracked at call site
  T* p = &a; // Escape to local pointer, @safe? if *p is tracked
  static T* s = &a; // Escape by global pointer, @system
}

In this sense, 'scope' is a blunt instrument, because you might 
want to say, 'returnable, but not globally assignable'.


'scope' is also the kind of thing which might be better as the 
default than as something you must specifically add. But then 
we'd need an attribute '@noscope' or something like that. Ugh.


 - It is inferior, and impair the introduction of lifetime. 
This isn't even discussed.


You've mentioned lifetime a couple times. Can you show what 
lifetime is and show how it contrasts with the current proposal, 
particularly DIP25?

Re: From C++14 and Java 1.8

[bearophile]

Dynamic Arrays: they replace the variable-sized stack-allocated 
arrays of C99. I'd like something like this in D2 (Issue 9832) 
with a better integration with the type system.


With some more changes:

http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130415/078426.html

Bye,
bearophile

Re: Compiler / Language Infrastructure

[John Colvin]

On Sunday, 21 April 2013 at 15:09:48 UTC, Suminda Dharmasena 
wrote:

 - separate grammar definition


This is being worked on:
http://forum.dlang.org/thread/iabqtohohovkxjwtw...@forum.dlang.org

Digitalmars (i.e. Walter Bright) is a big part of D development 
but it is primarily a community driven open-source project.

Compiler / Language Infrastructure

[Suminda Dharmasena]

Hi,

Since Digitalmars has expertise in C++ and D it can release the 
compiler project such that:

 - separate grammar definition
 - parser
 - compile to intermediate like LLVM but using the Digitalmars 
infrastructure


This will help other language projects re use this technology.

Suminda

Re: From C++14 and Java 1.8

[dsimcha]

On Sunday, 21 April 2013 at 13:30:32 UTC, bearophile wrote:

dsimcha:

I abandoned because I was disappointed at how poorly most of 
it was scaling in practice, probably due to memory bandwidth.


Then do you know why the Java version seems to be advantageous 
(with four cores)?


Bye,
bearophile


I don't know Java very well, but possiblities include:

1.  Sorting using a virtual or otherwise non-inlined comparison 
function.  This makes the sorting require much more CPU time but 
not a lot more memory bandwidth.  It does beg the question, 
though, of why the comparison function isn't inlined, especially 
since modern JITs can sometimes inline virtual functions.


2.  Different hardware than I tested on, maybe with better memory 
bandwidth.


3.  Expensive comparison functions.  I didn't test this in D 
either because I couldn't think of a good use case.  I tested the 
D parallel sort using small primitive types (ints and floats and 
stuff).

Re: From C++14 and Java 1.8

[bearophile]

dsimcha:

I abandoned because I was disappointed at how poorly most of it 
was scaling in practice, probably due to memory bandwidth.


Then do you know why the Java version seems to be advantageous 
(with four cores)?


Bye,
bearophile

Re: From C++14 and Java 1.8

[dsimcha]

On Sunday, 21 April 2013 at 12:08:54 UTC, bearophile wrote:
Arrays#parallelSort uses Fork/Join framework introduced in Java 
7 to assign the sorting tasks to multiple threads available in 
the thread pool. This is called eating your own dog food. 
Fork/Join implements a work stealing algorithm where in a idle 
thread can steal tasks queued up in another thread.

An overview of Arrays#parallelSort:

The method uses a threshold value and any array of size lesser 
than the threshold value is sorted using the Arrays#sort() API 
(i.e sequential sorting). And the threshold is calculated 
considering the parallelism of the machine, size of the array 
and is calculated as:


private static final int getSplitThreshold(int n) {
  int p = ForkJoinPool.getCommonPoolParallelism();
  int t = (p > 1) ? (1 + n / (p << 3)) : n;
  return t < MIN_ARRAY_SORT_GRAN ? MIN_ARRAY_SORT_GRAN : t;
}

Once its decided whether to sort the array in parallel or in 
serial, its now to decide how to divide the array in to 
multiple parts and then assign each part to a Fork/Join task 
which will take care of sorting it and then another Fork/Join 
task which will take care of merging the sorted arrays. The 
implementation in JDK 8 uses this approach:

- Divide the array into 4 parts.
- Sort the first two parts and then merge them.
- Sort the next two parts and then merge them.
And the above steps are repeated recursively with each part 
until the size of the part to sort is not lesser than the 
threshold value calculated above.





I think it's worth adding something similar as strategy of 
std.algorithm.sort.


FWIW, I created a parallel sort in D a while back using 
std.parallelism.  It was part of std.parallel_algorithm, a 
half-finished project that I abandoned because I was disappointed 
at how poorly most of it was scaling in practice, probably due to 
memory bandwidth.  If you have some expensive-to-compare types, 
though, it may be worthwhile.


https://github.com/dsimcha/parallel_algorithm/blob/master/parallel_algorithm.d

From C++14 and Java 1.8

[bearophile]

Through Reddit I've seen this interesting report about C++14:

http://isocpp.org/blog/2013/04/trip-report-iso-c-spring-2013-meeting


Variable templates: sometimes in D I've felt a little desire for 
a shorter syntax, a templated alias:


alias Foo(T) = Bar!(T, "red");

But in the end I think this that syntax sugar isn't so necessary.

- - - - - - - - -

Dynamic Arrays: they replace the variable-sized stack-allocated 
arrays of C99. I'd like something like this in D2 (Issue 9832) 
with a better integration with the type system.


- - - - - - - - -

optional: see the little maybeTo helper function I have 
suggested in

http://d.puremagic.com/issues/show_bug.cgi?id=6840

---

From another thread about the future Java 1.8 I've seen Java 
parallelSort:


http://blog.sanaulla.info/2013/04/08/arrays-sort-versus-arrays-parallelsort/


That blog post explains quickly how it works:

<<
Arrays#parallelSort uses Fork/Join framework introduced in Java 7 
to assign the sorting tasks to multiple threads available in the 
thread pool. This is called eating your own dog food. Fork/Join 
implements a work stealing algorithm where in a idle thread can 
steal tasks queued up in another thread.

An overview of Arrays#parallelSort:

The method uses a threshold value and any array of size lesser 
than the threshold value is sorted using the Arrays#sort() API 
(i.e sequential sorting). And the threshold is calculated 
considering the parallelism of the machine, size of the array and 
is calculated as:


private static final int getSplitThreshold(int n) {
  int p = ForkJoinPool.getCommonPoolParallelism();
  int t = (p > 1) ? (1 + n / (p << 3)) : n;
  return t < MIN_ARRAY_SORT_GRAN ? MIN_ARRAY_SORT_GRAN : t;
}

Once its decided whether to sort the array in parallel or in 
serial, its now to decide how to divide the array in to multiple 
parts and then assign each part to a Fork/Join task which will 
take care of sorting it and then another Fork/Join task which 
will take care of merging the sorted arrays. The implementation 
in JDK 8 uses this approach:

- Divide the array into 4 parts.
- Sort the first two parts and then merge them.
- Sort the next two parts and then merge them.
And the above steps are repeated recursively with each part until 
the size of the part to sort is not lesser than the threshold 
value calculated above.





I think it's worth adding something similar as strategy of 
std.algorithm.sort.


Bye,
bearophile

Re: DIP 36: Rvalue References

[Dicebot]

On Sunday, 21 April 2013 at 02:50:02 UTC, deadalnix wrote:
If that is your concern then the DIP36 is a very bad answer to 
it :
 - It require extra anotation, which wont be added most of the 
time.


Automatic annotations are indicators of broken language. If 
someone will forget this one, he won't be able to use rvalues, no 
problem.


 - It is inferior, and impair the introduction of lifetime. 
This isn't even discussed.


Scope is the absolute minimal lifetime which is needed for this 
DIP. Any other lifetime options are simply irrelevant.

Re: DIP 36: Rvalue References

[Dicebot]

On Sunday, 21 April 2013 at 01:04:04 UTC, deadalnix wrote:

On Saturday, 20 April 2013 at 18:00:50 UTC, Namespace wrote:
The fact is, there's much more to any change than simply 
implementing it. Changes break unexpected things. There are 
always extra corner cases not considered. There are always 
bugs and inconsistencies.
Could be, but I don't see what could be broken by this DIP. 
All contingencies are listed also in the DIP (and that are not 
many). And it passed all tests what is crucial.




The DIP for instance, consider that const scope ref is 
semantically equivalent to pass by value, when it isn't (and 
not only for performance reasons, but for aliasing reasons). 
Nothing is considered about it.


At least some objections that make sense and I'd love to see in 
the very first announcement. If you see any issues that prevent 
treating "const scope int" as "const scope ref int", please tell 
about them and they will be addressed in DIP. Because it is the 
intention. I don't understand what aliasing are you speaking 
about.

Re: Abstract syntax tree manipulation

[Belzurix]

On Sunday, 21 April 2013 at 07:57:51 UTC, Suminda Dharmasena 
wrote:

Hi,

Since macro is reserved perhaps D can introduce AST 
manipulating macros.


Suminda


Hi!

As far as I can remember, macros have been deferred to D3 because 
it has mixins and templates, so one can easily manipulate code in 
D. However, it's been long time since there was serious 
discussion about the implementation details. I'm happy to see 
that the topic emerged again just before DConf - maybe the 
discussion will continue there.
Several non-lispy languages introduced macros long ago so the 
developers may learn from others mistakes and they will avoid the 
pitfalls. These languages include Groovy,

Scala, Nimrod and Rust.

The Rust implementation is much like text substituation when 
used, so one can easily learn it in an hour. Its syntax is a 
little distinct from the base language, and there has been a 
problem with lexing it according to a past issue: 
https://github.com/mozilla/rust/issues/2755
It's still unfinished, there are some limitations. ( although 
it's been always hard to debug them ) Have a look at: 
http://static.rust-lang.org/doc/0.6/tutorial-macros.html

and also see the language manual ( at http://rust-lang.org )

Beyond AST macros, Nimrod ( http://nimrod-code.org ) has text 
substituation mechanisms called templates - much like C macros or 
templates in C++ and D. It also has term rewriting macros. In my 
opinion, Nimrod is a language where a lot of features can produce 
dirty code ( although some of them are very well done and they 
are extremely powerful tools ), and it's the developer's choice 
to use the features for the right purposes ( especially true with 
term rewriting ).
So obfuscation is just as easy in that language as in C++ or 
Perls before version 6 despite the fact that its sysntax is 
derived from Python.


I can't say much about Scala and Groovy, but their syntax for 
defining macros doesn't use as cryptic symbols as Nimrod. For 
example I couldn't find out for first time what is nnk the nnk 
prefix in the nnkInfix symbol.


Zsombor

Re: Abstract syntax tree manipulation

[Jacob Carlborg]

On 2013-04-21 09:57, Suminda Dharmasena wrote:

Hi,

Since macro is reserved perhaps D can introduce AST manipulating macros.

Suminda


The original idea with the "macro" keyword was to introduce AST macros. 
Although nothing has happened yet. People have been talking about it 
from time to time but no one has had a real proposal.


I've got this: https://dl.dropboxusercontent.com/u/18386187/ast_macros.html

But I haven't turned it into a DIP (D Improvement Proposal) yet.

--
/Jacob Carlborg

Re: DIP 36: Rvalue References

[Namespace]

Well perhaps I am too hasty. I'll wait and see what is happening.

BTW: Thanks for the support. ;)

Abstract syntax tree manipulation

[Suminda Dharmasena]

Hi,

Since macro is reserved perhaps D can introduce AST manipulating 
macros.


Suminda