www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Proposal: struct and array literal syntax

reply "Chris Miller" <chris dprogramming.com> writes:
This is an old idea I had, and also applies to struct initializers which  
now has ambiguity with literal delegates.

Given the following struct:
    struct MyStruct { int foo; int bar; }
can be created with the following proposed syntax:
    MyStruct!{3, 4}
which can be used in initializers and anywhere else MyStruct is expected.

For array initializers, see the following proposed syntax:
    int[]![6, 7, 8, 9]
which creates a dynamic array of 4 int elements.
This as well can be used in initializers and anywhere else such an array  
is expected.

- Chris
Jun 20 2006
next sibling parent Alexander Panek <alexander.panek brainsware.org> writes:
I like the idea very much, as it's like:
"Use MyStruct as a 'template' for this data!{...}"

Chris ftw! (Got my vote ;) )

Regards,
Alex

Chris Miller wrote:
 This is an old idea I had, and also applies to struct initializers which 
 now has ambiguity with literal delegates.
 
 Given the following struct:
    struct MyStruct { int foo; int bar; }
 can be created with the following proposed syntax:
    MyStruct!{3, 4}
 which can be used in initializers and anywhere else MyStruct is expected.
 
 For array initializers, see the following proposed syntax:
    int[]![6, 7, 8, 9]
 which creates a dynamic array of 4 int elements.
 This as well can be used in initializers and anywhere else such an array 
 is expected.
 
 - Chris
Jun 20 2006
prev sibling next sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
Chris Miller wrote:

 This is an old idea I had, and also applies to struct initializers which
 now has ambiguity with literal delegates.
 
 Given the following struct:
     struct MyStruct { int foo; int bar; }
 can be created with the following proposed syntax:
     MyStruct!{3, 4}
 which can be used in initializers and anywhere else MyStruct is expected.
 
 For array initializers, see the following proposed syntax:
     int[]![6, 7, 8, 9]
 which creates a dynamic array of 4 int elements.
 This as well can be used in initializers and anywhere else such an array
 is expected.
 
 - Chris
It is no doubt that we need some good syntax for initalizing structs and arrays, and this might as good as any other suggestion. I like Alex' thoughts on it too. -- Lars Ivar Igesund blog at http://larsivi.net DSource & #D: larsivi
Jun 20 2006
prev sibling next sibling parent Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Chris Miller wrote:
 This is an old idea I had, and also applies to struct initializers which 
 now has ambiguity with literal delegates.
 
 Given the following struct:
    struct MyStruct { int foo; int bar; }
 can be created with the following proposed syntax:
    MyStruct!{3, 4}
 which can be used in initializers and anywhere else MyStruct is expected.
 
 For array initializers, see the following proposed syntax:
    int[]![6, 7, 8, 9]
 which creates a dynamic array of 4 int elements.
 This as well can be used in initializers and anywhere else such an array 
 is expected.
I like it a lot. Readable and functional. -- Tomasz Stachowiak /+ a.k.a. h3r3tic +/
Jun 20 2006
prev sibling next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Chris Miller" <chris dprogramming.com> wrote in message 
news:op.tbft9dffpo9bzi moe...
 This is an old idea I had, and also applies to struct initializers which 
 now has ambiguity with literal delegates.

 Given the following struct:
    struct MyStruct { int foo; int bar; }
 can be created with the following proposed syntax:
    MyStruct!{3, 4}
 which can be used in initializers and anywhere else MyStruct is expected.

 For array initializers, see the following proposed syntax:
    int[]![6, 7, 8, 9]
 which creates a dynamic array of 4 int elements.
 This as well can be used in initializers and anywhere else such an array 
 is expected.
I like it, and it doesn't seem to introduce any ambiguity in the grammar, since if you're instantiating a templated struct, the ! will be immediately followed by a left paren, and not a left brace. And of course you never use ! with arrays. It also solves the problem of parsing the array literal, since int[][6] Would be parsed as a type, while int[]![6] Would be parsed as an array literal.
Jun 20 2006
prev sibling next sibling parent "Boris Wang" <nano.kago hotmail.com> writes:
It's Wonderfull, like it.

