Re: reference to 'self' inside a function

[Mehrdad]

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.


Recursive lambdas? o.O

Instead of changing the language, I'd say your situation merits 
using the Y combinator... maybe define Y(f) to be (g => g(g))(g 
=> f(x => g(g)(x)))

then if you need to define factorial, just say...
fact = Y(fact => n => n > 0 ? n * fact(n - 1) : 1);

Re: Octal Literals

[Andrei Alexandrescu]

On 7/18/12 1:39 PM, monarch_dodra wrote:

On Wednesday, 18 July 2012 at 17:37:02 UTC, Andrei Alexandrescu wrote:

On 7/18/12 10:29 AM, monarch_dodra wrote:

I see no reason not to add it


This is never a good argument for adding things to a language.

Andrei


Taken out of context, no it isn't. "It sounds like a good idea", is a
(relatively) good argument though.


Yah, thought the same after posting, sorry. Nevertheless, 0o or whatnot 
does not deserve, I opine, any attention.


Andrei

Re: Octal Literals

[monarch_dodra]

On Wednesday, 18 July 2012 at 17:37:02 UTC, Andrei Alexandrescu 
wrote:

On 7/18/12 10:29 AM, monarch_dodra wrote:

I see no reason not to add it


This is never a good argument for adding things to a language.

Andrei


Taken out of context, no it isn't. "It sounds like a good idea", 
is a (relatively) good argument though.

Re: K&R-style variadic functions

[Walter Bright]

On 7/18/2012 11:47 AM, Jacob Carlborg wrote:

On 2012-07-18 20:43, Walter Bright wrote:

On 7/18/2012 4:59 AM, Jacob Carlborg wrote:

Does that mean that this C++ declaration:

void foo (...);


Not allowed in C or C++.


When compiling in C++ mode, both Clang and GCC accepts this.


How would you get the arguments inside foo?

DMD stuck at semantic analyze

[Jacob Carlborg]

I just encountered a strange thing. I'm compiling my project, DStep, 
using DMD 2.059 and it get stuck at the semantic analyze (semantic3) of 
the following file:


https://github.com/jacob-carlborg/mambo/blob/43f7e8ffded8c50d6c1d864d472a8bcb511787e9/arguments/Arguments.d

It seems to have something to do with line 40. If I comment out that 
line DMD seems to behave correctly.


If I use latest git HEAD, DMD doesn't get stuck, it just exits at the 
same semantic analyze with exit code 0 and doesn't produce an executable.


I've done some tries to get a reduced test case but failed to reduce the 
code.


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

--
/Jacob Carlborg

Re: K&R-style variadic functions

[Jacob Carlborg]

On 2012-07-18 20:43, Walter Bright wrote:

On 7/18/2012 4:59 AM, Jacob Carlborg wrote:

Does that mean that this C++ declaration:

void foo (...);


Not allowed in C or C++.


When compiling in C++ mode, both Clang and GCC accepts this.


Is the same as this C declaration?

void foo ();


That is void foo(void) in C++.


--
/Jacob Carlborg

Re: K&R-style variadic functions

[Walter Bright]

On 7/18/2012 4:59 AM, Jacob Carlborg wrote:

Does that mean that this C++ declaration:

void foo (...);


Not allowed in C or C++.


Is the same as this C declaration?

void foo ();


That is void foo(void) in C++.

Re: Need runtime reflection?

[Jacob Carlborg]

On 2012-07-18 17:10, lijie wrote:

On Wed, Jul 18, 2012 at 2:59 PM, Jacob Carlborg mailto:d...@me.com>> wrote:

I think you can pass a module to a template via an alias parameter.
Then the template should be able to inspect all free functions using
something like __traits(allMembers).


Have a problem.

--
// file: A.d

module A;

// functions and classes
--

--
// file: testtraits.d

import std.stdio;
import A;

void main() {
   writeln(__traits(allMembers, A));
}
--

There is a compilation error:
testtraits.d(6): Error: import A has no members

If module is under a package name, it is OK, is that a bug?



Seems like it.

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

--
/Jacob Carlborg

Re: Octal Literals

[Andrei Alexandrescu]

On 7/18/12 10:29 AM, monarch_dodra wrote:

I see no reason not to add it


This is never a good argument for adding things to a language.

Andrei

Re: Octal Literals

[monarch_dodra]

On Tuesday, 17 July 2012 at 21:53:50 UTC, 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 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?


Coming from C++, the only time I've EVER seen octals used is "by 
accident" when developers try to 0-align his variables. Good 
riddance to the "0" prefix. Seriously >:(


That said, I did not know of this "0o" prefix. It sounds like a 
good idea, and I see no reason not to add it, other than it is 
hard work for the compiler devs of course, who already have a lot 
of work. :)

Re: Octal Literals

[H. S. Teoh]

On Wed, Jul 18, 2012 at 05:06:21PM +0200, Simen Kjaeraas wrote:
> On Wed, 18 Jul 2012 16:45:58 +0200, Dave X.  wrote:
> 
> >Not that this really matters, but out of curiosity, how does this
> >template work?
> 
> It converts the passed number to a string, then works on a digit at a
> time. Basically:
> 
> foreach ( digit; number ) {
>if ( digit >= '0' && digit <= '9' )
>   result = result * 8 + digit;
> }
[...]

