Re: Need runtime reflection?

[Paulo Pinto]

On Tuesday, 17 July 2012 at 15:08:18 UTC, David Piepgrass wrote:
I want to imitate golang's interface in D, to study D's 
template. I wrote

some code: https://gist.github.com/3123593

Now we can write code like golang:
--
interface IFoo {
   void foo(int a, string b, float c);
}

struct Foo {
   void foo(int a, string b, float c) {
   writeln("Foo.foo: ", a, ", ", b, ", ", c);
   }
}

struct FooFoo {
   void foo(int a, string b, float c) {
   writeln("FooFoo.foo: ", a, ", ", b, ", ", c);
   }
}

GoInterface!(IFoo) f = new Foo;
f.foo(3, "abc", 2.2);

f = new FooFoo;
f.foo(5, "def", 7.7);
--

It is also very naive, does not support some features, like 
out/ref
parameters, free functions *[1]* and so on. The biggest 
problem is downcast

not supported. In golang, we can write code like*[2]*:
--
var p IWriter = NewB(10)
p2, ok := p.(IReadWriter)
--

Seems [p.(IReadWriter)] dynamically build a virtual table 
*[3]*，because the
type of "p" is IWriter, it is *smaller* than IReadWriter, the 
cast

operation must search methods and build vtbl at run time.

In D, GoInterface(T).opAssign!(V)(V v) can build a rich 
runtime information
to *V* if we need. But if *V* is interface or base class, the 
type
information not complete. So, seems like I need runtime 
reflection? and how
can I do this in D? I did not find any useful information in 
the TypeInfo*.


--
[1] free functions support, e.g.
--
interface IFoo {
   void foo(int a, string b, float c);
}
void foo(int self, int a, string b, float c) {
   writefln("...");
}

GoInterface!(int) p = 1;
p.foo(4, "ccc", 6.6);
--
In theory no problem.


I, too, was enamored with Go Interfaces and implemented them 
for .NET:


http://www.codeproject.com/Articles/87991/Dynamic-interfaces-in-any-NET-language



Interesting article, but why not just make use of "dynamic" 
interfaces?


--
Paulo

Re: K&R-style variadic functions

[Paulo Pinto]

On Tuesday, 17 July 2012 at 18:37:54 UTC, H. S. Teoh wrote:
I guess you predate me. ;-) When I started learning C, it was 
already in
the ANSI syntax, though there were enough K&R style code 
floating around
that I've at least _seen_ K&R syntax. I'm guessing nowadays 
most people

don't even know what K&R syntax is.


T


I started coding in C around 1993 with Turbo C 2.0, but was 
exposed
to K&R code from different sources, specially when we needed to 
make use of a System V based system for some OS classes.


Plus as a language geek, I had the pleasure to have access a lots 
of books and papers since the late 70's in our university library.


That is a reason why I tend to have a good background in what 
languages introduced which paradigm.


Maybe it is the historian in me. :)

--
Paulo

Re: Need runtime reflection?

[lijie]

On Tue, Jul 17, 2012 at 11:08 PM, David Piepgrass wrote:
>
> I, too, was enamored with Go Interfaces and implemented them for .NET:
>
> http://www.codeproject.com/**Articles/87991/Dynamic-**
> interfaces-in-any-NET-language


Interesting, good article and project, thanks.

And I wasn't the only one; later, someone else published another library
> for .NET with the exact same goal. This is definitely a feature I would
> want to see in D, preferably as a first-class feature, although sadly that
> would break any code that relies on ISomething being pointer-sized; Go uses
> fat pointers, and we use a thin-pointer implementation in .NET but it's
> inefficient (as every cast creates a heap-allocated wrapper, and
> double-indirection is needed to reach the real method.)
>

D has powerful template and CTFE, seems we have more choices, fat pointer
or thin pointer. I didn't think seriously about the performance differences.

About every cast creates a heap-allocated wrapper, I think we can try to
use lower cost way in D. In my code:

--

void opAssign(V)(GoInterface!(V) v) if (is(V == interface)) {
//pragma(msg, "assign for GoInterface");
static if (isImplicitlyConvertible!(V, T)) {
//pragma(msg, V.stringof ~ " can implicitly convert to " ~
T.stringof);
m_impl = v.m_impl;
}
else static if (isImplicitlyConvertible!(T, V)) {
//pragma(msg, T.stringof ~ " can implicitly convert to " ~
V.stringof ~ ", try dynamic cast");
if (v.m_impl is null) {
m_impl = null;
}
else {
m_impl = cast(T)(v.m_impl);
if (m_impl is null) {
// dynamic cast failed, try dynamic proxy
m_impl = buildDynamicProxy!(V)(v);
}
}
}
else {
//pragma(msg, "cannot implicitly between " ~ V.stringof ~
" and " ~ T.stringof);
static if (isInterfaceConvertible!(V, T)) {
//pragma(msg, "generate static proxy to convert " ~
V.stringof ~ " to " ~ T.stringof);
m_impl = new StaticProxy!(V)(v.m_impl);
}
else {
//pragma(msg, V.stringof ~ " not compatible " ~
T.stringof ~ ", must dynamic build call proxy");
m_impl = buildDynamicProxy!(V)(v);
}
}
}

--

Some cases we can directly do assignment, it also can be optimized to
reduce heap allocation.


>
> Anyway, they say it's possible to build runtime reflection in D but I've
> no idea how... has it never been done before?


> Of course, runtime template instantiation won't be possible. Therefore,
> run-time casting will have to be more limited than compile-time casting.
>
> Reflection to free functions would be really nice, but it might be less
> capable at run-time. Consider if you there is a class A in third-party
> module MA that you want to cast to interface I, but class A is missing a
> function F() from I. So in your module (module MB) you define a free
> function F(B) and now you can do the cast. I guess realistically this can
> only happen at compile-time, since a run-time cast would naturally only
> look in module MA, not MB, for functions it could use to perform the cast.
> Presumably, it also requires that MA requested a run-time reflection table
> to be built, and is it possible to build a reflection table for a module
> over which you have no control?
>

Free functions support is hard, with runtime cast, I just think compile
time.

I am trying to support free functions at compile time, is also hard, since
the generator in gointerface module, but other modules are only visible in
the module that used these modules. I have an ugly implementation used
compile time string mixin, trying to simplify it. Fighting.

Re: K&R-style variadic functions

[Matt Soucy]

Definitely - I live in a very technologically-savvy dorm in college, and 
when I encountered it for the first time nobody there had any idea what 
it was.

...we did later find an old book in our library that had it, though.
-Matt


On 07/17/2012 02:39 PM, H. S. Teoh wrote:

On Tue, Jul 17, 2012 at 08:07:08PM +0200, Paulo Pinto wrote:

On Tuesday, 17 July 2012 at 15:16:56 UTC, Regan Heath wrote:

[...]

So all K&R function declarations were () with no parameters.

R


K&R was more than that.


This modern C declaration:

int main(int argc, char **argv) {
exit(1);
}

is written thus in K&R:

int main(argc, argv)
int argc;
char **argv;
{
exit(1);
}



I guess most old timers here will agree with me that it was
not much more than glorified assembler in what concerns typing.

[...]

I guess you predate me. ;-) When I started learning C, it was already in
the ANSI syntax, though there were enough K&R style code floating around
that I've at least _seen_ K&R syntax. I'm guessing nowadays most people
don't even know what K&R syntax is.


T

Re: reference to 'self' inside a function

[Jonathan M Davis]