"Chris Miller" <chris dprogramming.com> дÈëÏûÏ¢ÐÂÎÅ:op.tbft9dffpo9bzi moe...
 This is an old idea I had, and also applies to struct initializers which 
 now has ambiguity with literal delegates.

 Given the following struct:
    struct MyStruct { int foo; int bar; }
 can be created with the following proposed syntax:
    MyStruct!{3, 4}
 which can be used in initializers and anywhere else MyStruct is expected.

 For array initializers, see the following proposed syntax:
    int[]![6, 7, 8, 9]
 which creates a dynamic array of 4 int elements.
 This as well can be used in initializers and anywhere else such an array 
 is expected.

 - Chris
 
Jun 20 2006
prev sibling parent reply Derek Parnell <derek nomail.afraid.org> writes:
On Tue, 20 Jun 2006 05:35:27 -0400, Chris Miller wrote:

 This is an old idea I had, and also applies to struct initializers which  
 now has ambiguity with literal delegates.
 
 Given the following struct:
     struct MyStruct { int foo; int bar; }
 can be created with the following proposed syntax:
     MyStruct!{3, 4}
 which can be used in initializers and anywhere else MyStruct is expected.
 
 For array initializers, see the following proposed syntax:
     int[]![6, 7, 8, 9]
 which creates a dynamic array of 4 int elements.
 This as well can be used in initializers and anywhere else such an array  
 is expected.
Does it scale? struct BARBAR{ real bar; byte qwe; ulong rty; } ; struct YourStruct { int foo; BARBAR q; } YourStruct!{3, BARBAR!{1.2234, 15, int.max} } Now we try an nested *named* struct... struct MyStruct { int foo; struct BARBAR { int bar; char[] qwe; } BARBAR ety; } MyStruct!{3, .BARBAR!{4, "carrot"} } I tried "MyStruct.BARBAR!" at first but the redundant 'MyStruct' bothered me a bit so I just used a '.' prefix to refer to the current struct context. Now we try an nested *unnamed* struct... struct MyStruct { int foo; struct { int bar; char[] qwe; } ; } MyStruct!{3, .!{4, "carrot"} } Now we try multiple nested *unnamed* structs... struct MyStruct { int foo; struct { int bar; char[] qwe; } ; struct {int why; int bother;} } MyStruct!{3, .!{4, "carrot"}, .!{0,1} } Now an array of structs ... struct MyStruct { int foo; struct BARBAR { int bar; char[] qwe; } BARBAR ety; } MyStruct[]![ MyStruct!{3, .BARBAR!{4, "carrot"} }, MyStruct!{7, .BARBAR!{6, "turnip"} }, MyStruct!{13, .BARBAR!{2, "pea"} }, MyStruct!{42, .BARBAR!{0, "bean"} }, ] Now a 'rectangular' array ... int[][]![ int[]![1,2,3,4], int[]![5,6,7,8], int[]![9,0,1,2], int[]![3,4,5,6], ] Hmmm ... appears to do okay. A great idea, Chris. -- Derek (skype: derek.j.parnell) Melbourne, Australia "Down with mediocrity!" 21/06/2006 12:11:58 PM
Jun 20 2006
parent reply "Andrei Khropov" <andkhropov nospam_mtu-net.ru> writes:
Derek Parnell wrote:

 Now a 'rectangular' array ...
 
   int[][]![
       int[]![1,2,3,4],
       int[]![5,6,7,8],
       int[]![9,0,1,2],
       int[]![3,4,5,6],
     ]
 
 Hmmm ... appears to do okay. 
Well, in the last case inner int[]! s appear to be a syntactic overhead. I'm still waiting for better handling of multidimensional rectangular arrays (not less effective "jagged"). -- AKhropov
Jun 21 2006
next sibling parent reply "Boris Wang" <nano.kago hotmail.com> writes:
"Andrei Khropov" <andkhropov nospam_mtu-net.ru>
дÈëÏûÏ¢ÐÂÎÅ:e7b7fb$277d$1 digitaldaemon.com...
 Derek Parnell wrote:

 Now a 'rectangular' array ...

   int[][]![
       int[]![1,2,3,4],
       int[]![5,6,7,8],
       int[]![9,0,1,2],
       int[]![3,4,5,6],
     ]

 Hmmm ... appears to do okay.
