www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - 1.0 ??

reply Georg Wrede <georg.wrede nospam.org> writes:
1.0?

Does that imply a simultaneous 1.0 for D and DMD??

Suppose they were decoupled. Then we might decide on D 1.0 (say in 
December) and from there go on with fixing library issues, *installing* 
issues (especially on Linux), and even try to create a package that 
strives to be as good as Shrink-Wrap, i.e. simply work out of the box, 
and be somewhat usable regarding GUI development. Say, in March.

In the meantime we could polish DMD, interact with the GDC guys to get 
the two exactly alike, and then maybe even write some example code with 
more user value than the current printf-Hello-World style examples.

---

I recently talked with a CIO (who was somewhat familiar with D), who 
said that "short of taking a snapshot of D and sticking with it, there's 
no way we're gonna start using a moving target as our base, no matter if 
it's ten times as good as the next language." And he didn't seem likely 
to go the snapshot way.

The implication being that 1.0 or not, what a company needs is 
stability. Stability in code, tools, programmer knowledge (as in hiring 
and firing folks), a developer community specifically knowledgeable with 
the problems of the _current_ version, a community developing and 
maintaining up to date libraries targeted _precisely_ at the current 
release, and of course a conviction that the current state of affairs 
will continue for a reasonable amount of time (i.e. a belief in 
everything not becoming obsolete in three months, be it due to a super 
cool new version or simply code-breaking upgrades).

So,,, we need to create an _illusion_ of stability. This might be by 
publishing 1.0, and at the same time separating the newsgroups into two 
distinct areas:

  - faq
  - learn
  - issues
  - general
  - howto

and otoh:

  - future.general
  - future.issues
  - future.brainstorm
  - future.roadmap
  - future.implementation   ( = down-to-earth view on new things)

Or some such, anyway.

We might also promise to not publish a new (stable) version within 12 
months of 1.0. (This may really be a more important promise for the 
customers and prospective developers and consultants than we here 
realize just off-hand.)
Nov 04 2006
next sibling parent reply BCS <BCS pathilink.com> writes:
Georg Wrede wrote:
1.0?

 Does that imply a simultaneous 1.0 for D and DMD??

 Suppose they were decoupled. Then we might decide on D 1.0 (say in
 December) and from there go on with fixing library issues,
 *installing* issues (especially on Linux), and even try to create a
 package that strives to be as good as Shrink-Wrap, i.e. simply work
 out of the box, and be somewhat usable regarding GUI development. Say,
 in March.


I have always thought that it should be done that way. DMD is not D.

Actually, I think it should be D v1.0 RC1. I don't think that it should 
be carved in stone until someone other than Walter writes a complete 
reimplementation of the compiler. Not to belittle Walter (who is doing a 
great job) and DMD (which is a great program), but as it stands 
everything depends on one code base. The DMD frontend. A second 
independent implementation would remove another unknown from the future 
of D. Furthermore, doing a complete reimplementation, would provide an 
opportunity to make sure that the spec consistent and is up to date with 
the language. It would also likely find some more of the bugs in DMD.

<rant>
I know it is to much to ask but, if it were up to me, even more should 
be reimplemented before everything is set in stone. I wouldn't allow 
whoever is reimplementing D to look at how DMD works any more than they 
need to to write the new compiler (which would be written in D of 
course). This would include forbidding them to see how the stuff is done 
"under the hood". The hope would be that they might come up with a 
better way of making things work.
</rant>



 In the meantime we could polish DMD, interact with the GDC guys to get
 the two exactly alike, and then maybe even write some example code
 with more user value than the current printf-Hello-World style
 examples.


votes++;

[...]

 We might also promise to not publish a new (stable) version within 12
 months of 1.0. (This may really be a more important promise for the
 customers and prospective developers and consultants than we here
 realize just off-hand.)


I hope you mean no new versions of D. I would hope that Walter would 
still attack the DMD bug list with the same kind of aggressiveness that 
he has shown in the past.

As to an un-stable versions of D, maybe an excremental compiler could be 
made. For example I have been working on a D compiler (after several 
months of off and on work I'm not quite done with the *lexer*, so don't 
go getting all excited) that is intended to be as easy as possible to 
modify. The idea being that it can be a test bed for new features. To 
begin with I plan to  implement the official D feature set. After that, 
new features would be added with versions statements so that people 
would be able to try working with and without whatever features they want.

  As I have no plans to make it fast or put in any optimization what so 
ever, I don't think that there will be any risk of anyone using it for 
any major work.
Nov 04 2006
next sibling parent reply Charlie <charlies nowhere.com> writes:
Excremental :) ?  Freudian slip or spell check gone awry ?


 As to an un-stable versions of D, maybe an excremental compiler could be
 made.




BCS wrote:

  >Georg Wrede wrote:
  >1.0?
  >
  > Does that imply a simultaneous 1.0 for D and DMD??
  >
  > Suppose they were decoupled. Then we might decide on D 1.0 (say in
  > December) and from there go on with fixing library issues,
  > *installing* issues (especially on Linux), and even try to create a
  > package that strives to be as good as Shrink-Wrap, i.e. simply work
  > out of the box, and be somewhat usable regarding GUI development. Say,
  > in March.
  >
 
 I have always thought that it should be done that way. DMD is not D.
 
 Actually, I think it should be D v1.0 RC1. I don't think that it should 
 be carved in stone until someone other than Walter writes a complete 
 reimplementation of the compiler. Not to belittle Walter (who is doing a 
 great job) and DMD (which is a great program), but as it stands 
 everything depends on one code base. The DMD frontend. A second 
 independent implementation would remove another unknown from the future 
 of D. Furthermore, doing a complete reimplementation, would provide an 
 opportunity to make sure that the spec consistent and is up to date with 
 the language. It would also likely find some more of the bugs in DMD.
 
 <rant>
 I know it is to much to ask but, if it were up to me, even more should 
 be reimplemented before everything is set in stone. I wouldn't allow 
 whoever is reimplementing D to look at how DMD works any more than they 
 need to to write the new compiler (which would be written in D of 
 course). This would include forbidding them to see how the stuff is done 
 "under the hood". The hope would be that they might come up with a 
 better way of making things work.
 </rant>
 
 
  > In the meantime we could polish DMD, interact with the GDC guys to get
  > the two exactly alike, and then maybe even write some example code
  > with more user value than the current printf-Hello-World style
  > examples.
  >
 
 votes++;
 
 [...]
  >
  > We might also promise to not publish a new (stable) version within 12
  > months of 1.0. (This may really be a more important promise for the
  > customers and prospective developers and consultants than we here
  > realize just off-hand.)
 
 I hope you mean no new versions of D. I would hope that Walter would 
 still attack the DMD bug list with the same kind of aggressiveness that 
 he has shown in the past.
 
 As to an un-stable versions of D, maybe an excremental compiler could be 
 made. For example I have been working on a D compiler (after several 
 months of off and on work I'm not quite done with the *lexer*, so don't 
 go getting all excited) that is intended to be as easy as possible to 
 modify. The idea being that it can be a test bed for new features. To 
 begin with I plan to  implement the official D feature set. After that, 
 new features would be added with versions statements so that people 
 would be able to try working with and without whatever features they want.
 
  As I have no plans to make it fast or put in any optimization what so 
 ever, I don't think that there will be any risk of anyone using it for 
 any major work.
Nov 05 2006
parent BCS <nada pathlink.com> writes:
== Quote from Charlie (charlies nowhere.com)'s article

Spell check :P


 Excremental :) ?  Freudian slip or spell check gone awry ?
  > As to an un-stable versions of D, maybe an excremental compiler
  > could be made.
 BCS wrote:


[...]

