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:
h
Before I forget: the specially imported compiler flag "-del"
deletes the (temporary) generated files immediately after
compiling.
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
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 ?:
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)
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)
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
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
-
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 no
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 no
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.
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();
wou
Oh, I didn't know that, thanks.
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 _ba
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
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
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 pu
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.c
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 perf
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
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.
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 "cons
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 (Objec
On Wednesday, 21 November 2012 at 17:43:22 UTC, bearophile wrote:
Namespace:
I will write a struct and replace 'readonly ...' with an
instance of ReadOnly!(...) ...
OK.
Not good? What would be better? :)
What do you mean with 'how useful'?
It means to try to use your feature(s) to rewri
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 fe
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 th
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 _va
While Variable Length Arrays allocated on the heap can't be
I meant stack, sorry.
Bye,
bearophile
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 buil
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 ty
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.
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
h
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
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
On Wednesday, 7 November 2012 at 08:26:25 UTC, Aziz K. wrote:
On Mon, 05 Nov 2012 18:54:31 +0100, 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.
Writing a D parser
On Mon, 05 Nov 2012 18:54:31 +0100, 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.
Writing a D parser from the ground up, even if it's basic, seems to
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 da
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
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 i
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' w
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&
On 2012-11-05 22:01, Namespace wrote:
Works in the current Remus version with: [code]a ?= new Foo();[/code] ;)
Cool.
--
/Jacob Carlborg
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 wit
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
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.
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.
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
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
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
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 :)
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. :)
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
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&
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
> 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
e 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 work
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. :)
>
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 wonder if you could use a named public import to create something like a
namespace.
On 30 Oct 2012 00:25, "Rob T" 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.
>>>
>>
>> B
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
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
Not interested, huh? Funny, that I had not expected.
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, ar
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 ugl
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
h 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. ;)
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
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 an
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
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()
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
"namespace
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
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_func
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:
[
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 add
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?
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 inc
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. :)
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
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
-
80 matches
Mail list logo