Well, in the last case inner int[]! s appear to be a syntactic overhead. I'm still waiting for better handling of multidimensional rectangular arrays (not less effective "jagged"). -- AKhropov
May be: int[][]![ ![1,2,3,4], ![5,6,7,8], ![9,0,1,2], ![3,4,5,6], ] the type of ![1,2,3,4] can be inferred.
Jun 23 2006
next sibling parent reply "Andrei Khropov" <andkhropov nospam_mtu-net.ru> writes:
Boris Wang wrote:

 
 "Andrei Khropov" <andkhropov nospam_mtu-net.ru>
 P4HkO{O"PBNE:e7b7fb$277d$1 digitaldaemon.com...
 Derek Parnell wrote:
 
 Now a 'rectangular' array ...
 
  int[][]![
      int[]![1,2,3,4],
      int[]![5,6,7,8],
      int[]![9,0,1,2],
      int[]![3,4,5,6],
    ]
 
 Hmmm ... appears to do okay.
Well, in the last case inner int[]! s appear to be a syntactic overhead. I'm still waiting for better handling of multidimensional rectangular arrays (not less effective "jagged"). -- AKhropov
May be: int[][]![ ![1,2,3,4], ![5,6,7,8], ![9,0,1,2], ![3,4,5,6], ] the type of ![1,2,3,4] can be inferred.
In the spirit of the recent type inference extensions the outer type should be inferred also: just ![ ![1,2,3,4], ![5,6,7,8], ![9,0,1,2], ![3,4,5,6] ] -- AKhropov
Jun 23 2006
parent reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Andrei Khropov wrote:
 Boris Wang wrote:
 
 "Andrei Khropov" <andkhropov nospam_mtu-net.ru>
 P4HkO{O"PBNE:e7b7fb$277d$1 digitaldaemon.com...
 Derek Parnell wrote:

 Now a 'rectangular' array ...

  int[][]![
      int[]![1,2,3,4],
      int[]![5,6,7,8],
      int[]![9,0,1,2],
      int[]![3,4,5,6],
    ]

 Hmmm ... appears to do okay.
Well, in the last case inner int[]! s appear to be a syntactic overhead. I'm still waiting for better handling of multidimensional rectangular arrays (not less effective "jagged"). -- AKhropov
May be: int[][]![ ![1,2,3,4], ![5,6,7,8], ![9,0,1,2], ![3,4,5,6], ] the type of ![1,2,3,4] can be inferred.
In the spirit of the recent type inference extensions the outer type should be inferred also: just ![ ![1,2,3,4], ![5,6,7,8], ![9,0,1,2], ![3,4,5,6] ]
All this talk makes kinda wish that the ascii tables (and consequently the standard keyboards as well) had one more set of brackets, like the angle brackets for example (http://en.wikipedia.org/wiki/Bracket#Angle_brackets_or_chevrons_.E2.8C A9.C2.A0.E2.8C.AA), used for tuple notation in math. "〈1, 2〉" A comparison: <1, 2> ‹1, 2› «1, 2» 〈1, 2〉 // Why do these take two spaces? 《1, 2》 -- Bruno Medeiros - CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jun 23 2006
parent reply Daniel Keep <daniel.keep.list gmail.com> writes:
Bruno Medeiros wrote:
 Andrei Khropov wrote:
 
 Boris Wang wrote:

 "Andrei Khropov" <andkhropov nospam_mtu-net.ru>
 P4HkO{O"PBNE:e7b7fb$277d$1 digitaldaemon.com...

 Derek Parnell wrote:

 Now a 'rectangular' array ...

  int[][]![
      int[]![1,2,3,4],
      int[]![5,6,7,8],
      int[]![9,0,1,2],
      int[]![3,4,5,6],
    ]

 Hmmm ... appears to do okay.
Well, in the last case inner int[]! s appear to be a syntactic overhead. I'm still waiting for better handling of multidimensional rectangular arrays (not less effective "jagged"). -- AKhropov
May be: int[][]![ ![1,2,3,4], ![5,6,7,8], ![9,0,1,2], ![3,4,5,6], ] the type of ![1,2,3,4] can be inferred.
In the spirit of the recent type inference extensions the outer type should be inferred also: just ![ ![1,2,3,4], ![5,6,7,8], ![9,0,1,2], ![3,4,5,6] ]
All this talk makes kinda wish that the ascii tables (and consequently the standard keyboards as well) had one more set of brackets, like the angle brackets for example (http://en.wikipedia.org/wiki/Bracket#Angle_brackets_or_chevrons_.E2.8C A9.C2.A0.E2.8C.AA), used for tuple notation in math. "〈1, 2〉" A comparison: <1, 2> ‹1, 2› «1, 2» 〈1, 2〉 // Why do these take two spaces? 《1, 2》
AFAIK, they take spaces because they are "fullwidth" asian characters. I think it comes from most western glyphs being vertical rectangles, and most asian glyphs being square-ish. So they make the characters twice as wide :) As for more brackets: hell yeah. I think there are three things that really limit programming languages: lack of special characters that will reliably be on many computers, lack of special characters on our keyboards, and programming language's fixation on using special characters :P I think that what would help is adding these features with whatever syntax we can muster, and add alises for these using extended characters where we can find them. Maybe if we start supporting more than basic ASCII now, someday we'll get better keyboards :) -- Daniel
Jun 23 2006
next sibling parent reply "Andrei Khropov" <andkhropov nospam_mtu-net.ru> writes:
Daniel Keep wrote:

 All this talk makes kinda wish that the ascii tables (and consequently  the
 standard keyboards as well) had one more set of brackets, like the  angle
 brackets for example
 (http://en.wikipedia.org/wiki/Bracket#Angle_brackets_or_chevrons_.E2.8C.A9.C
 2.A0.E2.8C.AA),  used for tuple notation in math. "〈1, 2〉"
 
 A comparison:
 
 <1, 2>
 ‹1, 2›
 «1, 2»
 〈1, 2〉 // Why do these take two spaces?
 《1, 2》
 
AFAIK, they take spaces because they are "fullwidth" asian characters. I think it comes from most western glyphs being vertical rectangles, and most asian glyphs being square-ish. So they make the characters twice as wide :) As for more brackets: hell yeah. I think there are three things that really limit programming languages: lack of special characters that will reliably be on many computers, lack of special characters on our keyboards, and programming language's fixation on using special characters :P I think that what would help is adding these features with whatever syntax we can muster, and add alises for these using extended characters where we can find them. Maybe if we start supporting more than basic ASCII now, someday we'll get better keyboards :)
Well, I think Unicode is not the problem. The biggest problem is our limited keyboards really. unused in D yet. Maybe put 'em to some use? :-) P.S. And, yeah, I want tuples in D and lists too. -- AKhropov
Jun 24 2006
parent reply "Chris Miller" <chris dprogramming.com> writes:
On Sat, 24 Jun 2006 17:33:59 -0400, Andrei Khropov  
<andkhropov nospam_mtu-net.ru> wrote:

 Daniel Keep wrote:

 All this talk makes kinda wish that the ascii tables (and  
consequently the
 standard keyboards as well) had one more set of brackets, like the   
angle
 brackets for example
  
(http://en.wikipedia.org/wiki/Bracket#Angle_brackets_or_chevrons_.E2.8C.A9.C
 2.A0.E2.8C.AA),  used for tuple notation in math. "〈1, 2〉"

 A comparison:

 <1, 2>
 ‹1, 2›
 «1, 2»
 〈1, 2〉 // Why do these take two spaces?
 《1, 2》
AFAIK, they take spaces because they are "fullwidth" asian characters. I think it comes from most western glyphs being vertical rectangles, and most asian glyphs being square-ish. So they make the characters twice as wide :) As for more brackets: hell yeah. I think there are three things that really limit programming languages: lack of special characters that will reliably be on many computers, lack of special characters on our keyboards, and programming language's fixation on using special characters :P I think that what would help is adding these features with whatever syntax we can muster, and add alises for these using extended characters where we can find them. Maybe if we start supporting more than basic ASCII now, someday we'll get better keyboards :)
Well, I think Unicode is not the problem. The biggest problem is our limited keyboards really. are unused in D yet. Maybe put 'em to some use? :-) P.S. And, yeah, I want tuples in D and lists too.
` is for wysiwyg string literals; \ is for escaped string literals; is not on my keyboard.
Jun 24 2006
parent "Andrei Khropov" <andkhropov nospam_mtu-net.ru> writes:
Chris Miller wrote:

 ` is for wysiwyg string literals; \ is for escaped string literals;