On Wednesday, July 18, 2012 00:03:25 bearophile wrote:
> angel:
> > I propose to introduce a reference to the current function,
> > much like 'this' in a class method. Call it 'self' or
> > 'thisFunc', or whatever ...
> 
> Or __func or something. I'm asking for it for years.

You could always use __FUNCTION__ in a string mixin, but that _is_ rather 
ugly.

- Jonathan M Davis

Re: reference to 'self' inside a function

[Kevin Cox]

On Jul 17, 2012 6:50 PM, "Era Scarecrow"  wrote:
>
> On Tuesday, 17 July 2012 at 22:13:13 UTC, Eyyub wrote:
>>
>> On Tuesday, 17 July 2012 at 16:56:17 UTC, angel wrote:
>>>
>>> I propose to introduce a reference to the current function, much like
'this' in a class method. Call it 'self' or 'thisFunc', or whatever ...
>>> What might this be good for ?
>>> For implementing recursion in a lambda function. Writing in functional
style, one creates many functions, and looking for reasonable names for
these functions becomes unnecessarily painful.
>>
>>
>> Good idea !
>> "self" is a cute keyword, or "lambda" but this could break existing code.
>
>
> Mmm.. Why not an inner function to represent the recursive function? True
a 'self' reference may resolve the issue,

What about how JavaScript does it.  Anonymous functions can still have a
"name" that can be used from inside of a function to refer to itself.

And the most useless example ever.

var f = function func ( i ) {
return func(7);
};

I think that this is nice because there is no name space pollution, no new
keywords needed and it is pretty.

Re: reference to 'self' inside a function

[Era Scarecrow]

On Tuesday, 17 July 2012 at 22:13:13 UTC, Eyyub wrote:

On Tuesday, 17 July 2012 at 16:56:17 UTC, angel wrote:
I propose to introduce a reference to the current function, 
much like 'this' in a class method. Call it 'self' or 
'thisFunc', or whatever ...

What might this be good for ?
For implementing recursion in a lambda function. Writing in 
functional style, one creates many functions, and looking for 
reasonable names for these functions becomes unnecessarily 
painful.


Good idea !
"self" is a cute keyword, or "lambda" but this could break 
existing code.


Mmm.. Why not an inner function to represent the recursive 
function? True a 'self' reference may resolve the issue, and be 
syntactical sugar..


  auto f = function int(int x) {
//real function body
void self(int y) {
  if(y) {
inner(y-1);
x++;
  }
}

self(x); //double x
self(x); //double it again
return x;
  }; //end of f declaration

  writeln(10);
  writeln(f(10)); //10*4


 Mmm But using it as a shell although may work wouldn't be useful 
for a simple lambda anymore would it? Who knows, perhaps 'this' 
will extend to lambda's referencing itself.


 Using CTFE you could rebuild and get something similar to that, 
or a template function... H... Something to think on...

Re: Octal Literals

[Nick Sabalausky]

On Tue, 17 Jul 2012 23:53:47 +0200
"Dave X."  wrote:

> I'm a fresh college graduate who just got a job as a software 
> developer, and I have been enthusiastically watching D for a 
> while now (I program primarily in Java and C). I have some 
> functional programming experience in Haskell and Scala as well.
> 

I wish D had been as far along as it is now back when I was in college!

> I like using octal numbers, and I've always been interested in 
> D's octal literals. I'm glad to see that the traditional syntax 
> of C's octal literals is being replaced by a more readable one. 
> However, I can't help but think that the template solution 
> ("octal!nnn") is a little too roundabout; is there a reason that 
> that the "0o" prefix, which is already well established in 
> languages like Haskell, OCaml, and Python, is not used?

It was suggested a few times, but there was a lot of bikeshedding over
it. Some people liked it, some hated it. One of the bigger objections was that 
octal literals were too rarely-needed to justify adding a
new syntax into the language (this was at a time when D was far enough
along that we were trying to start stabalizing the langauge rather
than tossing in more stuff). The bikeshedding went around and around
like that for awhile, during which time the awful old 0123 octal syntax
remained.

So when it was discovered that D's templates made it possible to
implement octal literals in the library (octal!123), instead of in the
language itself (0o123), that solved the deadlock and we went with it.

Re: reference to 'self' inside a function

[Eyyub]

On Tuesday, 17 July 2012 at 16:56:17 UTC, angel wrote:
I propose to introduce a reference to the current function, 
much like 'this' in a class method. Call it 'self' or 
'thisFunc', or whatever ...

What might this be good for ?
For implementing recursion in a lambda function.
Writing in functional style, one creates many functions, and 
looking for reasonable names for these functions becomes 
unnecessarily painful.


Good idea !
"self" is a cute keyword, or "lambda" but this could break 
existing code.

Re: reference to 'self' inside a function

[angel]

Other languages provide other means.
In any case, I don't think it would be a problem if D solved a 
problem other languages failed to resolve properly.
As for  http://d.puremagic.com/issues/show_bug.cgi?id=7176, this 
is pretty much orthogonal to the 'self reference'.

Re: reference to 'self' inside a function

[bearophile]

angel:

I propose to introduce a reference to the current function, 
much like 'this' in a class method. Call it 'self' or 
'thisFunc', or whatever ...


Or __func or something. I'm asking for it for years.

Bye,
bearophile

Octal Literals

[Dave X.]

I'm a fresh college graduate who just got a job as a software 
developer, and I have been enthusiastically watching D for a 
while now (I program primarily in Java and C). I have some 
functional programming experience in Haskell and Scala as well.


I like using octal numbers, and I've always been interested in 
D's octal literals. I'm glad to see that the traditional syntax 
of C's octal literals is being replaced by a more readable one. 
However, I can't help but think that the template solution 
("octal!nnn") is a little too roundabout; is there a reason that 
that the "0o" prefix, which is already well established in 
languages like Haskell, OCaml, and Python, is not used?

Re: reference to 'self' inside a function

[Timon Gehr]

On 07/17/2012 06:56 PM, angel wrote:

I propose to introduce a reference to the current function, much like
'this' in a class method. Call it 'self' or 'thisFunc', or whatever ...
What might this be good for ?
For implementing recursion in a lambda function.
Writing in functional style, one creates many functions, and looking for
reasonable names for these functions becomes unnecessarily painful.


I think it is not the naming that is painful. (I am not aware of
functional languages that have a special identifier for the current
anonymous function.)

What makes writing short named functions inconvenient is lack of this:
http://d.puremagic.com/issues/show_bug.cgi?id=7176

Re: K&R-style variadic functions

[Lukasz]

I was sure that if function is declared with empty () than you 
can call it with any arguments you imagine, as it is in following 
examples.

= ex. 1
<*> cat main.c
void a() {
}

int main()
{
a(1, 2, 3);
return 0;
}

<*> gcc -Wall -Wextra -pedantic  main.c
<*>

== ex. 2
<*> cat test.c
#include 
void a(int a, char b, void* ptr)
{
printf("%d  %c  %p\n", a, b, ptr);
}

<*> cat main.c
extern void a();

int main()
{
int aa = 123;
char b = '#';
void* ptr = (void*)0xffaaffaa;
a(aa, b, ptr);
return 0;
}

<*> gcc -c test.c
<*> gcc -c main.c
<*> gcc -o main main.o test.o
<*> ./main
123  #  0xffaaffaa
<*>

But this is not:

Re: Rust updates

[Timon Gehr]

On 07/17/2012 07:25 PM, bearophile wrote:

Walter Bright:


auto code() { return cast(ushort)42; }

works fine. There isn't really a lack here, just some more typing. I
just don't see the case coming up hardly at all.


I have just found an example (reduced code):