And this is done at compile-time, so there is no runtime overhead (it
just becomes a constant like an actual literal).


T

-- 
"640K ought to be enough" -- Bill G., 1984. "The Internet is not a primary goal 
for PC usage" -- Bill G., 1995. "Linux has no impact on Microsoft's strategy" 
-- Bill G., 1999.

Re: Octal Literals

[Simen Kjaeraas]

On Wed, 18 Jul 2012 16:45:58 +0200, Dave X.  wrote:

Not that this really matters, but out of curiosity, how does this  
template work?


It converts the passed number to a string, then works on a digit at a
time. Basically:

foreach ( digit; number ) {
   if ( digit >= '0' && digit <= '9' )
  result = result * 8 + digit;
}

--
Simen

Re: Formal request to remove "put(OutRange, RangeOfElements)"

[Christophe Travert]

That sounds reasonable and justified. Let's wait to know if people 
maintaining legacy code will not strongly oppose to this.

Formal request to remove "put(OutRange, RangeOfElements)"

[monarch_dodra]

I'm really very sorry that this is such a long post, but I'd like 
to make request for a serious change to Phobos, so I think it 
should be as complete as possible.


Thank you to those who have the patience to read it and consider 
it.



**
Abstract:

  This is a formal request for the deprecation of the the support 
for accepting ranges of elements for the function "put" ie 
(put(OutRange, RangeOfElements)).


  As convenient as this functionality may be is, it undermines 
the very definition of what constitutes an output range, and 
creates some fundamental problems when trying to deal with them.


  put(Range, RangeOfElements) doesn't actually bring anything to 
the table that would be missed.


**
Explanation:

  The problem is not "put" in and out of itself, but rather that 
it is the fundamental definition of what constitutes an output 
range. In particular, because you cannot extract elements from 
output ranges, and because an output range can potentially 
support multiple types, you cannot write:
  "ElementType!OutputRange" => this will yield "void" on a 'true' 
output range. Rather, you have to individually query if the range 
is an output for specific types:

  "isOutputRange!(OutputRange, SomeElement)"

  The catch is that the definition of "isOutputRange" is just 
"does "put(range, element)" compile". This means that 
essentially, as soon as a range is an output for elements, it 
becomes an output for ranges of elements, for ranges of ranges of 
elements, for ranges of ranges of ranges of elements, for ...


For example: int[] is an outputRange of int (obviously), but it 
is also defined as an output range of int[], int[2], and 
int[][]...

This is clearly not right.

**
Problems put creates for template restrictions:

  At it simplest, it prevents any algorithm from properly working 
with outputRanges. This is the definition of "copy":


Range2 copy(Range1, Range2)(Range1 source, Range2 target)
  if (isInputRange!Range1 && isOutputRange!(Range2, 
ElementType!Range1))


See the trap? This is perfectly legal code:
  int a[][][][];
  int b[];
  copy(a, b);

  Look bad? it gets worse. Imagine the function fill. It works 
the same as "copy", but it can also take an "element" as an 
argument. One would be tempted to write this pair of signatures:


void fill(Range1, Range2)(Range1 target, Element filler)
  if(isOutputRange(Range1, Element))

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


You can try to write this, but if you do, the code will never 
work. ANYTHING that matches the range fill, will also match the 
element based fill, since the target range supports "put" from a 
range... For example:

int[2] a = [1, 2];
int[] b = new int[](8);
fill(b, a); //ambiguous call...
//Are you copying a "range" or an "element"?
//Answer: Who know! Honestly: if b is an output range of a, WHICH 
IS THE RIGHT CALL?


  The only way to really avoid this problem (as is currently done 
in algorithm.d) is to add: "is(typeof(range.front = filler))", 
but this defeats the very requirement of outputRange (outputRange 
does not have front), and bumps the algorithm's requirements up 
to "inputRange".


  Long story short, it is not currently possible to write 
templates that reliably support an outputRange restriction.


**
Problems put creates for implementation:

  The big problem about put is that it makes outputRanges _lie_ 
about what they support. Here is an example at its simplest:


alias int[] A; alias int[] B;
A a = new int[](2);
B b = new int[](1);
assert(isOutputRange!(typeof(a), typeof(b)));
if(!b.empty)
  b.put(a);

  In this code:
*b is an output range of A.
*b is not empty.
*putting an A inside b creates a empty range exception !?

  While this example might look "cute", it is also unacceptable 
behavior. if b is a non-empty range that supports "elements A", 
then it _HAS_ to be able to support a put. In this case, b 
clearly does not support elements of type A.


  I'm sure you can imagine the kinds of problems this can caue 
for a template developer.


**
Why we don't need put(Range):

  Quite simply: because we have the higher order function. The 
convenience "put(Range)" is nothing more than a glorified 
algorithm. Instead of using put, the user should make a call to 
copy. "copy" is designed specifically for copying an input range 
into an output range. Why duplicate this functionality into put? 
Calling copy is much more honest and accurate about what is 
actually happening.


**
Problems regarding removing put(Range):

  In theory, the only problem this would create is breaking code 
which can be legitimately replaced by “copy” wi

Re: Octal Literals

[Caligo]

This article by Walter might be of an interest to you:

http://www.drdobbs.com/tools/user-defined-literals-in-the-d-programmi/229401068

