www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Remus

reply "Namespace" <rswhite4 googlemail.com> writes:
Hi,

I'd like to present you Remus.
First things first. What is Remus?
Remus is a (Pre)Compiler for D. It adds D or rather the natural 
Syntax of D through various things, which are at the moment only 
offered by library solutions or not at all.

This includes:

  - Not null references
  - Stack instances (also known as scope instances)
  - Namespaces
  - Safe Null invocation

Planned further still: memoize for functions and methods as well 
as ref counted instances.

Here's one code example of what already works: 
http://dpaste.dzfl.pl/bc50f081

Why did I do that?
Many library solutions from D are for me (and probably for many 
others here) essentially built (built in) missing features that 
can't be missing.

An example would be not null references:
Not Null references doesn't exist and are not intended for D. 
They are at least a structure / library solution. Remus instead 
provides a simple, clear syntax. There is certainly more to say 
about the other features, but I'm not fond of many words:
Try it out, or leave it. It's your choice, but I will use it in 
future for myself, my fellow students and my university stuff.
Nevertheless I am thankful for suggestions and feedback.

You can download Remus here: http://rswhite.de/?q=downloads. This 
is my own little website (however, in German) on where I give you 
some  informations, details and features about Remus as well as 
how you install it: http://rswhite.de/?q=remus. I advise you to 
try reading some of the remus chapters to understand what's 
working and what doesn't and for what reason.

On this page there will soon (about 2 - 4 weeks) be released the 
Beta-version of my 2D game framework called Dgame. This builds on 
the SDL and OpenGL and should become a worthy substitute to SFML 
from C++. It already has been tested enough in 2-3 simulations. 
Even an Pong Clone has been developed by it. But what's missing 
is an adequate documentation.

So much of me. Greetings and in advance: sorry for my english ;)
Oct 07 2012
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Namespace:


  - Not null references
  - Stack instances (also known as scope instances)
  - Namespaces
  - Safe Null invocation

 Planned further still: memoize for functions and methods as 
 well as ref counted instances.


Similar efforts are useful almost as the Haskell GHC compiler 
extensions: to allow the community to try to use features not yet 
present in the language, to judge them better, allowing to 
understand if they are worth putting in the language, and trying 
few alternative implementation ideas looking for the best one of 
them.

But to do this well, people need to understand such extensions 
very well. So instead of just offering the source code and one 
uncommented example, I suggest to explain each feature, why they 
are present, what design choices you have taken and why, and how 
to use them in some common cases, with few specific examples.

This will make your work useful for the development of the 
mainstream D too.

Bye,
bearophile
Oct 07 2012
parent "Namespace" <rswhite4 googlemail.com> writes:
I have, but until now only in german. If you understand german, 
you could read it on my website on the remus chapter. I'm going 
to translate and explain it more detailed this week. :)
Oct 07 2012
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-10-07 19:32, Namespace wrote:

 Hi,

 I'd like to present you Remus.
 First things first. What is Remus?
 Remus is a (Pre)Compiler for D. It adds D or rather the natural Syntax
 of D through various things, which are at the moment only offered by
 library solutions or not at all.

 This includes:

   - Not null references
   - Stack instances (also known as scope instances)
   - Namespaces
   - Safe Null invocation


This looks cool, especially not null references and stack instances. But 
as bearophile said, it would be nice with some explanation of the features.

-- 
/Jacob Carlborg
Oct 07 2012
parent reply "Tove" <tove fransson.se> writes:
On Sunday, 7 October 2012 at 19:41:30 UTC, Jacob Carlborg wrote:

 On 2012-10-07 19:32, Namespace wrote:


amazing, good work...! what license is this under, is it allowed 
to be used commercially?
Oct 07 2012
parent reply "Namespace" <rswhite4 googlemail.com> writes:
On Sunday, 7 October 2012 at 20:54:28 UTC, Tove wrote:

 On Sunday, 7 October 2012 at 19:41:30 UTC, Jacob Carlborg wrote:

 On 2012-10-07 19:32, Namespace wrote:


 amazing, good work...! what license is this under, is it 
 allowed to be used commercially?


LGPL or zlib (but then with copyleft as addtion), isn't clear 
right now.
Oct 08 2012
parent reply "Namespace" <rswhite4 googlemail.com> writes:
As promised, a little description of Remus. :)

Not Null references:
I chose this syntax: int& b = a; because I like it in C++. This 
syntax is recognized by Remus and is converted to: Ref!(int) b = 
a;
If you must give a reference to a function or other things like 
that, you can write:
[code]
Foo obj = new Foo();
some_function( obj)
[/code]
instead of
[code]
Foo obj = new Foo();
{
	Foo& robj = obj;
	some_function(robj);
}
[/code]
Namespaces: You can declare a namespace this way:
[code]
namespace io {
	void print() {
		writeln("foo");
	}
}
[/code]
you _cannot_ use it without explicit "use" statement (will maybe 
change). So you must write
[code]use io;[/code] to use _all_ methods from "io", or, like 
import, [code]use io : print[/code] or [code]use io : write = 
print;[/code]
"use" statements are converted to one or more alias' and 
namespaces to (mixin) templates.

not null safe invocation:

If you have an object which can be null, you can write: 
obj?.print(); the print method is only called, if obj is not null.
It works even with more than one '?': obj?.getOtherObj?.print(); 
but then you have to take care of some special weakneses:
Until now you can not write obj?.getOtherObj()?.print() because 
the parent's aren't recognized as valid identifiers for '?'.
So you must use properties or this workaround:
[code]
Foo otherObj = obj?.getOtherObj(); // otherObj is null if obj is 
null
otherObj.print();
[/code]
Furthermore you cannot use '?' in the middle or end, or with 
breaks.
So these are valid: a?.b.c and this a?.b?.c but these a.b?.c and 
a?.b.c?.d not.

I described some more examples, do's and don't's on my website.

Stack Instances:
There aren't many words for: if you need a stack instance, write: 
local Foo f = new Foo(); it's more or less the same as scope.

My next version will contain the elvis operator:
[code]
Foo obj = otherObj.get() ?: null;
if otherObj.get() is _not_ null, it will assign to obj, otherwise 
obj will be assigned with null.
[/code]

And maybe cast's with 'as'. But my main interests are to fix the 
bugs and weakneses.

That's it. Sorry for the few words, but I'm a bit busy right now. 
If you have questions or suggesstions you can write it here,
I will read it every evening.
Oct 09 2012
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Namespace:


 Not Null references:
 I chose this syntax: int& b = a; because I like it in C++. This 
 syntax is recognized by Remus and is converted to: Ref!(int) b 
 = a;
 If you must give a reference to a function or other things like 
 that, you can write:
 [code]
 Foo obj = new Foo();
 some_function( obj)
 [/code]
 instead of
 [code]
 Foo obj = new Foo();
 {
 	Foo& robj = obj;
 	some_function(robj);
 }