import std.typecons;
void main() {
alias Tuple!(ubyte[]) Tu;
auto x1 = Tu([cast(ubyte)0]); // OK
auto x2 = Tu([0]); // Error
}


D tuples are very strict.

Bye,
bearophile


Looks like a bug in std.typecons.Tuple. That constructor shouldn't be
templated on the argument types.

Re: K&R-style variadic functions

[Jacob Carlborg]

On 2012-07-17 17:13, Regan Heath wrote:


Is Clang open source, can we see the code for that function?  Perhaps
it's a bug.. ANSI C may have made () without "void" obsolete, but no
compiler I've ever used has actually enforced that - or perhaps C++ made
old-style function definition/declarations obsolete and allowed () back
again.


Sure:

https://llvm.org/svn/llvm-project/cfe/trunk/tools/libclang/CXType.cpp

Just search for clang_isFunctionTypeVariadic.

--
/Jacob Carlborg

Re: Rust updates

[SomeDude]

On Friday, 13 July 2012 at 14:58:57 UTC, bearophile wrote:

A blog post about one of the Rust pointers, the "borrowed" ones:

http://smallcultfollowing.com/babysteps/blog/2012/07/10/borrowed-pointer-tutorial/

Bye,
bearophile


Rust is a much more interesting language than Go. At least they 
are taking some innovative paths and that's good.

Re: Why is std.algorithm so complicated to use?

[Jonathan M Davis]

On Tuesday, July 17, 2012 11:47:07 Christophe Travert wrote:
> The compiler could stop displaying at about 10 failed constrains and
> claim there are more. It would be best if it could figure out what are
> the 10 most interesting constrains, but that may not be easy!

That seems like a good idea.

- Jonathan M Davis

Re: K&R-style variadic functions

[Jacob Carlborg]

On 2012-07-17 17:11, Regan Heath wrote:


Ahh, I've been looking at the ANSI C spec and assuming that is what
you're basing things off, K&R C was pre-ANSI C and may have different
rules.  I think you should probably aim to be ANSI C compliant and
above, and ignore K&R.


This page says otherwise:

http://en.wikipedia.org/wiki/ANSI_C#Compliance_detectability

"...while an obsolescent non-prototype declaration is used otherwise. 
Those are still ANSI-compliant as of C99 and C90, but their use is 
discouraged".



Looking at the ANSI C spec again, section 6.7.5.3, item 10 says:

"The special case of an unnamed parameter of type void as the only item
in the list specifies that the function has no parameters."

So, "void" indicates no parameters..

Item 14 is also applicable and says:

"An identifier list declares only the identifiers of the parameters of
the function. An empty list in a function declarator that is part of a
definition of that function specifies that the function has no
parameters. The empty list in a function declarator that is not part of
a definition of that function specifies that no information about the
number or types of the parameters is supplied." 124)

The latter part of that is applicable to declarations in header files
(the former is for definitions in c files);  "The empty list in a
function declarator that is /not part of a definition of that function/
specifies that /no information about the number or types of the
parameters is supplied/."

So, a function like:
 int foo();

in a header "specifies that no information about the number or types of
the parameters is supplied".

However footnote 124) says see 6.1.6, and 6.1.6 says:

6.11.6 Function declarators
The use of function declarators with empty parentheses (not
prototype-format parameter type declarators) is an obsolescent feature.

So, coming full circle, it seems like I'm right after all .. I think.
"void" is required to indicate no parameters and () is obsolete in ANSI C.


It's still in the standard.

--
/Jacob Carlborg

Re: K&R-style variadic functions

[H. S. Teoh]

On Tue, Jul 17, 2012 at 08:07:08PM +0200, Paulo Pinto wrote:
> On Tuesday, 17 July 2012 at 15:16:56 UTC, Regan Heath wrote:
[...]
> >So all K&R function declarations were () with no parameters.
> >
> >R
> 
> K&R was more than that.

This modern C declaration:

int main(int argc, char **argv) {
exit(1);
}

is written thus in K&R:

int main(argc, argv)
int argc;
char **argv;
{
exit(1);
}


> I guess most old timers here will agree with me that it was
> not much more than glorified assembler in what concerns typing.
[...]

I guess you predate me. ;-) When I started learning C, it was already in
the ANSI syntax, though there were enough K&R style code floating around
that I've at least _seen_ K&R syntax. I'm guessing nowadays most people
don't even know what K&R syntax is.


T

-- 
If I were two-faced, would I be wearing this one? -- Abraham Lincoln

Re: reference to 'self' inside a function

[H. S. Teoh]

On Tue, Jul 17, 2012 at 01:09:09PM -0400, Kevin Cox wrote:
> On Jul 17, 2012 1:00 PM, "angel"  wrote:
> >
> > I propose to introduce a reference to the current function, much
> > like 'this' in a class method. Call it 'self' or 'thisFunc', or
> > whatever ...
> > What might this be good for ?
> > For implementing recursion in a lambda function.
> > Writing in functional style, one creates many functions, and looking
> > for reasonable names for these functions becomes unnecessarily
> > painful.
> 
> I like that idea, although I don't know about the name.  We also might
> want more features such as access to syntacticly nested functions.

We certainly can't use 'this', because it will break lambda functions
declared inside class methods. So 'self' seems like a reasonable
alternative. But this requires introducing a new keyword, which means
there's the likelihood of breaking existing code that happens to use an
identifier called 'self'.

It's a good idea, though. It will strengthen D's support for functional
style code.


T

-- 
Let's eat some disquits while we format the biskettes.

Re: D versionning

[Iain Buclaw]

On 17 July 2012 12:05, Wouter Verhelst  wrote:
> "Chris NS"  writes:
>
>> +1 for a "2.breaking.bugfix" scheme.  I've used this scheme on
>> anything serious for years, and know many others who have; so it is
>> not only popular but also quite tried and proven.  Not for every
>> project, of course (although I don't understand why the Linux kernel
>> team dropped it with 3.x), but for the majority it seems to work
>> wonders.
>
> They haven't, on the contrary.
>
> 3.x is a release with new features
> 3.x.y is a bugfix release.
>
> Before the move to 3.x, this was 2.6.x and 2.6.x.y -- which was
> confusing, because many people thought there was going to be a 2.8 at
> some point when there wasn't.
>

The reason for the move to 3.x is in the announcement.

http://lkml.org/lkml/2011/7/21/455

But yes, it simplifies the stable vs development kernel versioning.



-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

Re: K&R-style variadic functions

[Paulo Pinto]

On Tuesday, 17 July 2012 at 15:13:52 UTC, Regan Heath wrote:
On Tue, 17 Jul 2012 15:50:27 +0100, Jacob Carlborg 
 wrote:



On 2012-07-17 16:37, Regan Heath wrote:

All my googling for "old style" "variadic" etc returned the 
use of
va_alist and va_dcl so I can't see where/why Clang would do 
what it's

doing.


To be accurate it's the libclang function 
"clang_isFunctionTypeVariadic" that returns true.


http://clang.llvm.org/doxygen/group__CINDEX__TYPES.html#ga343b2463b0ed4b259739242cf26c3ae2


Is Clang open source, can we see the code for that function?  
Perhaps it's a bug.. ANSI C may have made () without "void" 
obsolete, but no compiler I've ever used has actually enforced 
that - or perhaps C++ made old-style function 
definition/declarations obsolete and allowed () back again.


R


In C++, a function with no parameters () is a synonym for (void).

--
Paulo

Re: K&R-style variadic functions

[Paulo Pinto]

