Since overlapped copying of arrays is disallowed it
might be nice if arrays had built in element insert
and delete or maybe just a move?

int[10] a;

// Move all the elements of a down over writeing a[0]
a.move(1,0,a.lenght-1);

a.delete(0,1);
// Same effect

Maybe an addtional flag to indicate what to do with
the uncovered elements.

a.delete(0,1,true);
// Same effect but a[9] = 0 too

a.delete(0,1,false);
// Same effect but a[8] == a[9]

I like the idea of an insert method that would expand the array, shift
everything over, and then put the new element in its place.

int[10] foo;
foo.insert(index,element);

Same with
delete. It would make sorted arrays very easy to implement. If you
wanted to go overboard, you could even have a insertinorder method
that would insert a new element into its rightful spot. I suppose
that would be better handled by a special SortedArray class though.

Or, perhaps if you left off the index argument, the method would
automatically find where in the array to insert the element? I am
not sure if this would involve calling some compareTo argument like
java does, or how D would accomplish this.

Patrick Down wrote:

> Since overlapped copying of arrays is disallowed it
> might be nice if arrays had built in element insert
> and delete or maybe just a move?
> 
> int[10] a;
> 
> // Move all the elements of a down over writeing a[0]
> a.move(1,0,a.lenght-1);
> 
> a.delete(0,1);
> // Same effect


I'm not completely sure what the second argument is for. Couldn't you
just have one argument saying which element you want to delete?
i.e

a.delete(4);
// now a[4] == a[5] if it shifts the remaining elements automatically?

> 
> Maybe an addtional flag to indicate what to do with
> the uncovered elements.
> 
> a.delete(0,1,true);
> // Same effect but a[9] = 0 too
> 
> a.delete(0,1,false);
> // Same effect but a[8] == a[9]
> 
> 

"Patrick Down" <pat@codemoon.com> wrote in message news:Xns92059CFA5F567patcodemooncom@63.105.9.61...
>
> Since overlapped copying of arrays is disallowed it
> might be nice if arrays had built in element insert
> and delete or maybe just a move?
>
> int[10] a;
>
> // Move all the elements of a down over writeing a[0]
> a.move(1,0,a.lenght-1);
>
> a.delete(0,1);
> // Same effect
>
> Maybe an addtional flag to indicate what to do with
> the uncovered elements.
>
> a.delete(0,1,true);
> // Same effect but a[9] = 0 too
>
> a.delete(0,1,false);
> // Same effect but a[8] == a[9]
>


This is what you get when you start adding some
really usefull features to a language...
People just keep coming back for more! :)

--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail

> I'm not completely sure what the second argument is for. Couldn't you
> just have one argument saying which element you want to delete?
> i.e

My guess is that it is the number of elements to delete
        <object>.delete( <array.offset>, <elements.to.delete> )
        <object>.insert( <array.offset>, <object.to.insert> )
Is this correct;  if so it eems a good idea for the standard library
(methods added to the base object class).

I suggest delete shortens the array by 1 item always, or sets the remaining items to NULL,  it would be simple for the user to do other functions such as setting object[8] == object[9],  therefore adding flags to alter its function seems at best inelegant.

C 2002/5/5

OddesE wrote:

> ...
> This is what you get when you start adding some
> really usefull features to a language...
> People just keep coming back for more! :)

Most of the requests seem to be centering on the issue of making it EXPLICIT what the programmer wants the compiler (and the compiled program) to do.  While many requests are to make complex things simpler, most requests seem to try to keep logically simple things simple (clear, obvious, not necessarily easy) in the language, in its implementation, and in its use.

While it may seem like feature-itis, I believe this trend is a Good Thing.  While Wirth tried to do similar things from a minimalist academic top-down perspective (Pascal, Modula, Oberon, etc.), the "D Way" is more bottom-up and inclusive: To take C, dump it's worst sins (but keeping printf() for nostalgic reasons), and adding "C++-like" features without incurring needless complexity in either the language design, its implementation, or its use.

From this perspective, many of the requested D features seem more like "mini patterns" than new or novel language features.  They reflect how real programmers use languages, and the solutions to common situations and problems they keep encountering.

Is it time to look at requested D features within a broader scope?  Some clearly affect the language at its core, while others are "syntactic sugar" for "mini-patterns".  Would it be possible (or desirable) to add a "sugar" layer to D so that "mini-patterns" (or other style rules) could be implemented as compiler plugins (or other meta-layer device)?

I can see many uses for such features, especially if the "plugin" mechanism used content that was in text form, and would need to be part of the general code base (like an include file or a library).  Yes, such plugins would probably look very much like rewrite rules.  But they would NOT be a pre-processor as such, since they would truly represent language extensions, and not mere textual trickery.

I'm no compiler or language designer, but I would love to be able to customize the "higher" features of a language on a per-project basis, and still remain true to the "essence" of the underlying language.  We presently are forced to obtain such features either via administrative means (rules and conventions for people to follow, not compilers), or the use of cumbersome libraries and object hierarchies, or via external custom languages (M4 processors that support a modified C, for example).

So, though the fundamental D language may not support the declaration of infix functions or the overloading of operators, it may be possible to obtain such functionality through the use of compiler plugins ("sugar pills").  Think of such "plugins" as syntactic (or semantic?) libraries.  Or as a way to keep the those needing such features within the D world, and not forcing them to fall back to the "bad old days" of preprocessing.

Or would this turn D into its own YACC?  Or into a "meta-language"?

Just a Sunday evening thought...


-BobC

Hmmm...

s[0..2] = s[1..3];	error, overlapping copy

Is this a compiler error or a runtime problem?

What if I do this...

b = a[1..10];
a[] = b[];

Patrick Down <pat@codemoon.com> wrote in news:Xns9205EEE9EA455patcodemooncom@63.105.9.61:

> 
> Hmmm...
> 
> s[0..2] = s[1..3];     error, overlapping copy
> 
> Is this a compiler error or a runtime problem?
> 
> What if I do this...
> 
> b = a[1..10];
> a[] = b[];
> 

Ok I answered my own question.

void FillArray(inout int[] a)
{
  a.length = 10;
  for(int i=0; i < 10; ++i)
    a[i] = i;
}

int main(char[][] args)
{
  int[] s;
  int[] t;

  printf("Start\n");

  FillArray(s);

  t=s[1..10];
  s[0..9]=t[0..9];

  return 0;
}

Generates:
Start
Error: overlapping array copy