• Benji Smith (19/19) Jun 25 2003 I may be missing something, but I haven't found any information in the D
• Georg Wrede (17/25) Jun 25 2003 This is entirely off hand, so it may clash with a number
• Ilya Minkov (9/17) Jun 25 2003 YUCK!
• Georg Wrede (9/12) Jun 25 2003 I love you, Ilya! You catalyse me to think even further:
• Ilya Minkov (16/17) Jun 25 2003 It's not a very important thinking direction. Walter has some
• Georg Wrede (28/36) Jun 25 2003 Hmm. I think, rather than trying to convince Walter, we
• Fabian Giesen (8/16) Jun 25 2003 That is not only quite conterintuitive and nonobvious (IMHO), it also
• Georg Wrede (7/12) Jun 25 2003 ..
• Julio César Carrascal Urquijo (7/9) Jun 25 2003 Since structs are initialized with the ":" operator associative arrays
• Carlos Santander B. (24/24) Jun 25 2003 "Julio César Carrascal Urquijo" escribió en el
• Helmut Leitner (6/19) Jun 26 2003 I would also prefer this syntax. It's intuitive for the user and
• BenjiSmith (3/22) Jun 26 2003 Add me to the list of people who like this syntax.
• Fabian Giesen (4/6) Jun 26 2003 When you add a new rule to an existing grammar, it doesn't really
• Georg Wrede (20/32) Jun 26 2003 In article , Fabian Giesen
• Richard Krehbiel (20/28) Jun 27 2003 Why not adopt prior art? We are trying to attract C users, after all...
• Fabian Giesen (4/11) Jun 27 2003 Nah, we are trying to attract C/C++ users who are looking for a cleaner
• Richard Krehbiel (9/22) Jun 27 2003 First of all, my example was not correct; it should be
• Fabian Giesen (3/11) Jun 27 2003 Oh, I thought it was a GCC extension. Anyway, my point still holds - tha...
• Walter (3/13) Aug 09 2003 I think it's a good syntax too.
• Charles Sanders (4/20) Aug 09 2003 Got my vote.
• Mike Wynn (12/28) Aug 09 2003 why not the perl/php syntax
• Walter (4/35) Aug 09 2003 if
• John Reimer (8/19) Aug 09 2003 I tend to agree with Walter (how can I go wrong? ;).

Benji Smith <Benji_member pathlink.com> writes:

I may be missing something, but I haven't found any information in the D
documentation for how to declare associative array literal values all at once.

For example, once I've declared an array as:

char[char[]][] myArray;

I can now only add values to that array one at a time, as follows:

myArray["red"] = "ff0000";
myArray["green"] = "00ff00";
myArray["green"] = "0000ff";

What I'd like to be able to do (especially in cases where I have lots of values
to add to the array) would look something like this:

myArray = {

"red" => "ff0000",
"green" => "00ff00",
"blue" => "0000ff"

};

..or something like that. I don't really care about the {} braces or the =>
operator, but I would like something that lets me declare an associative array
literal, just like I can declare a static array using the code:

int[] def = { 1, 2, 3 };

Georg Wrede <Georg_member pathlink.com> writes:

What I'd like to be able to do (especially in cases
where I have lots of values to add to the array)
would look something like this:

myArray = {

"red" => "ff0000",
"green" => "00ff00",
"blue" => "0000ff"

};

This is entirely off hand, so it may clash with a number
of things, but the above made me think about

myArray = {
"red", "ff0000";
"green", "00ff00";
"blue", "0000ff";
}

Of course, old programmers would in any case write this as

red     ff0000
green   00ff00
blue    0000ff

and then make a disposable macro to format the lines to
whatever is needed. The longer the list, the less the
particular format matters.

But there's the issue of clarity and readability, and 
also safety of hand editing the list afterwards, which
speak for (some) simplification of syntax here.

Ilya Minkov <midiclub 8ung.at> writes:

Georg Wrede wrote:
 This is entirely off hand, so it may clash with a number
 of things, but the above made me think about
 
 myArray = {
 "red", "ff0000";
 "green", "00ff00";
 "blue", "0000ff";
 }

YUCK!
why not simple assignment operator?

myArray = {"red" = "ff0000", 	// ...

This kind of syntax could be very handy in conjuction with a specially 
constructed prinf with named arguments. :) Actually good for 
multi-lingual contexts and other similar problems. And again: it should 
be possibe to define them in-line.

-i.

Georg Wrede <Georg_member pathlink.com> writes:

In article <bdcte8$2oig$1 digitaldaemon.com>, Ilya Minkov says...
YUCK!
why not simple assignment operator?

