www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Pending peeves again - getting tired of waiting

reply Stewart Gordon <smjg_1998 yahoo.com> writes:
I went to all the trouble to start this list.  And I'm quite sure I'm 
not the only one waiting for the items on it (some getting rather old 
now) to finally be dealt with.

As you see, they roughly fall into three categories:
- fixes that need to be coded up
- fixes that have already been written, and just need hooking up
- places where it's merely the documentation that needs finishing

Walter, could we please at least have a clue of where these are in your 
queue?

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the 
unfortunate victim of intensive mail-bombing at the moment.  Please keep 
replies on the 'group where everyone may benefit.
Jul 07 2004
next sibling parent reply Charlie <Charlie_member pathlink.com> writes:
url is http://www.prowiki.org/wiki4d/wiki.cgi?PendingPeeves ;)

Also hate to be picky but

string.d:1488
--

char[] toString(char c)
{
char[] result = new char[2];
result[0] = c;
result[1] = 0;
return result[0 .. 1];
}

Why all those extra operations ?  When it justs need 1 char assignment ?

Charlie


In article <ccgikc$92e$1 digitaldaemon.com>, Stewart Gordon says...

I went to all the trouble to start this list.  And I'm quite sure I'm 
not the only one waiting for the items on it (some getting rather old 
now) to finally be dealt with.

As you see, they roughly fall into three categories:
- fixes that need to be coded up
- fixes that have already been written, and just need hooking up
- places where it's merely the documentation that needs finishing

Walter, could we please at least have a clue of where these are in your 
queue?

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the 
unfortunate victim of intensive mail-bombing at the moment.  Please keep 
replies on the 'group where everyone may benefit.
Jul 07 2004
parent reply Norbert Nemec <Norbert.Nemec gmx.de> writes:
Charlie wrote:


 url is http://www.prowiki.org/wiki4d/wiki.cgi?PendingPeeves ;)
 
 Also hate to be picky but
 
 string.d:1488
 --
 
 char[] toString(char c)
 {
 char[] result = new char[2];
 result[0] = c;
 result[1] = 0;
 return result[0 .. 1];
 }
 
 Why all those extra operations ?  When it justs need 1 char assignment ?


I agree! It should be:

-----------------------
char[] toString(char c)
{
        char[] result = new char[1];
        result[0] = c;
        return result;
}
-----------------------

All that putting in trailing 0s automatically should be avoided. If you need
to interface C-code, you should do the conversion explicitely. Of course
that is less efficient, but why should the native string handling code
suffer for that? The native-string library should not care about trailing
0s at all!
Jul 07 2004
parent reply Andy Friesen <andy ikagames.com> writes:
Norbert Nemec wrote:

 It should be:
 
 -----------------------
 char[] toString(char c)
 {
         char[] result = new char[1];
         result[0] = c;
         return result;
 }


Or just:

     char[] toString(char c) { return (&c)[0..1].dup; }

  -- andy
Jul 07 2004
parent Norbert Nemec <Norbert.Nemec gmx.de> writes:
Andy Friesen wrote:


 Norbert Nemec wrote:

 It should be:
 
 -----------------------
 char[] toString(char c)
 {
         char[] result = new char[1];
         result[0] = c;
         return result;
 }


 
 Or just:
 
      char[] toString(char c) { return (&c)[0..1].dup; }


That's neat! I really need to learn thinking D...
Jul 07 2004
prev sibling next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Stewart Gordon" <smjg_1998 yahoo.com> wrote in message
news:ccgikc$92e$1 digitaldaemon.com...

 I went to all the trouble to start this list.  And I'm quite sure I'm
 not the only one waiting for the items on it (some getting rather old
 now) to finally be dealt with.

 As you see, they roughly fall into three categories:
 - fixes that need to be coded up
 - fixes that have already been written, and just need hooking up
 - places where it's merely the documentation that needs finishing

 Walter, could we please at least have a clue of where these are in your
 queue?


There are hundreds of items in the bug list, I try to give priority to
crashers. Anyhow, I've stopped adding new features, and have just been
working the bug list.
Jul 07 2004
next sibling parent reply pragma <EricAnderton at yahoo dot com> <pragma_member pathlink.com> writes:
In article <cchbph$1dmh$1 digitaldaemon.com>, Walter says...