On Tuesday, 17 July 2012 at 15:16:56 UTC, Regan Heath wrote:
On Tue, 17 Jul 2012 15:46:34 +0100, Jacob Carlborg 
 wrote:



On 2012-07-17 16:36, Regan Heath wrote:

I believe old-style no parameter function declarations MUST 
have "void"

i.e.

int foo(void);


That is still the case, regardless of "style"?


They cannot read:

int foo();

The latter MUST have parameters, we just can't tell what they 
are.


Take a look at this:

http://en.wikipedia.org/wiki/K%26R_C#KRC

In that example none of the functions have any parameters 
declared and are not called with any arguments.


K&R C did not allow you to declare arguments at all, according 
to the wiki:


"Since K&R function declarations did not include any 
information about function arguments, function parameter type 
checks were not performed, although some compilers would issue 
a warning message if a local function was called with the wrong 
number of arguments, or if multiple calls to an external 
function used different numbers or types of arguments. Separate 
tools such as Unix's lint utility were developed that (among 
other things) could check for consistency of function use 
across multiple source files."


So all K&R function declarations were () with no 
parameters.


R


K&R was more than that.

I guess most old timers here will agree with me that it was
not much more than glorified assembler in what concerns typing.

Much of the typing C has today, was actually brought in as part 
of the

ANSI C standardization process.

--
Paulo

Re: K&R-style variadic functions

[Daniel Murphy]

"deadalnix"  wrote in message 
news:ju3uqc$55g$1...@digitalmars.com...
>
> It is used in testfptr.d from dmd's testsuite.

No, that's a D-linkage variadic. 

Re: Rust updates

[bearophile]

Walter Bright:


   auto code() { return cast(ushort)42; }

works fine. There isn't really a lack here, just some more 
typing. I just don't see the case coming up hardly at all.


I have just found an example (reduced code):


import std.typecons;
void main() {
alias Tuple!(ubyte[]) Tu;
auto x1 = Tu([cast(ubyte)0]); // OK
auto x2 = Tu([0]); // Error
}


D tuples are very strict.

Bye,
bearophile

Re: std.algorithm imporvments

[Jonathan M Davis]

On Tuesday, July 17, 2012 10:47:50 Andrei Alexandrescu wrote:
> On 7/17/12 4:41 AM, monarch_dodra wrote:
> > On Monday, 16 July 2012 at 22:42:47 UTC, Andrei Alexandrescu
> > 
> > wrote:
> >> Wow, this is awesome. Did you discover that by inspection or by
> >> testing? I think a "malicious input range" would be a great tool for
> >> assessing which algorithms fail on input ranges.
> >> 
> >> Andrei
> > 
> > The first I discovered testing with a "ConsumableRange",
> > actually. The second, I found by inspection.
> > 
> > I'll correct those two issues myself, but I don't feel
> > comfortable with the other issues.
> 
> You may want to submit them as bug requests. Thanks!

Yes. Please do. It's on my todo list to improve std.algorithm and std.range's 
tests (particularly for reference type ranges), and I've gotten started on it, 
but it could take a while to get it all done, and anything that you find will 
be valuable in not only figuring out what needs fixing but also in figuring out 
what needs better testing.

bugzilla: http://d.puremagic.com/issues

- Jonathan M Davis

Re: reference to 'self' inside a function

[Kevin Cox]

On Jul 17, 2012 1:00 PM, "angel"  wrote:
>
> I propose to introduce a reference to the current function, much like
'this' in a class method. Call it 'self' or 'thisFunc', or whatever ...
> What might this be good for ?
> For implementing recursion in a lambda function.
> Writing in functional style, one creates many functions, and looking for
reasonable names for these functions becomes unnecessarily painful.

I like that idea, although I don't know about the name.  We also might want
more features such as access to syntacticly nested functions.

reference to 'self' inside a function

[angel]

I propose to introduce a reference to the current function, much 
like 'this' in a class method. Call it 'self' or 'thisFunc', or 
whatever ...

What might this be good for ?
For implementing recursion in a lambda function.
Writing in functional style, one creates many functions, and 
looking for reasonable names for these functions becomes 
unnecessarily painful.

Re: Definition of "OutputRange" insuficient

[monarch_dodra]

OutputRange is designed for infinite output ranges, like output 
files and appender.


[snip]


Well, "designed" is open for interpretation.

Yes, all (most) "ranges defined as output" (files, streams, 
appenders) are infinite, and don't define empty (or define it as 
false).


But that does not mean that all ranges that fulfill 
"isOutputRange" are infinite. By leaving out the "empty" 
requirement from output range, we are forcing the infinity 
concept on anything that wishes to use the output facilities of a 
range.


On Tuesday, 17 July 2012 at 14:53:00 UTC, Andrei Alexandrescu 
wrote:
Actually if you look at put() it's designed to accept an input 
range with assignable elements, in which case it assigns to the 
front and moves forward. But I agree we could improve output 
ranges with a notion of "full". The paradox is, for an input 
range used for output, "full" is a synonym for "empty" :o).


Andrei


Well, the "underlying" container being full makes the range 
empty. I don't really see how we could have a notion of a "full 
range". But I'll admit the contrast if funny to observe :D


Regarding put, I noticed that actually. I was going to propose 
using it in "copy", as it could probably improve performance in 
the "generic case" (that, and it is _meant_ to be used that way). 
Right now, it defines a "genericImplementation" as:



static Range2 genericImpl(Range1 source, Range2 target)
{
for (; !source.empty; source.popFront())
{
put(target, source.front);
}

return target;
}

which should really just be

static Range2 genericImpl(Range1 source, Range2 target)
{
put(target, source);
return target;
}

In the case of "fill" is that "put" will throw an exception if 
source does fit into target. There is no real way to know this 
before hand either, and it is not possible to just insert until 
full: That is the entire problem.


An easy fix at this point would be to just provide "hasEmpty", 
no? After all, we have "hasLength". That said, I feel this is 
more a bandage, and that outputRange really should define empty.



On a same note, I just noticed that "forwardRange" does not have 
to adhere to the "outputRange" concept. This is in stark 
opposition to the classification in C++. Is this on purpose? I 
took it for granted that "forward" meant "output"+"input"+"save", 
but it is really just "input"+"save".


In theory, this means that the only "safe" way to write to a 
range would be to use "put".


There is a "hasAssignableElements" trait, but the requirements 
are odd:
1) It requires the range to be at least "forward", meaning an 
inputRange or an outputRange (!) will fail the 
"hasAssignableElements" test.
2) It only checks that "front" is assignable, so that does not 
guarantee you can assign to the indexes of a RandomAccess range :/

Re: K&R-style variadic functions

[Regan Heath]

On Tue, 17 Jul 2012 15:46:34 +0100, Jacob Carlborg  wrote:


On 2012-07-17 16:36, Regan Heath wrote:


I believe old-style no parameter function declarations MUST have "void"
i.e.

 int foo(void);


That is still the case, regardless of "style"?


They cannot read:

 int foo();

The latter MUST have parameters, we just can't tell what they are.


Take a look at this:

http://en.wikipedia.org/wiki/K%26R_C#KRC

In that example none of the functions have any parameters declared and  
are not called with any arguments.


K&R C did not allow you to declare arguments at all, according to the wiki:

"Since K&R function declarations did not include any information about  
function arguments, function parameter type checks were not performed,  
although some compilers would issue a warning message if a local function  
was called with the wrong number of arguments, or if multiple calls to an  
external function used different numbers or types of arguments. Separate  
tools such as Unix's lint utility were developed that (among other things)  
could check for consistency of function use across multiple source files."


So all K&R function declarations were () with no parameters.

R