P.S. you forgot "bad/failed joke"
Nov 05 2006
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
BCS wrote:

 Actually, I think it should be D v1.0 RC1. I don't think that it should 
 be carved in stone until someone other than Walter writes a complete 
 reimplementation of the compiler. Not to belittle Walter (who is doing a 
 great job) and DMD (which is a great program), but as it stands 
 everything depends on one code base. The DMD frontend. A second 
 independent implementation would remove another unknown from the future 
 of D. Furthermore, doing a complete reimplementation, would provide an 
 opportunity to make sure that the spec consistent and is up to date with 
 the language. It would also likely find some more of the bugs in DMD.


While an independent implementation of D would be worthwhile for many 
reasons, there are many very successful languages for which only one 
implementation exists - such as Perl, Ruby, etc., so it is not a 
requirement.

What I think is critical for the success of a single implementation 
language is it being open source, which D is.
Nov 05 2006
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Walter Bright wrote:

 BCS wrote:



 While an independent implementation of D would be worthwhile for many 
 reasons, there are many very successful languages for which only one 
 implementation exists - such as Perl, Ruby, etc., so it is not a 
 requirement.


I definitely agree.


 What I think is critical for the success of a single implementation 
 language is it being open source, which D is.


Technically yes.

But practically, no.  D is not open source.  D is partially open source. 
  Just because there is an out-of-date open source compiler that does 
compile and an up-to-date open source front end that won't compile does 
not make it open source in the sense that matters most, I think.

The sense that matters is the one in which I can do "cvs update -Pd" and 
get the latest complete, working compiler, make changes to it, and 
submit those changes as patches.

It's great that there's an open source D compiler, and I applaud the 
effort of those folks who have gotten it to where it is.  But it really 
should be the MAIN compiler not a sad also-ran huffing and puffing to 
keep up.

I'm pretty sure I could get to the point where I could submit simple 
patches to fix some things here and there in the front end, but frankly 
I have very little interest in spending that time if it's just going to 
serve the purpose of getting an out-of-date compiler a smidge closer to 
where DMD was three months ago.  Maybe not everyone feels that way, but 
I'd be willing to bet a significant number do.  I love new features.  I 
like to get stuff that's hot off the presses.  I have the source code 
for 5 or 6 open source projects on my harddrive right now that I 
sometimes contribute to.

Open source is most motivating when everyone is working together to 
create something new and useful and cutting edge, but it's not so 
exciting when the goal is the re-create that which was new and cutting 
edge last month.  I can only assume that at least some other would-be 
contributors feel the same way.

Anyway, I do applaud you for making so much of D open source.  I think 
it probably wouldn't be going as strong today if you hadn't.  But at the 
same time, you shouldn't have any illusions that DMD's model is 
equivalent to or contains the same magic open source recipe that helped 
Perl or Ruby or Python make it to where they are today.  It's more like 
Java's recipe, but Sun had megabucks with which to force Java down 
everyone's throat despite not being fully open source.

--bb
Nov 06 2006
next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Bill Baxter wrote:

 It's great that there's an open source D compiler, and I applaud the 
 effort of those folks who have gotten it to where it is.  But it really 
 should be the MAIN compiler not a sad also-ran huffing and puffing to 
 keep up.


There's nothing impeding anyone from submitting the patches to it to 
keep it up to date. I try pretty hard to make all the updates to the D 
language in the front end, to make getting it to GDC easier. For the 
rest, I am available for advice and help in any way I can (although I 
cannot work on the gnu backend code itself, as I wish to avoid 'taint').
Nov 06 2006
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Walter Bright wrote:

 Bill Baxter wrote:

 It's great that there's an open source D compiler, and I applaud the 
 effort of those folks who have gotten it to where it is.  But it 
 really should be the MAIN compiler not a sad also-ran huffing and 
 puffing to keep up.


 
 There's nothing impeding anyone from submitting the patches to it to 
 keep it up to date. I try pretty hard to make all the updates to the D 
 language in the front end, to make getting it to GDC easier. For the 
 rest, I am available for advice and help in any way I can (although I 
 cannot work on the gnu backend code itself, as I wish to avoid 'taint').


Hmm.  So why isn't the strategy working?
Current GDC is based on 0.162 from June 22.  Over ten releases, 4 
months,  dozens of bug fixes, and at least ten significant features 
behind DMD.

In your estimation, for someone who knows what they are doing, how long 
should it take to update GDC for 'an average DMD release'?  Is the 
problem just that we've been lacking anyone who meets the qualifications 
since July?  Did I miss the good old days when GDC and DMD used to walk 
hand in hand and frolic in the Autumn mist?

--bb
Nov 06 2006
next sibling parent Walter Bright <newshound digitalmars.com> writes:
Bill Baxter wrote:

 Walter Bright wrote:

 Bill Baxter wrote:

 It's great that there's an open source D compiler, and I applaud the 
 effort of those folks who have gotten it to where it is.  But it 
 really should be the MAIN compiler not a sad also-ran huffing and 
 puffing to keep up.


 There's nothing impeding anyone from submitting the patches to it to 
 keep it up to date. I try pretty hard to make all the updates to the D 
 language in the front end, to make getting it to GDC easier. For the 
 rest, I am available for advice and help in any way I can (although I 
 cannot work on the gnu backend code itself, as I wish to avoid 'taint').


 
 Hmm.  So why isn't the strategy working?


If everyone expects someone else to do it, it won't happen. The whole 
point of open source is so that anyone can contribute, and should 
contribute when they need something from it.

Me, I cannot work on gcc for legal reasons. Since I work on compilers 
professionally, I wish to avoid even the appearance of impropriety.
Nov 06 2006
prev sibling next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Bill Baxter wrote:


 Current GDC is based on 0.162 from June 22.  Over ten releases, 4 
 months,  dozens of bug fixes, and at least ten significant features 
 behind DMD.


To be fair, "current GDC" is up to about DMD 166 or so.
http://dgcc.svn.sourceforge.net/viewvc/dgcc/trunk/d/

It is still 2 months and lack D 2.0 features, but anyway...
I haven't done any gdcmac/gdcwin, waited for a GDC release.

I have been working on a GUI library and an IDE instead. :-)


 In your estimation, for someone who knows what they are doing, how long 
 should it take to update GDC for 'an average DMD release'?  Is the 
 problem just that we've been lacking anyone who meets the qualifications 
 since July?  Did I miss the good old days when GDC and DMD used to walk 
 hand in hand and frolic in the Autumn mist?


David Friedman is the one maintaining the GDC compiler...
I don't think there would be a GCC D Compiler without him.

Historic track record for DMD and GDC releases is at:
http://www.prowiki.org/wiki4d/wiki.cgi?HistoryRoadmap

It averages around two weeks, except when David is busy.

--anders
Nov 06 2006
prev sibling next sibling parent Don Clugston <dac nospam.com.au> writes:
Bill Baxter wrote:

 Walter Bright wrote:

 Bill Baxter wrote:

 It's great that there's an open source D compiler, and I applaud the 
 effort of those folks who have gotten it to where it is.  But it 
 really should be the MAIN compiler not a sad also-ran huffing and 
 puffing to keep up.


 There's nothing impeding anyone from submitting the patches to it to 
 keep it up to date. I try pretty hard to make all the updates to the D 
 language in the front end, to make getting it to GDC easier. For the 
 rest, I am available for advice and help in any way I can (although I 
 cannot work on the gnu backend code itself, as I wish to avoid 'taint').


 
 Hmm.  So why isn't the strategy working?
 Current GDC is based on 0.162 from June 22.  Over ten releases, 4 
 months,  dozens of bug fixes, and at least ten significant features 
 behind DMD.
 
 In your estimation, for someone who knows what they are doing, how long 
 should it take to update GDC for 'an average DMD release'?  Is the 
 problem just that we've been lacking anyone who meets the qualifications 
 since July?  Did I miss the good old days when GDC and DMD used to walk 
 hand in hand and frolic in the Autumn mist?
 
 --bb


