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 "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
prev sibling next sibling 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 next 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
next 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 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
prev sibling next sibling 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 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 next 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 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 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 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 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 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 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 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
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-11-22 13:19, John Chapman wrote:

 I believe Jacob is referring to C#'s auto-implemented properties:
 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 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 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 "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
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 next sibling parent "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
prev sibling next sibling parent "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
prev sibling 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 next sibling 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
prev sibling next sibling parent 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
prev sibling next sibling parent "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
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
Not interested, huh? Funny, that I had not expected.
Oct 29 2012
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent Rory McGuire <rjmcguire gmail.com> writes:
--e89a8f838e49d21da604cd40187d
Content-Type: text/plain; charset=UTF-8

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

--e89a8f838e49d21da604cd40187d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <p dir=3D"ltr">I wonder if you could use a named public import to create so= mething like a namespace.</p> <div class=3D"gmail_quote">On 30 Oct 2012 00:25, &quot;Rob T&quot; &lt;<a h= ref=3D"mailto:rob ucora.com">rob ucora.com</a>&gt; wrote:<br type=3D"attrib= ution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-= left:1px #ccc solid;padding-left:1ex"> On Tuesday, 9 October 2012 at 21:31:48 UTC, bearophile wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"m= argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> &quot;use&quot; statements are converted to one or more alias&#39; and name= spaces to (mixin) templates.<br> </blockquote> <br> But what are they useful for?<br> </blockquote> <br> Namespaces can be useful for organizational reasons. For example they can b= e used for grouping a collection of items under one roof. However you can a= lready accomplish this and more using struct along with static members.<br> <br> struct io<br> {<br> =C2=A0 =C2=A0static<br> =C2=A0 =C2=A0{<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 void print() { writeln(&quot;foo&quot;); =C2=A0= }<br> =C2=A0 =C2=A0}<br> }<br> <br> io.print();<br> <br> Plus struct&#39;s come with additional abilities that can turn a simple nam= espace into a much more capable one, for example by adding in ctors and dto= rs.<br> <br> --rt<br> <br> </blockquote></div> --e89a8f838e49d21da604cd40187d--
Oct 29 2012
prev sibling next sibling parent "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
prev sibling next sibling parent Rory McGuire <rjmcguire gmail.com> writes:
--e89a8fb2069c56c79904cd412531
Content-Type: text/plain; charset=UTF-8

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. :)

--e89a8fb2069c56c79904cd412531 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It would be really awesome if you could play around with making the AST ava= ilable during compilation so we can alter it using ctfe.<br> <br><br><div class=3D"gmail_quote">On Tue, Oct 30, 2012 at 8:34 AM, Namespa= ce <span dir=3D"ltr">&lt;<a href=3D"mailto:rswhite4 googlemail.com" target= =3D"_blank">rswhite4 googlemail.com</a>&gt;</span> wrote:<br><blockquote cl= ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p= adding-left:1ex"> <div class=3D"HOEnZb"><div class=3D"h5">On Monday, 29 October 2012 at 22:09= :02 UTC, bearophile wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Namespace:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Not interested, huh? Funny, that I had not expected.<br> </blockquote> <br> Maybe they appreciate more something that improves the life of regular D pr= ogrammers. There are many possible ways to do that, like trying to design f= eatures that quite probably will be added to D, or trying library ideas tha= t will become part of Phobos, trying new GC features, trying new Phobos mod= ules, and so on and on.<br> <br> Otherwise you risk creating another Delight (<a href=3D"http://delight.sour= ceforge.net/" target=3D"_blank">http://delight.sourceforge.<u></u>net/</a> = ) that no one uses, it&#39;s just a waste of time for you too.<br> <br> Bye,<br> bearophile<br> </blockquote> <br></div></div> Yes, but I need input. Tell me some ideas and I&#39;ll try to implement the= m. So you could just test new features in the real world, instead of just t= alking about them theoretically.<br> And it is not &#39;waste of time&#39;. Me and my fellow students use D as e= arly as the second Semester for almost all university projects. But as &#39= ;(pre) compiler&#39; we use Remus just because we miss some features, such = as not-null references, since the first week. And it&#39;s a damn good exer= cise to understand, how a compiler works. :)<br> </blockquote></div><br> --e89a8fb2069c56c79904cd412531--
Oct 29 2012
prev sibling next sibling parent "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
prev sibling next sibling parent 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
prev sibling next 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 next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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.

I hope a few other say something also.
 Foo a;
 a ?:= new Foo; // only assign if "a" is null

Foo();[/code] ;)
Nov 05 2012
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling 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 next sibling parent "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
prev sibling next sibling 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 "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 
present in F# and other functional languages.

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
prev sibling next sibling parent "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 
 syntax is present in F# and other functional languages.

 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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling 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 next sibling parent "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).

 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" :-)

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

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
prev sibling next sibling parent "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
prev sibling 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.

 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 next sibling parent "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.

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
prev sibling next sibling parent "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.

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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling 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 next sibling parent "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.

IMO is too short not always the best. Therefore I like the C# syntax with set and get. The aquivalent of this in D is IMO 'in' and 'out'.
Nov 22 2012
prev sibling next sibling parent "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.

IMO is too short not always the best. Therefore I like the C# syntax with set and get. The aquivalent of this in D is IMO 'in' and 'out'.

I believe Jacob is referring to C#'s auto-implemented properties: 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
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
Oh, I didn't know that, thanks.
Nov 22 2012
prev sibling next sibling parent "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
prev sibling next 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 next 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 next sibling parent "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
prev sibling 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 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

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
prev sibling parent "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