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."

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

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

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.
I have made a little inspection and found that some symbols (`,\,@,#,№) are
unused in D yet. Maybe put 'em to some use? :-)

P.S. And, yeah, I want tuples in D and lists too.

-- 
AKhropov

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.
> I have made a little inspection and found that some symbols (`,\,@,#,№) 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 unused; # is for special token sequences; and I don't know about № - it's not on my keyboard.

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.

> # is for special token sequences;
Yep, I missed that too.

-- 
AKhropov

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

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.