D is hardly limited by the compiler. On his own, Walter's equivalent to 
a medium-size team. No other language gets variadic templates, signals 
and slots, and  other significant template improvements only two weeks 
after the previous release.  Sure, GDC lags behind DMD, but really, even 
GDC releases are more common than compiler releases for most other 
languages.

It's the libraries that need attention.
Nov 06 2006
prev sibling parent Sean Kelly <sean f4.ca> writes:
Bill Baxter wrote:

 Walter Bright wrote:

 Bill Baxter wrote:

 It's great that there's an open source D compiler, and I applaud the 
 effort of those folks who have gotten it to where it is.  But it 
 really should be the MAIN compiler not a sad also-ran huffing and 
 puffing to keep up.


 There's nothing impeding anyone from submitting the patches to it to 
 keep it up to date. I try pretty hard to make all the updates to the D 
 language in the front end, to make getting it to GDC easier. For the 
 rest, I am available for advice and help in any way I can (although I 
 cannot work on the gnu backend code itself, as I wish to avoid 'taint').


 
 Hmm.  So why isn't the strategy working?
 Current GDC is based on 0.162 from June 22.  Over ten releases, 4 
 months,  dozens of bug fixes, and at least ten significant features 
 behind DMD.


GDC is more up to date in SVN (maybe 0.168), it just hasn't been 
repackaged since June.


 In your estimation, for someone who knows what they are doing, how long 
 should it take to update GDC for 'an average DMD release'?  Is the 
 problem just that we've been lacking anyone who meets the qualifications 
 since July?  Did I miss the good old days when GDC and DMD used to walk 
 hand in hand and frolic in the Autumn mist?


Library changes are generally not too hard, but compiler changes can 
involve new code generation, etc, which requires a solid understanding 
of GCC at least.


Sean
Nov 06 2006
prev sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Walter Bright wrote:


 There's nothing impeding anyone from submitting the patches to it to 
 keep it up to date. I try pretty hard to make all the updates to the D 
 language in the front end, to make getting it to GDC easier. For the 
 rest, I am available for advice and help in any way I can (although I 
 cannot work on the gnu backend code itself, as I wish to avoid 'taint').


The one feature I miss the most from DMD is version(Unix) and std.c.unix

version(linux) and std.c.linux really makes porting to Mac more "work".

--anders
Nov 06 2006
prev sibling parent Dave <Dave_member pathlink.com> writes:
Bill Baxter wrote:

 Walter Bright wrote:

 BCS wrote:


 

 While an independent implementation of D would be worthwhile for many 
 reasons, there are many very successful languages for which only one 
 implementation exists - such as Perl, Ruby, etc., so it is not a 
 requirement.


 
 I definitely agree.
 

 What I think is critical for the success of a single implementation 
 language is it being open source, which D is.


 
 Technically yes.
 
 But practically, no.  D is not open source.  D is partially open source. 
  Just because there is an out-of-date open source compiler that does 
 compile and an up-to-date open source front end that won't compile does 
 not make it open source in the sense that matters most, I think.
 
 The sense that matters is the one in which I can do "cvs update -Pd" and 
 get the latest complete, working compiler, make changes to it, and 
 submit those changes as patches.
 


Patches, yes. But that's assuming that the current method of fixing bugs is
lacking in some way. 
That is, we have the person most familiar with the compiler and language doing
the bug fixing, so we 
may actually have the fastest, safest and most efficient way of getting things
done. Obviously, 
often a patch to a seemingly simple problem can wreak havoc on other
functionality. I'd hate to have 
someone else submitting patches to the template code right now for example.

Over the space of several releases, I took the dmdfe front-end, kept it up to
date with the current 
front-end source code (distributed with DMD) and modified it to do header
generation. I mention this 
because the current distribution model allows for things like that if you want
to pursue it, and I 
don't think it was much more difficult than if the latest version was in a
publicly available 
repository somewhere; if it took longer than a single release cycle, you'd have
to keep the code 
you're working on in sync with the latest before you submitted the patches
anyhow. One should be 
able to do the same with other new language features.

What may have made things easier initially is if somehow we could get a binary
of the back-end to 
plug into the open-source front-end, because a decent amount of time was spent
adjusting things to 
work w/ the back-end interface stubbed out. I don't want to push for that
though if it would impede 
other progress, or make it tougher for Walter to add new features and/or fix
bugs.


 It's great that there's an open source D compiler, and I applaud the 
 effort of those folks who have gotten it to where it is.  But it really 
 should be the MAIN compiler not a sad also-ran huffing and puffing to 
 keep up.
 


As for GDC - I don't know what the deal is there except to say that since I
don't have the time to 
maintain it, I'm assuming that's the case with others as well.

But GDC was started to address your exact concerns and now what's needed is for
people to jump-in 
and keep it up-to-date.


 I'm pretty sure I could get to the point where I could submit simple 
 patches to fix some things here and there in the front end, but frankly 
 I have very little interest in spending that time if it's just going to 
 serve the purpose of getting an out-of-date compiler a smidge closer to 
 where DMD was three months ago.  Maybe not everyone feels that way, but 
 I'd be willing to bet a significant number do.  I love new features.  I 
 like to get stuff that's hot off the presses.  I have the source code 
 for 5 or 6 open source projects on my harddrive right now that I 
 sometimes contribute to.
 
 Open source is most motivating when everyone is working together to 
 create something new and useful and cutting edge, but it's not so 
 exciting when the goal is the re-create that which was new and cutting 
 edge last month.  I can only assume that at least some other would-be 
 contributors feel the same way.
 
 Anyway, I do applaud you for making so much of D open source.  I think 
 it probably wouldn't be going as strong today if you hadn't.  But at the 
 same time, you shouldn't have any illusions that DMD's model is 
 equivalent to or contains the same magic open source recipe that helped 
 Perl or Ruby or Python make it to where they are today.  It's more like 
 Java's recipe, but Sun had megabucks with which to force Java down 
 everyone's throat despite not being fully open source.
 


As mentioned above, I can't say I agree with that. After all, it's taken
several years for those 
languages to get where they're at and D is a relative newcomer with a whole
bunch of leading-edge 
features.

One thing that makes those languages so useful (and seems to need the most work
(judging from this 
news-group)) is the open-source library work, and that is completely
open-source for D. The current 
'model' should not impede development there at all.

All IMHO.


 --bb
Nov 06 2006
prev sibling next sibling parent reply Don Clugston <dac nospam.com.au> writes:
Georg Wrede wrote:

 1.0?
 
 Does that imply a simultaneous 1.0 for D and DMD??
 
 Suppose they were decoupled. Then we might decide on D 1.0 (say in 
 December) and from there go on with fixing library issues, *installing* 
 issues (especially on Linux), and even try to create a package that 
 strives to be as good as Shrink-Wrap, i.e. simply work out of the box, 
 and be somewhat usable regarding GUI development. Say, in March.


I think that's an excellent idea. If, as Walter has said, "1.0" is an 
arbitrary line in the sand, tying it to a particular date gives a 
rationale for associating a name to a particular release. If we can say 
"a DMD 1.0 release will exist on January 1, 2007" (or at least, 1.0 RC 
1), we'd gain a lot of focus.

I thought we were really close to a 1.0 release at 0.166, but starting 
with the array literals in 0.167, a stable release suddenly seems a very 
long way off.
On the positive side, I think that array literals and variadic templates 
were the two major 2.0 features which were likely to render a lot of 
library code obselete.

