On 2012-04-29 00:02, deadalnix wrote:

> Off topic. I discussed several proposals, and I invest time ever since
> to come up with a good solution. Introducing a whole new paradigm in a
> language isn't something light.
>
> AST manipulation at compile time is the key.

This would be awesome to have.

-- 
/Jacob Carlborg

On Sunday, 29 April 2012 at 12:26:13 UTC, David Nadlinger wrote:
>  - Anonymous nested classes: They might be useful in Java, particularly in older incarnations, but not so much in D – never used them.

I never used these until very recently. A couple weeks
ago, I wanted to do some kind of range adapter kinda like
Phobos does with the anon structs... but I wanted it to
work with runtime too.

So, I made an interface with empty, front, popFront,
and then pulled out the old "return new class ByChunkRange"
for the first time.

I never expected that I'd use it, but it was nice to have
for that time when I did decide I wanted it.


That's my biggest concern with saying we have too many
features. We might not use them often, but it would suck
to say "that would be perfect" just to find it was removed
later.

On 29.04.2012 18:40, Jacob Carlborg wrote:

>
> 1 + 2
> foo bar foo_bar
>
> Would be translated to:
>
> 1.+(2)
> foo.bar(foo_bar)
>
> That is a very general way to handle operators and let the user create
> new operators, not just overloading existing ones.
>

warning(1): Smalltalk detected! [use -foop-only to ignore]

Operator precedence would get real tricky (or stupid just like in Smalltalk).


-- 
Dmitry Olshansky

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

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?
[...]

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

I read somewhere that one of D's goals was to be able to lex the language without requiring semantic knowledge in the lexer. You have no idea 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 and template best-match algorithms. Be glad, be very glad that we have D instead of C++!


T

-- 
Designer clothes: how to cover less by paying more.

On Sun, Apr 29, 2012 at 08:40:16AM +0200, Paulo Pinto wrote: [...]
> My employer does consulting for big projects. The type of entreprise projects that require multi-site development scattered across the globe, sometimes with 300+ developers.
> 
> There is no way a dynamic language would work in such scenarios, without having a constant broken build on the CI system.
[...]

Yeah, at my work we have about 20-30 people working on a very large C/C++ codebase (one among many), and we already get broken builds every now and then, like bugs that completely break just about every feature in the system -- makes you wonder how any sane programmer could've checked in such a mess (and how said mess made it through the kangaroo code review process). Or blatant internal API breakages that make you wonder if anybody even *read* what they wrote.

I cannot begin to imagine the horror of using a dynamic language in this setting. Static languages are already painful enough; throw in indeterminate typing at compile-time and it's a recipe for utter disaster, probably every single work day.  And this is only 20-30 developers. The problem gets exponentially worse when that number goes up. At 300+ developers, the project would grind to a complete halt in less than a day (probably less than an hour).


T

-- 
Study gravitation, it's a field with a lot of potential.

On Sun, Apr 29, 2012 at 10:28:47AM +0200, SomeDude wrote:
> On Sunday, 29 April 2012 at 08:13:53 UTC, Nick Sabalausky wrote:
> >
> >There will still be sugar in the compiler so they appear to be builtins.  When the switch happens, I'm sure it'll be transparent - average users probably won't even notice. It's just that "behind the scenes" their implementation will move from DMD to Druntime.
> 
> Hmmm, sounds nice, but bolting the language with the standard library is very risky (and a rather bad idea imho). Unless there is a very lightweight minimalistic core for Phobos (something which I advocate), you bolt a heavyweight library to your language, and that's not good.
[...]

Please note that the AA implementation will be moving into druntime, NOT phobos. The compiler already depends on a bunch of stuff in druntime (the GC being a prime example, and the Object class being another). And every time you write 'typeid'? That's druntime code too.


T

-- 
It is widely believed that reinventing the wheel is a waste of time; but I disagree: without wheel reinventers, we would be still be stuck with wooden horse-cart wheels.

On Sunday, 29 April 2012 at 15:16:57 UTC, H. S. Teoh wrote:
> […] and template best-match algorithms. Be glad, be very glad that we have D instead of C++!

To be fair, the template matching logic in D is quite complicated as well (at least I can recall several instances of stumbling over bugs in the implementation, would have to search Bugzilla for details) – the only thing is that we don't really have a formal spec for it yet…

David

On 2012-04-29 04:32, Francois Chabot wrote:
>> - properties - another incredibly convenient feature. I think a more
>> sexy implementation of properties are in order, but the construct is
>> great. It would be nice to have properties as a language type, rather
>> than a attribute:
>
> To me, properties are much more than a convenience. The important part
> of it comes from its existence, not its usage. Quite simply, having
> properties mean that using public member variables does not break
> encapsulation (as long as having them part of the public interface is
> intentional).
>
> Without properties, you MUST write accessors for all of them on the off
> chance that you might want to refactor/delegate them in the future. This
> adds a huge amount of boilerplate code that ends up wasted time 98% of
> the time.
>
> In short, properties existing, even if not used, end up improving both
> my efficiency and the legibility of my code.

In principle I agree with you. But in practice this doesn't always work. Take this for example:

struct Point
{
    int x;
    int y;
}

class Widget
{
    Point point;
}

void main()
{
    auto w = new Widget;
    writeln(w.point.x);
    w.point.x++;
    writeln(w.point.x);
}

Prints "0" and "1" as expected. If we now change "point" to a property like this:

class Widget
{
    //Point point;

    Point point_;

    @property Point point ()
    {
        return point_;
    }

    @property Point point (Point point)
    {
        return point_ = point;
    }
}

It will now print "0" and "0". This is a silently breaking change. Sure you can change "point" to return by reference:

class Widget
{
    Point point_;

    @property ref Point point ()
    {
        return point_;
    }

    @property ref Point point (Point point)
    {
        writeln("foo");
        point_ = point;
        return point_;
    }
}

Which will print "0" and "1" again. But it won't print "foo", meaning you bypassed the getter. To solve this the compiler would need to perform some kind of property rewriting. Translating:

w.point.x++;

To:

auto __p = w.point;
__p.x++;
w.point = __p;

Also you might need to just as well use properties from the beginning because you need virtual properties. It would help if this was allowed:

class Widget
{
    @property Point point;
}

Which would translate to:

@property Point point ()
{
    return point_;
}

@property Point point (Point point)
{
    return point_ = point;
}

-- 
/Jacob Carlborg

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).
* package. I have no idea how a failed Java experiment got incorporated into D.
* the zoo of parameter passing options
* Most of the __traits are useless and redundant.