--
Using Opera's revolutionary email client: http://www.opera.com/mail/

Re: K&R-style variadic functions

[Regan Heath]

On Tue, 17 Jul 2012 15:50:27 +0100, Jacob Carlborg  wrote:


On 2012-07-17 16:37, Regan Heath wrote:


All my googling for "old style" "variadic" etc returned the use of
va_alist and va_dcl so I can't see where/why Clang would do what it's
doing.


To be accurate it's the libclang function "clang_isFunctionTypeVariadic"  
that returns true.


http://clang.llvm.org/doxygen/group__CINDEX__TYPES.html#ga343b2463b0ed4b259739242cf26c3ae2


Is Clang open source, can we see the code for that function?  Perhaps it's  
a bug.. ANSI C may have made () without "void" obsolete, but no compiler  
I've ever used has actually enforced that - or perhaps C++ made old-style  
function definition/declarations obsolete and allowed () back again.


R

--
Using Opera's revolutionary email client: http://www.opera.com/mail/

Re: K&R-style variadic functions

[Regan Heath]

On Tue, 17 Jul 2012 15:46:34 +0100, Jacob Carlborg  wrote:


On 2012-07-17 16:36, Regan Heath wrote:


I believe old-style no parameter function declarations MUST have "void"
i.e.

 int foo(void);


That is still the case, regardless of "style"?


They cannot read:

 int foo();

The latter MUST have parameters, we just can't tell what they are.


Take a look at this:

http://en.wikipedia.org/wiki/K%26R_C#KRC

In that example none of the functions have any parameters declared and  
are not called with any arguments.


Ahh, I've been looking at the ANSI C spec and assuming that is what you're  
basing things off, K&R C was pre-ANSI C and may have different rules.  I  
think you should probably aim to be ANSI C compliant and above, and ignore  
K&R.


Looking at the ANSI C spec again, section 6.7.5.3, item 10 says:

"The special case of an unnamed parameter of type void as the only item in  
the list specifies that the function has no parameters."


So, "void" indicates no parameters..

Item 14 is also applicable and says:

"An identifier list declares only the identifiers of the parameters of the  
function. An empty list in a function declarator that is part of a  
definition of that function specifies that the function has no parameters.  
The empty list in a function declarator that is not part of a definition  
of that function specifies that no information about the number or types  
of the parameters is supplied." 124)


The latter part of that is applicable to declarations in header files (the  
former is for definitions in c files);  "The empty list in a function  
declarator that is /not part of a definition of that function/ specifies  
that /no information about the number or types of the parameters is  
supplied/."


So, a function like:
int foo();

in a header "specifies that no information about the number or types of  
the parameters is supplied".


However footnote 124) says see 6.1.6, and 6.1.6 says:

6.11.6 Function declarators
The use of function declarators with empty parentheses (not  
prototype-format parameter type declarators) is an obsolescent feature.


So, coming full circle, it seems like I'm right after all .. I think.   
"void" is required to indicate no parameters and () is obsolete in ANSI C.


R

--
Using Opera's revolutionary email client: http://www.opera.com/mail/

Re: Need runtime reflection?

[David Piepgrass]

I want to imitate golang's interface in D, to study D's 
template. I wrote

some code: https://gist.github.com/3123593

Now we can write code like golang:
--
interface IFoo {
void foo(int a, string b, float c);
}

struct Foo {
void foo(int a, string b, float c) {
writeln("Foo.foo: ", a, ", ", b, ", ", c);
}
}

struct FooFoo {
void foo(int a, string b, float c) {
writeln("FooFoo.foo: ", a, ", ", b, ", ", c);
}
}

GoInterface!(IFoo) f = new Foo;
f.foo(3, "abc", 2.2);

f = new FooFoo;
f.foo(5, "def", 7.7);
--

It is also very naive, does not support some features, like 
out/ref
parameters, free functions *[1]* and so on. The biggest problem 
is downcast

not supported. In golang, we can write code like*[2]*:
--
var p IWriter = NewB(10)
p2, ok := p.(IReadWriter)
--

Seems [p.(IReadWriter)] dynamically build a virtual table 
*[3]*，because the
type of "p" is IWriter, it is *smaller* than IReadWriter, the 
cast

operation must search methods and build vtbl at run time.

In D, GoInterface(T).opAssign!(V)(V v) can build a rich runtime 
information
to *V* if we need. But if *V* is interface or base class, the 
type
information not complete. So, seems like I need runtime 
reflection? and how
can I do this in D? I did not find any useful information in 
the TypeInfo*.


--
[1] free functions support, e.g.
--
interface IFoo {
void foo(int a, string b, float c);
}
void foo(int self, int a, string b, float c) {
writefln("...");
}

GoInterface!(int) p = 1;
p.foo(4, "ccc", 6.6);
--
In theory no problem.


I, too, was enamored with Go Interfaces and implemented them for 
.NET:


http://www.codeproject.com/Articles/87991/Dynamic-interfaces-in-any-NET-language

And I wasn't the only one; later, someone else published another 
library for .NET with the exact same goal. This is definitely a 
feature I would want to see in D, preferably as a first-class 
feature, although sadly that would break any code that relies on 
ISomething being pointer-sized; Go uses fat pointers, and we use 
a thin-pointer implementation in .NET but it's inefficient (as 
every cast creates a heap-allocated wrapper, and 
double-indirection is needed to reach the real method.)


Anyway, they say it's possible to build runtime reflection in D 
but I've no idea how... has it never been done before?


Of course, runtime template instantiation won't be possible. 
Therefore, run-time casting will have to be more limited than 
compile-time casting.


Reflection to free functions would be really nice, but it might 
be less capable at run-time. Consider if you there is a class A 
in third-party module MA that you want to cast to interface I, 
but class A is missing a function F() from I. So in your module 
(module MB) you define a free function F(B) and now you can do 
the cast. I guess realistically this can only happen at 
compile-time, since a run-time cast would naturally only look in 
module MA, not MB, for functions it could use to perform the 
cast. Presumably, it also requires that MA requested a run-time 
reflection table to be built, and is it possible to build a 
reflection table for a module over which you have no control?

Re: K&R-style variadic functions

[deadalnix]

On 17/07/2012 08:56, Jacob Carlborg wrote:

To my understanding this is legal C :

int foo ();

It's a K&R-style variadic functions, while their use is discouraged,
they're still legal C.

If I, in D, declare a variadic function with C linkage that doesn't
take, at least, one regular parameter the compiler will complain.

extern (C) int foo (...);



It is used in testfptr.d from dmd's testsuite.

Re: K&R-style variadic functions

[Jacob Carlborg]

On 2012-07-17 16:37, Regan Heath wrote:


All my googling for "old style" "variadic" etc returned the use of
va_alist and va_dcl so I can't see where/why Clang would do what it's
doing.


To be accurate it's the libclang function "clang_isFunctionTypeVariadic" 
that returns true.


http://clang.llvm.org/doxygen/group__CINDEX__TYPES.html#ga343b2463b0ed4b259739242cf26c3ae2 



--
/Jacob Carlborg

Re: Definition of "OutputRange" insuficient

[Andrei Alexandrescu]

On 7/17/12 6:44 AM, monarch_dodra wrote:

I was trying to fix a few bugs in algorithm, as well as be more correct
in template type specifiers, and I have to say: There is a serious
restraint in the definition of an outputRange.

The current definition of "isOutputRange" is simply that "an output
range is defined functionally as a range that supports the operation put".