There are hundreds of items in the bug list, I try to give priority to
crashers. Anyhow, I've stopped adding new features, and have just been
working the bug list.


I don't think it's said enough around here: Thank you for all your hard work.  

D is a wonderful language and has truely changed how I approach solving problems
with software.

- Pragma
Jul 07 2004
parent "Walter" <newshound digitalmars.com> writes:
"pragma" <EricAnderton at yahoo dot compragma_member pathlink.com> wrote in
message news:cchftn$1jv5$1 digitaldaemon.com...

 In article <cchbph$1dmh$1 digitaldaemon.com>, Walter says...

There are hundreds of items in the bug list, I try to give priority to
crashers. Anyhow, I've stopped adding new features, and have just been
working the bug list.


 I don't think it's said enough around here: Thank you for all your hard


work.

 D is a wonderful language and has truely changed how I approach solving


problems

 with software.


Thanks! D is the language I always wanted to use, too <g>.
Jul 07 2004
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Walter wrote:

 "Stewart Gordon" <smjg_1998 yahoo.com> wrote in message 
 news:ccgikc$92e$1 digitaldaemon.com...
 

 I went to all the trouble to start this list.  And I'm quite sure 
 I'm not the only one waiting for the items on it (some getting 
 rather old now) to finally be dealt with.
 
 As you see, they roughly fall into three categories: - fixes that 
 need to be coded up - fixes that have already been written, and 
 just need hooking up - places where it's merely the documentation 
 that needs finishing
 
 Walter, could we please at least have a clue of where these are in 
 your queue?


 
 There are hundreds of items in the bug list, I try to give priority 
 to crashers. Anyhow, I've stopped adding new features, and have just 
 been working the bug list.


I see, so as long as you're in control, that's OK.

But I am particularly surprised at how late you've left implementation 
of array arithmetic.  Let's just hope there's still time to test this 
corner of the spec!

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the 
unfortunate victim of intensive mail-bombing at the moment.  Please keep 
replies on the 'group where everyone may benefit.
Jul 08 2004
parent reply Norbert Nemec <Norbert.Nemec gmx.de> writes:
Stewart Gordon wrote:


 But I am particularly surprised at how late you've left implementation
 of array arithmetic.  Let's just hope there's still time to test this
 corner of the spec!


I'm not yet convinced of that concept for array operations in the specs. It
is a simple concept (which certainly is good), but I fear that it is
neither very flexible nor extensible.

=================================

First, the analogy given in the specs to explain array operations: this
implies that a certain order of evaluation is guaranteed. This kind of
operation would be mere syntactic sugar for "for"-loops. Vectorization is
far more than that.

Furthermore: trying to understand the specs, there would be nothing like an
"array expression". Only "array statements". (Even though the specs
erraneously talk of "expressions")

For example:

----------
void myfunc(real[] x) {
        return ...;
}

real[] a = ...;
real[] b = ...;

myfunc(a[] + b[]);
-----------

This will not work, since the last line would be interpreted as

-----------
for (i = 0; i < a.length; i++)
    myfunc(a[i] + b[i]);
-----------


=================================

The concept I have of "array expressions" is fundamentally different:

        a[] + b[]

itself would be an expression of the type of an array. You really build up
expressions from arrays.

Anyhow: this concept taken alone is not extensible. You can have a certain
number of operators defined on arrays, but defining your own
array-functions would only be possible using a "for" loop. This loop would
break vectorization and require a temporary copy of the data. In some
cases, the compiler might be able to optimize this away, but in general,
this will not be possible.

To make the concept of "array expressions" extensible, I came up with the
idea of "vector expressions" similar to:

        [i=0..10](a[i] + b[i])  // still haven't found any better syntax for it

these allow to build the most general vectorized expressions from simple,
scalar building-blocks. For simple expressions, you could use the
index-free notation, for anything more complicated, you can fall back to
the full-fledged index-notation.

================================

Now, why do I bring this up at this point: as I understand it, the Array
Operations described in the specs (and not yet implemented) are
fundamentally incompatible with the concept of real "array expressions".
Pushing for the implementation of array operations now will lead to
troubles when array expressions are to be introduced some day. I would
rather have neither of them in 1.0 then the quick-and-dirty concept that is
in the specs.