We should choose a date and stick to it. Remove the angst.
Nov 05 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Don Clugston wrote:

 I think that's an excellent idea. If, as Walter has said, "1.0" is an 
 arbitrary line in the sand, tying it to a particular date gives a 
 rationale for associating a name to a particular release. If we can say 
 "a DMD 1.0 release will exist on January 1, 2007" (or at least, 1.0 RC 
 1), we'd gain a lot of focus.
 
 I thought we were really close to a 1.0 release at 0.166, but starting 
 with the array literals in 0.167, a stable release suddenly seems a very 
 long way off.
 On the positive side, I think that array literals and variadic templates 
 were the two major 2.0 features which were likely to render a lot of 
 library code obselete.
 
 We should choose a date and stick to it. Remove the angst.


Sounds good to me, and Jan 1, 2007 is a great date to pick.

I've been playing a lot with the template tuple thing. It flings open 
some doors pretty wide to a great simplification of library code. That's 
why I put a priority on it. I've been fiddling with some of Andrei 
Alexandrescu's Loki C++ template code, and some of it shrinks by an 
*order of magnitude* with language support for tuples. Not only that, it 
becomes much more understandable <g>.

Another goal of mine is support for a Spirit-like library. I used to 
think Spirit was of only marginal use, but I am more and more thinking 
that, from the right point of view, it can be core to making some 
ubiquitous and very powerful library tools.
Nov 05 2006
next sibling parent reply Don Clugston <dac nospam.com.au> writes:
Walter Bright wrote:

 Don Clugston wrote:

 I think that's an excellent idea. If, as Walter has said, "1.0" is an 
 arbitrary line in the sand, tying it to a particular date gives a 
 rationale for associating a name to a particular release. If we can 
 say "a DMD 1.0 release will exist on January 1, 2007" (or at least, 
 1.0 RC 1), we'd gain a lot of focus.

 I thought we were really close to a 1.0 release at 0.166, but starting 
 with the array literals in 0.167, a stable release suddenly seems a 
 very long way off.
 On the positive side, I think that array literals and variadic 
 templates were the two major 2.0 features which were likely to render 
 a lot of library code obselete.

 We should choose a date and stick to it. Remove the angst.


 
 Sounds good to me, and Jan 1, 2007 is a great date to pick.
 
 I've been playing a lot with the template tuple thing. It flings open 
 some doors pretty wide to a great simplification of library code. That's 
 why I put a priority on it. I've been fiddling with some of Andrei 
 Alexandrescu's Loki C++ template code, and some of it shrinks by an 
 *order of magnitude* with language support for tuples. Not only that, it 
 becomes much more understandable <g>.


And consequently less buggy. In an early release of Loki, there was a 
typo which meant there was a nasty bug if tuples had exactly 27 parameters.

0.173 is an incredible release. We're getting frightening close to being 
able to say "D templates are a superset of the C++ template *wishlist*" <g>.


 Another goal of mine is support for a Spirit-like library. I used to 
 think Spirit was of only marginal use, but I am more and more thinking 
 that, from the right point of view, it can be core to making some 
 ubiquitous and very powerful library tools.


I have a vague intuition that template tuples will enable some serious 
innovation in that direction. It scares me at the same time, because 
there's *so much* unexplored territory.
Nov 05 2006
next sibling parent Kyle Furlong <kylefurlong gmail.com> writes:
Don Clugston wrote:

 Walter Bright wrote:

 Don Clugston wrote:

 I think that's an excellent idea. If, as Walter has said, "1.0" is an 
 arbitrary line in the sand, tying it to a particular date gives a 
 rationale for associating a name to a particular release. If we can 
 say "a DMD 1.0 release will exist on January 1, 2007" (or at least, 
 1.0 RC 1), we'd gain a lot of focus.

 I thought we were really close to a 1.0 release at 0.166, but 
 starting with the array literals in 0.167, a stable release suddenly 
 seems a very long way off.
 On the positive side, I think that array literals and variadic 
 templates were the two major 2.0 features which were likely to render 
 a lot of library code obselete.

 We should choose a date and stick to it. Remove the angst.


 Sounds good to me, and Jan 1, 2007 is a great date to pick.

 I've been playing a lot with the template tuple thing. It flings open 
 some doors pretty wide to a great simplification of library code. 
 That's why I put a priority on it. I've been fiddling with some of 
 Andrei Alexandrescu's Loki C++ template code, and some of it shrinks 
 by an *order of magnitude* with language support for tuples. Not only 
 that, it becomes much more understandable <g>.


 
 And consequently less buggy. In an early release of Loki, there was a 
 typo which meant there was a nasty bug if tuples had exactly 27 parameters.
 
 0.173 is an incredible release. We're getting frightening close to being 
 able to say "D templates are a superset of the C++ template *wishlist*" 
 <g>.
 

 Another goal of mine is support for a Spirit-like library. I used to 
 think Spirit was of only marginal use, but I am more and more thinking 
 that, from the right point of view, it can be core to making some 
 ubiquitous and very powerful library tools.


 
 I have a vague intuition that template tuples will enable some serious 
 innovation in that direction. It scares me at the same time, because 
 there's *so much* unexplored territory.


GO EXPLORE IT! /me pushes Don over the edge, into the wild new territory.
Nov 05 2006
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Don Clugston wrote:

 I have a vague intuition that template tuples will enable some serious 
 innovation in that direction. It scares me at the same time, because 
 there's *so much* unexplored territory.


It's fun pulling on that string and seeing where it goes! For example, I 
now have a working Curry template, which will curry *any* function or 
delegate.
Nov 06 2006
parent reply Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Walter Bright wrote:

 Don Clugston wrote:

 I have a vague intuition that template tuples will enable some serious 
 innovation in that direction. It scares me at the same time, because 
 there's *so much* unexplored territory.


 
 It's fun pulling on that string and seeing where it goes! For example, I 
 now have a working Curry template, which will curry *any* function or 
 delegate.


Interesting ! :) Can it handle partial currying ? My Bind lib is also 
about function/delegate currying, with arbitrary partial currying, 
parameter swizzling and function composition. The only thing that it's 
currently lacking is support of 'out', 'inout' and 'lazy' parameters. 
But this cannot be done without more info from the compiler. Would it be 
hard on your side to add more meta-info for functions and delegates ? 
I'm sure many people would appreciate the ability to extract parameter 
types, their count and a return value type for functions and delegates. 
The current approach to obtain this kind of meta-info is well 
demonstrated in the 'meta' package of Pyd: 
http://www.dsource.org/projects/pyd/browser/trunk/infrastructure/meta


--
Tomasz Stachowiak
Nov 06 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Tom S wrote:

 Interesting ! :) Can it handle partial currying ?


I don't know.


 My Bind lib is also 
 about function/delegate currying, with arbitrary partial currying, 
 parameter swizzling and function composition. The only thing that it's 
 currently lacking is support of 'out', 'inout' and 'lazy' parameters. 
 But this cannot be done without more info from the compiler. Would it be 
 hard on your side to add more meta-info for functions and delegates ? 
 I'm sure many people would appreciate the ability to extract parameter 
 types, their count and a return value type for functions and delegates. 
 The current approach to obtain this kind of meta-info is well 
 demonstrated in the 'meta' package of Pyd: 
 http://www.dsource.org/projects/pyd/browser/trunk/infrastructure/meta


You are way, way ahead of me with this stuff. Wow!

BTW, I am considering changing the ==function and ==delegate is 
expressions, which you use, to the following:


