Is there any rationale to make language support dynamic arrays natively? We got standart library for that. IMHO C++ has got it almost right with std::vector. Seriously, there's nothing that prevents one from coding a portable and reliable implementation of dynamic array class. Why do we need a direct support from language here?

RTTI, reflection, GOOD compile-time language (not like c++ template metaprogramming) are the areas where language support is absolutely needed. No need to add extra complexity into language.

P.S. God, give us that stacktrace feature someday.

quetzal wrote:
> Is there any rationale to make language support dynamic arrays natively? We got
> standart library for that. IMHO C++ has got it almost right with std::vector.
> Seriously, there's nothing that prevents one from coding a portable and reliable
> implementation of dynamic array class. Why do we need a direct support from
> language here?

I think so.  By making dynamic arrays first class citizens of the language, they work a bit smoother.

Also, D arrays can do a number of things std::vector couldn't hope to, like vector operations.

    int[] a, b;
    a[] += b[]; // increment each element in a by the corresponding element in b

There's also issues like std::string's inescapably second-classness. You can't concatenate two string literals with the + operator because, in the end, they're char*s, not strings.

> RTTI, reflection, GOOD compile-time language (not like c++ template
> metaprogramming) are the areas where language support is absolutely needed. No
> need to add extra complexity into language.

RTTI - almost there.  All we need is TypeInfo for other metatypes, and, ideally, more details.  (associative arrays, function pointer types)

Reflection - at runtime?  It'd be nice, but I could live without.

Compile-time language - A thousand times *YES*.  It wouldn't even be all that hard.  (macros compile to DLLs.  Compiler links with these DLLs at compile-time, calls into them when macros are invoked)  All that's needed is an API. (some shortcut syntax for composing and decomposing syntax trees would be extremely helpful, though)

A good compile-time language would set D far and away as being more powerful than just about any other language of its type. (then we could start laughing at the C++ people in earnest, like the Lisp people have been doing for the past 30 years now)

 -- andy

In article <cbs5ot$281r$1@digitaldaemon.com>, Andy Friesen says...
>Compile-time language - A thousand times *YES*.  It wouldn't even be all that hard.  (macros compile to DLLs.  Compiler links with these DLLs at compile-time, calls into them when macros are invoked)  All that's needed is an API. (some shortcut syntax for composing and decomposing syntax trees would be extremely helpful, though)
>
>A good compile-time language would set D far and away as being more powerful than just about any other language of its type. (then we could start laughing at the C++ people in earnest, like the Lisp people have been doing for the past 30 years now)

Actually, since I've started work on DSP (http://www.dsource.org/projects/dsp/) something along these lines became aparent to me.  DSP performs something similar to what you're proposing.  I suppose you could call it "late compilation and binding", where code is generated, compiled into a dll, bound and executed all within the same running context.

It sounds to me that what you're suggesting is more like a kind of preprocessor that performs these exact same steps.  If it were to keep the D grammar in mind, then I guess it would look like template code, only one step earlier in the compilation process?  Then again, perhaps a more generic  reflection API akin to C#'s reflection.emit. may come in handy for all cases (early, late, runtime, whatever).

#// compile time scripting anyone? (just an idea)
#pragma(compileTime){
#    class Foobar: DAttribute{
#         char[] getKeyword(){ return "foobar"; }
#         void modifyClass(DCompiler.Class classObj){
#              // inserts a method into the class
#              classObj.addMethod("void doFoobar(){ printf(\"hello world\");
}");
#         }
#    }
#    void compileTimeMain(DCompiler comp){
#         comp.addClassAttribute(new Foobar());
#         comp.addStructAttirbute(new Foobar());
#    }
#}

.. and one could just as easily throw in hooks for 'pragma(runTime)' for late compilation of code, provided that DMD's location is somehow provided.

