On Tuesday, 9 October 2012 at 21:31:48 UTC, bearophile wrote:
>> "use" statements are converted to one or more alias' and namespaces to (mixin) templates.
>
> But what are they useful for?

Namespaces can be useful for organizational reasons. For example they can be used for grouping a collection of items under one roof. However you can already accomplish this and more using struct along with static members.

struct io
{
   static
   {
	void print() { writeln("foo");	}
   }
}

io.print();

Plus struct's come with additional abilities that can turn a simple namespace into a much more capable one, for example by adding in ctors and dtors.

--rt

I wonder if you could use a named public import to create something like a
namespace.
On 30 Oct 2012 00:25, "Rob T" <rob@ucora.com> wrote:

> On Tuesday, 9 October 2012 at 21:31:48 UTC, bearophile wrote:
>
>> "use" statements are converted to one or more alias' and namespaces to
>>> (mixin) templates.
>>>
>>
>> But what are they useful for?
>>
>
> Namespaces can be useful for organizational reasons. For example they can be used for grouping a collection of items under one roof. However you can already accomplish this and more using struct along with static members.
>
> struct io
> {
>    static
>    {
>         void print() { writeln("foo");  }
>    }
> }
>
> io.print();
>
> Plus struct's come with additional abilities that can turn a simple namespace into a much more capable one, for example by adding in ctors and dtors.
>
> --rt
>
>

On Monday, 29 October 2012 at 22:09:02 UTC, bearophile wrote:
> Namespace:
>
>> Not interested, huh? Funny, that I had not expected.
>
> Maybe they appreciate more something that improves the life of regular D programmers. There are many possible ways to do that, like trying to design features that quite probably will be added to D, or trying library ideas that will become part of Phobos, trying new GC features, trying new Phobos modules, and so on and on.
>
> Otherwise you risk creating another Delight (http://delight.sourceforge.net/ ) that no one uses, it's just a waste of time for you too.
>
> Bye,
> bearophile

Yes, but I need input. Tell me some ideas and I'll try to implement them. So you could just test new features in the real world, instead of just talking about them theoretically.
And it is not 'waste of time'. Me and my fellow students use D as early as the second Semester for almost all university projects. But as '(pre) compiler' we use Remus just because we miss some features, such as not-null references, since the first week. And it's a damn good exercise to understand, how a compiler works. :)

It would be really awesome if you could play around with making the AST available during compilation so we can alter it using ctfe.


On Tue, Oct 30, 2012 at 8:34 AM, Namespace <rswhite4@googlemail.com> wrote:

> On Monday, 29 October 2012 at 22:09:02 UTC, bearophile wrote:
>
>> Namespace:
>>
>>  Not interested, huh? Funny, that I had not expected.
>>>
>>
>> Maybe they appreciate more something that improves the life of regular D programmers. There are many possible ways to do that, like trying to design features that quite probably will be added to D, or trying library ideas that will become part of Phobos, trying new GC features, trying new Phobos modules, and so on and on.
>>
>> Otherwise you risk creating another Delight (http://delight.sourceforge.* *net/ <http://delight.sourceforge.net/> ) that no one uses, it's just a waste of time for you too.
>>
>> Bye,
>> bearophile
>>
>
> Yes, but I need input. Tell me some ideas and I'll try to implement them.
> So you could just test new features in the real world, instead of just
> talking about them theoretically.
> And it is not 'waste of time'. Me and my fellow students use D as early as
> the second Semester for almost all university projects. But as '(pre)
> compiler' we use Remus just because we miss some features, such as not-null
> references, since the first week. And it's a damn good exercise to
> understand, how a compiler works. :)
>

On Tuesday, 30 October 2012 at 06:34:26 UTC, Namespace wrote:
> Yes, but I need input. Tell me some ideas and I'll try to implement them. So you could just test new features in the real world, instead of just talking about them theoretically.
> And it is not 'waste of time'. Me and my fellow students use D as early as the second Semester for almost all university projects. But as '(pre) compiler' we use Remus just because we miss some features, such as not-null references, since the first week. And it's a damn good exercise to understand, how a compiler works. :)

I can see the value in testing ideas out in practice. I cannot see C++ style namespaces being all that useful given that there are much better alternatives already available, non-nullable references and AST macros would be very nice to try out. Wish we had these features in the real D right now.

--rt

> It would be really awesome if you could play around with making the AST available during compilation so we can alter it using ctfe.

I have a compile-time parser and code generator project here:

https://github.com/PhilippeSigaud/Pegged

We are adding a D grammar in there and there is a compile-time D
parser (some current transatlantic cable problem make github act
erratically from Europe, but it's transitory).
Pegged gives you a compile-time parse tree, which can then be
manipulated with CTFE and transformed back into other code (the last
part is not implemented for D specifically, but I have other
tree-transformation function and they work alright at compile-time.

Next step (2013?) would be to have a working macro system for D.

Philippe

On 2012-10-29 23:24, Rob T wrote:

> Namespaces can be useful for organizational reasons. For example they
> can be used for grouping a collection of items under one roof. However
> you can already accomplish this and more using struct along with static
> members.
>
> struct io
> {
>     static
>     {
>      void print() { writeln("foo");    }
>     }
> }
>
> io.print();
>
> Plus struct's come with additional abilities that can turn a simple
> namespace into a much more capable one, for example by adding in ctors
> and dtors.

Or using a template.

-- 
/Jacob Carlborg

> (some current transatlantic cable problem make github act erratically from Europe, but it's transitory).

Damn, and I just read some articles on Sandy. I sure hope everything will be OK in the end.

On Tuesday, 30 October 2012 at 07:25:14 UTC, Rob T wrote:
> On Tuesday, 30 October 2012 at 06:34:26 UTC, Namespace wrote:
>> Yes, but I need input. Tell me some ideas and I'll try to implement them. So you could just test new features in the real world, instead of just talking about them theoretically.
>> And it is not 'waste of time'. Me and my fellow students use D as early as the second Semester for almost all university projects. But as '(pre) compiler' we use Remus just because we miss some features, such as not-null references, since the first week. And it's a damn good exercise to understand, how a compiler works. :)
>
> I can see the value in testing ideas out in practice. I cannot see C++ style namespaces being all that useful given that there are much better alternatives already available, non-nullable references and AST macros would be very nice to try out. Wish we had these features in the real D right now.
>
> --rt

I like them. But if so many people against them, I can implement a voting to deprecate this feature. Not-null references are already available.

10/30/2012 8:09 AM, Philippe Sigaud пишет:
>> It would be really awesome if you could play around with making the AST
>> available during compilation so we can alter it using ctfe.
>
> I have a compile-time parser and code generator project here:
>
> https://github.com/PhilippeSigaud/Pegged
>
> We are adding a D grammar in there and there is a compile-time D
> parser (some current transatlantic cable problem make github act
> erratically from Europe, but it's transitory).
> Pegged gives you a compile-time parse tree, which can then be
> manipulated with CTFE and transformed back into other code (the last
> part is not implemented for D specifically, but I have other
> tree-transformation function and they work alright at compile-time.
>

Cool. Reminds myself that I need to find some more time to play with it (and the source).

-- 
Dmitry Olshansky