==return gets the return type:


 template Return(dg)
 {
     static if (is(dg R == return))
 	alias R Return;
     else
 	static assert(0, "argument has no return type");
 }


==function or ==delegate gets the parameter types as a tuple:


 template Parameters(dg)
 {
     static if (is(dg P == function))
 	alias P Parameters;
     else static if (is(dg P == delegate))
 	alias P Parameters;
     else static if (is(dg P == P*))
 	alias Parameters!(P) Parameters;
     else
 	static assert(0, "argument has no parameters");
 }


This will require some adjustment in your code. I didn't think anyone 
was using that stuff. Will it be an issue for you? Or should I find 
another way to do it?
Nov 06 2006
next sibling parent reply Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Walter Bright wrote:

 BTW, I am considering changing the ==function and ==delegate is 
 expressions, which you use, to the following:
 
 
 ==return gets the return type:
 

 template Return(dg)
 {
     static if (is(dg R == return))
     alias R Return;
     else
     static assert(0, "argument has no return type");
 }


 
 ==function or ==delegate gets the parameter types as a tuple:
 

 template Parameters(dg)
 {
     static if (is(dg P == function))
     alias P Parameters;
     else static if (is(dg P == delegate))
     alias P Parameters;
     else static if (is(dg P == P*))
     alias Parameters!(P) Parameters;
     else
     static assert(0, "argument has no parameters");
 }


 
 This will require some adjustment in your code. I didn't think anyone 
 was using that stuff. Will it be an issue for you? Or should I find 
 another way to do it?


Whoa, That would be awesome ! I don't think anyone would mind such a 
change :)
I'm certainly not the only one to use that code/feature. E.g. that link 
I gave you is from Kirk's Pyd, which contains modified versions of my 
code. It's also based on efforts from Daniel Keep. But I'm sure they 
will gladly welcome the enhancement you're proposing :)

One question thought: will the 'P' tuple from your example be able to 
remember in/out/inout/lazy modifiers ?


--
Tomasz Stachowiak
Nov 06 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Tom S wrote:

 Walter Bright wrote:

 BTW, I am considering changing the ==function and ==delegate is 
 expressions, which you use, to the following:


 ==return gets the return type:


 template Return(dg)
 {
     static if (is(dg R == return))
     alias R Return;
     else
     static assert(0, "argument has no return type");
 }


 ==function or ==delegate gets the parameter types as a tuple:


 template Parameters(dg)
 {
     static if (is(dg P == function))
     alias P Parameters;
     else static if (is(dg P == delegate))
     alias P Parameters;
     else static if (is(dg P == P*))
     alias Parameters!(P) Parameters;
     else
     static assert(0, "argument has no parameters");
 }


 This will require some adjustment in your code. I didn't think anyone 
 was using that stuff. Will it be an issue for you? Or should I find 
 another way to do it?


 
 Whoa, That would be awesome ! I don't think anyone would mind such a 
 change :)
 I'm certainly not the only one to use that code/feature. E.g. that link 
 I gave you is from Kirk's Pyd, which contains modified versions of my 
 code. It's also based on efforts from Daniel Keep. But I'm sure they 
 will gladly welcome the enhancement you're proposing :)


I hate to tip over working code. I'll see if I can find another way.


 One question thought: will the 'P' tuple from your example be able to 
 remember in/out/inout/lazy modifiers ?


I don't know. I'll have to work on that.
Nov 06 2006
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Walter Bright wrote:

 Tom S wrote:

 Whoa, That would be awesome ! I don't think anyone would mind such a
 change :)
 I'm certainly not the only one to use that code/feature. E.g. that
 link I gave you is from Kirk's Pyd, which contains modified versions
 of my code. It's also based on efforts from Daniel Keep. But I'm sure
 they will gladly welcome the enhancement you're proposing :)


 
 I hate to tip over working code. I'll see if I can find another way.


To derive a function's return type, number of arguments, type of
arguments, I had to write an external Python script that spat out a huge
ugly-as-hell D source file with support for functions of N arguments.

I can't speak for Kirk, but if you can do away with the need for the
current way of doing things, I don't care if my code is completely
broken—I'd be a happy little Vegemiter[1].  Sometimes you need to break
a bone to help it heal properly.

	-- Daniel

[1]: I *hate* Vegemite, but I think you get the idea :3

-- 
Unlike Knuth, I have neither proven or tried the above; it may not even
make sense.

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D
i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/
Nov 06 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Daniel Keep wrote:

 Walter Bright wrote:

 I hate to tip over working code. I'll see if I can find another way.


 
 To derive a function's return type, number of arguments, type of
 arguments, I had to write an external Python script that spat out a huge
 ugly-as-hell D source file with support for functions of N arguments.


I'm writing an std.traits module, which will abstract away that stuff. 
So, if you're willing to rewrite using std.traits.Returns and std.traits 
.Parameters, you'll be immunized against changes in the future.

Also, to get number of parameters for function foo:

	Parameters!(foo).length

will do it. First parameter type is:

	Parameters!(foo)[0]

Rest of the parameter types are:

	Parameters!(foo)[1 .. length]

Etc.
Nov 06 2006
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:eiosfr$283p$1 digitaldaemon.com...


 I'm writing an std.traits module, which will abstract away that stuff. So, 
 if you're willing to rewrite using std.traits.Returns and std.traits 
 .Parameters, you'll be immunized against changes in the future.

 Also, to get number of parameters for function foo:

 Parameters!(foo).length

 will do it. First parameter type is:

 Parameters!(foo)[0]

 Rest of the parameter types are:

 Parameters!(foo)[1 .. length]

 Etc.


Sounds great.

Just dreaming:

template bind(alias func, dchar[] name = nameof(func))()
{
    alias RetType!(func) ReturnType;
    alias Parameters!(func) Params;

    // Creates a MiniD-friendly function which acts as a shim between
    // MiniD and the real function.
    // GOD I wish I could create identifiers using token pasting.
    int identifier("bound_" ~ nameof(func))(MDState s)
    {
        // Create a new tuple big enough to hold all the parameter values
        alias NTuple!(Params.length) paramValues;

        // Get the params off the MiniD stack
        foreach(i, paramType; Params)
            paramValues[i] = s.getParam!(paramType)(i);

        // Call the function with the params (natively!)
        static if(is(ReturnType == void))
        {
            func(paramValues);
            return 0;
        }
        else
        {
            s.push(func(paramValues));
            return 1;
        }
    }

    // actually create the closure and set it as a global
    void bind(MDState s)
    {
        s.setGlobal(name, new MDClosure(s, &identifier("bound_" ~ 
nameof(func)), name));
    }
}

...

void foo(int x, int y)
{
    writefln(x, y);
}

bind!(foo);

AAAAA

I wish.
Nov 06 2006
parent Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Jarrett Billingsley wrote:

 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:eiosfr$283p$1 digitaldaemon.com...
 

 I'm writing an std.traits module, which will abstract away that stuff. So, 
 if you're willing to rewrite using std.traits.Returns and std.traits 
 .Parameters, you'll be immunized against changes in the future.

 Also, to get number of parameters for function foo:

 Parameters!(foo).length

 will do it. First parameter type is:

 Parameters!(foo)[0]

 Rest of the parameter types are:

 Parameters!(foo)[1 .. length]

 Etc.


 
 Sounds great.
 
 Just dreaming:
 
 template bind(alias func, dchar[] name = nameof(func))()
 {
     alias RetType!(func) ReturnType;
     alias Parameters!(func) Params;
 
     // Creates a MiniD-friendly function which acts as a shim between
     // MiniD and the real function.
     // GOD I wish I could create identifiers using token pasting.
     int identifier("bound_" ~ nameof(func))(MDState s)
     {
         // Create a new tuple big enough to hold all the parameter values
         alias NTuple!(Params.length) paramValues;
 
         // Get the params off the MiniD stack
         foreach(i, paramType; Params)
             paramValues[i] = s.getParam!(paramType)(i);
 
         // Call the function with the params (natively!)
         static if(is(ReturnType == void))
         {
             func(paramValues);
             return 0;
         }
         else
         {
             s.push(func(paramValues));
             return 1;
         }
     }
 
     // actually create the closure and set it as a global
     void bind(MDState s)
     {
         s.setGlobal(name, new MDClosure(s, &identifier("bound_" ~ 
 nameof(func)), name));
     }
 }
 
 ...
 
 void foo(int x, int y)
 {
     writefln(x, y);
 }
 
 bind!(foo);
 
 AAAAA
 
 I wish. 
 
 