Actually if you look at put() it's designed to accept an input range 
with assignable elements, in which case it assigns to the front and 
moves forward. But I agree we could improve output ranges with a notion 
of "full". The paradox is, for an input range used for output, "full" is 
a synonym for "empty" :o).


Andrei

Re: K&R-style variadic functions

[Jacob Carlborg]

On 2012-07-17 16:36, Regan Heath wrote:


I believe old-style no parameter function declarations MUST have "void"
i.e.

 int foo(void);


That is still the case, regardless of "style"?


They cannot read:

 int foo();

The latter MUST have parameters, we just can't tell what they are.


Take a look at this:

http://en.wikipedia.org/wiki/K%26R_C#KRC

In that example none of the functions have any parameters declared and 
are not called with any arguments.


--
/Jacob Carlborg

Re: std.algorithm imporvments

[Andrei Alexandrescu]

On 7/17/12 4:41 AM, monarch_dodra wrote:

On Monday, 16 July 2012 at 22:42:47 UTC, Andrei Alexandrescu
wrote:

Wow, this is awesome. Did you discover that by inspection or by
testing? I think a "malicious input range" would be a great tool for
assessing which algorithms fail on input ranges.

Andrei


The first I discovered testing with a "ConsumableRange",
actually. The second, I found by inspection.

I'll correct those two issues myself, but I don't feel
comfortable with the other issues.


You may want to submit them as bug requests. Thanks!

Andrei

Re: K&R-style variadic functions

[Regan Heath]

On Tue, 17 Jul 2012 15:01:02 +0100, Jacob Carlborg  wrote:


On 2012-07-17 15:05, Regan Heath wrote:


In my specific case I could add "int a" as the first parameter, and all
was well.  Each case will be different, and it's conceivable there is a
C old-style variadic which takes /any/ type of first parameter, which
could be a problem, however the key issue is the size of the argument.
If all types which could be passed are 32 bits big, then "int a" is
sufficient to get it working in all cases.


It could just as well be no parameters.


I believe old-style no parameter function declarations MUST have "void"  
i.e.


int foo(void);

They cannot read:

int foo();

The latter MUST have parameters, we just can't tell what they are.

R

--
Using Opera's revolutionary email client: http://www.opera.com/mail/

Re: K&R-style variadic functions

[Regan Heath]

On Tue, 17 Jul 2012 15:02:44 +0100, Jacob Carlborg  wrote:


On 2012-07-17 14:32, Regan Heath wrote:



After a bit of googling and a test with my local MSVC9 I think old-style
variadics look like this:

#include 
#include 

void foo(va_alist)
 va_dcl
{
 va_list p;
 va_start(p);
 vprintf("%d %d %d\n", p);
}

void main()
{
 foo(1, 2, 3);
}

(the above runs and outputs "1 2 3" on the console)

The same syntax is/was supported by GNU C, see:
http://ftp.gnu.org/old-gnu/Manuals/glibc-2.2.3/html_chapter/libc_34.html#SEC676



I believe, if you see an "old-style" function declaration in a header
file like:

 int foo ();

that you can't actually assume anything about it's parameters, it may
have /any/ number of parameters, and may or may not be variadic.


Clang seems to interpret it as a variadic function. Then if that is  
correct or not I don't know.


All my googling for "old style" "variadic" etc returned the use of  
va_alist and va_dcl so I can't see where/why Clang would do what it's  
doing.


R

--
Using Opera's revolutionary email client: http://www.opera.com/mail/

Re: K&R-style variadic functions

[Jacob Carlborg]

On 2012-07-17 15:05, Regan Heath wrote:


In my specific case I could add "int a" as the first parameter, and all
was well.  Each case will be different, and it's conceivable there is a
C old-style variadic which takes /any/ type of first parameter, which
could be a problem, however the key issue is the size of the argument.
If all types which could be passed are 32 bits big, then "int a" is
sufficient to get it working in all cases.


It could just as well be no parameters.

--
/Jacob Carlborg

Re: K&R-style variadic functions

[Jacob Carlborg]

On 2012-07-17 14:32, Regan Heath wrote:



After a bit of googling and a test with my local MSVC9 I think old-style
variadics look like this:

#include 
#include 

void foo(va_alist)
 va_dcl
{
 va_list p;
 va_start(p);
 vprintf("%d %d %d\n", p);
}

void main()
{
 foo(1, 2, 3);
}

(the above runs and outputs "1 2 3" on the console)

The same syntax is/was supported by GNU C, see:
http://ftp.gnu.org/old-gnu/Manuals/glibc-2.2.3/html_chapter/libc_34.html#SEC676



I believe, if you see an "old-style" function declaration in a header
file like:

 int foo ();

that you can't actually assume anything about it's parameters, it may
have /any/ number of parameters, and may or may not be variadic.


Clang seems to interpret it as a variadic function. Then if that is 
correct or not I don't know.


--
/Jacob Carlborg

Re: Exquisite code samples

[renoX]

On Tuesday, 10 July 2012 at 09:24:42 UTC, Don Clugston wrote:

On 10/07/12 09:49, renoX wrote:

On Monday, 9 July 2012 at 11:40:37 UTC, Gor Gyolchanyan wrote:
[cut]

You're right. This is a bit advanced code sample, which uses
templates,template constraints, contract programming among 
syntax

advantages of D.


Hum it show the power of D sure, but IMHO it also show its 
syntax

deficiencies..

For me this "real[d] bezier(size_t d, Number)(Number[d][] p, 
Number t)
if(d > 1 && isFloatingPoint!Number)" is difficult to read, and 
a better

syntax would be:
real[d] bezier!(size_t d && d > 1, Number &&
isFloatingPoint!Number)(Number[d][] p, Number t)

The template parameter would be indicated in a !() (as in a 
call), and
the template constraints inside the template parameter: this 
way the
template parameters are clearly indicated and separated from 
the

function parameter.

renoX


Well it used to work vaguely in that way, but it gets very ugly 
once you leave the simplest cases.  Even that one you've listed 
is hard for me to read.



IMHO, the "normal" way is even harder to read..


And the idea that constraints apply to individual parameters is 
wrong. If you have a constraint that depends on two template 
parameters, where do you put it?


int bezier (int A, int B)(int t) if ( A + B == 10 )



How about:
int bezier!(int A, int B; A + B == 10)(int t) ?

I think that grouping together template parameters and 
constraints helps the readability YMMV.


BR,
renoX

PS: Sorry for the multiple posting, the posting didn't seem to 
work so I retried..

Re: K&R-style variadic functions

[Regan Heath]

On Tue, 17 Jul 2012 13:32:08 +0100, Regan Heath   
wrote:



On Tue, 17 Jul 2012 12:43:46 +0100, Jacob Carlborg  wrote:


On 2012-07-17 09:06, Mehrdad wrote:


My eyes!! They're bleeding!!


First I wanted to know if my interpretation is correct and then I was  
trying to figure out how my tool should behave if it encounters a  
function like this.


After a bit of googling and a test with my local MSVC9 I think old-style  
variadics look like this:


#include 
#include 

void foo(va_alist)
va_dcl
{
va_list p;
va_start(p);
vprintf("%d %d %d\n", p);
}

void main()
{
foo(1, 2, 3);
}

(the above runs and outputs "1 2 3" on the console)


Some follow up information, for interests sake.

1. va_dcl is defined in varargs.h as..
#define va_dcl va_list va_alist;

So, the old-style variable args function definiton can be written:

void foo(va_alist)
va_list va_alist;
{
... 
}

2. va_start in defined in varargs.h as..
#define va_start(ap) ap = (va_list)&va_alist

