On Mon, Apr 30, 2012 at 07:07:53AM +0200, David Nadlinger wrote:
> On Monday, 30 April 2012 at 03:16:09 UTC, H. S. Teoh wrote:
> >On Sun, Apr 29, 2012 at 02:26:12PM +0200, David Nadlinger wrote:
> >>[…]
> >> - Built-in arrays and AAs: They are convenient to use, but as
> >>far as I can see the single biggest GC dependency in the language. Why not lower array and AA literals to expression tuples (or whatever) to make the convenient syntax usable with custom (possibly non-GC safe) containers as well? A GC'd default implementation could then be provided in druntime, just like today's arrays and AAs.
> >[...]
> >
> >AA's are moving into druntime. Yours truly is supposed to make that happen eventually, but lately time hasn't been on my side. :-/
> 
> This moves the _implementation_ to druntime, but there is still realistically no way to use AA literals with my own non-GC'd version of hash maps without shipping a custom druntime (and thus modifying the semantics of an existing language construct). What I'm talking about would let you do things like
> 
> MyVector!int stuff = [1, 2, 3, 4, 5];
> 
> without needing a (temporary) GC'd allocation, and thus please the GC-hater crowd because they can still have all the syntax candy with their own containers, even if they can't resp. don't want to use the default GC'd constructs.
[...]

