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