View mode: basic / threaded / horizontal-split · Log in · Help
April 27, 2007
Re: DMD 1.014 release
Frits van Bommel escribió:
> Tom wrote:
>> Walter Bright escribió:
>>> Sports associative array literals, and struct literals. This enables 
>>> compile time function execution to work with symbol tables (AA's) and 
>>> user defined types.
>>>
>>> http://www.digitalmars.com/d/changelog.html
>>>
>>> http://ftp.digitalmars.com/dmd.1.014.zip
>>
>> Bugzilla 1189: Reverse the titles on web pages
>>
>> Perhaps you miss to reverse the titles on phobos docs?
> 
> As mentioned before, the new docs don't seem to have been uploaded to 
> the site yet. The docs in the zip are fixed (I just checked).

Oh, sorry, I see.
April 27, 2007
Re: DMD 1.014 release
BCS wrote:
> Don Clugston wrote:
>>
>> In practice, you _can_ have initialized static AAs, provided they are 
>> read-only (which is probably the main time you want to supply 
>> initializers). The declaration syntax for a read-only AA slightly 
>> lacks syntactic sugar, but the syntax for usage is perfect:
>>
>> char[][uint] symTable() { return [2u:"he",4:"ho",6:"hi"]; }
>>
>> void main()
>> {
>>     for (int k=1; k<=6; ++k) {
>>         if ((k&1)==0) printf("%.*s\n", symTable[k]);
>>     }
>> }
>>
> 
> function call overhead on every use? Ouch!!
> 
> I'd rather go with
> 
> char[][uint] symTable; static this(){symTable=[2u:"he",4:"ho",6:"hi"];}

Which reminds me of an ancient enhancement request idea: allow the presence of /multiple/ 
static constructors within a scope (module or class), which are later concatenated into 
one function body by the compiler.  Then your above item becomes just one line, rather 
than a declaration in one place, and an initialization in the midst of a possibly longer 
function somewhere else entirely within the source file.  (I like keeping the number of 
lines that have to be hit for changes small... can you tell?  It makes it less likely I or 
someone else will make a silly mistake later.)

-- Chris Nicholson-Sauls
April 27, 2007
Re: DMD 1.014 release
BCS wrote:
> This is what I'm waiting for:
> 
> #!/usr/bin/dmd -c -o- > your_code.o
> 
> import comp.time.comp;
> 
> pragma(msg, D2ELF!(import("your_code.d"));

Must ... resist... the temptation... arrghth I love it! :D <3 *fluffles* 
erm... I mean.. don't do this! This is too perverted! *hides*



-- 
Tomasz Stachowiak
http://h3.team0xf.com/
h3/h3r3tic on #D freenode
April 27, 2007
Re: DMD 1.014 release
renoX wrote:
> - array initialisation count elements for dynamic arrays but not for 
> array with fixed length.


I'm sure it's been suggested before, but would this work?

int[3] = [1, 2, 3];  // explicit length

int[$] = [1, 2, 3];  // compiler infers length
April 29, 2007
Re: DMD 1.014 release
F wrote:
>  Why the release date is shown as Apr 20, 2007 (on the changelog web page)? A typo?
> 
> 
> Walter Bright Wrote:
> 
>> Sports associative array literals, and struct literals. This enables 
>> compile time function execution to work with symbol tables (AA's) and 
>> user defined types.
>>
>> http://www.digitalmars.com/d/changelog.html
>>
>> http://ftp.digitalmars.com/dmd.1.014.zip
> 

Walter's Freudian slip :) secret message to those that understand...
April 30, 2007
Re: DMD 1.014 release
"Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message 
news:f0svs3$1u13$1@digitalmars.com...
> Is there any ambiguity to the syntax:
>
> S s = S{a : 1, c : 3, b : 2};
>
> That is, just an Ident followed by a static struct initializer?

Do you have _any_ thoughts on this?
May 01, 2007
Re: DMD 1.014 release (struct literal syntax and keywords)
Jarrett Billingsley wrote:
> "Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message 
> news:f0svs3$1u13$1@digitalmars.com...
>> Is there any ambiguity to the syntax:
>>
>> S s = S{a : 1, c : 3, b : 2};
>>
>> That is, just an Ident followed by a static struct initializer?
> 
> Do you have _any_ thoughts on this? 
> 
> 

I like your suggestion better.  Walter's way takes us back to the 
error-prone, fragile, mystery-meat way of constructing structs that they 
tossed out in C99.  Ok, not "tossed out" but "provided an alternative to."

Walter's way, however, gives you a way to transition from quick and 
dirty usage like
  struct Coord{ float x; float y; }
  func(Coord(xval,yval));
to something more complex via static opCall.  Say you realize you should 
have been using polar coordinates internally, then you can just add an 
opCall and some properties to do that:

  struct Coord{
    float r; float theta;
    float x() { return r*cos(theta); }
    float y() { return r*sin(theta); }
    static Coord opCall(float x, float y) {
         Coord it; with(it) {
           r = hypot(x,y);
           theta = atan2(y,x);
         }
         return it;
  }

  // This still works
  func(Coord(xval,yval));

Not extremely realistic, because if you have a polar coord struct 
probably you'll want the (float,float) opCall to take (r,theta) instead 
of (x,y), but well, the above is the best defense of Walter's approach I 
could come up with.

Keyword Arguments:

On the other hand, it would be potentially very cool if we could write 
member function to override the behavior of S s = S{a:1,c:3,b:2} as 
well.  But we need functions with keyword arguments for that to work.  I 
think we're not so far away.  If you treat a keyword function as 
functions of one anonymous struct then you're pretty much there.  For 
instance this:

   void a_keyword_func({int a=10, int b=4, int c=20}) {. . .}

   a_keyword_func(c:10, a:1);

could be treated as

   struct _S { int a=10; int b=4; int c=20; }
   a_keyword_func( _S ) { . . . }

   a_keyword_func( _S{c:10, a:1} );  //using your struct literals

Not sure what to do about out/inout/ref args.  That's the kicker I supposed.
But I think this approach to keyword args differs from the previous 
proposals by myself and others in that it makes keyword functions 
different from regular functions.  That means the programmer has to 
decide whether to make it a keyword function or not, but it also means 
fewer backwards compatibility issues.

The times I've seen keyword args suggested the rejoinder was always -- 
if you have so many arguments then just make a struct to hold them all. 
 Well that's exactly what this does, except it doesn't require the 
library desiger to litter his code and namespaces with structs that only 
serve the purpose of calling one function, and it doesn't make the user 
think about creating useless one-time structs to call that function 
either.  It's still what happens under the hood, just no one has to 
think about it.

I think the desire to limit the scope of such an argument struct to the 
function that requires it, is very similar to the desire to have inner 
functions.  The goal is to keep information specific to a particular 
function local to that function.  In the case of inner functions that 
means a function is created with a specially mangled name.  In the case 
of these automatic parameter structs for keyword arguments, you'd have a 
specially mangled struct name automatically generated.

--bb
May 01, 2007
Re: DMD 1.014 release (struct literal syntax and keywords)
"Bill Baxter" <dnewsgroup@billbaxter.com> wrote in message 
news:f161g5$2kno$1@digitalmars.com...
> I like your suggestion better.  Walter's way takes us back to the 
> error-prone, fragile, mystery-meat way of constructing structs that they 
> tossed out in C99.  Ok, not "tossed out" but "provided an alternative to."
>
> Walter's way, however, gives you a way to transition from quick and dirty 
> usage like
>   struct Coord{ float x; float y; }
>   func(Coord(xval,yval));
> to something more complex via static opCall.

I thought about that too.  It just doesn't seem like a very compelling 
argument, especially considering that the language already has a perfectly 
good syntax for static struct literals.

> If you treat a keyword function as functions of one anonymous struct then 
> you're pretty much there.  For instance this:
>
>    void a_keyword_func({int a=10, int b=4, int c=20}) {. . .}
>
>    a_keyword_func(c:10, a:1);
>
> could be treated as
>
>    struct _S { int a=10; int b=4; int c=20; }
>    a_keyword_func( _S ) { . . . }
>
>    a_keyword_func( _S{c:10, a:1} );  //using your struct literals

I like the idea.  It also seems relatively unambiguous to parse.  Any colon 
in the param list of a call would signal use of names parameters, and the 
compiler would be able to check the function for any named params it has.
May 01, 2007
D Doc diffs (Re: DMD 1.014 release)
Is anyone interested in diffs of the D Docs between releases? I usually 
do that on all releases anyway, since I want to keep up with the changes 
but some things don't go to the changelog, so I diff the docs and remove 
(most of) the HTML or otherwise redundant changes.
Here's the diff for 1.014 for example.


-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
May 01, 2007
Re: DMD 1.014 release
Walter Bright wrote:
> Sports associative array literals, and struct literals. This enables 
> compile time function execution to work with symbol tables (AA's) and 
> user defined types.
> 
> http://www.digitalmars.com/d/changelog.html
> 
> http://ftp.digitalmars.com/dmd.1.014.zip

"If any of the keys or values in the KeyValuePairs are an 
ExpressionTuple, then the elements of the ExpressionTuple are inserted 
as arguments in place of the tuple. "

Can you give an example of that? I was thinking of something like:
  int[char[]] f;
  f = [ Tuple!(["one"[]:1, "two":2]) ];
but it didn't work.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
1 2 3 4
Top | Discussion index | About this forum | D home