On Tue, Jul 17, 2012 at 4:53 PM, 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 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: std.algorithm imporvments

[monarch_dodra]

On Tuesday, 17 July 2012 at 17:19:31 UTC, Jonathan M Davis wrote:

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


Hi Jonathan,

I've made changes to algorithm to the best of my abilities. If it 
does not meet requirements, please tell me what is wrong, and all 
work on it as I can. I've put an in-depth explanation of the 
changes in the pull request description.


Slightly on topic, did you read my post about "Definition of 
"OutputRange" insuficient""? Would it be OK to add "hasLength" to 
range.d? This would be the first step to making outputRanges more 
useable, without directly changing the definition of an output 
range quite yet.

Re: Octal Literals

[Christophe Travert]

"Dave X." , dans le message (digitalmars.D:172680), a écrit :
> Not that this really matters, but out of curiosity, how does this 
> template work?


By looking at the sources, if the template argument is a string, the 
program just compute the octal value as a human would do, that is it 
makes the sum of the digits multiplied by their respective power of 8. 
If the template argument is not a string, it is transformed into a 
string and the previous algorithm is used.

-- 
Christophe

Re: Need runtime reflection?

[lijie]

On Wed, Jul 18, 2012 at 2:59 PM, Jacob Carlborg  wrote:

> I think you can pass a module to a template via an alias parameter. Then
> the template should be able to inspect all free functions using something
> like __traits(allMembers).
>
>
Have a problem.

--
// file: A.d

module A;

// functions and classes
--

--
// file: testtraits.d

import std.stdio;
import A;

void main() {
  writeln(__traits(allMembers, A));
}
--

There is a compilation error:
testtraits.d(6): Error: import A has no members

If module is under a package name, it is OK, is that a bug?

Random sampling in D -- blog post

[Joseph Rushton Wakeling]

Hello all,

My patches to RandomSample were accepted earlier this month (thanks to both 
Jonathan and Andrei:-) so I thought I'd write a short blog post (which turned 
into a very long blog post...) about random sampling, the algorithms concerned, 
and its implementation in D.

http://braingam.es/2012/07/sampling-d/

If anyone's interested I may write up something more extended on the algorithms 
(if I can find a decent maths-notation solution for WordPress...) and on the D 
framework for random sampling (it could be fun to put up some creative examples 
of how to use it with different kinds of input).


Best wishes,

-- Joe

Re: Octal Literals

[Dave X.]

On Tuesday, 17 July 2012 at 22:35:48 UTC, Nick Sabalausky wrote:

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.


Thanks! I guess I'll get used to it.

Not that this really matters, but out of curiosity, how does this 
template work?

Re: Re-thinking D's modules

[Paulo Pinto]

On Wednesday, 18 July 2012 at 13:55:10 UTC, Marco Leise wrote:

Am Wed, 18 Jul 2012 11:56:45 +0200
schrieb "Paulo Pinto" :

Last time I checked, I could compile Java and C# to native 
code if I wished to do so.


--
Paulo


Forum.getUserByName("Paulo Pinto").addAttribute("nit-picky"); ;)


Yeah, I guess I deserve it. :)

Re: Re-thinking D's modules

[Marco Leise]

Am Wed, 18 Jul 2012 11:56:45 +0200
schrieb "Paulo Pinto" :

> Last time I checked, I could compile Java and C# to native code 
> if I wished to do so.
> 
> --
> Paulo

Forum.getUserByName("Paulo Pinto").addAttribute("nit-picky"); ;)

-- 
Marco

Re: K&R-style variadic functions

[H. S. Teoh]

On Wed, Jul 18, 2012 at 11:23:33AM +0100, Regan Heath wrote:
> On Tue, 17 Jul 2012 19:39:25 +0100, H. S. Teoh
>  wrote:
[...]
> >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);
> > }
> 
> Clarification.
> 
> The /definition/ is as you have above, the /declaration/ is not.
> The declaration is what goes in the header file, and in K&R (and
> ANSI C for that matter) looks like:
> 
> int main();
> 
> parameters are not required for the declaration, only the definition.
[...]

You are right.

And also, under K&R syntax, the 'int' can be omitted from before main. I
*think* the entire argc line can be omitted as well (undeclared
variables default to int, IIRC). 'Tis a strange world they used to live
in. :-)


T

-- 
Almost all proofs have bugs, but almost all theorems are true. -- Paul Pedersen

Re: Initialization of std.typecons.RefCounted objects

[Christophe Travert]

I see you found the appropriate entry to discuss this bug:

http://d.puremagic.com/issues/show_bug.cgi?id=6153

Re: Initialization of std.typecons.RefCounted objects

[Christophe Travert]

Matthias Walter , dans le message (digitalmars.D:172673), a écrit :
> I looked at Bug #6153 (Array!(Array!int) failure) and found that the
>
> This exactly is what makes the following code fail:
> 
> Array!(Array!int) array2d;
> array2d.length = 1;
> array2d[0].insert(1);
> 
> The inner array "array2d[0]" was not initialized and hence the reference
> pointer is null. Since Array.opIndex returns by value, the 'insert'
> method is called on a temporary object and does not affect the inner
> array (still being empty) which is stored in the outer array.
> 
> What do you think about this?
> 
> Must the user ensure that the Array container is always initialized
> explicitly? If yes, how shall this happen since the only constructor
> takes a (non-empty) tuple of new elements. Or shall opIndex return by
> reference?