... have you been reading Pyd's function wrapping code? ;-)

The internal code isn't /quite/ that clean, but the end result (the def 
template) is.

http://www.dsource.org/projects/pyd/browser/trunk/infrastructure/pyd/func_wrap.d

void foo(int x, int y) {
     writefln(x, y);
}

extern(C)
export void inittestdll() {
     def!(foo);
     module_init("testdll");
}

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://pyd.dsource.org
Nov 06 2006
prev sibling next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Walter Bright wrote:

 ...

 I'm writing an std.traits module, which will abstract away that stuff.
 So, if you're willing to rewrite using std.traits.Returns and std.traits
 ..Parameters, you'll be immunized against changes in the future.
 


Well, I originally wrote the code because I was playing with embedding
Python in D, and needed a way to get that information about a function.
 However, Kirk beat me to the punch, so I haven't used it since.

So, yes.  I'd be happy to use the "proper" traits library :)

Any idea what else will be going in std.traits?  I've already got a
small traits library that I use in a few places that does things like
convert between signed and unsigned types, find the next largest integer
type, work out if a type is an integer or float, etc.  I can post the
code if you're looking for ideas.


 Also, to get number of parameters for function foo:
 
     Parameters!(foo).length
 
 will do it. First parameter type is:
 
     Parameters!(foo)[0]
 
 Rest of the parameter types are:
 
     Parameters!(foo)[1 .. length]
 
 Etc.


Very cool.  I likes :)

	-- Daniel

-- 
Unlike Knuth, I have neither proven or tried the above; it may not even
make sense.

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D
i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/
Nov 06 2006
parent Walter Bright <newshound digitalmars.com> writes:
Daniel Keep wrote:

 Any idea what else will be going in std.traits?


So far, it's got only two entries <g>. I figure it to be a grab bag of 
stuff like what you've done. After the next update, please look it over 
and see what makes sense to go in it from your stuff.
Nov 06 2006
prev sibling parent reply BCS <BCS pathlink.com> writes:
While the topic is function, "there arguments and what not" could we get 

no way to reference an overloaded function with out already knowing it's 
type.

int foo(char c){return 0;}
void foo(long l){}

auto fn = &foo;
// the foo used changes if the order of the above changes.

this could also cause problems while attempting to call overloaded 
functions the an overloaded function as a parameter

void fuf(int function(char) fn){}
void fuf(void function(long) fn){}

fuf(&foo);	// what is used here
Nov 07 2006
next sibling parent Kirk McDonald <kirklin.mcdonald gmail.com> writes:
BCS wrote:

 While the topic is function, "there arguments and what not" could we get 

 no way to reference an overloaded function with out already knowing it's 
 type.
 
 int foo(char c){return 0;}
 void foo(long l){}
 
 auto fn = &foo;
 // the foo used changes if the order of the above changes.
 
 this could also cause problems while attempting to call overloaded 
 functions the an overloaded function as a parameter
 
 void fuf(int function(char) fn){}
 void fuf(void function(long) fn){}
 
 fuf(&foo);    // what is used here
 


Pyd grapples with this problem by passing around all "real" functions as 
a combination of function alias and function type, which are typically 
referenced as fn and fn_t, respectively, in the code.

Given your overloads of foo, above, saying
     def!(foo);
will wrap the first overload in Pyd. To wrap the other overload, the 
user has to explicitly provide its type (and an alternate name):
     def!(foo, "foo2", void function(long));

A related problem is the issue of default arguments.

void bar(int i, real r=5.8, char[] s="hello") {}

typeof(&bar) is void function(int, real, char[]). Attempting to say
     void function(int) fn = &bar;
does not work. (It fails to compile as written. Casting &bar to the 
proper type allows it to compile, but results in odd behavior.) 
Similarly, saying
     void function(int, real, char[]) fn = &bar;
     fn(1);
doesn't work. (Calling fn with the wrong number of arguments is an error.)

One of the additions I made to the metaprogramming library I use in Pyd 
is a simple little array of template functions that allows you to get a 
function pointer calling the first n arguments of a function. The 
original version used a mass of templates; the new variadics would allow 
it to look something like this:

template firstArgsT(alias fn, uint i, fn_t) {
     alias RetType!(fn_t) R;
     alias tupleFromFn_T!(fn_t)[0..i] T; // A theoretical template

     R func(T t) {
         return fn(t);
     }
}

template firstArgs(alias fn, uint i, fn_t = typeof(&fn)) {
     alias firstArgsT!(fn, i, fn_t).func firstArgs;
}

Some sort of streamlining of this process would be appreciated as well.

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://pyd.dsource.org
Nov 07 2006
prev sibling parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
BCS wrote:

 While the topic is function, "there arguments and what not" could we get 

 no way to reference an overloaded function with out already knowing it's 
 type.
 
 int foo(char c){return 0;}
 void foo(long l){}
 
 auto fn = &foo;
 // the foo used changes if the order of the above changes.
 
 this could also cause problems while attempting to call overloaded 
 functions the an overloaded function as a parameter
 
 void fuf(int function(char) fn){}
 void fuf(void function(long) fn){}
 
 fuf(&foo);    // what is used here
 


Seems like it ought to be simple enough to provide this just by allowing a
tuple of type 
symbols in the address-of-function expression.  Or in other words, to get the
foo(long) in 
your first example, rather than foo(char) just do:


which is still shorter than the explicit:


And again in your second example:


which has grown in this case, but not by a lot, and certainly the type
information 
shouldn't be neccessary if there are no overloads.

-- Chris Nicholson-Sauls
Nov 07 2006
prev sibling parent reply Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Walter Bright wrote:

 Tom S wrote:

 Interesting ! :) Can it handle partial currying ?


 
 I don't know.
 

 My Bind lib is also about function/delegate currying, with arbitrary 
 partial currying, parameter swizzling and function composition. The 
 only thing that it's currently lacking is support of 'out', 'inout' 
 and 'lazy' parameters. But this cannot be done without more info from 
 the compiler. Would it be hard on your side to add more meta-info for 
 functions and delegates ? I'm sure many people would appreciate the 
 ability to extract parameter types, their count and a return value 
 type for functions and delegates. The current approach to obtain this 
 kind of meta-info is well demonstrated in the 'meta' package of Pyd: 
 http://www.dsource.org/projects/pyd/browser/trunk/infrastructure/meta


 
 You are way, way ahead of me with this stuff. Wow!
 
 BTW, I am considering changing the ==function and ==delegate is 
 expressions, which you use, to the following:
 
 
 ==return gets the return type:
 

 template Return(dg)
 {
     static if (is(dg R == return))
     alias R Return;
     else
     static assert(0, "argument has no return type");
 }


 
 ==function or ==delegate gets the parameter types as a tuple:
 

 template Parameters(dg)
 {
     static if (is(dg P == function))
     alias P Parameters;
     else static if (is(dg P == delegate))
     alias P Parameters;
     else static if (is(dg P == P*))
     alias Parameters!(P) Parameters;
     else
     static assert(0, "argument has no parameters");
 }


 
 This will require some adjustment in your code. I didn't think anyone 
 was using that stuff. Will it be an issue for you? Or should I find 
 another way to do it?