B.t.w: Array assignments should not be a problem. They would look the same
in both concepts.

Ciao,
Nobbi
Jul 08 2004
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Norbert Nemec wrote:

<snip>

 First, the analogy given in the specs to explain array operations:
 this implies that a certain order of evaluation is guaranteed. This
 kind of operation would be mere syntactic sugar for "for"-loops.
 Vectorization is far more than that.


Not sure what you mean by that.


 Furthermore: trying to understand the specs, there would be nothing
 like an "array expression". Only "array statements". (Even though the
 specs erraneously talk of "expressions")


It is a simple matter of overloading the arithmetic operators themselves
for arrays.  Just looking at it....

----------
So, for the expression:

	a[] = b[] + 3;


the result is equivalent to:

	for (i = 0; i < a.length; i++)
	    a[i] = b[i] + 3;

----------

Notice the word "result".  From a semantic point of view, b[] + 3 is
simply an expression that evaluates to an array.


 For example:
 
 ---------- void myfunc(real[] x) { return ...; }
 
 real[] a = ...; real[] b = ...;
 
 myfunc(a[] + b[]); -----------
 
 This will not work, since the last line would be interpreted as
 
 ----------- for (i = 0; i < a.length; i++) myfunc(a[i] + b[i]); 
 -----------


Similarly, a[] + b[] evaluates to an array.  Which is what myfunc
expects, so there's no problem there.


 =================================
 
 The concept I have of "array expressions" is fundamentally different:
 
 
 a[] + b[]
 
 itself would be an expression of the type of an array. You really
 build up expressions from arrays.


That is indeed how I understand it to work.  That for loop is purely for
illustration, not to define the semantics.  Also, notice that this

----------
	for (i = n; i < m; i++)
	    a[i] op e;
----------

if strictly interpreted, only follows if op is an assignment operation.
  Even then it's not quite right, as that for loop doesn't return the 
array from the expression.

What is actually meant AFAICS is exactly as you suggest they should
work.  That is:

	T temp = new T[m-n];
	for (i = n; i < m; i++)
	    temp[i-n] = a[i] op e;
	return temp;


 Anyhow: this concept taken alone is not extensible. You can have a 
 certain number of operators defined on arrays, but defining your own 
 array-functions would only be possible using a "for" loop. This loop 
 would break vectorization and require a temporary copy of the data.  
 In some cases, the compiler might be able to optimize this away, but 
 in general, this will not be possible.


By "vectorization" do you mean the possibility of optimising elementwise 
formulas to be evaluated without storing intermediate arrays, and 
possibly in parallel?  Maybe a future D feature (perhaps a function 
attribute) combined with these array expressions could accommodate this.

<snip>

 Now, why do I bring this up at this point: as I understand it, the 
 Array Operations described in the specs (and not yet implemented) are 
 fundamentally incompatible with the concept of real "array 
 expressions". Pushing for the implementation of array operations now 
 will lead to troubles when array expressions are to be introduced 
 some day.


 From the FAQ:

"The programming community is better served by multiple implementations
competing on quality of code generated rather than by which corners of
the spec are implemented at all."

Oh dear, now we're already inviting competition on which corners of the 
spec are implemented.


 I would rather have neither of them in 1.0 then the quick-and-dirty 
 concept that is in the specs.


In your interpretation of the specs, I think you'll find.

If we're going to leave it out at this stage, it will need to be 
specified as implementation-optional and define a version identifier for 
it, the way the inline assembler is already.

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the
unfortunate victim of intensive mail-bombing at the moment.  Please keep
replies on the 'group where everyone may benefit.
Jul 08 2004
parent Norbert Nemec <Norbert.Nemec gmx.de> writes:
Stewart Gordon wrote:


 Norbert Nemec wrote:
 
 <snip>

 First, the analogy given in the specs to explain array operations:
 this implies that a certain order of evaluation is guaranteed. This
 kind of operation would be mere syntactic sugar for "for"-loops.
 Vectorization is far more than that.


 
 Not sure what you mean by that.


"Vectorization" means: the language explicitely does not guarantee any order
of execution, thereby allowing the compiler reordering without further
checks.