I think opIndex should return by reference. opIndexAssign is of no help 
when the user want to use a function that takes a reference (here 
Array.insert). It is normal that Array uses default construction when 
someone increases the array's length.

Besides that point, I don't see why default-constructed Array have an 
uninitialised Payload. This makes uninitialised Array behaves 
unexpectedly, because making a copy and using the copy will not affect 
the original, which is not the intended reference value behavior.

Correcting default-initialization of Array would correct your bug, but 
would not correct the wrong behavior of Array when the value returned by 
opIndex is used with a non-const method with other objects (dynamic 
arrays?). So both have to be changed in my opinion.

-- 
Christophe

Re: reference to 'self' inside a function

[angel]

True, but the concept could still be used, we just need some 
syntax.


IMHO introducing a new keyword is the clearest solution.
As for the danger of breaking existing code, let's face it, there 
is no whole world legacy written in D with extensive use of 
'thisFunc' keyword.

Initialization of std.typecons.RefCounted objects

[Matthias Walter]

Hi,

I looked at Bug #6153 (Array!(Array!int) failure) and found that the
reason is the following behavior:

Given some type T you wrap as RefCounted!T object, then proper use of
the auto-initialization feature or manual initialization on demand
ensures that no null-pointer dereference will happen. But the other
problem is that as long as the wrapped object is uninitialized, the
object behaves like a value type instead of a reference type.

This exactly is what makes the following code fail:

Array!(Array!int) array2d;
array2d.length = 1;
array2d[0].insert(1);

The inner array "array2d[0]" was not initialized and hence the reference
pointer is null. Since Array.opIndex returns by value, the 'insert'
method is called on a temporary object and does not affect the inner
array (still being empty) which is stored in the outer array.

What do you think about this?

Must the user ensure that the Array container is always initialized
explicitly? If yes, how shall this happen since the only constructor
takes a (non-empty) tuple of new elements. Or shall opIndex return by
reference?

The problem arises in the same way if Array was a class - but then the
user typically knows that after enlarging the outer array, the inner
array is a null pointer which must be created by new.

Best regards,

Matthias Walter

Re: K&R-style variadic functions

[Jacob Carlborg]

On 2012-07-18 11:41, Walter Bright wrote:


Variadic functions, in order to work in C, need at least one parameter
so that varargs can work.

   int foo();

declares a function with an unspecified parameter list, not a variadic
one. It is specified by a definition somewhere:

   int foo(a,b)
   int a;
   int b;
   { ... }

somewhere.


I think I understand now.


If Dstep encounters the first declaration form, your options are to:

1. reject it (a perfectly reasonable approach)

2. treat it as:

 int foo(void);

I suggest option 2, which is what C++ does.


Sounds reasonable. I will also provide a flag specifying how this should 
be handled.


I actually found library that uses this style of declaration. It's used 
in several places in libruby. For example:


void rb_define_virtual_variable(const 
char*,VALUE(*)(ANYARGS),void(*)(ANYARGS));


ANYARGS is defined as:

#ifdef __cplusplus
#define ANYARGS ...
#else
#define ANYARGS
#endif

Does that mean that this C++ declaration:

void foo (...);

Is the same as this C declaration?

void foo ();

I'm wondering if the intention is to cast these function pointers to 
their correct signature before calling them.


--
/Jacob Carlborg

Re: D versionning

[Chris NS]

On Tuesday, 17 July 2012 at 18:12:28 UTC, Iain Buclaw wrote:

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.


I don't recall where I first got my information, but clearly I 
was mistaken.  And I'm happy to have been so.  Maybe if I 
actually kept up more with the info on kernel releases I'd have 
known... alas.


-- Chris NS

Re: Re-thinking D's modules

[Jacob Carlborg]

On 2012-07-18 12:23, Dejan Lekic wrote:


I am aware of the Orbit project, but what Jigsaw will do for Java, and
what similar built-in module versioning in other languages do, is to
give control of pieces of large software systems. Having module version
as part of the language will give tools like Orbit a nice, standardized
way to know what is the module version of a D source file it is
currently processing. Later on, it may help compilers create SO/DLL
version information if a certain module becomes a library...
Say you have a product, and you want to provide support for all legacy
versions. One way to that is to put all old(er) versions of a module
into a single library. If the module is not versioned, you would have to
use external module information, typically stored in bunch of config
files, and what is worse is quite often, if you lose these files, you
have no idea what module version it was... (Unless you are pedantic, and
write that information in the header comment of the module)

I use Maven a lot, every day, Jigsaw is not a replacement for Maven, it
is a help to Maven, coming from the language itself.


Yeah, sure. With language support we could do much more. Orbit is 
focused at working without language support, at least as a start.


--
/Jacob Carlborg

Re: K&R-style variadic functions

[Jacob Carlborg]

On 2012-07-18 12:25, Regan Heath wrote:

In any case.  It think the practical solution to this problem is to
assume you're working with modern code, and have a command line option
to make it assume K&R or old-style declarations.

In the old-style mode you would have to assume a function with an empty
() could have any number of parameters and the best you can do is produce:

extern (C)  (/* fill in the blanks please*/);

R


Seems like this will be the solution.

--
/Jacob Carlborg