This would be great! The one thing we lose is the ability to get the 
underlying function type of a delegate. If you were to also add some 
mechanism to freely convert a function type to a delegate type and vice 
versa, that would be perfect.

The other thing that would be nice is the ability to derive the storage 
classes of a function's arguments (in/out/inout/lazy). That linked-to 
code only works with functions that only have 'in' arguments. (With some 
limited inout support I added to deal with opApply.)

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://pyd.dsource.org
Nov 06 2006
next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Kirk McDonald wrote:

 This would be great! The one thing we lose is the ability to get the 
 underlying function type of a delegate.


Is that needed, though?
Nov 06 2006
parent reply Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Walter Bright wrote:

 Kirk McDonald wrote:

 This would be great! The one thing we lose is the ability to get the 
 underlying function type of a delegate.


 
 Is that needed, though?


Yes. It will be less needed if, as Tom suggests, there is a way to 
derive a tuple from a function or delegate type, and then derive a 
function or delegate type from a tuple.

As was pointed out in a previous thread, the latter could be done if the 
following worked:

template FuncType(Ret, T ...) {
     alias Ret function(T) FuncType;
}

In Pyd, users wrap member functions by providing an alias to the member 
function directly. Take the following class:

class Foo {
     void f() { }
}

Wrapping this class in Pyd might be done with:

wrapped_class!(Foo) f;
f.def!(Foo.f);
finalize_class(f);

The signature of .def is:

void def(alias fn, char[] name=symbolnameof!(fn), fn_t=typeof(&fn))();

fn_t, then, comes out to be void function(). Note that this is a 
/function/ type, and not a delegate type (which is right and proper). To 
actually call this, I need to derive a delegate type from this function 
type, and perform some hackery to call it.

Which brings up another point: It's really great that you added the .ptr 
property to delegates in 0.168, but it would also be great to have a .fn 
property to access the function pointer. (And optimally, this pointer 
would be of the right type, and not just a void*.)

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://pyd.dsource.org
Nov 06 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Kirk McDonald wrote:

 Which brings up another point: It's really great that you added the .ptr 
 property to delegates in 0.168, but it would also be great to have a .fn 
 property to access the function pointer. (And optimally, this pointer 
 would be of the right type, and not just a void*.)