So, it assumes a parameter called va_alist exists, and it simply takes the  
address of it.  A new style variadic uses a definition like this..


	#define _crt_va_start(ap,v)  ( ap = (va_list)_ADDRESSOF(v) +  
_INTSIZEOF(v) )


which takes the address of 'v' (which is the argument prior to the ...)  
then skips past it, obtaining the address of the first ... argument.


So, in effect they are doing the same thing, taking the address of the  
first variable argument.  In which case, I can only assume if we can call  
new-style variadics from D, we can call old-style ones as well - provided  
any preceding arguments to the va_alist argument are defined correctly,  
.e.g.


given this old-style function declaration:

void foo();

which actually happens to match this old-style variadic function  
definition:


void foo(a,b,va_alist)
int a;
int b;
va_list va_alist;
{
}

we could produce the following:

extern (C) void foo(/*TODO: add args here*/);

and, once the user filled in the args

extern (C) void foo(int a, int b, ...);

it should be callable from D.. in fact I just did a test (albeit with a  
slightly different test case..)


[testdll.c]
#include 
#include 

__declspec( dllexport )
void foo(va_alist)
va_list va_alist;
{
va_list p;
va_start(p);
vprintf("%d %d %d\n", p);
}

(compiled with MSVC to dll and lib, lib converted with coffimplib to OMF  
format)


[test.d]
extern (C) void foo(int a, ...);

int main(string[] args)
{
foo(1, 3, 5);
return 0;
}

compile with dmd test.d testdll.lib, run test.exe, outputs "1 3 5" :)

But, this highlights one issue I was unaware of.  The D extern (C)  
declaration needs at least 1 parameter before the ..., having just:


extern (C) void foo(...);

is illegal.

In my specific case I could add "int a" as the first parameter, and all  
was well.  Each case will be different, and it's conceivable there is a C  
old-style variadic which takes /any/ type of first parameter, which could  
be a problem, however the key issue is the size of the argument.  If all  
types which could be passed are 32 bits big, then "int a" is sufficient to  
get it working in all cases.


R

--
Using Opera's revolutionary email client: http://www.opera.com/mail/

Re: Definition of "OutputRange" insuficient

[Christophe Travert]

"monarch_dodra" , dans le message (digitalmars.D:172586), a écrit :
> I was trying to fix a few bugs in algorithm, as well as be more 
> correct in template type specifiers, and I have to say: There is 
> a serious restraint in the definition of an outputRange.
> 
> The current definition of "isOutputRange" is simply that "an 
> output range is defined functionally as a range that supports the 
> operation put".
> 
> The problem with this is this definition is not very useful (at 
> all). Not just because it lacks front/popFront (this is actually 
> OK). It is because it lacks an "empty". This makes it virtually 
> un-useable unless you are blind writing to an infinite output 
> range.
> 
> The proof that it is useless is that NOT A SINGLE ALGORITHM is 
> compatible with output ranges. All algorithms that really only 
> require an "output" systematically actually require 
> "isForwardRange", or, worse yet "isInputRange" (!). This is only 
> because they all make use of range.empty.

OutputRange is designed for infinite output ranges, like output files 
and appender.

Copy is the only algorithm that uses OutputRange. But still, this is 
enough. That enables to do a lot of things, since copy can branch to any 
lazy input range performing all the generic operation you want*.

However, output range with a limited capacity are not taken into 
account. They are partly covered by the input ranges family. Most ranges 
that are output ranges with a capacity are also input ranges. Arguably, 
we may want to cover output ranges with capacity that are not input 
range. This would may make fill cleaner. uninitializedFill would 
be fill with an output range that does not defines a front method, which 
would be much cleaner than using emplace arbitrarily on a range that is 
not designed for that. This also opens the door to an algorithm that 
copy a input range into an output range, but stops when the output range 
is full of the input range is empty, and return both filled output range 
and consumed input range (the input range could be taken by ref). Copy 
could be improved with an additional "StopPolicy" template argument.

To do this, two methods could be added to output ranges, one telling if 
the range is full, and one telling what is the remaining capacity of the 
range (capacity already has a meaning, some other word should be used). 
These methods are like empty and length.

-- 
Christophe

Out of topic foot note:
* After thoughts, one thing you can't do directly in phobos is to modify 
an output range to return a new output range. You are obliged 
to apply the operation on the input range.
For example:
input.map!toString().copy(output);
can't be written:
input.copy(output.preMap!toString());

Creating a modified output range like my (badly named) output.preMap can 
be useful, but may be to marginal to be put in Phobos. With a revamped 
stdio using more ranges, this may become less marginal. map, joiner, 
filter, chain, take and friends, zip and chunks may have a meaning for 
output range with capacity...

Re: K&R-style variadic functions

[Regan Heath]

On Tue, 17 Jul 2012 12:43:46 +0100, Jacob Carlborg  wrote:


On 2012-07-17 09:06, Mehrdad wrote:


My eyes!! They're bleeding!!


First I wanted to know if my interpretation is correct and then I was  
trying to figure out how my tool should behave if it encounters a  
function like this.


After a bit of googling and a test with my local MSVC9 I think old-style  
variadics look like this:


#include 
#include 

void foo(va_alist)
va_dcl
{
va_list p;
va_start(p);
vprintf("%d %d %d\n", p);
}

void main()
{
foo(1, 2, 3);
}

(the above runs and outputs "1 2 3" on the console)

The same syntax is/was supported by GNU C, see:
http://ftp.gnu.org/old-gnu/Manuals/glibc-2.2.3/html_chapter/libc_34.html#SEC676


I believe, if you see an "old-style" function declaration in a header file  
like:


int foo ();

that you can't actually assume anything about it's parameters, it may have  
/any/ number of parameters, and may or may not be variadic.


e.g. see: http://msdn.microsoft.com/en-us/library/efx873ys.aspx

The "declaration" syntax shown there for a function with 2 arguments is  
simply:


double old_style();

In short, I don't think you can produce a valid .di/d file for old-style  
declarations automatically, it will require a manual step where the user  
enters the function type-arguments.



However, if you see an old-style:

int foo(void);

you can be sure it has 0 parameters and can happily produce:

extern (C) int foo();


So, I think you should assume no old-style function declarations but have  
a command line option/mode which assumes all functions declarations are  
old-style.  In this mode you would output something like..


extern (C)  (/*TODO: add args here*/);

and require the user manually find and define these.

I can't think of any other way you could do it.

R

p.s. I found this copy of the C spec online:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf
section 6.7.5.3 appears to deal with function declarations.

--
Using Opera's revolutionary email client: http://www.opera.com/mail/

Re: D versionning

[deadalnix]

On 17/07/2012 06:37, RivenTheMage wrote:

On Monday, 16 July 2012 at 22:14:03 UTC, Jonathan M Davis wrote:


Going to v3 would mean incrementing the 2.
We have _no_ intention of doing that for years
to come.


Small steps are perfect for many projects, but - in my opinion -
not for a programming language specification (and reference
implementation). Big leaps are better.

Look at C# - 2.0, 3.0, 4.0...

I'm aware of counterexamples (like PHP), but these are bad
examples to follow.


Yeah sure. Nothing was released between 3.0 and 4.0 for instance. Not a 
single patch.

Re: Why is std.algorithm so complicated to use?

[Christophe Travert]

