Am 29.04.2012 17:27, schrieb H. S. Teoh:
> On Sun, Apr 29, 2012 at 08:40:16AM +0200, Paulo Pinto wrote:
> [...]
 At 300+ developers, the project would grind to a complete halt in
> less than a day (probably less than an hour).
>

Suffice to say, that on that specific project we had weeks without
any working build, that had to be saved with hard code free rules
until it got green again.

This type of projects is what made me change my mind about static vs
dynamic.

Static languages with automatic type inference, and some type of
dynamic dispatch like D's variant type/opDispatch, fullfil most
use cases a dynamic language is good for, without sacrificing tooling
or large scale development.

--
Paulo

On 2012-04-29 17:07, David Nadlinger wrote:
> On Sunday, 29 April 2012 at 14:40:38 UTC, Jacob Carlborg wrote:
>> foreach ([1, 2, 3, 4], (i) { writeln(i); });
>>
>> The above already works today. If we can a bit syntax sugar for
>> delegates and inlinable delegates we could have this:
>>
>> foreach ([1, 2, 3, 4] ; i) {
>> writeln(i);
>> }
>
> We'd still need a solution for continue and break, though.
>
> David

This has already been solved when using opApply, although quite an ugly solution.

-- 
/Jacob Carlborg

On 04/29/2012 04:53 PM, Jacob Carlborg wrote:
> On 2012-04-28 22:43, Timon Gehr wrote:
>> On 04/28/2012 09:58 PM, foobar wrote:
>>> It should be replaced by a standard compilation
>>> API and the compiler should be able to use plugins/addons.
>>
>> Are you serious?
>
> Have a look at what Scala have done. They basically have the complete
> compiler available as a library. Then they used this library to
> implement runtime reflection and macros. Macros in Scala are functions
> that execute at compile time.
>

It is not as powerful as what we have in D and it requires invoking the compiler multiple times.

On Sunday, 29 April 2012 at 16:10:40 UTC, Jacob Carlborg wrote:
> On 2012-04-29 17:07, David Nadlinger wrote:
>> On Sunday, 29 April 2012 at 14:40:38 UTC, Jacob Carlborg wrote:
>>> foreach ([1, 2, 3, 4] ; i) {
>>> writeln(i);
>>> }
>>
>> We'd still need a solution for continue and break, though.
>>
>> David
>
> This has already been solved when using opApply, although quite an ugly solution.

Yes, but that requires the compiler to generate the return value »glue« code for continue/break inside an opApply foreach. If foreach is a library function and you pass an ordinary delegate, you have a problem in the current language since you can't know that a »return« statement inside that delegate really should return from the outer function.

David

On Sunday, 29 April 2012 at 15:50:54 UTC, Don wrote:
> * package. I have no idea how a failed Java experiment got incorporated into D.

+1, forgot to mention that one.

David

On Sunday, 29 April 2012 at 09:52:21 UTC, David Nadlinger wrote:
> On Saturday, 28 April 2012 at 21:12:39 UTC, SomeDude wrote:
>> […] And this opinion doesn't come just out of thin air, I speak from my own professional experience.
>
> Regardless of the fact that I tend to agree with you on this one, isn't »my own professional experience« usually a synonym for »thin air«? ;)
>
> David

Well yes and no. It's the difference between "I think that", and "I've experienced in real projects that". And well, discussing in another forum, I've had other similar echos and experiences. Basically, with Python and other dynamically typed languages, the time you gain writing code, you lose testing it and correcting bugs that a compiler would have found for you.

Don:

> * package. I have no idea how a failed Java experiment got incorporated into D.

Weren't Java designers thinking about adding superpackages too to Java?


> * the zoo of parameter passing options

Please explain, what do you mean?

Bye,
bearophile

On 04/29/2012 05:17 PM, H. S. Teoh wrote:
> On Sun, Apr 29, 2012 at 02:35:07AM -0400, Nick Sabalausky wrote:
>> "Timon Gehr"<timon.gehr@gmx.ch>  wrote in message
>> news:jnhpvv$ih4$1@digitalmars.com...
> [...]
>>> Implementing a compiler is probably harder for D, because of the
>>> interplay of forward references, CTFE and compile time
>>> introspection.
>>
>> Those make D more difficult to implement than many languages, but
>> OTOH, AIUI, C++ has some real nightmarish details with templates and
>> even just simply parsing. Probably some other bizarre cruft, too.
>> IIRC, I think Walter's occasionally mentioned something about
>> the...overload rules?
> [...]

C++ implementation complexity is incidental.