This seems far from being well designed not-nullable 
pointers/class references :-(



 [/code]
 Namespaces: You can declare a namespace this way:
 [code]
 namespace io {
 	void print() {
 		writeln("foo");
 	}
 }
 [/code]
 you _cannot_ use it without explicit "use" statement (will 
 maybe change). So you must write
 [code]use io;[/code] to use _all_ methods from "io", or, like 
 import, [code]use io : print[/code] or [code]use io : write = 
 print;[/code]
 "use" statements are converted to one or more alias' and 
 namespaces to (mixin) templates.


But what are they useful for?



 Stack Instances:
 There aren't many words for: if you need a stack instance, 
 write: local Foo f = new Foo(); it's more or less the same as 
 scope.


scope was removed for certain reasons, are those reasons not 
valid for "local"?

Bye,
bearophile
Oct 09 2012
next sibling parent reply "Namespace" <rswhite4 googlemail.com> writes:
 This seems far from being well designed not-nullable 
 pointers/class references :-(


And why not? In my test cases, they fulfilled their task / 
purpose very well.

And you ask for what namespaces are usefull? Aren't you miss 
them? I do, and so I implement them. You can already write 
"namespaces" in D, but you must use a (mixin) template (so you 
have these ugly parents) and for using you have to write: alias 
tpl_nspace!().print print or directly: tpl_nspace!().print. And 
that's ugly (because of '!()') and annoying IMO.

For what local is good for and whats the differences between my 
version and scoped from dmd I will tell later, but as you can 
see: you have to write: local Foo f = new Foo(); what is more 
intuitive as Scoped! Foo f = scoped!Foo(); IMO.
Oct 09 2012
parent reply David <d dav1d.de> writes:
Am 10.10.2012 07:32, schrieb Namespace:

 And you ask for what namespaces are usefull? Aren't you miss them? I do,
 and so I implement them. You can already write "namespaces" in D, but
 you must use a (mixin) template (so you have these ugly parents) and for
 using you have to write: alias tpl_nspace!().print print or directly:
 tpl_nspace!().print. And that's ugly (because of '!()') and annoying IMO.


No, I really don't miss namespaces and if I really needed one, I would 
use a struct.
Oct 10 2012
next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
On Wednesday, 10 October 2012 at 15:19:22 UTC, David wrote:

 Am 10.10.2012 07:32, schrieb Namespace:

 And you ask for what namespaces are usefull? Aren't you miss 
 them? I do,
 and so I implement them. You can already write "namespaces" in 
 D, but
 you must use a (mixin) template (so you have these ugly 
 parents) and for
 using you have to write: alias tpl_nspace!().print print or 
 directly:
 tpl_nspace!().print. And that's ugly (because of '!()') and 
 annoying IMO.


 No, I really don't miss namespaces and if I really needed one, 
 I would use a struct.


Each to their own. ;) And: you can use Remus without using 
namespaces. So if you don't like one piece of Remus, don't use 
it. ;)
Oct 10 2012
prev sibling parent reply Leandro Lucarella <luca llucax.com.ar> writes:
David, el 10 de October a las 16:55 me escribiste:

 Am 10.10.2012 07:32, schrieb Namespace:

And you ask for what namespaces are usefull? Aren't you miss them? I do,
and so I implement them. You can already write "namespaces" in D, but
you must use a (mixin) template (so you have these ugly parents) and for
using you have to write: alias tpl_nspace!().print print or directly:
tpl_nspace!().print. And that's ugly (because of '!()') and annoying IMO.


 No, I really don't miss namespaces and if I really needed one, I
 would use a struct.


Or even better, just use static import.

--
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Sometimes you got to suffer a little in your youth to motivate you to
succeed later in life. Do you think if Bill Gates got laid in high
school, do you think there'd be a Microsoft? Of course not. You gotta
spend a lot of time stuffin your own locker with your underwear wedged
up your arse before you think "I'm gona take over the world with
computers! You'll see I'll show them."
Oct 10 2012
parent reply "Namespace" <rswhite4 googlemail.com> writes:
Version 1.1 is now available.
Alterations:
  -> Package import. I see in the forum a good solution for 
package imports and so I merged it with Remus.
Because of that you can write now: import package PACKAGE_NAME : 
MODULE1, MODULE2, ... ;
Short example: import package std : stdio, regex, array;

  -> improved not null references:
  - you can declare not null references now as Return Type (wasn't 
possible before)
  - detect reliable if a reference is assigned or not (and if not: 
throw an error)
  - delete the ' ' operator: you now have the 'makeRef' function.
Short example for that:
[code]
void test(Foo& fr) { }

void main() {
     Foo f = new Foo();
     Foo& fr = f;

     test(fr);
     test(makeRef(f));
     test(makeRef(new Foo));
}
[/code]
As you can see: there is no need to declare a senseless reference 
variable for a function which takes only a reference: you can use 
makeRef. And as you can see also: makeRef works even fine with 
RValues.

  -> improved Elvis Operator. And new: short elvis operator.
Example:
Foo f[ = new Foo()];
// ...
f ?= new Foo(); -> this is converted to: f = (f ? f : new Foo());
Oct 28 2012
parent reply "Namespace" <rswhite4 googlemail.com> writes:
Not interested, huh? Funny, that I had not expected.
Oct 29 2012
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
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
Oct 29 2012
next sibling parent reply "Namespace" <rswhite4 googlemail.com> writes:
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. :)
Oct 29 2012
next sibling parent Rory McGuire <rjmcguire gmail.com> writes:
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. :)





 Oct 29 2012



prev sibling next sibling parent reply "Rob T" <rob ucora.com>  writes:


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



 Oct 30 2012



  parent reply "Namespace" <rswhite4 googlemail.com>  writes:


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.



 Oct 30 2012



  parent reply "Namespace" <rswhite4 googlemail.com>  writes:


Small update: cast with 'as' now works. A little syntax sugar. 
And that's about the last feature, which I will implement. Maybe 
some of you will test remus and/or find a few bugs, or other 
suggest other features that they would like to see in remus. I 
look forward to suggestions. :)



 Oct 30 2012



  parent reply "bearophile" <bearophileHUGS lycos.com>  writes:


Namespace:


 or other suggest other features that they would like
 to see in remus. I look forward to suggestions. :)


There is a D problem that in my opinion is worth exploring. 
Usually I prefer const/immutable variables/collections, but there 
are several different situations where this is hard to do. In 
some cases to do this you even have to create a function in-place 
that is called in-place, that creates an array, returns it, and 
the result is assigned to const. There are other different 
situations.

One other case is at global scope:

immutable foo = bar + baz
     where {
         auto foo = ...;
         auto baz = ...;
     };

Bye,
bearophile



 Nov 01 2012



  parent reply "Namespace" <rswhite4 googlemail.com>  writes:


On Thursday, 1 November 2012 at 15:41:26 UTC, bearophile wrote:

 Namespace:


 or other suggest other features that they would like
 to see in remus. I look forward to suggestions. :)


 There is a D problem that in my opinion is worth exploring. 
 Usually I prefer const/immutable variables/collections, but 
 there are several different situations where this is hard to 
 do. In some cases to do this you even have to create a function 
 in-place that is called in-place, that creates an array, 
 returns it, and the result is assigned to const. There are 
 other different situations.

 One other case is at global scope:

 immutable foo = bar + baz
     where {
         auto foo = ...;
         auto baz = ...;
     };

 Bye,
 bearophile


When did you use something like this? In this case you could take 
a function that assign foo:

immutable foo;
void assignFoo() {
    string bar, barz; // ...
    foo = bar + baz;
}

or not?



 Nov 01 2012



  parent reply "bearophile" <bearophileHUGS lycos.com>  writes:


Namespace:


 When did you use something like this?


Now and then :-)



 In this case you could take a function that assign foo:


Usually in that case I use the module "static this". But the point



 immutable foo;
 void assignFoo() {
    string bar, barz; // ...
    foo = bar + baz;
 }

 or not?


That doesn't work because foo has no type, and because you can 
only initialize immutable global variables inside the "static 
this".

But the main point of what I was saying is not that it's 
impossible to do some things, most times there is already some 
way to do it in D.

I was saying that the current ways to assign immutable 
values/collections is sometimes not handy in D. So Remus seems 
the right place to experiment several different ideas to improve 
those situations. A "where" is just one of the different 
possibilities.

Bye,
bearophile



 Nov 01 2012



  parent reply "Namespace" <rswhite4 googlemail.com>  writes:


I see.
My comprehension ATM is, that you want to concatenate two or more 
strings at compile time, but this works fine: immutable string 
test = "abc" ~ "def";
Because of that it would be greatly helped if you can give me a 
concrete example.



 Nov 01 2012



 next sibling parent reply "bearophile" <bearophileHUGS lycos.com>  writes:


Namespace:


 I see.
 My comprehension ATM is, that you want to concatenate two or 
 more strings at compile time, but this works fine: immutable 
 string test = "abc" ~ "def";


It's not a class of problems related to strings, it's quite more 
generic.



 Because of that it would be greatly helped if you can give me a 
 concrete example.


In D code I prefer to see variables/collections tagged as 
immutable/const. Look at your D code, at any D code. What is 
stopping you to tag all your variables in your D code as 
immutable?

According to the role of those variables in some cases this is 
not possible (or forces you to write recursive functions as you 
see in certain functional languages, that often in D I prefer to 
avoid for clarity and efficiency). But in many other cases it's 
possible with no loss of clarity and performance.

I'd like to increase the percentage of this second group. There 
are four of or more different kinds of situations where it seems 
possible to have immutables where currently you usually see 
mutables in normal D code (and keep in mind I am talking about 
possible or impossible. As I have explained it's more a matter of 
handy/not handy/nice enough ways to do it).

This is one of my two or three threads about this topic:
http://forum.dlang.org/thread/iosrld$5o8$1 digitalmars.com

Bye,
bearophile



 Nov 01 2012



  parent reply "bearophile" <bearophileHUGS lycos.com>  writes:


Another interesting possible feature for Remus: as the usage of 
immutable structs becomes more common in D code, it becomes more 
useful a syntax to create an updated struct. Similar syntax is 


struct Foo { int first, second, third; }
immutable f1 = Foo(10, 20, 30);

Current syntax:
immutable f2a = Foo(f1.first, 200, f1.third);

A possible syntax:
immutable f2b = Foo(f1 with second = 200);

Bye,
bearophile



 Nov 07 2012



  parent reply "Namespace" <rswhite4 googlemail.com>  writes:


On Thursday, 8 November 2012 at 03:21:03 UTC, bearophile wrote:

 Another interesting possible feature for Remus: as the usage of 
 immutable structs becomes more common in D code, it becomes 
 more useful a syntax to create an updated struct. Similar 


 struct Foo { int first, second, third; }
 immutable f1 = Foo(10, 20, 30);

 Current syntax:
 immutable f2a = Foo(f1.first, 200, f1.third);

 A possible syntax:
 immutable f2b = Foo(f1 with second = 200);

 Bye,
 bearophile


That sounds like named parameters, which I don't like very much. 
:/



 Nov 07 2012



  parent reply "Namespace" <rswhite4 googlemail.com>  writes:


After some consideration, I now have the following things, which 
I wish that D would have them built-in:
  - scope arrays: like static arrays, but you can init them at 
runtime with constant and non-constant expressions and they are 
resizeable if you have to. They will (so far) allocated on the 
heap and will released at the end of the lifetime of the scope. 
Furthermore you _can_ reserve memory, but by default the length 
and the capacity of the array are equal. Means: you don't pay (by 
default) for memory which you don't need. Syntax idea: 'scope 
int[5] arr;' and 'scope int[some_runtime_int] arr;'
  - lazy const: Just a spontaneous idea: I have often variables, 
which aren't initialize in the CTor, but they are initialized 
only once, and then they should be constant. That isn't possible 
yet. Therefore I whish something like: lazy const var;
  - And of course: not-null references. There is not much to say. 
Current syntax idea comes from C++: Foo& f = other_f;

So what do you mean about these ideas? And if you like one, what 
do you mean about the syntax?



 Nov 21 2012



 next sibling parent reply Jacob Carlborg <doob me.com>  writes:


On 2012-11-21 10:37, Namespace wrote:

 After some consideration, I now have the following things, which I wish
 that D would have them built-in:
   - scope arrays: like static arrays, but you can init them at runtime
 with constant and non-constant expressions and they are resizeable if
 you have to. They will (so far) allocated on the heap and will released
 at the end of the lifetime of the scope. Furthermore you _can_ reserve
 memory, but by default the length and the capacity of the array are
 equal. Means: you don't pay (by default) for memory which you don't
 need. Syntax idea: 'scope int[5] arr;' and 'scope int[some_runtime_int]
 arr;'
   - lazy const: Just a spontaneous idea: I have often variables, which
 aren't initialize in the CTor, but they are initialized only once, and
 then they should be constant. That isn't possible yet. Therefore I whish
 something like: lazy const var;
   - And of course: not-null references. There is not much to say.
 Current syntax idea comes from C++: Foo& f = other_f;

 So what do you mean about these ideas? And if you like one, what do you
 mean about the syntax?


Is this in addition to what you had previously or is that removed?

In addition to this, how about "final" variables, or something similar.

final Foo foo = new Foo;

It's not possible to reassign a "final" variable but you can call any 
method on it, not just const/immutable methods.