The "definition by analogy" that is used in the specs misses this fact.


 Furthermore: trying to understand the specs, there would be nothing
 like an "array expression". Only "array statements". (Even though the
 specs erraneously talk of "expressions")


 
 It is a simple matter of overloading the arithmetic operators themselves
 for arrays.  Just looking at it....
 
 ----------
 So, for the expression:
 
 a[] = b[] + 3;
 
 
 the result is equivalent to:
 
 for (i = 0; i < a.length; i++)
 a[i] = b[i] + 3;
 
 ----------
 
 Notice the word "result".  From a semantic point of view, b[] + 3 is
 simply an expression that evaluates to an array.


Wrong. What you are quoting is an example, not the definition. The definion,
though, is a bit unclear and needs for interpretation based on the example.

The definition is

----------------------
In general, (a[n..m] op e) is defined as: 
        for (i = n; i < m; i++)
            a[i] op e;
----------------------

taken by word, this is nonsense. You cannot define an expression by a
statement! Just consider

        myfunc(a[] + b[]);

should this be turned into

        myfunc(for (i = n; i < m; i++) a[i] + b[i])

??!! The only way you could possibly read this definition, is, on a
per-statement basis. Take the whole statement and wrap it up into a for
loop. Anyhow, this interpretation would give you

        for (i = n; i < m; i++) 
                myfunc(a[i] + b[i]);

Which would make sense syntactically, but probably is not what you want.

We can continue like this, but I don't think it would be leading very far.
Bottom line: the specs are not clearly saying what array operations really
are. Taking the definition by word gives you nonsense, and trying to
understand the "spirit" of the definition, we obviously agree.

Before implementing any feature, and even before doing any serious
discussion of it, we should really have a clear definition.

Ciao,
Norbert
Jul 08 2004
prev sibling parent reply Ant <Ant_member pathlink.com> writes:
In article <ccgikc$92e$1 digitaldaemon.com>, Stewart Gordon says...

Walter, could we please at least have a clue of where these are in your 
queue?


That would be nice!

but i see it like this:
We are very lucky that Walter decided to offer D to the world.
Unfortunatly the over centralized development model might not
seem the best to all of us but that's how Walter prefers to do it.

So please join me in saying:
Walter thank you for D,
and please take a few weeks vacations I'm here for a year and never saw
you miss a single day. That can't be good. We can wait.

:)

Ant
Jul 07 2004
next sibling parent Charlie <Charlie_member pathlink.com> writes:
We are very lucky that Walter decided to offer D to the world.


Hear Hear!

He has been sweating over this for years, and I think a vacation is well
deserved :).  We can wait.

Charlie



In article <cchdgn$1g4d$1 digitaldaemon.com>, Ant says...

In article <ccgikc$92e$1 digitaldaemon.com>, Stewart Gordon says...

Walter, could we please at least have a clue of where these are in your 
queue?


That would be nice!

but i see it like this:
We are very lucky that Walter decided to offer D to the world.
Unfortunatly the over centralized development model might not
seem the best to all of us but that's how Walter prefers to do it.

So please join me in saying:
Walter thank you for D,
and please take a few weeks vacations I'm here for a year and never saw
you miss a single day. That can't be good. We can wait.

:)

Ant
Jul 07 2004
prev sibling parent reply "Bent Rasmussen" <exo bent-rasmussen.info> writes:
 So please join me in saying:
 Walter thank you for D,
 and please take a few weeks vacations I'm here for a year and never saw
 you miss a single day. That can't be good. We can wait.


Yes, thanks for D, its great.

Walter may resemble Santa but he ain't got unlimited resources. :-)


 :)

 Ant
Jul 07 2004
parent "Walter" <newshound digitalmars.com> writes:
"Bent Rasmussen" <exo bent-rasmussen.info> wrote in message
news:cchj59$1pec$1 digitaldaemon.com...

 Yes, thanks for D, its great.


You're welcome


 Walter may resemble Santa but he ain't got unlimited resources. :-)


I hope that someday we'll get a corporate sponsor with deep pockets. As it
is today, D is entering corporate programming at the grass roots level.
Soon, managers will look around and notice that half their projects are in
D!
Jul 07 2004