View mode: basic / threaded / horizontal-split · Log in · Help
October 30, 2012
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. :)
November 01, 2012
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 :)
November 01, 2012
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
November 01, 2012
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?
November 01, 2012
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
November 01, 2012
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.
November 01, 2012
Re: Remus
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
November 05, 2012
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?
November 05, 2012
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
November 05, 2012
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] ;)
1 2 3 4 5 6 7 8
Top | Discussion index | About this forum | D home