On 7/28/14, 4:54 AM, Daniel Murphy wrote:
> "Jonathan M Davis"  wrote in message
> news:lfhsrrkauworheqmedhm@forum.dlang.org...
>
>> I would point out that every time I've seen compiler devs discuss
>> using Phobos in dmd, there has been a large reluctance to do so (if
>> not outright a desire to avoid it entirely) in order to avoid the
>> circular dependencies that would ensue (Daniel Murphy in particular
>> really doesn't seem to like the idea).
>
> Yes, and I'm still against it.  It's not about the circular dependency
> (that already exists with druntime and is manageable) it's that
> including phobos effectively massively increases the size of the dmd
> codebase.  Phobos is also tied to the release cycles in a different way
> than it looks like ddmd will be.  Druntime is much smaller and much less
> worrying (and impossible to avoid).

There'd also be the argument that using phobos inside ddmd would make the latter a better test for itself and phobos. -- Andrei

On Mon, Jul 28, 2014 at 11:03:22AM -0700, Andrei Alexandrescu via Digitalmars-d wrote:
> On 7/28/14, 4:54 AM, Daniel Murphy wrote:
> >"Jonathan M Davis"  wrote in message news:lfhsrrkauworheqmedhm@forum.dlang.org...
> >
> >>I would point out that every time I've seen compiler devs discuss using Phobos in dmd, there has been a large reluctance to do so (if not outright a desire to avoid it entirely) in order to avoid the circular dependencies that would ensue (Daniel Murphy in particular really doesn't seem to like the idea).
> >
> >Yes, and I'm still against it.  It's not about the circular dependency (that already exists with druntime and is manageable) it's that including phobos effectively massively increases the size of the dmd codebase.  Phobos is also tied to the release cycles in a different way than it looks like ddmd will be.  Druntime is much smaller and much less worrying (and impossible to avoid).
> 
> There'd also be the argument that using phobos inside ddmd would make the latter a better test for itself and phobos. -- Andrei

FWIW, I'm for dogfooding. I think using Phobos in ddmd will (indirectly) improve the quality of Phobos. I still have this lurking suspicion that large swaths of Phobos have only barely been used, and therefore there are probably many bugs, design issues, and inefficiencies that we're unaware of. Or only unknown user code out there uses some of these things, but we don't know about it so we're not conscious of issues that may arise. Using Phobos in ddmd will give us very strong incentives to polish Phobos to a far higher quality than it currently is, IMO.


T

-- 
Frank disagreement binds closer than feigned agreement.