myArray = {"red" = "ff0000", 	// ...

I love you, Ilya! You catalyse me to think even further:

myArray = { "red" "ff0000", "green" "00ff00" ...}

or 

myArray = {
"red" "ff0000",
"green" "00ff00",
..
}

Ilya Minkov <midiclub 8ung.at> writes:

Georg Wrede wrote:
 I love you, Ilya! You catalyse me to think even further:

It's not a very important thinking direction. Walter has some 
experience, and i believe he would figure out very fast what syntax 
would appeal to most people in this case, which seems rather simple.

What is way more important, is to convince him that it makes sense. Just 
as the in-line array definition, which is not implemented yet, and the 
absence of a suitable way to express a single value as a dynamic array 
literal.

It may also be that such things are better postponed to a later version 
(like after 1.0), since really due, announced and already in-spec 
features are not implemented yet, e.g. getters and setters for 
Delphi-like class propertes. I believe the spec mentions something of 
him not having yet figured out a good way to do something (don't really 
remember what) and it may make sense to help him with ideas in this 
direction.

-i.

Georg Wrede <Georg_member pathlink.com> writes:

In article <bdd087$2rl1$1 digitaldaemon.com>, Ilya Minkov

What is way more important, is to convince him that it
makes sense. Just as the in-line array definition, which is
not implemented yet, and the absence of a suitable way to
express a single value as a dynamic array literal.

Hmm. I think, rather than trying to convince Walter, we
should just discuss the issues. "With enough eyes" these
issues tend to become clarified. At that point we all see
the light (which may even shine from a direction none of us
thought initially), and by that time Walter may have decided
to implement the thing, before we get around to asking him.
(Which of course, is not the same thing as it appearing in
the very next version of D!)

It may also be that such things are better postponed to a
later version (like after 1.0), since really due, announced
and already in-spec features are not implemented yet, e.g.
getters and setters for Delphi-like class propertes.

Yes, it is all too easy for us to gallop away conjuring up
creative ideas faster than anyone could ever implement them.

Recently there have been a few ideas about tidying up the
syntax of D, and I must say I am happy with them. I think
there are few things more important than the smoothness and
the coherence of the syntax of a new language. What comes
second is the smoothness and the coherence of the semantics.

Then, after a space, come all the other things. 

I think Walter has done an excellent job so far! (And maybe
I am missing other persons who really deserve credit, too.)

Right now, we are in such an early stage that we can afford
a few ventures into unknown or dubious territory with both
of them, but we have to keep in mind that whatever we do as
trial-and-error, has to be diligently pruned, before it
sticks. 

There are enough grave examples of leaving these in the
language "for just a few minutes too long, and then they
stuck!" (Just read some of the later writings of
Stroustrup, and maybe Kernighan or Ritchie.)

"Fabian Giesen" <rygNO SPAMgmx.net> writes:

 I love you, Ilya! You catalyse me to think even further:

 myArray = { "red" "ff0000", "green" "00ff00" ...}

 or

 myArray = {
 "red" "ff0000",
 "green" "00ff00",
 ..
 }

That is not only quite conterintuitive and nonobvious (IMHO), it also
cannot work with current lexical analysis rules:

"Adjacent strings are concatenated with the ~ operator, or by simple
juxtaposition"
("Lexical" part of the D language spec)

Which means that in your case, the lexical analyzer will collapse that list into
"redff0000","green00ff00" before the parser even sees it.

-fg

Georg Wrede <Georg_member pathlink.com> writes:

In article <bdd2h5$2tt8$1 digitaldaemon.com>, Fabian Giesen
says...
 I love you, Ilya! You catalyse me to think even further:


..
 myArray = { "red" "ff0000", "green" "00ff00", ..  }

That is not only quite conterintuitive and nonobvious
(IMHO), it also cannot work with current lexical analysis
rules:

Hmm. Now I have a choice between saying "I hate you, Ilya!",
or reminding everyone of the disclaimer I wrote 2 messages
ago.   :-)

Anyhow, that is a valid point!