-- 
/Jacob Carlborg



 Nov 21 2012



  parent reply "Namespace" <rswhite4 googlemail.com>  writes:


It is a completly restart.
Hm, I don't know, a solution for 'final' should be this:
[code]
struct Final(T) {
private:
	T _val;
	
public:
	 disable
	this();
	
	this(T val) {
		this._val = val;
	}
	
	 disable
	ref typeof(this) opAssign(T val);
	
	 property
	inout(T) get() inout {
		return this._val;
	}
	
	alias get this;
}
[/code]
If you can write some use cases for this I will think about it.



 Nov 21 2012



  parent reply Jacob Carlborg <doob me.com>  writes:


On 2012-11-21 15:55, Namespace wrote:

 It is a completly restart.


What happened to the elvis-operator. I though that was one of the best 
features. I also like scoped/stack allocated classes.


 Hm, I don't know, a solution for 'final' should be this:
 [code]
 struct Final(T) {
 private:
      T _val;

 public:
       disable
      this();

      this(T val) {
          this._val = val;
      }

       disable
      ref typeof(this) opAssign(T val);

       property
      inout(T) get() inout {
          return this._val;
      }

      alias get this;
 }
 [/code]
 If you can write some use cases for this I will think about it.


class Foo
{
     final Object x;
     final Object y;

     this (Object x, Object y)
     {
         this.x = x;
         this.y = y;
     }
}

I used this all the time in D1, when "const" worked like that. Now I 
have to create getters for these variables instead:

class Foo
{
     private Object x_;
     private Object y_;

     this (Object x, Object y)
     {
         this.x = x;
         this.y = y;
     }

     Object x () { return x_; }
     Object y () { return y_; }
}

-- 
/Jacob Carlborg



 Nov 21 2012



  parent reply "Namespace" <rswhite4 googlemail.com>  writes:


 What happened to the elvis-operator. I though that was one of 
 the best features. I also like scoped/stack allocated classes.


Nothing, if enough people say that they need him I will implement 
them again.
But maybe better. :)


 class Foo
 {
     final Object x;
     final Object y;

     this (Object x, Object y)
     {
         this.x = x;
         this.y = y;
     }
 }

 I used this all the time in D1, when "const" worked like that. 
 Now I have to create getters for these variables instead:

 class Foo
 {
     private Object x_;
     private Object y_;

     this (Object x, Object y)
     {
         this.x = x;
         this.y = y;
     }

     Object x () { return x_; }
     Object y () { return y_; }
 }


const in D1 isn't the const as in D2 and enforce only that the 
object cannot be assigned again? Strange. O.o
But then I will think about it. Schould not be much work.



 Nov 21 2012



  parent  Jacob Carlborg <doob me.com>  writes:


On 2012-11-21 19:11, Namespace wrote:


 Nothing, if enough people say that they need him I will implement them
 again.
 But maybe better. :)


Cool :)


 const in D1 isn't the const as in D2 and enforce only that the object
 cannot be assigned again? Strange. O.o


Yes, it worked a bit more like "const" in C than in C++. I just came to 
think of this since you mentioned "lazy const".


 But then I will think about it. Schould not be much work.


Thanks.

-- 
/Jacob Carlborg



 Nov 21 2012



prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com>  writes:


Namespace:


  - scope arrays: like static arrays,


I think they are fully implementable in library code. Maybe
Phobos Array already does that fully.

While Variable Length Arrays allocated on the heap can't be
implemented with a nice syntax in library code, so I think they
are more fit for a built-in implementation (but they need new
syntax and they are more complex to implement).



  - lazy const: Just a spontaneous idea: I have often variables, 
 which aren't initialize in the CTor, but they are initialized 
 only once, and then they should be constant. That isn't 
 possible yet. Therefore I whish something like: lazy const var;


This is a quite common need, like when you want to perform a
costly computation only once. Maybe there is even an enhancement
request in Bugzilla.

I understand why this is named "lazy const" but this code is
currently accepted:

void foo(lazy const int x) {}
void main() {}


So to avoid confusion I suggest to give a different name to this
feature. One possibility is to use a new keyword, like a
"monoassignable" :-)

How did you implement this feature? If done well, with a good
enough name, it's even possible to make a pull request in the
main D compiler with just this feature.



  - And of course: not-null references. There is not much to 
 say. Current syntax idea comes from C++: Foo& f = other_f;


Probably this requires far more design to be done well enough.

I suggest to write/adapt several small programs with your new
features (like from here:
http://rosettacode.org/wiki/Category:D), and to try them to see
how useful they are.

Bye,
bearophile



 Nov 21 2012



 next sibling parent  "bearophile" <bearophileHUGS lycos.com>  writes:


 While Variable Length Arrays allocated on the heap can't be


I meant stack, sorry.

Bye,
bearophile



 Nov 21 2012



prev sibling  parent reply "Namespace" <rswhite4 googlemail.com>  writes:


 I think they are fully implementable in library code. Maybe
 Phobos Array already does that fully.

 While Variable Length Arrays allocated on the heap can't be
 implemented with a nice syntax in library code, so I think they
 are more fit for a built-in implementation (but they need new
 syntax and they are more complex to implement).


Hm, I like scope int[i] arr; I will think about it.


 This is a quite common need, like when you want to perform a
 costly computation only once. Maybe there is even an enhancement
 request in Bugzilla.

 I understand why this is named "lazy const" but this code is
 currently accepted:

 void foo(lazy const int x) {}
 void main() {}


Oh good point, thanks.


 So to avoid confusion I suggest to give a different name to this
 feature. One possibility is to use a new keyword, like a
 "monoassignable" :-)


Then preferably "readonly" or something like this. :D Or just 
'mono'.


 How did you implement this feature? If done well, with a good
 enough name, it's even possible to make a pull request in the
 main D compiler with just this feature.


I don't understand. What do you mean with 'how'? I will write a 
struct and replace 'readonly ...' with an instance of 
ReadOnly!(...) ...


 Probably this requires far more design to be done well enough.

 I suggest to write/adapt several small programs with your new
 features (like from here:
 http://rosettacode.org/wiki/Category:D), and to try them to see
 how useful they are.


What do you mean with 'how useful'?



 Nov 21 2012



  parent reply "bearophile" <bearophileHUGS lycos.com>  writes:


Namespace:


 I will write a struct and replace 'readonly ...' with an 
 instance of ReadOnly!(...) ...


OK.



 What do you mean with 'how useful'?


It means to try to use your feature(s) to rewrite/modify several 
of those little programs, and then take at how much frequently 
you use those new features, what advantages they give you, and so 
on. An usability experiment.

Bye,
bearophile



 Nov 21 2012



 next sibling parent  "Namespace" <rswhite4 googlemail.com>  writes:


On Wednesday, 21 November 2012 at 17:43:22 UTC, bearophile wrote:

 Namespace:


 I will write a struct and replace 'readonly ...' with an 
 instance of ReadOnly!(...) ...


 OK.


Not good? What would be better? :)

 What do you mean with 'how useful'?


 It means to try to use your feature(s) to rewrite/modify 
 several of those little programs, and then take at how much 
 frequently you use those new features, what advantages they 
 give you, and so on. An usability experiment.

 Bye,
 bearophile