>
> It has been said that C++ cannot be lexed before it's parsed.  Before
> C++11, for example, this is invalid:
>
> 	std::vector<std::vector<T>>  nestedList;
>
> Instead, you have to write:
>
> 	std::vector<std::vector<T>  >  nestedList;
>
> Fortunately they fixed this in C++11. But now you have another problem:
>
> 	std::vector<myTemplate<T>>1>  nestedList;
>
> Whether or not this is valid depends on whether T is a type name or a
> variable name

I think it is never valid.

> (e.g., if myTemplate takes an int parameter). But how is
> the lexer even supposed to know whether the>>  should be a right shift
> operator or two right angle brackets? It has to understand the
> _semantics_ of T before it can even lex the thing.
>

A D compiler has to semantically analyse the code without full information about which symbols are declared, (getting the full set of declared symbols is actually an ill-defined problem because conditional compilation is Turing complete and can already depend on any declared symbol or even on the fact that a certain symbol has _not_ been declared). There might also be ambiguities or contradictions in the code that a compiler should detect.

There is no mention of this issue or its (necessarily conservative and somewhat arbitrary) solution in the language documentation. DMD does not solve the problem, but just fails in funny ways when faced with a non-trivial instance of it.

C++ does not have such issues at all because it disallows forward references!


Don't get me wrong, I think this is rather awesome. But I predict it will be somewhat of a roadblock for getting the language into a stable state.


> I read somewhere that one of D's goals was to be able to lex the
> language without requiring semantic knowledge in the lexer.

This is required in order to have forward references.

> You have no idea

I do.

> how much such a seemingly-obvious concept can save hours, days,
> nay, months and years of frustration in compiler implementation.
>
> So you think D is hard to implement? We have barely even begun to delve
> into the insane convolutions of C++. You'll start to have some real
> hair-tearing sessions once you start getting into implicit conversion
> rules

Well, again, DMD does not get those right. And there is some black magic in that area, because the implicitly-converts-to-relation is from expressions to types instead of from types to types. (which is awesome of course, but it is complex to get right).

Try this (this *should* compile).

pragma(msg, typeof(1?[[]]:[[1]]));
pragma(msg, typeof(1?1?[[]]:[[]]:[[1]]));
pragma(msg, typeof([[[]],[[]],[[1]]]));

class C{}
static C[] c = [null];
pragma(msg, typeof([[null],[new C]]));


> and template best-match algorithms. Be glad, be very glad that we
> have D instead of C++!
>

static if(!is(typeof(foo))) enum bar = 1;
static if(!is(typeof(bar))) enum foo = 1;


In D, most of the complexity stems from its advanced features, while in C++ a lot of the complexity is merely incidental.

On 29 April 2012 18:50, Don <nospam@nospam.com> wrote:

> On 28.04.2012 20:47, Walter Bright wrote:
>
>> Andrei and I had a fun discussion last night about this question. The idea was which features in D are redundant and/or do not add significant value?
>>
>> A couple already agreed upon ones are typedef and the cfloat, cdouble and creal types.
>>
>> What's your list?
>>
>
> * The >>> operator, which does nothing except introduce bugs (It does NOT
> perform an unsigned shift).
>

What does it do? I use this all over the place, I assumed it worked... maybe I have bugs?


> * package. I have no idea how a failed Java experiment got incorporated into D.
>

package confuses me, it's poorly documented. What are the protections between packages, sub-packages. Can parent packages see sub-package contents? vice-versa?

* Most of the __traits are useless and redundant.
>

Which traits are useless and redundant? I'm actually finding the set is incomplete, and there are some missing (parameter list introspection, current scope/object identification, current module/package)

On 4/29/12, David Nadlinger <see@klickverbot.at> wrote:
> As for r"", every time I
> actually need WysiwigString, I use backticks, because such
> strings often contain quotes anyway.

IIRC I think the reason for this might be that some keyboards don't have the backtick key, or something like that.

> Regarding TokenString(i.e.
> q{}) .. The problem is that
> can't just »interrupt« q{}s strings to do something like
> »q{…} ~ identifierName ~ q{…}«,

I typically use format for these purposes, e.g.:
string x = format(q{
void %s() { }
}, "foo");

Works fairly well for me.

>   - Concatenation of adjacent strings: Also an anti-feature, imho.

Absolutely!

>   - »Short« floating point literals like .4 instead of 0.4 and
> 4. instead of 4.0 – the saved characters are not worth the
> syntax special cases, especially w.r.t. UFCS.

I think those are already deprecated? Or they're about to be anyway.

>   - shared: TLS by default is great, but only __gshared is really
> usable right now.

Yep, and Phobos doesn't deal with shared all that well either. E.g.
format() doesn't work on shared variables
(http://d.puremagic.com/issues/show_bug.cgi?id=7036).