On 7/28/14, 11:12 AM, H. S. Teoh via Digitalmars-d wrote:
> On Mon, Jul 28, 2014 at 11:03:22AM -0700, Andrei Alexandrescu via Digitalmars-d wrote:
>> On 7/28/14, 4:54 AM, Daniel Murphy wrote:
>>> "Jonathan M Davis"  wrote in message
>>> news:lfhsrrkauworheqmedhm@forum.dlang.org...
>>>
>>>> I would point out that every time I've seen compiler devs discuss
>>>> using Phobos in dmd, there has been a large reluctance to do so (if
>>>> not outright a desire to avoid it entirely) in order to avoid the
>>>> circular dependencies that would ensue (Daniel Murphy in particular
>>>> really doesn't seem to like the idea).
>>>
>>> Yes, and I'm still against it.  It's not about the circular
>>> dependency (that already exists with druntime and is manageable) it's
>>> that including phobos effectively massively increases the size of the
>>> dmd codebase.  Phobos is also tied to the release cycles in a
>>> different way than it looks like ddmd will be.  Druntime is much
>>> smaller and much less worrying (and impossible to avoid).
>>
>> There'd also be the argument that using phobos inside ddmd would make
>> the latter a better test for itself and phobos. -- Andrei
>
> FWIW, I'm for dogfooding. I think using Phobos in ddmd will (indirectly)
> improve the quality of Phobos.

According to Simon Peyton Jones, it has greatly worked for ghc (the reference Haskell compiler). Essentially ghc is one of the largest and most complex codebases of ghc itself. I assume they use Haskell's own standard library in the compiler.

> I still have this lurking suspicion that
> large swaths of Phobos have only barely been used, and therefore there
> are probably many bugs, design issues, and inefficiencies that we're
> unaware of. Or only unknown user code out there uses some of these
> things, but we don't know about it so we're not conscious of issues that
> may arise. Using Phobos in ddmd will give us very strong incentives to
> polish Phobos to a far higher quality than it currently is, IMO.

Agreed. Conversely we'd be hamstringing ourselves by essentially making D a poorer choice for implementing dmd than any other languages. The standard library of a language is a good part of any language's power, and that's true especially for D; static introspection has moved a bunch of stuff usually confined to builtins into the standard library.

I'm not among the compiler development regulars but it seems to me converting to ddmd would be a mistake if we don't plan for using Phobos.


Andrei

"Andrei Alexandrescu"  wrote in message news:lr6395$19r7$1@digitalmars.com...

> There'd also be the argument that using phobos inside ddmd would make the latter a better test for itself and phobos. -- Andrei

This is true, but my main concern is the quality of the compiler source.

My main concerns are: (not in order)
- Compile time
- Binary bloat
- Reduced scrutiny of code that is used in the compiler - I review every single compiler patch, but I do not have time to do that for phobos too
- The compiler must build with the last release, and with HEAD.  HEAD phobos only needs to build with HEAD.
- Some other things.

Anyway, there is no rush.  We will have plenty of time to talk about this after ddmd becomes dmd. 

On Tue, Jul 29, 2014 at 04:24:27AM +1000, Daniel Murphy via Digitalmars-d wrote:
> "Andrei Alexandrescu"  wrote in message news:lr6395$19r7$1@digitalmars.com...
> 
> >There'd also be the argument that using phobos inside ddmd would make the latter a better test for itself and phobos. -- Andrei
> 
> This is true, but my main concern is the quality of the compiler source.
> 
> My main concerns are: (not in order)
> - Compile time
> - Binary bloat

I see this as a good thing, actually. Not that I think it's good to increase compile time and binary bloat, but that when this happens, we will have very strong incentives to do something about it, that will drive us to do whatever it takes for Phobos to *not* get in the way of fast compile times and to *not* introduce tons of template bloat. The end result will be a far better quality Phobos than we might ever achieve otherwise, since external D codebases wouldn't be as strong an incentive as the compiler itself would.


> - Reduced scrutiny of code that is used in the compiler - I review
>   every single compiler patch, but I do not have time to do that for
>   phobos too

Perhaps the solution is to get more people involved in this review? Y'know, increase the bus factor and everything.


> - The compiler must build with the last release, and with HEAD.  HEAD
>   phobos only needs to build with HEAD.
[...]

Would it be too unrealistic to set things up so that ddmd bootstraps itself with a *previous* release of Phobos, and then compile itself again with the latest Phobos git HEAD? (And by this I mean that `make -f posix.mak` will actually run through this bootstrap process, so that if something breaks, it will be very obvious in the autotester and we wouldn't pull whatever PR it is that caused the breakage.) This would ensure that whatever we do, ddmd won't become uncompilable with a previous release of itself, but will be effectively written in a prior version of D (or ideally, in the common subset of D between the two releases, or N releases if we decide to do that).


T

-- 
What is Matter, what is Mind? Never Mind, it doesn't Matter.

"H. S. Teoh via Digitalmars-d"  wrote in message news:mailman.124.1406572776.16021.digitalmars-d@puremagic.com...

> I see this as a good thing, actually. Not that I think it's good to
> increase compile time and binary bloat, but that when this happens, we
> will have very strong incentives to do something about it, that will
> drive us to do whatever it takes for Phobos to *not* get in the way of
> fast compile times and to *not* introduce tons of template bloat. The
> end result will be a far better quality Phobos than we might ever
> achieve otherwise, since external D codebases wouldn't be as strong an
> incentive as the compiler itself would.

I do not see it that way.  Once phobos quality is acceptable, then we can think about using it in dmd.  As much as I want phobos to be as good as possible, this cannot in any way come at the expense of the compiler's quality.

> Perhaps the solution is to get more people involved in this review?
> Y'know, increase the bus factor and everything.

Do you mean dmd contributors should be reviewing phobos pulls instead of working on dmd?

> Would it be too unrealistic to set things up so that ddmd bootstraps
> itself with a *previous* release of Phobos, and then compile itself
> again with the latest Phobos git HEAD? (And by this I mean that `make -f
> posix.mak` will actually run through this bootstrap process, so that if
> something breaks, it will be very obvious in the autotester and we
> wouldn't pull whatever PR it is that caused the breakage.) This would
> ensure that whatever we do, ddmd won't become uncompilable with a
> previous release of itself, but will be effectively written in a prior
> version of D (or ideally, in the common subset of D between the two
> releases, or N releases if we decide to do that).

Yes, this one can be solved somewhat by improving test infrastructure.  But it will tie the parts of phobos that dmd uses to dmd's release cycle.

eg if we add a new built-in attribute, it can't be used in phobos until the last compiler that doesn't support it is no longer supported for building dmd.  Same for every compiler patch.

It would also be nice to keep compatibility further back than a single dmd release.  This would make things harder. 

"Andrei Alexandrescu"  wrote in message news:lr64ah$1akc$1@digitalmars.com...

> Agreed. Conversely we'd be hamstringing ourselves by essentially making D a poorer choice for implementing dmd than any other languages.

This doesn't make any sense.  Somehow D is a worse choice than C++ if we don't use phobos?

> I'm not among the compiler development regulars but it seems to me converting to ddmd would be a mistake if we don't plan for using Phobos.

You are severely underestimating the benefits of D as a language. 

On Monday, 28 July 2014 at 12:43:03 UTC, Dominikus Dittes Scherkl wrote:
> On Sunday, 27 July 2014 at 13:17:42 UTC, Iain Buclaw wrote:
>> The cent and ucent keywords have been reserved since... well... certainly before the first D1 (as opposed to D0.xx) release [2].  But that's all they have ever seemed to be.  Just reserved keywords that give odd errors when you try to use them.
> Yes, I truly wish those would be supported - not only to use them directly, but at least as fallback for e.g. safe multiplication (cent x = long * long; if(x > long.max) throw exception;)
> From the language reference I had strongly expected that cent and ucent are supported - a look into phobos destroyed that hope :-/

https://github.com/d-gamedev-team/gfm/blob/master/math/gfm/math/wideint.d FWIW

On 7/28/14, 11:24 AM, Daniel Murphy wrote:
> "Andrei Alexandrescu"  wrote in message
> news:lr6395$19r7$1@digitalmars.com...
>
>> There'd also be the argument that using phobos inside ddmd would make
>> the latter a better test for itself and phobos. -- Andrei
>
> This is true, but my main concern is the quality of the compiler source.
>
> My main concerns are: (not in order)
> - Compile time
> - Binary bloat
> - Reduced scrutiny of code that is used in the compiler - I review every
> single compiler patch, but I do not have time to do that for phobos too
> - The compiler must build with the last release, and with HEAD.  HEAD
> phobos only needs to build with HEAD.
> - Some other things.

The way I see some of these liabilities is as dogfooding. For example if slow compile times and code bloat become a problem with ddmd they are also a problem with other large D programs, and it's good to have an extra incentive to fix them.

> Anyway, there is no rush.  We will have plenty of time to talk about
> this after ddmd becomes dmd.

That's the spirit!


Andrei

On 7/28/14, 11:37 AM, H. S. Teoh via Digitalmars-d wrote:
> On Tue, Jul 29, 2014 at 04:24:27AM +1000, Daniel Murphy via Digitalmars-d wrote:
>> "Andrei Alexandrescu"  wrote in message
>> news:lr6395$19r7$1@digitalmars.com...
>>
>>> There'd also be the argument that using phobos inside ddmd would make
>>> the latter a better test for itself and phobos. -- Andrei
>>
>> This is true, but my main concern is the quality of the compiler
>> source.
>>
>> My main concerns are: (not in order)
>> - Compile time
>> - Binary bloat
>
> I see this as a good thing, actually. Not that I think it's good to
> increase compile time and binary bloat, but that when this happens, we
> will have very strong incentives to do something about it, that will
> drive us to do whatever it takes for Phobos to *not* get in the way of
> fast compile times and to *not* introduce tons of template bloat. The
> end result will be a far better quality Phobos than we might ever
> achieve otherwise, since external D codebases wouldn't be as strong an
> incentive as the compiler itself would.

YES! I wrote my reply before reading this!! -- Andrei