Ok, but as long as everyone realizes the function cannot be called via 
that function pointer (because the calling convention for delegates is 
different because there's that extra parameter). The type of the 
.funcptr would only be useful for extracting other information.
Nov 06 2006
parent reply Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Walter Bright wrote:

 Kirk McDonald wrote:

 Which brings up another point: It's really great that you added the 
 .ptr property to delegates in 0.168, but it would also be great to 
 have a .fn property to access the function pointer. (And optimally, 
 this pointer would be of the right type, and not just a void*.)


 
 
 Ok, but as long as everyone realizes the function cannot be called via 
 that function pointer (because the calling convention for delegates is 
 different because there's that extra parameter). The type of the 
 .funcptr would only be useful for extracting other information.


The hope is that I could then say something like this:

class Foo {
     void func() { }
}

void main() {
     void delegate() dg;
     Foo f = new Foo;
     dg.ptr = &f;
     dg.funcptr = &Foo.func;
     dg();
}

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://pyd.dsource.org
Nov 07 2006
parent Walter Bright <newshound digitalmars.com> writes:
Kirk McDonald wrote:

 The hope is that I could then say something like this:
 
 class Foo {
     void func() { }
 }
 
 void main() {
     void delegate() dg;
     Foo f = new Foo;
     dg.ptr = &f;


dg.ptr = f;

     dg.funcptr = &Foo.func;
     dg();
 }


and it should work.
Nov 07 2006
prev sibling parent reply Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Kirk McDonald wrote:

 This would be great! The one thing we lose is the ability to get the 
 underlying function type of a delegate. If you were to also add some 
 mechanism to freely convert a function type to a delegate type and vice 
 versa, that would be perfect.


Or... a mechanism to derive a function or delegate type from a tuple 
(for param types) and one more type (for the return type).

e.g.

static assert (is(delegateType!(int, tuple(float, out char)) == int 
delegate(float, out char));


It would provide more power than just function/delegate type conversion 
and simplify some parametric function generation. For instance, my Bind 
lib generates a delegate from compile-type calculations based on the 
curried/bound arguments and function composition.


--
Tomasz Stachowiak
Nov 06 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Ok, so here's what I'll do unless someone objects:

==delegate

remains the same

==return

for functions, delegates, and pointers to functions, gets the return type

==function

gets the prototype as a tuple (this breaks existing code)

Also, is there a need for:

==class

getting the base class?
Nov 06 2006
next sibling parent Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Walter Bright wrote:

 
 Ok, so here's what I'll do unless someone objects:
 
 ==delegate
 
 remains the same
 
 ==return
 
 for functions, delegates, and pointers to functions, gets the return type
 
 ==function
 
 gets the prototype as a tuple (this breaks existing code)


It sounds fine, but it still lacks the ability to get the delegate type 
of a function... Unless, of course there is a way to derive the 
delegate/function type from a tuple and return type ;)



 Also, is there a need for:
 
 ==class
 
 getting the base class?


I'm sure someone would find a use case for that, but wouldn't it break 
existing code too ? Currently using 'class' inside IsExpression simply 
yields the same type as the one in question. An alternative approach 
would be to allow .super to be accessed from outside of a class, so 
typeof(Foo.super) would become a valid expression.


--
Tomasz Stachowiak
Nov 07 2006
prev sibling parent Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Walter Bright schrieb am 2006-11-07:

 Ok, so here's what I'll do unless someone objects:


<snip>


 Also, is there a need for:

==class

 getting the base class?


I could have used this once or twice.

How about the index type of an associative array?

Thomas


-----BEGIN PGP SIGNATURE-----

iD4DBQFFUgR2LK5blCcjpWoRAuTVAKCjKFwhJPL3HX1Osa3mgXVpJD/HBACWIf1u
mYdI//16W1k6o7GVPidhOA==
=4cKz
-----END PGP SIGNATURE-----
Nov 08 2006
prev sibling next sibling parent clayasaurus <clayasaurus gmail.com> writes:
Walter Bright wrote:

 Don Clugston wrote:

 We should choose a date and stick to it. Remove the angst.


 
 Sounds good to me, and Jan 1, 2007 is a great date to pick.


Please make an announcement in d.announce to make the whole D community 
aware, if you are serious.

I'm sure we'll see something of a 'gold rush' to stabilize libraries and 
such :)
Nov 06 2006
prev sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
Walter Bright wrote:


 Don Clugston wrote:

 I think that's an excellent idea. If, as Walter has said, "1.0" is an
 arbitrary line in the sand, tying it to a particular date gives a
 rationale for associating a name to a particular release. If we can say
 "a DMD 1.0 release will exist on January 1, 2007" (or at least, 1.0 RC
 1), we'd gain a lot of focus.
 
 I thought we were really close to a 1.0 release at 0.166, but starting
 with the array literals in 0.167, a stable release suddenly seems a very
 long way off.
 On the positive side, I think that array literals and variadic templates
 were the two major 2.0 features which were likely to render a lot of
 library code obselete.
 
 We should choose a date and stick to it. Remove the angst.


 
 Sounds good to me, and Jan 1, 2007 is a great date to pick.


But there still is no dis-entanglement of D (the spec) and DMD (the
compiler), which really is needed if something like
std.compiler.supported_spec-version is supposed to work.

As far as I am concerned, too little focus is spent on "fixing" the spec.
Bugs are important to fix, but if they are bugs according to a less than
optimal spec, then what's the point?

If we can make sure that we are fairly happy with the specification, and (if
possible) for future features, like const/readonly and others, try to make
the spec less suspectible to breakage when those features _are_ added, then
I'm all for releasing D (the spec) 1.0, preferrably after one or two
release candidates. Whether DMD gains the same version number or not, I
don't much care about, but we then have something real to measure against.
Even if DMD is the reference implementation, it is important that DMD 1.0
don't necessarily equal D 1.0 !

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi
Nov 06 2006
prev sibling next sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
Georg Wrede wrote:


 1.0?
 
 Does that imply a simultaneous 1.0 for D and DMD??


In general it should not, although DMD for D is useful to test if the spec
actually works. Now, the spec is "unstable" enough, especially regarding
mixins, variadic templates and more, for D 1.0 not to be ready (IMO). That
DMD goes 1.0, I wouldn't care too much about. What will be important is
that once the D spec is said to be stable, consistent and correctly
written, there needs to be a way to compile a program according to that
spec.

That is, if only one DMD branch is kept, it needs to be able to do -std=D1.0
and -std=exp (or similar).

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi
Nov 05 2006
prev sibling next sibling parent Charlie <charlies nowhere.com> writes:
I'd love to see this happen, both the separation of DMD and D and a 1.0.
I also think the sooner than better, as these things usually take longer 
than expected.


Georg Wrede wrote:

 1.0?
 
 Does that imply a simultaneous 1.0 for D and DMD??
 
 Suppose they were decoupled. Then we might decide on D 1.0 (say in 
 December) and from there go on with fixing library issues, *installing* 
 issues (especially on Linux), and even try to create a package that 
 strives to be as good as Shrink-Wrap, i.e. simply work out of the box, 
 and be somewhat usable regarding GUI development. Say, in March.
 
 In the meantime we could polish DMD, interact with the GDC guys to get 
 the two exactly alike, and then maybe even write some example code with 
 more user value than the current printf-Hello-World style examples.
 
 ---
 
 I recently talked with a CIO (who was somewhat familiar with D), who 
 said that "short of taking a snapshot of D and sticking with it, there's 
 no way we're gonna start using a moving target as our base, no matter if 
 it's ten times as good as the next language." And he didn't seem likely 
 to go the snapshot way.
 
 The implication being that 1.0 or not, what a company needs is 
 stability. Stability in code, tools, programmer knowledge (as in hiring 
 and firing folks), a developer community specifically knowledgeable with 
 the problems of the _current_ version, a community developing and 
 maintaining up to date libraries targeted _precisely_ at the current 
 release, and of course a conviction that the current state of affairs 
 will continue for a reasonable amount of time (i.e. a belief in 
 everything not becoming obsolete in three months, be it due to a super 
 cool new version or simply code-breaking upgrades).
 
 So,,, we need to create an _illusion_ of stability. This might be by 
 publishing 1.0, and at the same time separating the newsgroups into two 
 distinct areas:
 
  - faq
  - learn
  - issues
  - general
  - howto
 
 and otoh:
 
  - future.general
  - future.issues
  - future.brainstorm
  - future.roadmap
  - future.implementation   ( = down-to-earth view on new things)
 
 Or some such, anyway.
 
 We might also promise to not publish a new (stable) version within 12 
 months of 1.0. (This may really be a more important promise for the 
 customers and prospective developers and consultants than we here 
 realize just off-hand.)
Nov 05 2006
prev sibling next sibling parent Kyle Furlong <kylefurlong gmail.com> writes:
Georg Wrede wrote:

 1.0?
 
 Does that imply a simultaneous 1.0 for D and DMD??
 
 Suppose they were decoupled. Then we might decide on D 1.0 (say in 
 December) and from there go on with fixing library issues, *installing* 
 issues (especially on Linux), and even try to create a package that 
 strives to be as good as Shrink-Wrap, i.e. simply work out of the box, 
 and be somewhat usable regarding GUI development. Say, in March.
 
 In the meantime we could polish DMD, interact with the GDC guys to get 
 the two exactly alike, and then maybe even write some example code with 
 more user value than the current printf-Hello-World style examples.
 
 ---
 
 I recently talked with a CIO (who was somewhat familiar with D), who 
 said that "short of taking a snapshot of D and sticking with it, there's 
 no way we're gonna start using a moving target as our base, no matter if 
 it's ten times as good as the next language." And he didn't seem likely 
 to go the snapshot way.
 
 The implication being that 1.0 or not, what a company needs is 
 stability. Stability in code, tools, programmer knowledge (as in hiring 
 and firing folks), a developer community specifically knowledgeable with 
 the problems of the _current_ version, a community developing and 
 maintaining up to date libraries targeted _precisely_ at the current 
 release, and of course a conviction that the current state of affairs 
 will continue for a reasonable amount of time (i.e. a belief in 
 everything not becoming obsolete in three months, be it due to a super 
 cool new version or simply code-breaking upgrades).
 
 So,,, we need to create an _illusion_ of stability. This might be by 
 publishing 1.0, and at the same time separating the newsgroups into two 
 distinct areas:
 
  - faq
  - learn
  - issues
  - general
  - howto
 
 and otoh:
 
  - future.general
  - future.issues
  - future.brainstorm
  - future.roadmap
  - future.implementation   ( = down-to-earth view on new things)
 
 Or some such, anyway.
 
 We might also promise to not publish a new (stable) version within 12 
 months of 1.0. (This may really be a more important promise for the 
 customers and prospective developers and consultants than we here 
 realize just off-hand.)


Yarr, me hearties, we should be releasin' soon. Arrr. Get 'em bugs 
squarshed.
Nov 05 2006
prev sibling parent reply RA <ra wolven.net> writes:
== Quote from Georg Wrede (georg.wrede nospam.org)'s article

 We might also promise to not publish a new (stable) version within 12
 months of 1.0. (This may really be a more important promise for the
 customers and prospective developers and consultants than we here
 realize just off-hand.)



I wouldn't want to hear a promise like that.  To me, it makes it sound like
there's definately not going to be any new improvements\features for at least
the
next year.

I think you would be better off not making any statement about the "next"
version... period.

If you really want to promise anything, something along the lines of "All
updates\versions\releases will be backwards compatible with 1.0 for the next 12
months (or until 2.0), except for unintended 'features' caused by bugs." would
be
plenty to imply a stable platform.

Just my opinion of course.
Nov 05 2006
parent Dave <Dave_member pathlink.com> writes:
RA wrote:

 == Quote from Georg Wrede (georg.wrede nospam.org)'s article

 We might also promise to not publish a new (stable) version within 12
 months of 1.0. (This may really be a more important promise for the
 customers and prospective developers and consultants than we here
 realize just off-hand.)


 
 
 I wouldn't want to hear a promise like that.  To me, it makes it sound like
 there's definately not going to be any new improvements\features for at least
the
 next year.
 
 I think you would be better off not making any statement about the "next"
 version... period.
 


One way to handle this would be to not place any public links up for the
"version next" model except 
in these newgroups. Then the community (all of us "beta testers") would be
aware of it, and it would 
have a web presence, but the public at large wouldn't confuse it with
"unstability".


 If you really want to promise anything, something along the lines of "All
 updates\versions\releases will be backwards compatible with 1.0 for the next 12
 months (or until 2.0), except for unintended 'features' caused by bugs." would
be
 plenty to imply a stable platform.
 
 Just my opinion of course.
Nov 06 2006