Re: Remus
Before I forget: the specially imported compiler flag -del deletes the (temporary) generated files immediately after compiling.
Re: Remus
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.
Re: Remus
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.
Re: Remus
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'.
Re: Remus
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_;
}
Re: Remus
Oh, I didn't know that, thanks.
Re: Remus
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
Re: Remus
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?
Re: Remus
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
Re: Remus
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
Re: Remus
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'?
Re: Remus
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
Re: Remus
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.
Re: Remus
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
Re: Remus
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
Re: Remus
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; }
Re: Remus
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.
Re: Remus
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
Re: Remus
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.
Re: Remus
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
Re: Remus
On Mon, 05 Nov 2012 18:54:31 +0100, Namespace rswhi...@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
Re: Remus
On Wednesday, 7 November 2012 at 08:26:25 UTC, Aziz K. wrote: On Mon, 05 Nov 2012 18:54:31 +0100, Namespace rswhi...@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.
Re: Remus
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
Re: Remus
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.
:/
Re: Remus
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? ;)
Re: Remus
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...
Re: Remus
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?
Re: Remus
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
Re: Remus
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] ;)
Re: Remus
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...
Re: Remus
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 :)
Re: Remus
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
Re: Remus
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?
Re: Remus
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
Re: Remus
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.
Re: Remus
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. :)
Re: Remus
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 rswhi...@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. :)
Re: Remus
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
Re: Remus
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
Re: Remus
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.
Re: Remus
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
Re: Remus
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. :)
Re: Remus
Not interested, huh? Funny, that I had not expected.
Re: Remus
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
Re: Remus
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
Re: Remus
I wonder if you could use a named public import to create something like a
namespace.
On 30 Oct 2012 00:25, Rob T r...@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
Re: Remus
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());
Re: Remus
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
Re: Remus
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.
Re: Remus
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.
Re: Remus
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. ;)
Re: Remus
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. :)
Re: Remus
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.
Re: Remus
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.
Re: Remus
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
Re: Remus
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?
Re: Remus
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.
Re: Remus
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.
Remus
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 ;)
Re: Remus
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
Re: Remus
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. :)
Re: Remus
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
Re: Remus
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?