"Julio César Carrascal Urquijo" <adnoctum phreaker.net> writes:

 why not simple assignment operator?

 myArray = {"red" = "ff0000", // ...


Since structs are initialized with the ":" operator associative arrays
should to

char[char[]] myArray = [
    "red": "ff0000",
    "green": "00ff00",
    ...
]

"Carlos Santander B." <carlos8294 msn.com> writes:

"Julio César Carrascal Urquijo" <adnoctum phreaker.net> escribió en el
mensaje news:bddhhf$bqj$1 digitaldaemon.com...
| > why not simple assignment operator?
| >
| > myArray = {"red" = "ff0000", // ...
|
|
| Since structs are initialized with the ":" operator associative arrays
| should to
|
| char[char[]] myArray = [
|     "red": "ff0000",
|     "green": "00ff00",
|     ...
| ]
|
|

I agree

—————————————————————————
Carlos Santander


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.493 / Virus Database: 292 - Release Date: 2003-06-25

Helmut Leitner <leitner hls.via.at> writes:

"Julio César Carrascal Urquijo" wrote:
 
 why not simple assignment operator?

 myArray = {"red" = "ff0000", // ...

 
 Since structs are initialized with the ":" operator associative arrays
 should to
 
 char[char[]] myArray = [
     "red": "ff0000",
     "green": "00ff00",
     ...
 ]

I would also prefer this syntax. It's intuitive for the user and 
it should be easiest to implement.

-- 
Helmut Leitner    leitner hls.via.at
Graz, Austria   www.hls-software.com

BenjiSmith <BenjiSmith_member pathlink.com> writes:

In article <3EFAB509.52286B89 hls.via.at>, Helmut Leitner says...
"Julio César Carrascal Urquijo" wrote:
 
 why not simple assignment operator?

 myArray = {"red" = "ff0000", // ...

 
 Since structs are initialized with the ":" operator associative arrays
 should to
 
 char[char[]] myArray = [
     "red": "ff0000",
     "green": "00ff00",
     ...
 ]

I would also prefer this syntax. It's intuitive for the user and 
it should be easiest to implement.

-- 
Helmut Leitner    leitner hls.via.at
Graz, Austria   www.hls-software.com

Add me to the list of people who like this syntax.

--Benji Smith

"Fabian Giesen" <rygNO SPAMgmx.net> writes:

 I would also prefer this syntax. It's intuitive for the user and
 it should be easiest to implement.

When you add a new rule to an existing grammar, it doesn't really
matter that much which tokens the rule contains, unless they create
heavy ambiguities :)

-fg

Georg Wrede <Georg_member pathlink.com> writes:

In article <bddhhf$bqj$1 digitaldaemon.com>, Julio César
Carrascal Urquijo says...

Since structs are initialized with the ":" operator
associative arrays should to

char[char[]] myArray = [
    "red": "ff0000",
    "green": "00ff00",
    ...
]

In article <bdf708$20ir$1 digitaldaemon.com>, Fabian Giesen
says...

 I would also prefer this syntax. It's intuitive for the
 user and it should be easiest to implement.

When you add a new rule to an existing grammar, it doesn't
really matter that much which tokens the rule contains,
unless they create heavy ambiguities :)

I disagree. 

One could say that it may not matter for the one writing the
compiler, but I doubt even that. But carefully choosing the
tokens is an extremely important task! A sloppy choice of
token early on in the development of a language may not
cause any discomfort for a long time, but eventually it will
get seriously in the way when new tokens are needed for
other things, or when the grammar has to be expanded to
encompass new concepts.

I think the above syntax looks nice, and the fact that
associative arrays are "sort of" related to structs also
speaks for a similar syntax.

But -- I think now is the time for everyone to search for
valid reasons why this is not a good choice. If we don't
find any, then we can assume this syntax with a good degree
of confidence!

Richard Krehbiel <rich kastle.com> writes:

Julio César Carrascal Urquijo wrote:
 Since structs are initialized with the ":" operator associative arrays
 should to
 
 char[char[]] myArray = [
     "red": "ff0000",
     "green": "00ff00",
     ...
 ]

Why not adopt prior art?  We are trying to attract C users, after all...

char[char[]] myArray = {
     ["red"] "ff0000",
     ["green"] "00ff00",
     ...

http://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html

"Designated Initializers

Standard C89 requires the elements of an initializer to appear in a 
fixed order, the same as the order of the elements in the array or 
structure being initialized.

In ISO C99 you can give the elements in any order, specifying the array 
indices or structure field names they apply to, and GNU C allows this as 
an extension in C89 mode as well. This extension is not implemented in 
GNU C++.

To specify an array index, write [index] = before the element value. For 
example,

      int a[6] = { [4] = 29, [2] = 15 };


is equivalent to

      int a[6] = { 0, 0, 15, 0, 29, 0 };"

"Fabian Giesen" <rygNO SPAMgmx.net> writes:

 Why not adopt prior art?  We are trying to attract C users, after
 all...

 char[char[]] myArray = {
      ["red"] "ff0000",
      ["green"] "00ff00",
      ...

 http://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html

Nah, we are trying to attract C/C++ users who are looking for a cleaner
language. GCCs syntax is IMHO quite cumbersome (and probably meant not
to interfere with existing valid source files).

-fg

Richard Krehbiel <rich kastle.com> writes:

Fabian Giesen wrote:
Why not adopt prior art?  We are trying to attract C users, after
all...

char[char[]] myArray = {
     ["red"] "ff0000",
     ["green"] "00ff00",
     ...

http://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html

 
 Nah, we are trying to attract C/C++ users who are looking for a cleaner
 language. GCCs syntax is IMHO quite cumbersome (and probably meant not
 to interfere with existing valid source files).

First of all, my example was not correct; it should be

char[char[]] myArray = {
      ["red"] = "ff0000",
      ["green"] = "00ff00",
      ...

Secondly, it's not GCC's syntax, it's C99 (the four-year-old C standard 
that most compiler vendors haven't bothered to adopt, except GCC which 
is moving rather slowly).

"Fabian Giesen" <rygNO SPAMgmx.net> writes:

 First of all, my example was not correct; it should be

 char[char[]] myArray = {
       ["red"] = "ff0000",
       ["green"] = "00ff00",
       ...

 Secondly, it's not GCC's syntax, it's C99 (the four-year-old C
 standard that most compiler vendors haven't bothered to adopt, except
 GCC which is moving rather slowly).

Oh, I thought it was a GCC extension. Anyway, my point still holds - that
is hardly intuitive or elegant syntax.

-fg

"Walter" <walter digitalmars.com> writes:

"Julio César Carrascal Urquijo" <adnoctum phreaker.net> wrote in message
news:bddhhf$bqj$1 digitaldaemon.com...
 why not simple assignment operator?

 myArray = {"red" = "ff0000", // ...


 Since structs are initialized with the ":" operator associative arrays
 should to

 char[char[]] myArray = [
     "red": "ff0000",
     "green": "00ff00",
     ...
 ]

I think it's a good syntax too.

"Charles Sanders" <sanders-consulting comcast.net> writes:

Got my vote.

Charles

"Walter" <walter digitalmars.com> wrote in message
news:bh38pd$2hhg$1 digitaldaemon.com...
 "Julio César Carrascal Urquijo" <adnoctum phreaker.net> wrote in message
 news:bddhhf$bqj$1 digitaldaemon.com...
 why not simple assignment operator?

 myArray = {"red" = "ff0000", // ...


 Since structs are initialized with the ":" operator associative arrays
 should to

 char[char[]] myArray = [
     "red": "ff0000",
     "green": "00ff00",
     ...
 ]

 I think it's a good syntax too.

"Mike Wynn" <mike.wynn l8night.co.uk> writes:

"Walter" <walter digitalmars.com> wrote in message
news:bh38pd$2hhg$1 digitaldaemon.com...
 "Julio César Carrascal Urquijo" <adnoctum phreaker.net> wrote in message
 news:bddhhf$bqj$1 digitaldaemon.com...
 why not simple assignment operator?

 myArray = {"red" = "ff0000", // ...


 Since structs are initialized with the ":" operator associative arrays
 should to

 char[char[]] myArray = [
     "red": "ff0000",
     "green": "00ff00",
     ...
 ]

 I think it's a good syntax too.

why not the perl/php syntax
(and isn't it char[][key_type] for a assoc array (key of char[]) of arrays
of char ??)
char[][char[]] myArray = [
    "red" => "ff0000",
    "green" =>  "00ff00"
];

I don't object to the  ':' and can see the consistency, seems to me that if
another lang (derived from the same roots) has a syntax for something it
seems better to copy it unmodified (as long as it fits).

"Walter" <walter digitalmars.com> writes:

"Mike Wynn" <mike.wynn l8night.co.uk> wrote in message
news:bh3ggq$2obn$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:bh38pd$2hhg$1 digitaldaemon.com...
 "Julio César Carrascal Urquijo" <adnoctum phreaker.net> wrote in message
 news:bddhhf$bqj$1 digitaldaemon.com...
 why not simple assignment operator?

 myArray = {"red" = "ff0000", // ...


 Since structs are initialized with the ":" operator associative arrays
 should to

 char[char[]] myArray = [
     "red": "ff0000",
     "green": "00ff00",
     ...
 ]

 I think it's a good syntax too.

 why not the perl/php syntax
 (and isn't it char[][key_type] for a assoc array (key of char[]) of arrays
 of char ??)
 char[][char[]] myArray = [
     "red" => "ff0000",
     "green" =>  "00ff00"
 ];

 I don't object to the  ':' and can see the consistency, seems to me that

if
 another lang (derived from the same roots) has a syntax for something it
 seems better to copy it unmodified (as long as it fits).

=> would work, but I think the consistency of : gives it a slight edge.

John Reimer <jjreimer telus.net> writes:

I don't object to the  ':' and can see the consistency, seems to me that

 
 if
 
another lang (derived from the same roots) has a syntax for something it
seems better to copy it unmodified (as long as it fits).

 
 
 => would work, but I think the consistency of : gives it a slight edge.
 
 

I tend to agree with Walter (how can I go wrong? ;).

'=>' does not feel consistant with a language like D, though it does 
look attractive.  It seems like something Ada would have. A colon feels 
more natural and C-like.  It's used in the 'case' and 'goto' statements 
(and ?:).  It just feels more fitting to the associative array context 
where an effect is being related to a cause.

Later,

John