Ok.



 Nov 21 2012



prev sibling  parent reply "Namespace" <rswhite4 googlemail.com>  writes:


 It means to try to use your feature(s) to rewrite/modify 
 several of those little programs, and then take at how much 
 frequently you use those new features, what advantages they 
 give you, and so on. An usability experiment.

 Bye,
 bearophile


A short question: what ist your imagination of a perfect not-null 
references? What should they can do, how they should assigned? 
Only with (valid) lvalues, or even with rvalues? Tell me a bit of 
your thoughts.



 Nov 21 2012



  parent reply "bearophile" <bearophileHUGS lycos.com>  writes:


Namespace:


 A short question: what ist your imagination of a perfect 
 not-null references? What should they can do, how they should 
 assigned? Only with (valid) lvalues, or even with rvalues? Tell 
 me a bit of your thoughts.


I put some partial notes here:
http://d.puremagic.com/issues/show_bug.cgi?id=4571

See in particular:
http://research.microsoft.com/pubs/67461/non-null.pdf

Bye,
bearophile



 Nov 21 2012



  parent  "Namespace" <rswhite4 googlemail.com>  writes:


On Wednesday, 21 November 2012 at 23:47:55 UTC, bearophile wrote:

 Namespace:


 A short question: what ist your imagination of a perfect 
 not-null references? What should they can do, how they should 
 assigned? Only with (valid) lvalues, or even with rvalues? 
 Tell me a bit of your thoughts.


 I put some partial notes here:
 http://d.puremagic.com/issues/show_bug.cgi?id=4571

 See in particular:
 http://research.microsoft.com/pubs/67461/non-null.pdf

 Bye,
 bearophile


Thank you. So you would prefer it if they accept ravlues _and_ 
lvalues. Ok.



 Nov 21 2012



prev sibling  parent reply Jacob Carlborg <doob me.com>  writes:


On 2012-11-21 10:37, Namespace wrote:

 After some consideration, I now have the following things, which I wish
 that D would have them built-in:
   - scope arrays: like static arrays, but you can init them at runtime
 with constant and non-constant expressions and they are resizeable if
 you have to. They will (so far) allocated on the heap and will released
 at the end of the lifetime of the scope. Furthermore you _can_ reserve
 memory, but by default the length and the capacity of the array are
 equal. Means: you don't pay (by default) for memory which you don't
 need. Syntax idea: 'scope int[5] arr;' and 'scope int[some_runtime_int]
 arr;'
   - lazy const: Just a spontaneous idea: I have often variables, which
 aren't initialize in the CTor, but they are initialized only once, and
 then they should be constant. That isn't possible yet. Therefore I whish
 something like: lazy const var;
   - And of course: not-null references. There is not much to say.
 Current syntax idea comes from C++: Foo& f = other_f;

 So what do you mean about these ideas? And if you like one, what do you
 mean about the syntax?


A property shortcut syntax would be cool to have.

class Foo
{
      property int bar;
}

Lowered to:

class
{
     private int bar_;

      property int bar () { return bar_; }
      property int bar (int value) { return bar_ = value; }
}

It would also be nice if you could manually implement any of the getter 
or setter and none would be generated in that case.

-- 
/Jacob Carlborg



 Nov 21 2012



  parent reply "Namespace" <rswhite4 googlemail.com>  writes:


 A property shortcut syntax would be cool to have.

 class Foo
 {
      property int bar;
 }

 Lowered to:

 class
 {
     private int bar_;

      property int bar () { return bar_; }
      property int bar (int value) { return bar_ = value; }
 }

 It would also be nice if you could manually implement any of 
 the getter or setter and none would be generated in that case.


Hm, I like the Idea.
But I would prefer:
private:
     int _bar in(int val) {
         _bar = val;
     } out {
         return _bar;
     }
which results in:
private:
      int _bar;

       property int bar() { return _bar_; }
       property void bar(int val) { _bar = val; }



 Nov 21 2012



  parent reply Jacob Carlborg <doob me.com>  writes:


On 2012-11-21 21:48, Namespace wrote:


 Hm, I like the Idea.
 But I would prefer:
 private:
      int _bar in(int val) {
          _bar = val;
      } out {
          return _bar;
      }


The point was to make the syntax short. I wouldn't consider this much of 
an improvement.

-- 
/Jacob Carlborg



 Nov 21 2012



  parent reply "Namespace" <rswhite4 googlemail.com>  writes:


On Thursday, 22 November 2012 at 07:14:38 UTC, Jacob Carlborg 
wrote:

 On 2012-11-21 21:48, Namespace wrote:


 Hm, I like the Idea.
 But I would prefer:
 private:
     int _bar in(int val) {
         _bar = val;
     } out {
         return _bar;
     }


 The point was to make the syntax short. I wouldn't consider 
 this much of an improvement.



syntax with set and get. The aquivalent of this in D is IMO 'in' 
and 'out'.



 Nov 22 2012



  parent reply "John Chapman" <johnch_atms hotmail.com>  writes:


On Thursday, 22 November 2012 at 11:55:08 UTC, Namespace wrote:

 On Thursday, 22 November 2012 at 07:14:38 UTC, Jacob Carlborg 
 wrote:

 On 2012-11-21 21:48, Namespace wrote:


 Hm, I like the Idea.
 But I would prefer:
 private:
    int _bar in(int val) {
        _bar = val;
    } out {
        return _bar;
    }


 The point was to make the syntax short. I wouldn't consider 
 this much of an improvement.



 syntax with set and get. The aquivalent of this in D is IMO 
 'in' and 'out'.



http://msdn.microsoft.com/en-us/library/bb384054.aspx

The compiler generates the get/set pair and backing store from 
the user's single-line declaration.

So,

     property int bar();

would expand to:

   private int bar_;

    property void bar(int value) {
     bar_ = value;
   }

    property int bar() {
     return bar_;
   }



 Nov 22 2012



 next sibling parent reply "Namespace" <rswhite4 googlemail.com>  writes:


Oh, I didn't know that, thanks.



 Nov 22 2012



  parent reply "Namespace" <rswhite4 googlemail.com>  writes:


Remus, or now Romulus, is mostly finished.
For two days it is also on github:
https://github.com/Dgame/Romulus/tree/master/Romulus
I expect that at the end of the week a first, small decription 
and "how to use" section will be online. Feel free to comment my 
code.



 Dec 03 2012



 next sibling parent reply "Namespace" <rswhite4 googlemail.com>  writes:


Last pull today. Romulus is ready to use/test. A website and 
documentation coming soon and then I need some help to write it 
in english. But first I hope that some of you could test it.

Here a brief overview:
  - not null references. Syntax: Object& obj
  - final variables. mutable access, but not rebindable. Syntax: 
final Object obj
  - readonly variables, even called "lazy const". constant 
variable, not rebindable but value must not assign by 
declaration. Syntax: readonly int i;
  - Elvis operator. Short ternary operator.
Syntax:
Object o;
// ...
o = o ?: new Object();

  - Not null safe invocation. Syntax: a?.b?.c will be converted to:
if (a && a.b) a.b.c. (works only with identifiers).

- Scoped arrays. scoped and static/stack array with the ability, 
that their size could be a runtime value. You can resize them, 
but if you do and if the capacity is fully used, it is 
reallocated on the heap. After leaving scope the memory is 
automatically destroyed, even if you have reallocated memory on 
the heap.
Syntax:
scope byte[4] arr1;
int i = 4;
scope byte[i] arr2;



 Dec 04 2012



 next sibling parent  Jacob Carlborg <doob me.com>  writes:


On 2012-12-04 22:59, Namespace wrote:

 Last pull today. Romulus is ready to use/test. A website and
 documentation coming soon and then I need some help to write it in
 english. But first I hope that some of you could test it.

 Here a brief overview:
   - not null references. Syntax: Object& obj
   - final variables. mutable access, but not rebindable. Syntax: final
 Object obj
   - readonly variables, even called "lazy const". constant variable, not
 rebindable but value must not assign by declaration. Syntax: readonly
 int i;
   - Elvis operator. Short ternary operator.
 Syntax:
 Object o;
 // ...
 o = o ?: new Object();

   - Not null safe invocation. Syntax: a?.b?.c will be converted to:
 if (a && a.b) a.b.c. (works only with identifiers).

 - Scoped arrays. scoped and static/stack array with the ability, that
 their size could be a runtime value. You can resize them, but if you do
 and if the capacity is fully used, it is reallocated on the heap. After
 leaving scope the memory is automatically destroyed, even if you have
 reallocated memory on the heap.
 Syntax:
 scope byte[4] arr1;
 int i = 4;
 scope byte[i] arr2;


Looks good.

-- 
/Jacob Carlborg



 Dec 04 2012



prev sibling  parent reply "renoX" <renozyx gmail.com>  writes:


On Tuesday, 4 December 2012 at 21:59:15 UTC, Namespace wrote:
[cut]

  - readonly variables, even called "lazy const". constant 
 variable, not rebindable but value must not assign by 
 declaration. Syntax: readonly int i;


In the (unlikely) case you didn't know: the name for this feature 
in Eiffel is "once" variable.

BR,
renoX



 Dec 05 2012



 next sibling parent  "Namespace" <rswhite4 googlemail.com>  writes:


On Wednesday, 5 December 2012 at 13:36:14 UTC, renoX wrote:

 On Tuesday, 4 December 2012 at 21:59:15 UTC, Namespace wrote:
 [cut]

 - readonly variables, even called "lazy const". constant 
 variable, not rebindable but value must not assign by 
 declaration. Syntax: readonly int i;


 In the (unlikely) case you didn't know: the name for this 
 feature in Eiffel is "once" variable.

 BR,
 renoX


I really did not know that, thanks. I will change the name 
directly. once is a "little" more intuitive than readonly.



 Dec 05 2012



prev sibling  parent reply "Namespace" <rswhite4 googlemail.com>  writes:


On Wednesday, 5 December 2012 at 13:36:14 UTC, renoX wrote:

 On Tuesday, 4 December 2012 at 21:59:15 UTC, Namespace wrote:
 [cut]

 - readonly variables, even called "lazy const". constant 
 variable, not rebindable but value must not assign by 
 declaration. Syntax: readonly int i;


 In the (unlikely) case you didn't know: the name for this 
 feature in Eiffel is "once" variable.

 BR,
 renoX


Changed. ReadOnly is now Once.
Furthermore I improved the Elvis operator. You can now write:
Foo f;
Foo f2 = f !is null ?: new Foo();
This will be translated to:
Foo f2 = f !is null ? f : new Foo();

Only the valid identifier will be taken.
But take care of this. If you write int[] arr = other_arr.length 
?: [1, 2, 3]; You don't get only 'other_arr', but 
'other_arr.length'. This is because of using member 
functions/propoerties with elvis operators.



 Dec 05 2012



  parent reply "Namespace" <rswhite4 googlemail.com>  writes:


 But take care of this. If you write int[] arr = 
 other_arr.length ?: [1, 2, 3]; You don't get only 'other_arr', 
 but 'other_arr.length'. This is because of using member 
 functions/propoerties with elvis operators.


Improved.
Examples:

// declaration of vars...
int[] values = vars[].length == 0 ?: [1, 2, 3];
or
int[] values = vars[].length != 0 ?: [1, 2, 3];
or
int[] values = vars[].length > 0 ?: [1, 2, 3];

will be converted to:
int[] values = vars[].length == 0 ? vars[] : [1, 2, 3];

But if you write:
int[] values = vars[].length ?: [1, 2, 3];

you get:
int[] values = vars[].length == 0 ? vars.length : [1, 2, 3];

So if you have a compare operator after the last .property, only 
the identifiers before that will be taken.



 Dec 06 2012



  parent reply "Namespace" <rswhite4 googlemail.com>  writes:


Update:
Now available: auto ref compiler.
Because I assume that the 'auto ref' situation won't be fixed in 
this release, I wrote a workaround which provides remedy. But I 
still hope, that someone writes a solution.

So these code:
https://github.com/Dgame/Romulus/blob/master/Romulus/test/praesi.d
is converted to: 
https://github.com/Dgame/Romulus/blob/master/Romulus/test/Romulus_praesi.d

It isn't perfect because _all_ possible permutation (2^n) are 
generated, but better than nothing.



 Dec 28 2012



  parent reply "Namespace" <rswhite4 googlemail.com>  writes:


On Friday, 28 December 2012 at 21:19:47 UTC, Namespace wrote:

 Update:
 Now available: auto ref compiler.
 Because I assume that the 'auto ref' situation won't be fixed 
 in this release, I wrote a workaround which provides remedy. 
 But I still hope, that someone writes a solution.

 So these code:
 https://github.com/Dgame/Romulus/blob/master/Romulus/test/praesi.d
 is converted to: 
 https://github.com/Dgame/Romulus/blob/master/Romulus/test/Romulus_praesi.d

 It isn't perfect because _all_ possible permutation (2^n) are 
 generated, but better than nothing.


And now it works even with Visual Studio (on Windows).
It generates new files and generates for functions with auto ref 
parameter all possible permutations.
So it is a workaround as long as there is nothing comparable in D.



 Dec 29 2012



  parent  "Namespace" <rswhite4 googlemail.com>  writes:


Before I forget: the specially imported compiler flag "-del" 
deletes the (temporary) generated files immediately after 
compiling.



 Dec 29 2012



prev sibling  parent  "Namespace" <rswhite4 googlemail.com>  writes:


Last pull today. Romulus is ready to use/test. A website and 
documentation coming soon and then I need some help to write it 
in english. But first I hope that some of you could test it.

Here a brief overview:
  - not null references. Syntax: Object& obj
  - final variables. mutable access, but not rebindable. Syntax: 
final Object obj
  - readonly variables, even called "lazy const". constant 
variable, not rebindable but value must not assign by 
declaration. Syntax: readonly int i;
  - Elvis operator. Short ternary operator.
Syntax:
Object o;
// ...
o = o ?: new Object();

  - Not null safe invocation. Syntax: a?.b?.c will be converted to:
if (a && a.b) a.b.c. (works only with identifiers).

- Scoped arrays. scoped and static/stack array with the ability, 
that their size could be a runtime value. You can resize them, 
but if you do and if the capacity is fully used, it is 
reallocated on the heap. After leaving scope the memory is 
automatically destroyed, even if you have reallocated memory on 
the heap.
Syntax:
scope byte[4] arr1;
int i = 4;
scope byte[i] arr2;



 Dec 04 2012



prev sibling  parent  Jacob Carlborg <doob me.com>  writes:


On 2012-11-22 13:19, John Chapman wrote:



 http://msdn.microsoft.com/en-us/library/bb384054.aspx

 The compiler generates the get/set pair and backing store from the
 user's single-line declaration.

 So,

      property int bar();

 would expand to:

    private int bar_;

     property void bar(int value) {
      bar_ = value;
    }

     property int bar() {
      return bar_;
    }



Yeah, that's what I wrote.

-- 
/Jacob Carlborg



 Nov 22 2012



prev sibling  parent reply "Namespace" <rswhite4 googlemail.com>  writes:


I am considering to rewrite Remus from the ground up.
Because I hope that Remus earn next time more interest, I would 
like to vote or discuss the features.
As there would be:
  - Not null references. Example: Foo& f / int& i. Maybe only 
for Objects?
  - not null safe invocation. Example: some_obj?.do_something();
  - Elvis operator. Example: Foo result = foo ?: new Foo();
  - Stack instances with own keyword? For example, with 'local' 
as it is now.
  - Package import? Example: import package std: stdio, array, 
regex;
  - Namespaces?

What is preferred by this list / what not? What should be 
included in any case in Remus / what not?



 Nov 05 2012



 next sibling parent reply Jacob Carlborg <doob me.com>  writes:


On 2012-11-05 18:54, Namespace wrote:

 I am considering to rewrite Remus from the ground up.
 Because I hope that Remus earn next time more interest, I would like to
 vote or discuss the features.
 As there would be:
    - Not null references. Example: Foo& f / int& i. Maybe only for Objects?
    - not null safe invocation. Example: some_obj?.do_something();
    - Elvis operator. Example: Foo result = foo ?: new Foo();
    - Stack instances with own keyword? For example, with 'local' as it
 is now.
    - Package import? Example: import package std: stdio, array, regex;
    - Namespaces?

 What is preferred by this list / what not? What should be included in
 any case in Remus / what not?


I would say yes to everything except namespaces. I would also like the 
elvis operator in combination with the assignment operator, i.e.

Foo a;
a ?:= new Foo; // only assign if "a" is null

-- 
/Jacob Carlborg



 Nov 05 2012



  parent reply "Namespace" <rswhite4 googlemail.com>  writes:


 I would say yes to everything except namespaces. I would also 
 like the elvis operator in combination with the assignment 
 operator, i.e.


Nice to hear. :)
I hope a few other say something also.


 Foo a;
 a ?:= new Foo; // only assign if "a" is null


Works in the current Remus version with: [code]a ?= new 
Foo();[/code] ;)



 Nov 05 2012



  parent  Jacob Carlborg <doob me.com>  writes:


On 2012-11-05 22:01, Namespace wrote:


 Works in the current Remus version with: [code]a ?= new Foo();[/code] ;)


Cool.

-- 
/Jacob Carlborg



 Nov 05 2012



prev sibling next sibling parent reply "Tavi Cacina" <octavian.cacina outlook.com>  writes:


On Monday, 5 November 2012 at 17:54:32 UTC, Namespace wrote:

 I am considering to rewrite Remus from the ground up.
 Because I hope that Remus earn next time more interest, I would 
 like to vote or discuss the features.
 As there would be:
   - Not null references. Example: Foo& f / int& i. Maybe only 
 for Objects?
   - not null safe invocation. Example: 
 some_obj?.do_something();
   - Elvis operator. Example: Foo result = foo ?: new Foo();
   - Stack instances with own keyword? For example, with 
 'local' as it is now.
   - Package import? Example: import package std: stdio, array, 
 regex;
   - Namespaces?

 What is preferred by this list / what not? What should be 
 included in any case in Remus / what not?


I'm learning the D language right now, and I can not say that 
I've missed any of these things. They may offer some 'syntactic 
sugar', but the D is very expressive anyway. Ex: for safe 
invocation I would use an assert/enforce anyway if there is a 
chance the object is null. The 'import package' whould be usefull 
though...



 Nov 05 2012



  parent reply "Namespace" <rswhite4 googlemail.com>  writes:


 I'm learning the D language right now, and I can not say that 
 I've missed any of these things. They may offer some 'syntactic 
 sugar', but the D is very expressive anyway. Ex: for safe 
 invocation I would use an assert/enforce anyway if there is a 
 chance the object is null. The 'import package' whould be 
 usefull though...


Which language(s) did you use before? Java? ;)



 Nov 06 2012



  parent reply "Tavi Cacina" <octavian.cacina outlook.com>  writes:


On Tuesday, 6 November 2012 at 16:39:24 UTC, Namespace wrote:

 I'm learning the D language right now, and I can not say that 
 I've missed any of these things. They may offer some 
 'syntactic sugar', but the D is very expressive anyway. Ex: 
 for safe invocation I would use an assert/enforce anyway if 
 there is a chance the object is null. The 'import package' 
 whould be usefull though...


 Which language(s) did you use before? Java? ;)


I'm on the C++ wagon, thus the plain and simple (though 
expressive) syntax of D is what keeps me here :-)
It is just my opinion, because you asked for feedback :-) Hack 
forward as you like it...



 Nov 06 2012



  parent reply "Namespace" <rswhite4 googlemail.com>  writes:


On Tuesday, 6 November 2012 at 20:03:21 UTC, Tavi Cacina wrote:

 On Tuesday, 6 November 2012 at 16:39:24 UTC, Namespace wrote:

 I'm learning the D language right now, and I can not say that 
 I've missed any of these things. They may offer some 
 'syntactic sugar', but the D is very expressive anyway. Ex: 
 for safe invocation I would use an assert/enforce anyway if 
 there is a chance the object is null. The 'import package' 
 whould be usefull though...


 Which language(s) did you use before? Java? ;)


 I'm on the C++ wagon, thus the plain and simple (though 
 expressive) syntax of D is what keeps me here :-)
 It is just my opinion, because you asked for feedback :-) Hack 
 forward as you like it...


No offense. :)
But if you came from C++: didn't you miss (not-null) references?



 Nov 06 2012



  parent  "Rob T" <rob ucora.com>  writes:


On Tuesday, 6 November 2012 at 22:00:47 UTC, Namespace wrote:

 No offense. :)
 But if you came from C++: didn't you miss (not-null) references?


You could perform trickery and create null references in C++ and 
the compiler would not catch it, but you'd have to intentionally 
mess around and do dangerous things.

I do agree that not null references is an item D could really 
use. Of course you'll need to also allow nullable references too 
because that is also extremely useful, so really what you want is 
ability to pick and choose which references are guaranteed to 
never be null and which can be null. By default it should be not 
nullable. There was a thread in here on this topic not long ago, 
but Im not so sure we'll get to see it in D any time soon.

--rt



 Nov 06 2012



prev sibling  parent reply "Aziz K." <aziz.koeksal gmail.com>  writes:


On Mon, 05 Nov 2012 18:54:31 +0100, Namespace <rswhite4 googlemail.com>  
wrote:


 I am considering to rewrite Remus from the ground up.
 Because I hope that Remus earn next time more interest, I would like to  
 vote or discuss the features.


Writing a D parser from the ground up, even if it's basic, seems to be an  
awful waste of time.

Check out my D compiler to see if it could serve any of your purposes:

https://github.com/azizk/dil



 Nov 07 2012



  parent  "Namespace" <rswhite4 googlemail.com>  writes:


On Wednesday, 7 November 2012 at 08:26:25 UTC, Aziz K. wrote:

 On Mon, 05 Nov 2012 18:54:31 +0100, Namespace 
 <rswhite4 googlemail.com> wrote:


 I am considering to rewrite Remus from the ground up.
 Because I hope that Remus earn next time more interest, I 
 would like to vote or discuss the features.


 Writing a D parser from the ground up, even if it's basic, 
 seems to be an awful waste of time.

 Check out my D compiler to see if it could serve any of your 
 purposes:

 https://github.com/azizk/dil


Thanks a lot, but my Lexer/Parser isn't that smart and I think I 
need nothing wiser. But thanks, maybe I find some nice features 
which I can implement by my own. :)

Rob T:
Absolutely right. Hence the brackets around "non-null" is. ;)
First of all, I plan to implement real not-null references. I 
hope that I receive some feedback then.



 Nov 07 2012



prev sibling next sibling parent reply Philippe Sigaud <philippe.sigaud gmail.com>  writes:


 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



 Oct 30 2012



  parent  Dmitry Olshansky <dmitry.olsh gmail.com>  writes:


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



 Oct 30 2012



prev sibling  parent  Philippe Sigaud <philippe.sigaud gmail.com>  writes:


 (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.



 Oct 30 2012



prev sibling  parent  Jeff Nowakowski <jeff dilacero.org>  writes:


On 10/29/2012 06:09 PM, bearophile wrote:

 Otherwise you risk creating another Delight
 (http://delight.sourceforge.net/ ) that no one uses, it's just a waste
 of time for you too.


I'm waiting for the bearD programming language :)



 Nov 01 2012



prev sibling  parent reply "Rob T" <rob ucora.com>  writes:


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



 Oct 29 2012



 next sibling parent  Rory McGuire <rjmcguire gmail.com>  writes:


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





 Oct 29 2012



prev sibling  parent  Jacob Carlborg <doob me.com>  writes:


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



 Oct 30 2012



prev sibling next sibling parent  "thedeemon" <dlang thedeemon.com>  writes:


On Tuesday, 9 October 2012 at 19:34:01 UTC, Namespace wrote:


 Stack Instances:
 There aren't many words for: if you need a stack instance, 
 write: local Foo f = new Foo(); it's more or less the same as 
 scope.


What's the difference between this and std.typecons.scoped, 
except for alignment and syntax?



 Oct 09 2012



prev sibling  parent reply Jacob Carlborg <doob me.com>  writes:


On 2012-10-09 21:10, Namespace wrote:


 My next version will contain the elvis operator:
 [code]
 Foo obj = otherObj.get() ?: null;
 if otherObj.get() is _not_ null, it will assign to obj, otherwise obj
 will be assigned with null.
 [/code]


Will it support this syntax:

Foo obj;
obj ?= otherObj.get();

Will only assign to "obj" if it's null.

-- 
/Jacob Carlborg



 Oct 09 2012



  parent reply "Namespace" <rswhite4 googlemail.com>  writes:


On Wednesday, 10 October 2012 at 07:06:54 UTC, Jacob Carlborg 
wrote:

 On 2012-10-09 21:10, Namespace wrote:


 My next version will contain the elvis operator:
 [code]
 Foo obj = otherObj.get() ?: null;
 if otherObj.get() is _not_ null, it will assign to obj, 
 otherwise obj
 will be assigned with null.
 [/code]


 Will it support this syntax:

 Foo obj;
 obj ?= otherObj.get();

 Will only assign to "obj" if it's null.


You mean:
[code]
Foo obj;
if (obj is null) {
     obj = otherObj.get();
}
[/code]
?

Interesting point. Until now this isn't supported but I will 
think about it.



 Oct 10 2012



  parent reply Jacob Carlborg <doob me.com>  writes:


On 2012-10-10 09:10, Namespace wrote:


 You mean:
 [code]
 Foo obj;
 if (obj is null) {
      obj = otherObj.get();
 }
 [/code]
 ?

 Interesting point. Until now this isn't supported but I will think about
 it.


Exactly, most language supporting the elvis operator supports this form 
as well, both Ruby and CoffeeScript do.

-- 
/Jacob Carlborg



 Oct 10 2012



  parent  "Namespace" <rswhite4 googlemail.com>  writes:


On Wednesday, 10 October 2012 at 13:14:22 UTC, Jacob Carlborg 
wrote:

 On 2012-10-10 09:10, Namespace wrote:


 You mean:
 [code]
 Foo obj;
 if (obj is null) {
     obj = otherObj.get();
 }
 [/code]
 ?

 Interesting point. Until now this isn't supported but I will 
 think about
 it.


 Exactly, most language supporting the elvis operator supports 
 this form as well, both Ruby and CoffeeScript do.


The evlis operator is the next i will implement.
So I will consider if something like this is necessary. :)



 Oct 10 2012