I think you're talking about two orthogonal issues here. One is language-level support for arrays and AA's, which IMO are necessary and are even a plus (built-in AA's are one of the big reasons I chose D). The other is language-level support for literal syntax in user-defined types.

I think the latter area has lots of room for improvement. From a theoretical standpoint, syntax like [1,2,3,4,5] really should not be prematurely tied to a specific type: at the most fundamental level, it's just specifying a list of things. How the abstract concept of a list of things should be implemented need not be constrained to concrete built-in types; I'd argue that the language should permit the realization of the concept in a user-defined type as well (i.e., the literal interpreted by a user type).

Just off the top of my head, this might be achievable by introducing a fromList method in user-defined types that takes a compile-time parameter containing some representation of the list, say as a builtin array. This method then does whatever is needed to create an instance of the type accordingly. (Since the parameter is compile-time, this essentially just generates code to create the custom container directly.)

The same thing can be done for custom floating-point literals, say. A fromFloat() method takes a compile-time string containing the literal, and creates an instance of the custom type. (A string is used here so that you can implement types that far exceed the maximum precision of any builtin type.)

Ditto for AA literals: a fromAA() method takes a compile-time list of key/value pairs and does whatever it needs to do to create the appropriate runtime AA. In fact, such a construct would alleviate much of the need for compiler hacks to support AA's (both old and the prospective new replacement). There will be no unnecessary overhead of allocating runtime arrays, copying, etc.; the fromAA() method at compile-time generates whatever code is necessary to create the literal into the target object directly.

This is a language enhancement issue, though, not really an issue about builtin AA's or arrays being "unnecessary features".


T

-- 
All men are mortal. Socrates is mortal. Therefore all men are Socrates.

On 4/30/12, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> On Sunday, April 29, 2012 21:56:08 H. S. Teoh wrote:
>> I wonder if dmd (or rdmd) should have a mode where it *only* compiles
>> unittest code (i.e., no main() -- the resulting exe just runs unittests
>> and nothing else).

For RDMD you can do:
version(unittest) { }
else
void main() {
    // regular code here
}

And then you can invoke rdmd with --unittest and --main to insert an empty main function when unittesting. Personally I put in a stub main so I don't depend on rdmd features like --main:

version(unittest) { void main(string[] args) { } }  // stub main
else
void main() {
    // regular code here
}

On 4/30/12, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:
> I think the correct solution here is to use alias. (If that doesn't work, then it should be made to work..)

It probably will. Quote Andrei: "Yah, we should add that at some point. Walter and I discussed about it and it's virtually approved. But to be on the conservative side, it's not for expressions but for mere pointer-chasing chains."

So this would probably work:
alias var.some.deeply.nested.object obj;
// use obj here..

I think that's what is being discussed w.r.t. with()?

On Monday, April 30, 2012 07:46:48 Andrej Mitrovic wrote:
> On 4/30/12, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> > On Sunday, April 29, 2012 21:56:08 H. S. Teoh wrote:
> >> I wonder if dmd (or rdmd) should have a mode where it *only* compiles
> >> unittest code (i.e., no main() -- the resulting exe just runs unittests
> >> and nothing else).
> 
> For RDMD you can do:
> version(unittest) { }
> else
> void main() {
>     // regular code here
> }
> 
> And then you can invoke rdmd with --unittest and --main to insert an empty main function when unittesting. Personally I put in a stub main so I don't depend on rdmd features like --main:
> 
> version(unittest) { void main(string[] args) { } }  // stub main
> else
> void main() {
>     // regular code here
> }

Yes, but that still compiles everything. It just gives you a convenient way to have a unit test executable separate from your normal executable.

- Jonathan M Davis

On 2012-04-29 18:28, Timon Gehr wrote:
> 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.

That's the whole point, there won't be any special case for CTFE. BTW, isn't that basically the same as having a built-in interpreter?

-- 
/Jacob Carlborg

On 4/30/12, Jesse Phillips <jessekphillips+D@gmail.com> wrote:
> I believe DIP 4 is the proposal
>
> http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs
>
> But don't forget to check out DIP 5 too.

Well it says they're both superseeded by DIP 6 but DIP6 didn't implement things DIP4 was talking about.DIP4 goes on to discuss C#-style properties a bit and acknowledges the issue with += as well. I didn't find anything in bugzilla, so I'm opening an enhancement request: http://d.puremagic.com/issues/show_bug.cgi?id=8006

On 2012-04-29 19:03, David Nadlinger wrote:

> 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

Yeah, that would need to be solved. In Ruby it works like this:

[1, 2, 3, 4].each do |i|
  if i == 2
    return
  end
end

Results in:

LocalJumpError: unexpected return

If you instead wrap it in method you can return from the each-block. So in Ruby it behaves just like having a "return" in a plain for-loop and not in a delegate. It would basically force a return in the "each" method.

-- 
/Jacob Carlborg

> Sorry, I managed to get myself confused here. What I meant to say was that I think >> should do an arithmetic shift if the operands are signed; unsigned shift otherwise.

It does arithmetic shift if the left operand is signed,
unsigned shift otherwise. This code:

void main()
{
    int a = 0xffffffff;
    uint b = a;
    writefln("%x", a >> 1);
    writefln("%x", b >> 1);
}

prints

ffffffff
7fffffff

On 2012-04-29 20:08, Manu wrote:

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

As far as I know it works like this:

pack
  |- pack1
    |- foo.d
    |- bar.d
      |- pack2
          |- a.d
  |- pack3
      |- b.d
  |- c.d

// pack.pack1.foo

package int x = 3;

// pack.pack1.bar

x = 4; // this is fine since it's in the same package.

// pack.pack1.pack2.a

x = 5; // error, cannot access package protected variable.

// pack.pack3.b

x = 6; // error, cannot access package protected variable.

// pack.c

x = 7; // error, cannot access package protected variable.

Oh, and "package" is non-virtual, for some reason.

-- 
/Jacob Carlborg

On Monday, April 30, 2012 01:41:45 bearophile wrote:
> Walter:
> > What's your list?
> 
> This thread now has something like 240 answers (and probably few more will come), and despite some variability in the answers, we have seen several recurring patterns too. So what are the conclusions, take-home insights, and the to-do's to make something in practice, from Walter & Andrei?

Honestly, I don't think that you _can_ take much from this thread other than the fact that pretty _every_ feature is wanted and used by someone, even if other people hate it. Pretty much every feature listed as undesirable by someone was listed as desirable by someone else.

As for TODOs, the impression that I got from Walter's post was that he wanted to know what people thought out of curiosity or just for "lessons learned" from the design process of D and not that he was really looking to remove anything from the language. So, I don't think that it was ever his intention to create a TODO list from this (though I could be wrong). There may be some minor things that get changed (such as making it so that adjacent string literals don't get automatically concatenated), but I don't think that D is really going to have any of its features removed at this point.

- Jonathan M Davis