Re: Orbit (Was: Re-thinking D's modules)

[Jacob Carlborg]

On 2012-07-18 12:07, Nick Sabalausky wrote:


Speaking of, how's that coming along?


I haven't been working on that for a while. I've been working on DStep. 
The most basic functionality is there:


* Creating packages
* Installing packages
* Downloading packages
* Uploading packages

Although no real dependency algorithm is implemented yet. I think 
there's a really simple one, if I recall correctly.


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

--
/Jacob Carlborg

Re: Re-thinking D's modules

[Paulo Pinto]

On Wednesday, 18 July 2012 at 09:59:03 UTC, Marco Leise wrote:

Am Wed, 18 Jul 2012 10:24:36 +0100
schrieb Russel Winder :

Go solves the problem by refusing all notion of dynamic 
linking and

insisting on static linking of all applications.


... not possible? While I learned a while back that system 
calls exist and are not dynamically linked, I wonder how Go 
goes about:


* basic system libraries (static linking to kernel32.dll?)
* executable bloat from large OO toolkits like Qt


Don't flame me, just giving the typical set of answers in gonuts,
which you can easily find when searching for .so/.dll discussions.

Use strip to reduce executable size.

* increased memory footprint by not allowing shared instances 
of DLLs/SOs
* modular development (e.g. separating "server" and "client" 
code in games)


Separate code in common packages, while generating separate 
executables.



* dynamically loadable plugins/extensions


From the security point of view loadable plugins are not good.

Better make use of IPC to communicate between plugins.

If you need performance, make use of shared memory as IPC 
mechanism,

which incidentally invalidates the security reasons.


* security and bug fixes to libraries used in dozens of programs
  (-> recompile of all library users ?)


yes

Re: reference to 'self' inside a function

[Kevin Cox]

On Jul 18, 2012 6:20 AM, "FeepingCreature" 
wrote:
>
> On 07/18/12 01:05, Kevin Cox wrote:
> >

> > 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.
> Sadly, this collides with the return-type syntax already in place.
>
> auto f = function int(int i) { return 0; };

True, but the concept could still be used, we just need some syntax.

Re: K&R-style variadic functions

[Regan Heath]

On Tue, 17 Jul 2012 19:08:51 +0100, Paulo Pinto   
wrote:



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


That's what I've been assuming all this time, but I wasn't sure if I was  
technically (according to the spec) right, so I didn't want to say.. :)


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 20:42:09 +0100, Jacob Carlborg  wrote:


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.


It certainly seems intentional:

  if (T->getAs())
return 1;

I wonder if it's a case of "we can't be certain, so lets assume it is" or  
similar.


R

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

Re: K&R-style variadic functions

[Regan Heath]

In any case.  It think the practical solution to this problem is to assume  
you're working with modern code, and have a command line option to make it  
assume K&R or old-style declarations.


In the old-style mode you would have to assume a function with an empty ()  
could have any number of parameters and the best you can do is produce:


extern (C)  (/* fill in the blanks please*/);

R

Re: Re-thinking D's modules

[Dejan Lekic]

Go solves the problem by refusing all notion of dynamic linking 
and

insisting on static linking of all applications.


God, I feel sorry for programmers who use Go, in that case...

Re: Re-thinking D's modules

[Dejan Lekic]

Something like: 
https://github.com/jacob-carlborg/orbit/wiki/Orbit-Package-Manager-for-D


I am aware of the Orbit project, but what Jigsaw will do for 
Java, and what similar built-in module versioning in other 
languages do, is to give control of pieces of large software 
systems. Having module version as part of the language will give 
tools like Orbit a nice, standardized way to know what is the 
module version of a D source file it is currently processing. 
Later on, it may help compilers create SO/DLL version information 
if a certain module becomes a library...
Say you have a product, and you want to provide support for all 
legacy versions. One way to that is to put all old(er) versions 
of a module into a single library. If the module is not 
versioned, you would have to use external module information, 
typically stored in bunch of config files, and what is worse is 
quite often, if you lose these files, you have no idea what 
module version it was... (Unless you are pedantic, and write that 
information in the header comment of the module)


I use Maven a lot, every day, Jigsaw is not a replacement for 
Maven, it is a help to Maven, coming from the language itself.

Re: K&R-style variadic functions

[Regan Heath]

On Tue, 17 Jul 2012 20:31:19 +0100, Jacob Carlborg  wrote:


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


The full quote:

"In the above example, a prototype is used in a function declaration for  
ANSI compliant implementations, while an obsolescent non-prototype  
declaration is used otherwise. Those are still ANSI-compliant as of C99  
and C90, but their use is discouraged."


1) "a prototype is used in a function declaration for ANSI compliant  
implementations"

implies an ANSI compliant compiler /requires/ the full prototype.

2) "obsolescent non-prototype declaration is used otherwise"
implies non-prototype forms are /obsolete/

3) "Those are still"
what is being referred to by the word "those" in that sentence, it's not  
immediately clear to me.  It could mean the non-prototype (as you've  
assumed) but it might also mean the entire construct (using "#if  
__STDC__").


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 19:39:25 +0100, 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);
}


Clarification.

The /definition/ is as you have above, the /declaration/ is not.  The  
declaration is what goes in the header file, and in K&R (and ANSI C for  
that matter) looks like:


int main();

parameters are not required for the declaration, only the definition.