Of course this "example" assumes that D is more or less self-hosting, which it's not yet. That and it may be *too* powerful for the purposes that you had in mind.  A more conscise (and way-more restrictive as to avoid disrupting D's design) grammar is probably what is needed here.

- Pragma

In article <cbs2tm$23e7$1@digitaldaemon.com>, quetzal says...
>
>Is there any rationale to make language support dynamic arrays natively? We got standart library for that. IMHO C++ has got it almost right with std::vector. Seriously, there's nothing that prevents one from coding a portable and reliable implementation of dynamic array class. Why do we need a direct support from language here?

Just to muddy the waters, the last version of the C standard included a primitive dynamic array type.  AFAIK the C++ committe plans to include support for this type in the next iteration of the C++ standard as well.

>RTTI, reflection, GOOD compile-time language (not like c++ template metaprogramming) are the areas where language support is absolutely needed. No need to add extra complexity into language.

I don't think Walter would have built it into D if he thought it were overly complicated :)


Sean

pragma <EricAnderton at yahoo dot com> wrote:
>>A good compile-time language would set D far and away as being more powerful than just about any other language of its type. (then we could start laughing at the C++ people in earnest, like the Lisp people have been doing for the past 30 years now)
> 
> Actually, since I've started work on DSP (http://www.dsource.org/projects/dsp/)
> something along these lines became aparent to me.  DSP performs something
> similar to what you're proposing.  I suppose you could call it "late compilation
> and binding", where code is generated, compiled into a dll, bound and executed
> all within the same running context.
> 
> It sounds to me that what you're suggesting is more like a kind of preprocessor
> that performs these exact same steps.  If it were to keep the D grammar in mind,
> then I guess it would look like template code, only one step earlier in the
> compilation process?  Then again, perhaps a more generic  reflection API akin to
> C#'s reflection.emit. may come in handy for all cases (early, late, runtime,
> whatever).

Sort of, except that the preprocessor is also D. :)

Here's some ideas I was scribbling earlier: <http://andy.tadan.us/d/macro_example.d.html> (warning, not close to being fully baked)

 -- andy

In article <cbsdjs$2k4n$1@digitaldaemon.com>, Andy Friesen says...
>Here's some ideas I was scribbling earlier: <http://andy.tadan.us/d/macro_example.d.html> (warning, not close to being fully baked)

Gotcha.  I like the examples.  Really got me thinking.

I like your approach, but the syntax still felt too much like perl to me. :) IMO, It didn't really feel like D once you entered the 'meta{}' space (but what a neat example).  So I tried meshing our ideas together to see what we get.

Andy, feel free to abuse this post.  ;)

The result is a meta syntax that lets you generate code as string data, which then is wrapped by the compiler to create an extension.  The extension is then invoked to add the appropriate handles to the D parser.  When a meta symbol is parsed, its handle is invoked which in turn generates a substitute expression, method or whatever.

# module etc.macros;
#
# meta{
# 	expression char[] format(...) {
# 		char[] result;
#               // _args is implicit to varadic meta methods
# 		for (DCompiler.MethodArg arg; _args)
# 			result ~= ".format(" ~ arg.toString() ~ ")");
# 		}
# 		result ~= ";";
# 		return(result);
# 	}
# }



The compiler would expand the meta statement into the following to generate an extension .dll. (it could also make a first pass to collect all meta statements into a single dll if need be).


# import std.reflection.compiler; // Reflection to the rescue!
#
# DCompiler.Expression format_metahandle(DCompiler.MethodArg[] _args) {
# 	char[] result;
# 	for (DCompiler.MethodArg arg; args)
# 		result ~= ".format(" ~ arg.toString() ~ ")");
# 	}
# 	result ~= ";";
# 	return(new DCompiler.import std.reflection;(result));
# }
#
# static this{
# 	// inserts "format" into the parse tree, as a public meta
#       // varadic function that returns an expression.
#
#       DCompiler comp = DCompiler.getCompiler();
#       comp.registerMetaVaradicFunction(DCompiler.Expression,"format",
#           DCompiler.Attributes.Public,format_metahandle);
# }