Oh, I'm sorry for my ignorance I just haven't used them.
   is
 unused;
Well, after your clarification this seems to be the only unused character available.

Yep, I missed that too. -- AKhropov
Jun 25 2006
prev sibling parent Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Daniel Keep wrote:
 
 AFAIK, they take spaces because they are "fullwidth" asian characters. I 
 think it comes from most western glyphs being vertical rectangles, and 
 most asian glyphs being square-ish.  So they make the characters twice 
 as wide :)
 
You sure? I mean, they are used in mathematical notation as well, so I wonder if that's all to it (kinda lazy to get check it out more now).
 As for more brackets: hell yeah.  I think there are three things that 
 really limit programming languages: lack of special characters that will 
 reliably be on many computers, lack of special characters on our 
 keyboards, and programming language's fixation on using special 
 characters :P
 
 I think that what would help is adding these features with whatever 
 syntax we can muster, and add alises for these using extended characters 
 where we can find them.
 
 Maybe if we start supporting more than basic ASCII now, someday we'll 
 get better keyboards :)
 
     -- Daniel
I don't think we need other keyboards for that. One can use existing keyboards and extend it's key layout by adding new characters when certain keys are pressed with the AltGr modifier. For instance, angle brackets could be available when the US-layout keys for '<' or '>' were pressed together with AltGr. Nicely enough, almost all Roman_script keyboard layouts (http://en.wikipedia.org/wiki/Keyboard_layout#Keyboard_layouts_for_Roman_script) have that key entries available. (The exceptions are Canadian French,Canadian Multilingual Standard and US-International) -- Bruno Medeiros - CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jun 25 2006
prev sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Boris Wang wrote:
<snip>
 May be:
 
  int[][]![
      ![1,2,3,4],
      ![5,6,7,8],
      ![9,0,1,2],
      ![3,4,5,6],
  ]
 
 the type of ![1,2,3,4] can be inferred. 
To me, using '!' in the prefix position like this is just asking for confusion (potentially from both human-readability and parsing POVs) with the NOT operator. How about the contents of an array literal following the initialiser syntax? Then it would be int[][]![ [1,2,3,4], [5,6,7,8], [9,0,1,2], [3,4,5,6] ] Of course, this would be syntactic sugar for the aforementioned int[][]![ int[]![1,2,3,4], int[]![5,6,7,8], int[]![9,0,1,2], int[]![3,4,5,6] ] Indeed, ages ago I pointed out that the inability to initialise non-static arrays seems to be an arbitrary restriction. http://www.digitalmars.com/d/archives/26695.html One possible approach to lifting this restrictions is to treat an initialiser on a non-static array as syntactic sugar for an array literal. But on the whole, I quite like the int[]! syntax. We could make it work for associative array literals as well, and at the same time make it possible to initialise such things. Stewart.
Jun 26 2006
prev sibling parent BCS <BCS pathlink.com> writes:
Andrei Khropov wrote:
 Derek Parnell wrote:
 
 
Now a 'rectangular' array ...

  int[][]![
      int[]![1,2,3,4],
      int[]![5,6,7,8],
      int[]![9,0,1,2],
      int[]![3,4,5,6],
    ]

Hmmm ... appears to do okay. 
Well, in the last case inner int[]! s appear to be a syntactic overhead. I'm still waiting for better handling of multidimensional rectangular arrays (not less effective "jagged").
As to the non-jagged issue, how about some sort of wild card syntax like: // legal int[$][$] = ![ ![1,2,3], ![4,5,6], ![7,8,9]]; // illegal int[$][$] = ![ ![1], ![4,5], ![7,8,9]]; the "$" would indicate that the length of each sub array must be the same. Read it something like "an array of ints that is some length by some length."
Jun 23 2006