Anders F Björklund wrote:
> John Reimer wrote:
> 
>> This has been brought up before.  Automation of the task is as simple as creating a tool that does the stripping for you.  In fact I believe the library creation tool "digc" by Burton Radons has been able to do this for couple of years.  While it may be nice to have such a feature as part of the compiler, it's been argued that such a task is not strictly within the problem domain of the compiler.
> 
> 
> A demangler would be nice too, i.e. something that could convert
> "_D5hello5helloFAaZv" into "module hello; void hello(char[] _a);"
> 
> Wonder if something like that has already been done for debugging ?
> 
> --anders

Not that I'm aware of.  I agree that such a feature would be useful.

In article <cp75n8$28ps$2@digitaldaemon.com>, =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
>
>John Reimer wrote:
>
>> I believe the we're nearing the time when such tools need to surface to make D development go more smoothly and be more attractive to people.  We also need a well-designed GUI and an IDE, too.  :-)  It seems work is already in progress in these areas, though.
>
>Another thing that is needed is a documentation generator, but Doxygen kinda works and Ant is working on a new D tool. Otherwise one ends up with out-of-date documentation like http://www.digitalmars.com/d/phobos.html (sorry, Walter)

Ant has taken on that project and has provided preview here:

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/13302

>Javadoc sets an example for such API documentation, IMHO. http://java.sun.com/j2se/javadoc/ (but Doxygen is not bad)
>
>>> I guess the moral is that we should all do Open Source :-)
>> 
>> Opensource is what started the ball rolling.  :-)
>
>At least for me, since none of the Digital Mars compilers works on the platforms that I am using (Mac OS X, Linux PPC)
>
>--anders

Anders F Björklund wrote:
> John Reimer wrote:
> 
>> I believe the we're nearing the time when such tools need to surface to make D development go more smoothly and be more attractive to people.  We also need a well-designed GUI and an IDE, too.  :-)  It seems work is already in progress in these areas, though.
> 
> 
> Another thing that is needed is a documentation generator,
> but Doxygen kinda works and Ant is working on a new D tool.
> Otherwise one ends up with out-of-date documentation like
> http://www.digitalmars.com/d/phobos.html (sorry, Walter)
> 
> Javadoc sets an example for such API documentation, IMHO.
> http://java.sun.com/j2se/javadoc/ (but Doxygen is not bad)

That and proper debugging on linux.  Hunting down errors on linux, whether threading or phobos related, can be a real pain.  As the compiler matures, perhaps the need will not be as great.


>>> I guess the moral is that we should all do Open Source :-)
>>
>>
>> Opensource is what started the ball rolling.  :-)
> 
> 
> At least for me, since none of the Digital Mars compilers
> works on the platforms that I am using (Mac OS X, Linux PPC)
> 
> --anders


Ouch! Well, I love macs, but don't have one.  I hope gdc gets working smoothly on the powerpc soon.

Later,

John

Thanks for the idea :P

I've just been playing around with D name mangling, and I reckon it would be possible to build a library --> d interface generator.

The catch?  So far, I only know how to get it working under Linux :P

Anyway, I'll give it a shot over the next few days, and see what I can come up with.  Should be interesting.

	-- Daniel

Anders F Björklund wrote:
> John Reimer wrote:
> 
>> This has been brought up before.  Automation of the task is as simple as creating a tool that does the stripping for you.  In fact I believe the library creation tool "digc" by Burton Radons has been able to do this for couple of years.  While it may be nice to have such a feature as part of the compiler, it's been argued that such a task is not strictly within the problem domain of the compiler.
> 
> 
> A demangler would be nice too, i.e. something that could convert
> "_D5hello5helloFAaZv" into "module hello; void hello(char[] _a);"
> 
> Wonder if something like that has already been done for debugging ?
> 
> --anders

Andrei Alexandrescu Wrote:
>
> There are a few principles at work here that I consider universal, plus some others that I consider a matter of preference. One principle that I consider universal is that a language should minimize the number of syntactic constructs that are semantically and/or pragmatically meaningless. Another that I also consider universal is that the more frequently-used constructs should be given syntactic priority over the less-used constructs, particularly when the latter are also at risk of breaking the first principle.
> 
> C's handling of function names royally breaks both of these principles. It makes
> 
> func;
> 
> a valid syntactic construct with inoperant semantics and consequently useless pragmatics. Moreover,
> 
> a = func;
> gunc(func);
> 
> both have valid syntax and semantics, but the pragmatics are the infrequently-used manipulations of function addresses in higher-order programming, something C is not quite adept at to start with. (So that makes the state of affairs all the more ironic.)
> 
> C++ builds on that irony by making
> 
> obj.func;
> b = obj.func;
> gunc(obj.func);
> 
> still syntactically valid but one order of magnitude less useful because they traffic in references to member functions, a contraption that is defined sufficiently bad and inefficient to be useless in practice, and also of a type with a syntax I'd be glad to remove from my memory. (How many here _do_ know that type's syntax and have the scars to prove it?)
> 
> So thinking of function call syntax has quite a few deep underpinnings. We shouldn't confuse habit acquired from C and C++ with some fundamental truth or just a matter of preference that can't be decided on an objective basis.
> 
> One issue with today's function call syntax in D is that people can write code that is of dubious expressiveness:
> 
> writeln = 3;
> 
> Properties would solve this problem by confining assignment syntax to themselves only.
> 
> 
> Andrei

I didn't mean to suggest we need to have pointer-to-member-function as in c++.
I totally agree about all the problems you point out in C/C++ and I don't want to
import all of those problems to D.
you talk about how C is not quite adept at infrequently-used manipulations of
function addresses in higher-order programming but this is I think not relevant to D
since D has better facilities (delegates) and the use of those will be more frequent
since D tries to incorporate more FP (pure functions, etc)
also, there is the problem you stated above with allowing "writeln = 3;"

what would you think about the following scheme:

1. requiring parens to represent function invocation
2. using explicit property syntax similar to my previous post
3. the function name would be consistent with other identifiers and functions could be
    treated just like any other object.
    -  func.something; // refers to a property of the function itself.
    -  func();  // calling func
    -  func.something(); // calling method of func.
4.  function names represent delegates instead of function pointers,
     just like D arrays are "fat" structs and not pointers.
5. plain old C function pointers can be implicitly cast to delegates.
6. func.ptr will return the C style function pointer (just like with arrays).