Now the compiler has a chunk of code, in a library, that meshes with the compiler, and modifies the standard parse tree.  This means that any call to 'format' will cause an internal expansion to the macro code.

# import etc.macros; // imports the meta code extensions (macros)
#
# void main(){
# 	int a=0;
# 	int b=1;
# 	int c=2;
#
# 	format(a,b,c); // expands to 'format(a).format(b).format(c)';
# }

- Pragma

There is one aspect of arrays where no library will ever reach native arrays: vectorizing expressions!

In C++, expression templates go some way in that direction, but they are still way of what a good vectorizing compiler can do.

Years ago, this would only have been a matter for high-performance specialists coding for multi-processor number-crunching machines. Nowadays, every PC has plenty of vectorizing capabilities (super-scalar technology, etc.), therefore, high-level language elements really are necessary to allow the compiler to do the work of optimizing the code.


quetzal wrote:

> Is there any rationale to make language support dynamic arrays natively? We got standart library for that. IMHO C++ has got it almost right with std::vector. Seriously, there's nothing that prevents one from coding a portable and reliable implementation of dynamic array class. Why do we need a direct support from language here?
> 
> RTTI, reflection, GOOD compile-time language (not like c++ template metaprogramming) are the areas where language support is absolutely needed. No need to add extra complexity into language.
> 
> P.S. God, give us that stacktrace feature someday.

>I think so.  By making dynamic arrays first class citizens of the language, they work a bit smoother.
But also programmer loses control. He cant change how memory is managed in array, how array is sorted (bloody .sort) and other stuff like that.

>Also, D arrays can do a number of things std::vector couldn't hope to, like vector operations.
>
>     int[] a, b;
>     a[] += b[]; // increment each element in a by the corresponding
>element in b
This is for sure possible in library array implementation.

>There's also issues like std::string's inescapably second-classness. You can't concatenate two string literals with the + operator because, in the end, they're char*s, not strings.
This is not about strings, and this is not C++. D native string support is ok.

>Compile-time language - A thousand times *YES*.  It wouldn't even be all that hard.  (macros compile to DLLs.  Compiler links with these DLLs at compile-time, calls into them when macros are invoked)  All that's needed is an API. (some shortcut syntax for composing and decomposing syntax trees would be extremely helpful, though)

>A good compile-time language would set D far and away as being more powerful than just about any other language of its type. (then we could start laughing at the C++ people in earnest, like the Lisp people have been doing for the past 30 years now)

Agreed. Lisp-like macros should work quite good.

In article <cbso6e$1g4$1@digitaldaemon.com>, Norbert Nemec says...
>
>There is one aspect of arrays where no library will ever reach native arrays: vectorizing expressions!
>
>In C++, expression templates go some way in that direction, but they are still way of what a good vectorizing compiler can do.

>Years ago, this would only have been a matter for high-performance specialists coding for multi-processor number-crunching machines. Nowadays, every PC has plenty of vectorizing capabilities (super-scalar technology, etc.), therefore, high-level language elements really are necessary to allow the compiler to do the work of optimizing the code.

There's nothing that prevents library from implementing dynamic arrays as pointer to data + size (just like language does now). So it can be vectorized just the same way. Also programmer gets control and can fine-tune array implementation for his own needs. I think the way to go is interface based standart library.. if programmer wants to change array behaviour he can just write class that implements given interface and alias it.

In article <cbsqg4$4mt$1@digitaldaemon.com>, quetzal says...
>
>>I think so.  By making dynamic arrays first class citizens of the language, they work a bit smoother.
>
>But also programmer loses control. He cant change how memory is managed in array, how array is sorted (bloody .sort) and other stuff like that.

Only memory allocation is at issue.  It's simple enough to write your own sort routine and pass an array to that.  Sure it's not the default property but so what.


Sean