Jonathan M Davis , dans le message (digitalmars.D:172564), a écrit :
> They're likely to contain a lot of stuff negation of other template 
> constraints. For instance,
> 
> auto func(R)(R range)
> if(isForwardRange!R && !isBidirectionalRange!R)
> {}
> 
> auto func(R)(R range)
> if(isBidirectionalRange!R)
> {}
> 
> If you have a function with very many overloads, it can be very easy to end 
> up 
> with a bunch of different template constraints which are all slightly 
> different. 
> std.algorithm.find is a prime example of this.
> 
> But as much as it may be a bit overwhelming to print every failed constraint, 
> without doing that, you _have_ to go to the source code to see what they 
> were, 
> which isn't all that great (especially if it's not in a library that you 
> wrote 
> and don't normally look at the source of - e.g. Phobos).
> 
> On the other hand, a failed instantiation of std.conv.to would print out 
> reams 
> of failed constraints...

The compiler could stop displaying at about 10 failed constrains and 
claim there are more. It would be best if it could figure out what are 
the 10 most interesting constrains, but that may not be easy!

Then it's up to the programmer to use template constrains, static if and 
eventually pragma, to allow the compiler to display pleasant error 
messages. The langage could help you by allowing you to make hiearchized 
template constrains, but static if is a fine solution most of the time.

Re: K&R-style variadic functions

[Jacob Carlborg]

On 2012-07-17 09:06, Mehrdad wrote:


My eyes!! They're bleeding!!


First I wanted to know if my interpretation is correct and then I was 
trying to figure out how my tool should behave if it encounters a 
function like this.


--
/Jacob Carlborg

Re: Why doesn't to!MyEnumType(42) work

[Christophe Travert]

"Era Scarecrow" , dans le message (digitalmars.D:172568), a écrit :
> On Monday, 16 July 2012 at 21:59:17 UTC, Tommi wrote:
>> On Monday, 16 July 2012 at 20:22:12 UTC, Era Scarecrow wrote:
>>> MyEnumType y = cast(MyEnumType) 42; //Error: wtf is 42 anyways?
>>
>> Like the previous fellow said, it's not an error.
> 
>   I had the impression it was illegal by the compiler; Logically 
> forcing an enum to an invalid state is probably undefined and 
> unstable (but casting with compile-time constant that's provably 
> correct would be different). Also I've never tried force casting 
> the enums, so.. Hmmm...
> 
>   I suppose 'use at your own risk' applies here.

For what it's worth, I think cast should be at your own risk, and 
to!MyEnumType should assert the enum is valid.

Re: D versionning

[Wouter Verhelst]

"Chris NS"  writes:

> +1 for a "2.breaking.bugfix" scheme.  I've used this scheme on
> anything serious for years, and know many others who have; so it is
> not only popular but also quite tried and proven.  Not for every
> project, of course (although I don't understand why the Linux kernel
> team dropped it with 3.x), but for the majority it seems to work
> wonders.

They haven't, on the contrary.

3.x is a release with new features
3.x.y is a bugfix release.

Before the move to 3.x, this was 2.6.x and 2.6.x.y -- which was
confusing, because many people thought there was going to be a 2.8 at
some point when there wasn't.

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a

Re: Progress on std.container

[Tobias Pankrath]

I'm the bottleneck for that. My list of actual work (aside from 
my duties as phobos/druntime/tools/dlang.org curator) is:


1. Put std.benchmark through the review process

2. Define allocators

3. Integrate allocators with std.container

If you have fixes for std.container that are faraway from 
allocation issues, I think it's safe to propose them as pull 
requests. I assume the advent of allocators will be a uniform 
additive changes for all containers.



Thanks,

Andrei


What is left for std.benchmark before a second review can start?

We have several modules in the RQ or the TBD-Q (thinking about 
std.xml, std.json, std.benchmark, std.log) that are abandoned or 
at least don't get the love they deserve.


Maybe we should put a "what remains to be done" comment on those 
modules and advertise them as easy entry points for new 
contributors.

Definition of "OutputRange" insuficient

[monarch_dodra]

I was trying to fix a few bugs in algorithm, as well as be more 
correct in template type specifiers, and I have to say: There is 
a serious restraint in the definition of an outputRange.


The current definition of "isOutputRange" is simply that "an 
output range is defined functionally as a range that supports the 
operation put".


The problem with this is this definition is not very useful (at 
all). Not just because it lacks front/popFront (this is actually 
OK). It is because it lacks an "empty". This makes it virtually 
un-useable unless you are blind writing to an infinite output 
range.


The proof that it is useless is that NOT A SINGLE ALGORITHM is 
compatible with output ranges. All algorithms that really only 
require an "output" systematically actually require 
"isForwardRange", or, worse yet "isInputRange" (!). This is only 
because they all make use of range.empty.


Here is an example of me trying to write "fill" respecting output 
range restrictions.



void fill(Range1, Range2)(Range1 range, Range2 filler)
if (isOutputRange!(Range1, ElementType!Range2) && 
isForwardRange!Range2)

{
enforce(!filler.empty);
auto t = filler.save;
while (!range.empty) //Crud...
{
if (t.empty) t = filler.save;
put(range, t.front);
t.popFront();
}
}

Almost... but no cookie.

If the argument against this is "but the output range "can't know 
if it empty"/"may never be empty", then is why we have an 
"isInfinite" definition... isn't it?


On the same note, why is the definitions of "inputRange" so 
divergent from outputRange. Shouldn't inputRange's definition 
mirror output's and be "supports get" (and "is empty")?


Shouldn't a correct "front/popFront" _only_ be required once we 
reach "forwardRange" and it's ability to save?


Here is an example of an implementation of fill, that only 
requires the filler to be an input range, if it has infinity.


void fill(Range1, Range2)(Range1 range, Range2 filler)
if (isOutputRange!(Range1, ElementType!Range2) && 
isInputRange!Range2

&& isInfinite!Range2)
{
while( !range.empty )
{
put(range, get(filler));
}
}


The current definition makes anything like near impossible.

Re: K&R-style variadic functions

[Paulo Pinto]

On Tuesday, 17 July 2012 at 07:06:38 UTC, Mehrdad wrote:

On Tuesday, 17 July 2012 at 06:56:17 UTC, Jacob Carlborg wrote:

To my understanding this is legal C :

int foo ();

It's a K&R-style variadic functions, while their use is 
discouraged, they're still legal C.




My eyes!! They're bleeding!!


I had the "pleasure" to use K&R C in my early C days, around 
1992, yuck!

Re: std.algorithm imporvments

[monarch_dodra]

On Monday, 16 July 2012 at 22:42:47 UTC, Andrei Alexandrescu
wrote:
Wow, this is awesome. Did you discover that by inspection or by 
testing? I think a "malicious input range" would be a great 
tool for assessing which algorithms fail on input ranges.


Andrei


The first I discovered testing with a "ConsumableRange",
actually. The second, I found by inspection.

I'll correct those two issues myself, but I don't feel
comfortable with the other issues.

Re: K&R-style variadic functions

[Mehrdad]

On Tuesday, 17 July 2012 at 06:56:17 UTC, Jacob Carlborg wrote:

To my understanding this is legal C :

int foo ();

It's a K&R-style variadic functions, while their use is 
discouraged, they're still legal C.




My eyes!! They're bleeding!!

K&R-style variadic functions

[Jacob Carlborg]

To my understanding this is legal C :

int foo ();

It's a K&R-style variadic functions, while their use is discouraged, 
they're still legal C.


If I, in D, declare a variadic function with C linkage that doesn't 
take, at least, one regular parameter the compiler will complain.


extern (C) int foo (...);

Error: variadic functions with non-D linkage must have at least one 
parameter


Does that mean I can't use a function like this from D?

I'm trying to figure out what my tool, DStep, should do when it 
encounters a function like this.


https://github.com/jacob-carlborg/dstep

--
/Jacob Carlborg