R

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

Re: reference to 'self' inside a function

[FeepingCreature]

On 07/18/12 01:05, Kevin Cox wrote:
> 
> 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.
> 
Sadly, this collides with the return-type syntax already in place.

auto f = function int(int i) { return 0; };

Orbit (Was: Re-thinking D's modules)

[Nick Sabalausky]

On Wed, 18 Jul 2012 11:12:22 +0200
Jacob Carlborg  wrote:
> 
> Something like: 
> https://github.com/jacob-carlborg/orbit/wiki/Orbit-Package-Manager-for-D
> 

Speaking of, how's that coming along?

Re: Re-thinking D's modules

[Marco Leise]

Am Wed, 18 Jul 2012 10:24:36 +0100
schrieb Russel Winder :

> Go solves the problem by refusing all notion of dynamic linking and
> insisting on static linking of all applications.

... not possible? While I learned a while back that system calls exist and are 
not dynamically linked, I wonder how Go goes about:

* basic system libraries (static linking to kernel32.dll?)
* executable bloat from large OO toolkits like Qt
* increased memory footprint by not allowing shared instances of DLLs/SOs
* modular development (e.g. separating "server" and "client" code in games)
* dynamically loadable plugins/extensions
* security and bug fixes to libraries used in dozens of programs
  (-> recompile of all library users ?)

-- 
Marco


signature.asc
Description: PGP signature

Re: Re-thinking D's modules

[Paulo Pinto]

On Wednesday, 18 July 2012 at 09:43:09 UTC, Marco Leise wrote:

[..]
Unlike byte code languages like Java or C#, native compiled 
languages must also consider the target platform in addition to 
the module version. [...]


Last time I checked, I could compile Java and C# to native code 
if I wished to do so.


--
Paulo

Re: Re-thinking D's modules

[Dejan Lekic]

Jigsaw has just been dropped from Java 8.
http://mreinhold.org/blog/late-for-the-train


Erm, read my original post - I did not mention Java 8, i wrote 
"Java 9 SE"...

Re: Re-thinking D's modules

[Paulo Pinto]

On Wednesday, 18 July 2012 at 09:25:03 UTC, Russel Winder wrote:

[…]
Isn't the real question why is the same dynamic library linking 
problem
happening again. Has nothing been learned from UNIX shared 
objects and

Windows DLLs?

Go solves the problem by refusing all notion of dynamic linking 
and

insisting on static linking of all applications.



As I already mentioned a few times in Gonuts, static linking makes
it hard to implement certain types of applications.

Plus, the Go folks seem to live in open source land, where the 
code
for all 3rd party libraries is available, and no one has any 
issues

with licenses that forbade static linking.

Their attitude to keep versioning out of "go get" is a reflection 
of this.


For those that don't know .NET, due to the DLL Hell 
experience, Microsoft

has built version support in the CLR from day 1.


But, as ever, Microsoft see things like this as a way to try 
and get
everyone to use Windows via proprietary lock-in rather than by 
trying to

educate people about possible solutions.


To be fair to Microsoft, I am yet to see a commercial vendor that
does not do that.

The ones that do, usually have some consulting agenda, 
certifications,

whatever, to sell along their "free and standard" solution.


--
Paulo

Re: K&R-style variadic functions

[Walter Bright]

On 7/16/2012 11:56 PM, 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.


Variadic functions, in order to work in C, need at least one parameter so that 
varargs can work.


  int foo();

declares a function with an unspecified parameter list, not a variadic one. It 
is specified by a definition somewhere:


  int foo(a,b)
  int a;
  int b;
  { ... }

somewhere.

If Dstep encounters the first declaration form, your options are to:

1. reject it (a perfectly reasonable approach)

2. treat it as:

int foo(void);

I suggest option 2, which is what C++ does.

Re: Re-thinking D's modules

[Marco Leise]

Am Wed, 18 Jul 2012 10:08:19 +0200
schrieb "Dejan Lekic" :

> There are several places for D module system to improve.
> One thing we discussed in the past is the versioning, and as far 
> as I remember, we did not come to any constructive conclusion.
> 
> Java has been criticised often for not having modules. Apparently 
> Java 9 SE will have them, and in my humble opinion, Java 9 module 
> system is going to be far more powerful (or perhaps better word 
> would be USEFUL) than what D currently has.
> 
> More about Java Jigsaw: 
> http://cr.openjdk.java.net/~mr/jigsaw/notes/jigsaw-big-picture-01
> 
> Why is this better? - Speaking from a (senior) software engineer 
> point of view, Java Jigsaw is engineered for large systems where 
> versioning, module-dependency, and module-restrictions are very 
> important.
> 
> I do not like few things about Jigsaw, but most of the things 
> they plan there simply make sense, especially the versioning and 
> module-restrictions, which I urge D developers to take a look and 
> come up with something similar for D2 or D3... This is extremely 
> useful, and will be even more useful once we have shared 
> libraries where we can have N different shared libraries that 
> contain the same module, but different version of it...
> 
> Kind regards
> 

Shared library versioning and dependency management is traditionally done at 
the OS level (WinSxS, soname, package managers). That may also apply to what is 
exported aka visible from a library aka module (e.g. export-all policy). Unlike 
byte code languages like Java or C#, native compiled languages must also 
consider the target platform in addition to the module version. In addition to 
this, the scope of a Java module can be anything, up to a complete tomcat web 
server, whereas the scope of a D module is a single file. A Java module can 
contain several packages, a D module cannot.

The main difference is in the eco system, in my opinion. Java or .NET are 
platforms on their own while systems languages integrate with the hardware and 
OS (starting with calling conventions, up to high-level dependency management). 
Java is free to innovate here, it is 'their' platform.

Maybe you can elaborate a bit more on what module-restrictions are useful for. 
I think they are the only feature that I haven't seen in package managers or 
programming languages. Also the compiler doesn't currently scan shared 
libraries or even require them to exist. The resolution of symbols is deferred 
to the linking stage where there are existing mechanisms to hide symbols from a 
library. And some people like the export-all policy with no hidden symbols, so 
we are in for a hot discussion on details. :D

P.S.: I am all for a D package manager for developers, that can pull source 
code and bindings from the web.

-- 
Marco

Re: Re-thinking D's modules

[bearophile]

Dejan Lekic:

I do not like few things about Jigsaw, but most of the things 
they plan there simply make sense, especially the versioning 
and module-restrictions, which I urge D developers to take a 
look and come up with something similar for D2 or D3...


Keep in mind that D language seems designed for its parts to be 
minimal (this means "the simplest thing that works"), and that 
the D module system is not yet fully implementing its current 
simple design.


In past I have asked for those "Entry points" (that it's an 
unsolved problem in D), and I appreciate those "Exports". The 
versioning too seems useful.


Bye,
bearophile

Re: Re-thinking D's modules

[Russel Winder]

On Wed, 2012-07-18 at 11:00 +0200, Paulo Pinto wrote:
[…]
> > Java has been criticised often for not having modules. 

In the beginning there was WORA which assumed so much that was
unrealistic. It's consequence has been that artefact versioning is a
complete mess in Java.  OK so the Maven repository and build frameworks
like Gradle and Maven are getting close to defeating the problem. Sadly
transitive dependencies are still a nightmare.

Of course I have probably violated a Sun/Oracle patent by even
mentioning the acronym WORA.

> > Apparently Java 9 SE will have them, and in my humble opinion, 
> > Java 9 module system is going to be far more powerful (or 
> > perhaps better word would be USEFUL) than what D currently has.
> >
> > More about Java Jigsaw: 
> > http://cr.openjdk.java.net/~mr/jigsaw/notes/jigsaw-big-picture-01

Assuming that it doesn't get bounced to Java 10. It already got bounced
from Java 7 to Java 8 and now Java 8 to Java 9.

> > Why is this better? - Speaking from a (senior) software 
> > engineer point of view, Java Jigsaw is engineered for large 
> > systems where versioning, module-dependency, and 
> > module-restrictions are very important.
> >
> > I do not like few things about Jigsaw, but most of the things 
> > they plan there simply make sense, especially the versioning 
> > and module-restrictions, which I urge D developers to take a 
> > look and come up with something similar for D2 or D3... This is 
> > extremely useful, and will be even more useful once we have 
> > shared libraries where we can have N different shared libraries 
> > that contain the same module, but different version of it...

Isn't the real question why is the same dynamic library linking problem
happening again. Has nothing been learned from UNIX shared objects and
Windows DLLs?

Go solves the problem by refusing all notion of dynamic linking and
insisting on static linking of all applications.

> >
> > Kind regards
> 
> Jigsaw has just been dropped from Java 8.
> http://mreinhold.org/blog/late-for-the-train

That is because to all intents and purposes Jigsaw is vapourware.  The
competition, that the Jigsaw folks are studiously ignoring, is OSGi. I
know there are some slight differences in overall aim and goal between
the two, but in the end the effect is the same: being able to run
different versions of the same artefact on the same JVM in the same
application.

> Still I would say this is so relevant that most current build 
> systems
> have versions as first class concept.

Certainly Gradle and Maven support this idea very well.  Sadly Make,
CMake, Autotools, SCons, Waf,… tend to delegate the problem to someone
else.

> For those that don't know .NET, due to the DLL Hell experience, 
> Microsoft
> has built version support in the CLR from day 1.

But, as ever, Microsoft see things like this as a way to try and get
everyone to use Windows via proprietary lock-in rather than by trying to
educate people about possible solutions. Otherwise we would already have
solved the problem rather than have the shared object mess we currently
have, OSGi, Jigsaw, the mess that is Debian and Fedora support for
multiple versions of dynamically linked libraries and Java artefacts.

Sadly I have nothing constructive to say except that which stems from
the above: in a large system comprising subsystems with transitive
dependencies, if I cannot use different versions of the same subsystem
in the overall system then everything will break. Especially in the face
of dependency injection.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


signature.asc
Description: This is a digitally signed message part

Re: Re-thinking D's modules

[Jacob Carlborg]

On 2012-07-18 10:08, Dejan Lekic wrote:

There are several places for D module system to improve.
One thing we discussed in the past is the versioning, and as far as I
remember, we did not come to any constructive conclusion.

Java has been criticised often for not having modules. Apparently Java 9
SE will have them, and in my humble opinion, Java 9 module system is
going to be far more powerful (or perhaps better word would be USEFUL)
than what D currently has.

More about Java Jigsaw:
http://cr.openjdk.java.net/~mr/jigsaw/notes/jigsaw-big-picture-01

Why is this better? - Speaking from a (senior) software engineer point
of view, Java Jigsaw is engineered for large systems where versioning,
module-dependency, and module-restrictions are very important.

I do not like few things about Jigsaw, but most of the things they plan
there simply make sense, especially the versioning and
module-restrictions, which I urge D developers to take a look and come
up with something similar for D2 or D3... This is extremely useful, and
will be even more useful once we have shared libraries where we can have
N different shared libraries that contain the same module, but different
version of it...

Kind regards



Something like: 
https://github.com/jacob-carlborg/orbit/wiki/Orbit-Package-Manager-for-D


--
/Jacob Carlborg

Re: Re-thinking D's modules

[Paulo Pinto]

On Wednesday, 18 July 2012 at 08:08:21 UTC, Dejan Lekic wrote:

There are several places for D module system to improve.
One thing we discussed in the past is the versioning, and as 
far as I remember, we did not come to any constructive 
conclusion.


Java has been criticised often for not having modules. 
Apparently Java 9 SE will have them, and in my humble opinion, 
Java 9 module system is going to be far more powerful (or 
perhaps better word would be USEFUL) than what D currently has.


More about Java Jigsaw: 
http://cr.openjdk.java.net/~mr/jigsaw/notes/jigsaw-big-picture-01


Why is this better? - Speaking from a (senior) software 
engineer point of view, Java Jigsaw is engineered for large 
systems where versioning, module-dependency, and 
module-restrictions are very important.


I do not like few things about Jigsaw, but most of the things 
they plan there simply make sense, especially the versioning 
and module-restrictions, which I urge D developers to take a 
look and come up with something similar for D2 or D3... This is 
extremely useful, and will be even more useful once we have 
shared libraries where we can have N different shared libraries 
that contain the same module, but different version of it...


Kind regards


Jigsaw has just been dropped from Java 8.
http://mreinhold.org/blog/late-for-the-train

Still I would say this is so relevant that most current build 
systems

have versions as first class concept.

For those that don't know .NET, due to the DLL Hell experience, 
Microsoft

has built version support in the CLR from day 1.

--
Paulo

Re-thinking D's modules

[Dejan Lekic]

There are several places for D module system to improve.
One thing we discussed in the past is the versioning, and as far 
as I remember, we did not come to any constructive conclusion.


Java has been criticised often for not having modules. Apparently 
Java 9 SE will have them, and in my humble opinion, Java 9 module 
system is going to be far more powerful (or perhaps better word 
would be USEFUL) than what D currently has.


More about Java Jigsaw: 
http://cr.openjdk.java.net/~mr/jigsaw/notes/jigsaw-big-picture-01


Why is this better? - Speaking from a (senior) software engineer 
point of view, Java Jigsaw is engineered for large systems where 
versioning, module-dependency, and module-restrictions are very 
important.


I do not like few things about Jigsaw, but most of the things 
they plan there simply make sense, especially the versioning and 
module-restrictions, which I urge D developers to take a look and 
come up with something similar for D2 or D3... This is extremely 
useful, and will be even more useful once we have shared 
libraries where we can have N different shared libraries that 
contain the same module, but different version of it...


Kind regards

Re: Need runtime reflection?

[Jacob Carlborg]

On 2012-07-18 09:26, lijie wrote:


It is an optional way. I want to do all thing in D code.


You can do this in D.

--
/Jacob Carlborg

Re: Need runtime reflection?

[lijie]

On Wed, Jul 18, 2012 at 2:59 PM, Jacob Carlborg  wrote:

> On 2012-07-18 06:10, lijie wrote:
>
>  Free functions support is hard, with runtime cast, I just think compile
>> time.
>>
>
> It's possibly to implement runtime reflection by loading the running
> executable and inspecting the symbol table. It's an ugly hack but it should
> work.
>
> http://flectioned.kuehne.cn/


It is an optional way. I want to do all thing in D code.


>
>
>  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.
>>
>
> I think you can pass a module to a template via an alias parameter. Then
> the template should be able to inspect all free functions using something
> like __traits(allMembers).


I didn't know this usage, I will try it. Thanks.

Re: reference to 'self' inside a function

[angel]

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


Like this ?
auto fac = delegate(int n) {
if (n <= 1)
return 1;
return n * mixin(__FUNCTION__)(n - 1);
};

Well, there are a few problems with this:
- it _is_ ugly
- some 'automatic' name should be generated internally (possibly 
it is in any case)

- it doesn't currently work

Possibly more streamlined approach would be:
thisFunc (or 'self', or whatever)
thisFunc.stringof istead of __FUNCTION__

Re: Rust updates

[Marco Leise]

Am Tue, 17 Jul 2012 21:39:33 +0200
schrieb "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.

The irony is: "Rust intentionally does not include any novel or untested 
ideas." - Wikipedia

-- 
Marco

Re: Need runtime reflection?

[Jacob Carlborg]

On 2012-07-18 06:10, lijie wrote:


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


It's possibly to implement runtime reflection by loading the running 
executable and inspecting the symbol table. It's an ugly hack but it 
should work.


http://flectioned.kuehne.cn/


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.


I think you can pass a module to a template via an alias parameter. Then 
the template should be able to inspect all free functions using 
something like __traits(allMembers).


--
/Jacob Carlborg