Re: Changing the name of the language?

[Walter Bright]

On 3/15/2012 7:43 PM, Brad Anderson wrote:

https://github.com/D-Programming-Language/d-programming-language.org/pull/100


Right on :-)

Re: Changing the name of the language?

[Walter Bright]

On 3/15/2012 7:46 PM, ixid wrote:

I hope people were not angered by the question.


Not in the least. It's a common question, and belongs in the FAQ.

Re: Dynamic language

[so]

On Thursday, 15 March 2012 at 22:51:57 UTC, H. S. Teoh wrote:

It can also be a security concern. Somebody could offer players 
an
"awesome script" in DLL form that actually contains arbitrary 
exploit

code. Or a "script" that contains D code for an exploit.


If you are compiling at runtime you can expose only certain 
header files and with d annotations like "safe" and many others 
you can also disable low level access.

Re: Dynamic language

[so]

On Thursday, 15 March 2012 at 22:37:12 UTC, Manu wrote:

Do you expect users to be modifying the scripts in the retail 
release?

Surely scripting is still for what it has always been for, rapid
iteration/prototyping during development.


You need to be able to do both.

You only need the compiler as a part of the games 
asset-pipeline.


That is the biggest and (only :) ) blocker.

Re: Dynamic language

[Paulo Pinto]

That is the reason why managed environments with JIT are so popular,
you get the best of both worlds.

"Andrei Alexandrescu"  wrote in message 
news:jjtiu8$1ucs$1...@digitalmars.com...


On 3/15/12 3:12 PM, Nick Sabalausky wrote:

Anything an interpreter can do, a compiler can do. And dynamic typing
doesn't have anything to do with interpreted vs compiled anyway.


Generating and running code during runtime is often easier in
interpreted environments.

Andrei 

Re: Standalone AA implementation ready for review (Was: Re: Replacing AA's in druntime)

[Jacob Carlborg]

On 2012-03-15 23:59, foobar wrote:

On Thursday, 15 March 2012 at 10:39:04 UTC, Steven Schveighoffer wrote:



Why would that pose a problem to DMD? object.d is a regular D module and
D provides a public import feature. If that fails for some modules it
should be considered a bug in the compiler.

I disagree about the side of the benefit. This gains us readability of
code which is IMO a MAJOR benefit. It's not just the object.d module but
a lot of phobos too.
It frustrates me to no end Andrei's refusal to accept a design proven to
work for half a century (which is already utilized by the compiler!) -
the File System. Choosing instead to duplicate organization features
inside DDOC as sections. This is a classic example of a code smell.



I completely agree.

--
/Jacob Carlborg

Re: Multiple return values...

[Iain Buclaw]

On 16 March 2012 02:26, Andrei Alexandrescu
 wrote:
> On 3/15/12 5:44 PM, foobar wrote:
>>
>> On Thursday, 15 March 2012 at 18:23:57 UTC, Andrei Alexandrescu wrote:
>>>
>>>
>>> I understand how the draw of reaching for new syntax is extremely
>>> alluring. I used to fall for it much more often, but over years I have
>>> hardened myself to resist it, and I think that made me a better
>>> language designer. In this stage of D, I think we should all have an
>>> understanding that adding syntax is not a win. Instead, it is an
>>> acknowledgment that the existing language, for all its might, is
>>> unable to express the desired abstraction. This is sometimes fine
>>> (such as in the case of introducing multiple new symbols from one
>>> tuple), but generally the question is not "why couldn't we add syntax
>>> X?" but instead "why should we add syntax X?"
>>>
>>>
>>> Andrei
>>
>>
>> I agree that this is an acknowledgement of the current language's
>> inability to express the abstraction. That's why many people ask for it
>> to be added in the first place. We should add this syntax because it
>> *is* impossible ATM to implement the required abstraction.
>
>
> I think this is a reasonable request:
>
> (auto a, b) = fun();
>
> --->
>
> static assert(fun().length == 2);
> auto __t = fun();
> auto a = __t[0];
> auto b = __t[1];
>
> To express the idiom in the example, the programmer needs to do the
> expansion by hand, which is verbose and introduces unnecessary symbols. So
> the language as is has an expressiveness problem (albeit not a pernicious
> one) that is nice to solve.
>

Andrei++

This could also be done for arrays too.

(int a, b) = arr[];

->

static assert(arr.length == 2);
int a = arr[0];
int b = arr[1];



Or possibly a use in variadic templates, which could make D act more
like how some scripting languages work.

void conn(T ...)(T args) {
  // vars get default init if value wasn't passed to function.
  (string server, port, username, password) = args[];
}




-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

Re: Multiple return values...

[Iain Buclaw]

On 15 March 2012 17:51, Manu  wrote:
> On 15 March 2012 19:05, Andrei Alexandrescu 
> wrote:
>>
>> On 3/15/12 11:30 AM, Manu wrote:
>>>
>>> On 15 March 2012 17:32, Andrei Alexandrescu
>>> mailto:seewebsiteforem...@erdani.org>>
>>>
>>> wrote:
>>>    One note - the code is really ingenious, but I still prefer swap()
>>>    in this case. It's more concise and does less work in the general
>>> case.
>>>
>>>    swap(a[i + k], a[j + j]);
>>>
>>>    only computes the indexing once (in source, too).
>>>
>>>
>>> It all still feels to me like a generally ugly hack around the original
>>> example:
>>>   a,b = b,a;
>>
>>
>> It's a function call. Why is a function call a ugly hack?
>
>
> Because now we're involving libraries to perform a trivial assignment.
>

Question, what benefits would (a, b = b, a) bring over swap(a, b)  if
it was included?


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

Re: Dynamic language

[Paulo Pinto]

To be fair Python is not alone, all the ML languages (Ocaml, Haskell, F#, 
...) also work that way.


F# was even funnier. While the language was experimental the default mode 
was still like most
languages, and a "#light" mode was available, similar to what ML-like 
languages have.


Due to the amount of feedback received, by the time F# was an official MSVC 
language, the indentation

based "#light" mode was the default.

--
Paulo

"H. S. Teoh"  wrote in message 
news:mailman.712.1331843803.4860.digitalmar...@puremagic.com...


On Thu, Mar 15, 2012 at 03:24:24PM -0400, Nick Sabalausky wrote:
[...]

- If you can stomach the indent-scoping, Python is very well-regarded
and has a lot of fancy advanced features.


I used to despise Python's indent-scoping too, though since then I've
had some opportunity to use Python for build scripts (google for SCons),
and I have to say that it certainly has its own kind of beauty to it.
You never have to worry about closing blocks in if statements and the
like, for example, and you never have subtle bugs like:

auto func(bool x) {
int y=0;
if (x)
y = 1;
writeln("x is true");

return y;
}

But I certainly sympathize with the WAT sentiment when one first learns
that Python has indent scoping. :-)

(...) cutted 

Re: Dynamic language

[F i L]

Adam D. Ruppe wrote:

import std.variant;
struct Extendable {
Variant[string] properties;
Variant opDispatch(string name)() {
   return properties[name];
}
Variant opDispatch(string name, T)(T t) {
   properties[name] = t;
   return properties[name];
}
}

void main() {
auto a = Extendable();
a.sweet = 10;
a.cool = { a.sweet = a.sweet + 1; } // could probably fix 
++ too..

// fails with std.variant but the language *could* do it
a.cool(); // exercise for the reader: maek this work! Gotta 
add opCall.

}


Alright I give up dammit! How do you use opCall() to make 
a.cool() work?

Re: Dynamic language

[F i L]

On Friday, 16 March 2012 at 07:48:19 UTC, so wrote:

On Thursday, 15 March 2012 at 22:37:12 UTC, Manu wrote:

Do you expect users to be modifying the scripts in the retail 
release?
Surely scripting is still for what it has always been for, 
rapid

iteration/prototyping during development.


You need to be able to do both.


There are other (arguably better) ways to do post-release game 
mods.



You only need the compiler as a part of the games 
asset-pipeline.


That is the biggest and (only :) ) blocker.


There's no way around it really. Virtual Machines are technically 
compilers, to one degree or another. I'd argue that unless the 
entire engine is written in a interpreted/JITed language, having 
a compiler *only* as part of the development stage would be best 
for memory, performance, and file size. Just design the engine in 
a modularized way and publish libraries (plus tutorials) for a 
Mod community.

Re: Multiple return values...

[Artur Skawina]

On 03/16/12 01:03, H. S. Teoh wrote:
> On Fri, Mar 16, 2012 at 12:11:44AM +0100, Simen Kjærås wrote:
>> On Thu, 15 Mar 2012 23:44:09 +0100, foobar  wrote:
>>
>>> Is swap usually inlined by the compiler?
>>
>> This is the body of swap for simple types:
>>
>>   auto tmp = lhs;
>>   lhs = rhs;
>>   rhs = tmp;
>>
>> For more complex types:
>>
>>   ubyte[T.sizeof] t = void;
>>   auto a = (cast(ubyte*) &lhs)[0 .. T.sizeof];
>>   auto b = (cast(ubyte*) &rhs)[0 .. T.sizeof];
>>   t[] = a[];
>>   a[] = b[];
>>   b[] = t[];
>>
>> So yeah. If that's not inlined, something's wrong.
> 
> Ideally, though, a swap of large objects should be a single loop of xchg
> instructions (in x86 anyway, xchg may not exist on other architectures).
> Unless dmd is much more clever than I thought, the above code would
> generate 3 loops, which uses more memory and is (probably) slower.

x86 xchg w/ mem ref implies lock, plus you'd have to load and store one
of the operands anyway.

artur

Re: std.simd

[Manu]

On 16 March 2012 01:32, Robert Jacques  wrote:

> On Thu, 15 Mar 2012 14:02:15 -0500, Manu  wrote:
>
>> On 15 March 2012 20:35, Robert Jacques  wrote:
>>
>>> On Thu, 15 Mar 2012 12:09:58 -0500, Manu  wrote:
>>>
>> [snip]
>
>> This sounds reasonable. However, please realize that if you wish to use
>>> the short vector names (i.e. float4, float3, float2, etc) you should
>>> support the full set with a decent range of operations and methods.
>>> Several
>>> people (myself included) have written similar short vector libraries; I
>>> think having having short vectors in phobos is important, but having one
>>> library provide float4 and another float2 is less than ideal, even if not
>>> all of the types could leverage the SMID backend. For myself, the killer
>>> feature for such a library would be have the CUDA compatible alignments
>>> for
>>> the types. (or an equivalent enum to the effect)
>>>
>>>
>> I can see how you come to that conclusion, but I generally feel that
>> that's
>> a problem for a higher layer of library.
>>
>
> Then you should to leave namespace room for that higher level library.
>

I haven't stolen any names that aren't already taken by core.simd. I just
want to claim those primitive types already aliased in std.simd to enhance
them with some more useful base-level functionality.

Re: Dynamic language

[Boscop]

On Friday, 16 March 2012 at 09:12:57 UTC, F i L wrote:
Alright I give up dammit! How do you use opCall() to make 
a.cool() work?


How would it be possible, the type of the delegate can't be 
typechecked at the call-site, because the type info is lost in 
the variant. And you can't exhaustively test for all function 
types in the opDispatch getter.
opDispatch would have to store the names and types internally at 
compile-time, which isn't possible. But even then it would have 
to be guaranteed that all setter calls are evaluated before the 
getter calls are checked.
Maybe one could manually store the type info in a special struct 
together with the delegate and then cast it to that type in the 
opDispatch getter.

Re: Multiple return values...

[Manu]

On 16 March 2012 04:26, Andrei Alexandrescu
wrote:
>
>  A good design should strive to provide general features instead of
>> special cases (E.g. swap is limited to the 2-tuple case). Also, why
>> force an overhead of a function call on such a basic feature as
>> assignment? Is swap usually inlined by the compiler?
>>
>
> Sorry, this is grasping at straws.
>
> 1. swap can be easily generalized to take any number of arguments. I'm
> very happy that's possible, we've expended great efforts on making variadic
> functions as powerful as they are. But nobody asked for swap with many
> arguments until now. Which segues into...
>
> 2. When was the last time you needed to swap arbitrary numbers of
> elements, and so badly and frequently, you needed a new language feature
> for that?
>

This is called a swizzle. And constantly comes up when dealing with
x,y,z,w, or r,g,b,a.
It could just as easily be expressed this way:
  a,b = tuple(b,a); // swap
  r,g,b,a = tuple(a,r,g,b); // swizzle
At which point this multi assignment boils down to the exact same question
of syntax as MRV return assignment. I don't really distinguish this
swap/swizzle from MRV. It all comes back to the return assignment syntax.


> 3. Function overhead is solved by inlining, not by adding new features.
> That improves all functions, not only swap.


Requiring inlining to make it efficient is not enough. The proposed MRV ABI
would solve this not only for inlines, but for all multi-assignment type
constructs, including distant function calls.

Re: Interesting Memory Optimization

[Peter Alexander]

On Friday, 16 March 2012 at 02:31:47 UTC, Xinok wrote:

On Friday, 16 March 2012 at 02:18:27 UTC, Kevin wrote:
This is in no way D specific but say you have two constant 
strings.


const char[] a = "1234567890";
// and
const char[] b = "67890";

You could lay out the memory inside of one another. IE: if 
a.ptr = 1 then b.ptr = 6.  I'm not sure if this has been done 
and I don't think it would apply very often but it would be 
kinda cool.


I thought of this because I wanted to pre-generate 
hex-representations of some numbers I realized I could use 
half the memory if I nested them. (At least I think it would 
be half).


Kevin.


I'm pretty sure this is called string pooling.


My understanding is that string pooling just shares whole strings 
rather than combining suffixes.


e.g.
const char[] a = "fubar";
const char[] b = "fubar"; // shared
const char[] c = "bar"; // not shared at all

Combining suffixes is obviously possible, but I'm not sure that 
string pooling implies suffix pooling.

Re: Interesting Memory Optimization

[Alex Rønne Petersen]

On 16-03-2012 12:32, Peter Alexander wrote:

On Friday, 16 March 2012 at 02:31:47 UTC, Xinok wrote:

On Friday, 16 March 2012 at 02:18:27 UTC, Kevin wrote:

This is in no way D specific but say you have two constant strings.

const char[] a = "1234567890";
// and
const char[] b = "67890";

You could lay out the memory inside of one another. IE: if a.ptr = 1
then b.ptr = 6. I'm not sure if this has been done and I don't think
it would apply very often but it would be kinda cool.

I thought of this because I wanted to pre-generate
hex-representations of some numbers I realized I could use half the
memory if I nested them. (At least I think it would be half).

Kevin.


I'm pretty sure this is called string pooling.


My understanding is that string pooling just shares whole strings rather
than combining suffixes.

e.g.
const char[] a = "fubar";
const char[] b = "fubar"; // shared
const char[] c = "bar"; // not shared at all

Combining suffixes is obviously possible, but I'm not sure that string
pooling implies suffix pooling.


I don't see any reason why c couldn't point to element number 3 of b, 
and have its length set to 3...


--
- Alex

Re: Interesting Memory Optimization

[Kevin Cox]

On Mar 16, 2012 7:45 AM, "Alex Rønne Petersen"  wrote
>
> I don't see any reason why c couldn't point to element number 3 of b, and
have its length set to 3...
>
> --
> - Alex

And the previous examples were language agnostic.  In D and other languages
where the length of a string is stored we can nest strings anywhere inside
other strings.

const char[] a = "foofoo";
const char[] b = "oof";

Those can't be nested in null terminated strings, bit they can where
strings have an explicit length.

Re: Standalone AA implementation ready for review (Was: Re:

[bearophile]

H. S. Teoh:

> Alright, I've made a preliminary implementation of AA literals as a
> function that constructs an AA given an array of keys and and an array
> of values (just like the current aaA.d implementation).

See also:
http://d.puremagic.com/issues/show_bug.cgi?id=5502
http://d.puremagic.com/issues/show_bug.cgi?id=5466

Bye,
bearophile

Ideas for Phobos.

[Zz]

Features in the following libraries are really good.
IT would be really good if phobos incorporates what they have.

Just put here for reference:

General Pourpose:
POCO
http://pocoproject.org/features.html
It's a c++ library that is under Boost Software License 1.0.

JUCE
http://www.rawmaterialsoftware.com/jucefeatures.php
Good lib

Graphics and Windows.

Anti-Grain Geometry 2D
http://www.antigrain.com/
Used this before.

MigLayout - Java Layout Manager
http://www.miglayout.com
GUI layout management done right.

Winn32++
http://win32-framework.sourceforge.net/index.htm

Aswang - Win32 Wrapper
http://aswang.sourceforge.net/
Simple and straight forward.

Zz

Re: Ideas for Phobos.

[Jay Norwood]

On Friday, 16 March 2012 at 12:48:39 UTC, Zz wrote:

Features in the following libraries are really good.
IT would be really good if phobos incorporates what they have.

Just put here for reference:

General Pourpose:
POCO
http://pocoproject.org/features.html
It's a c++ library that is under Boost Software License 1.0.

JUCE
http://www.rawmaterialsoftware.com/jucefeatures.php
Good lib

Graphics and Windows.

Anti-Grain Geometry 2D
http://www.antigrain.com/
Used this before.



I don't know what the license is, but this guy doing U++ 
development did his own implementation of the subpixel rendering 
technique described by agg.  He says it added about 100 lines of 
code to his Painter library.  He discusses it in these posts.


  http://www.ultimatepp.org/forum/index.php?t=msg&goto=20174&;

It looks pretty nice to me when used in one of the graphing 
project in their examples.


http://www.ultimatepp.org/srcdoc$PlotLib$PlotLib$en-us.html

Re: std.simd

[David Nadlinger]

On Thursday, 15 March 2012 at 23:32:29 UTC, Robert Jacques wrote:
Then you should to leave namespace room for that higher level 
library.


What makes you thing that there would be only one such high-level 
library wanting to define a floatN type?


There is no such thing as a global namespace in D (well, one 
could probably argue that the things defined in object are). 
Thus, I don't see a problem with re-using a name in a third-party 
library, if its a good fit in both places – and you'll probably 
have a hard time coming up with a better name for SIMD stuff than 
float4.


If at some point you want to mix types from both modules, you 
could always use static or renamed imports. For example, »import 
lowlevel = std.simd« would give you »lowlevel.float4 
upVector;«, which might be clearer in the context of your 
application than any longer, pre-defined name could ever be.


True, we shouldn't generally pick very likely-to-collide names by 
default just because we can so, but denying the existence of the 
D module system altogether is going to set us back to using 
library name prefixes everywhere, like in C (and sometimes C++) 
code.


David

Re: A small const problem

[Peter Alexander]

On Friday, 16 March 2012 at 01:43:41 UTC, bearophile wrote:

So in a way here I am looking for a const that makes the struct
fields not mutable, but allows me to rebind the whole structs.


But that would make the fields mutable:

struct Foo
{
Foo(int _a, int _b, int _c) { a = _a; b = _b; c = _c; }
int a;
int b;
your_const(int) c;
}

Foo f = Foo(1, 2, 3);
f.c = 4; // illegal - good.

but...

f = Foo(f.a, f.b, 4); // ok? But it's the same thing.

Proposal: user defined attributes

[Adam D. Ruppe]

On the ride over here today, I had a thought that
I think neatly solves the user defined attribute
question.

enum Serializable { yes, no }

@note(Serializable.yes) int a;


We introduce two new things to the language:

1) the @note(expression) attribute. You can put
as many "notes" on a declaration as you want by
simply listing them.

The expression inside is appended to a list on
the declaration.

This would be valid on variables, functions,
function parameters, struct members, etc.

2) __traits(getNotes, decl). This returns a tuple
of all the note expressions.

foreach(i, exp; __traits(getNotes, a)) {
   static assert(is(typeof(exp) == Serializable);
   static assert(exp == Serializable.yes);
}




This simple extension to the language enables libraries,
using existing traits to navigate symbols, to get
additional information about things and implement it
however.

The lack of user defined attributes is D's biggest missed
opportunity right now, and I think this simple proposal
will plug that hole.



Previous user-defined attribute proposals have had counter
arguments like these:

1) how do you define what is and is not a valid attribute?

Here, the answer is pretty simple: you can put whatever notes
you want on the thing. Whether the library uses it or not
is up to it.

It has to be a valid type - so the compiler will catch
typos and whatnot - but it doesn't have to be used unless
you ask for it.


2) OK, how do you namespace things so different libraries don't
get different results?

That's where the beauty of the expression type comes in: D
already has namespaces. foo.Serializable != bar.Serializable,
so there's no conflict.

We simply declare types. The enum X {yes, no} pattern is already
common in Phobos, and is also the best way to express a bool 
condition
here. (Technically, @note(true) would compile, but it'd be much 
less

useful than declaring a name for the note too, with an enum.)

Name conflicts is a problem already solved by the language.


3) Can we have shared attributes, with declared names so people
know what to use in their own libraries?

Yes, we could add some to std.traits or make a new std.notes that
declare some common items as enums.

Though, I think having the types declared in the modules that use
them is generally more useful.


But, again, the library problem is already solved, and we're
just using that!





I think this is a winner... and I think I can do it in the
compiler in less time than it will take to convince git to
give me a clean pull request.


Am I missing anything?

Re: Ideas for Phobos., u++ STL speed comparison

[Jay Norwood]

On Friday, 16 March 2012 at 13:20:39 UTC, Jay Norwood wrote:

btw, the u++ page claims in the link below to be faster than D by 
70% on some operations, which they attribute to their STL 
rewrite. Maybe someone should take a look at what they've done.  
Or maybe this comparison is out of date...


http://www.ultimatepp.org/www$uppweb$vsd$en-us.html

Re: Proposal: user defined attributes

[Manu]

On 16 March 2012 15:35, Adam D. Ruppe  wrote:

> @note(Serializable.yes) int a;
>

Surely the term you're looking for here is @annotate(...) ?

This simple extension to the language enables libraries,
> using existing traits to navigate symbols, to get
> additional information about things and implement it
> however.
>
> The lack of user defined attributes is D's biggest missed
> opportunity right now, and I think this simple proposal
> will plug that hole.
>

I agree it's a very big hole against popular competing languages (Java, C#).

Previous user-defined attribute proposals have had counter
> arguments like these:
>
> 1) how do you define what is and is not a valid attribute?
>
> Here, the answer is pretty simple: you can put whatever notes
> you want on the thing. Whether the library uses it or not
> is up to it.
>

What if you want to annotate with a variable? Each instance may need to
hold some attribute state. This is extremely common, particularly in
serialisation systems which typically perform lazy updates, and need some
additional state for that.


> 2) OK, how do you namespace things so different libraries don't
> get different results?
>

Surely this is just as easy: @modulename.attribute int myThing;


> Am I missing anything?
>

 I think it only solves half the problem. There are certainly cases where
you just want to annotate with some sort of tag, so you can know to do
something special in this thing's case, but there are also times where you
want to associate some variable data with each instance.

Perhaps that's the key distinction between 'annotation' and a 'custom
attributes' .. an annotation this way is a shared compile time constant,
associating with its type info, as you suggest. A custom attribute is an
instance-specific association vontaining variable data.
I'd suggest that @annotate(someEnum) could work effectively just as you
suggest, but it doesn't fill the requirement for custom attributes, which
could be implemented separately, something like:

attribute myAttribute
{
  this(int something);

  bool bNeedsAttention;

  property void refresh(bool bRefresh) { bNeedsAttention = bRefresh; }
}

@myAttribute(10) int thing;

thing.refresh = true;

Re: Unified toHash() for all native types

[H. S. Teoh]

On Fri, Mar 16, 2012 at 05:01:16PM +1100, Daniel Murphy wrote:
> How close would this put us to not needing toHash in typeinfo at all? 
[...]

Is there anything besides AA's that uses TypeInfo.getHash? If not, this
will completely eliminate the need for it.

This is one of my motivations for doing this -- util.rt.hash.hashOf is
already pure, and I have a pull request to make it usable in CTFE. Once
we eliminate TypeInfo.getHash, we can finally clean up the
const/pure/etc. mess caused by the current dependency on it. That in
turn will allow most AA methods to be nothrow pure const @safe (or at
the very least nothrow pure @safe; the only AA method that can't be
nothrow is opIndex). Currently I have quite a few methods with "nothrow
pure" commented out, because of the mess in the various overrides of
TypeInfo.getHash.


T

-- 
To err is human; to forgive is not our policy. -- Samuel Adler

Re: Ideas for Phobos., u++ STL speed comparison

[Timon Gehr]

 On 03/16/2012 02:39 PM, Jay Norwood wrote:

On Friday, 16 March 2012 at 13:20:39 UTC, Jay Norwood wrote:

btw, the u++ page claims in the link below to be faster than D by 70% on
some operations, which they attribute to their STL rewrite. Maybe
someone should take a look at what they've done. Or maybe this
comparison is out of date...

http://www.ultimatepp.org/www$uppweb$vsd$en-us.html



"Means C++ is still well ahead of D (by 70%) if not being hold back by 
standard library design and average implementation..."


They explain the former results with differences in implementations and 
their new results with differences in languages, after having optimized 
the implementation in one language but not in the other. x)

Re: Dynamic language

[Adam D. Ruppe]

On Friday, 16 March 2012 at 09:12:57 UTC, F i L wrote:
Alright I give up dammit! How do you use opCall() to make 
a.cool() work?


I was a little unclear... but you'll have to modify
std.variant and/or wrap it.

Here's a solution that wraps it:

==

import std.traits;
import std.variant;

// we want to give a common interface to all functions,
// which is what this wrapper tries to do.

// note it is kinda buggy; this is just a quick example,
// not a finished product
Variant delegate(Variant[]) wrap(alias t)() {
  return delegate Variant(Variant[] args) {
ParameterTypeTuple!(typeof(t)) ptt;
foreach(i, param; ptt) {
  if(i == args.length)
break; // or throw if you want strictness
  // BTW, you can do default params and names too,
  // but it takes a fair amount of code. Check
  // out my web.d generateWrapper() for this if
  // you are interested.

  // or get for strictness
  ptt[i] = args[i].coerce!(typeof(param));
}

Variant returned;
static if(is(ReturnType!(typeof(t)) == void))
  t(ptt);
else
  returned = t(ptt);

return returned;
  };
}

// here's our variant wrapper...
struct MyVariant {
  Variant delegate(Variant[]) callable;
  Variant value;

  alias value this;

  // the main trick here is when we construct or assign,
  // we have compile time info about the function. So, we
  // use this opportunity to build a delegate to call it 
dynamically.

  this(T)(T t) {
value = t;
static if(isCallable!T) {
  callable = wrap!(t)();
} else {
  callable = null;
}
  }

  // and here, we use the delegate made above
  Variant opCall(T...)(T t) {
if(!callable)
  throw new Exception("not callable");
Variant[] args;
foreach(i, v; t)
  args ~= Variant(v);
return callable(args);
  }

  MyVariant opAssign(T)(T t) {
// FIXME: copy/paste from constructor because otherwise it
// tries to call a simple delegate instead of passing the 
delegate itself..

value = t;
static if(isCallable!T) {
  callable = wrap!(t)();
} else {
  callable = null;
}
return this;
  }
}


// let's test it
import std.stdio;

void main () {
  MyVariant v = 10;
  //v(); // would throw

  v = { writefln("Hello, world!"); };
  v(); // says hello!
}
==




One of the big bugs is that the compile conflates
instance opCall, static opCall, and constructors in
such a way that it sometimes calls the wrong one.

This makes calling things with parameters a pain
in the ass, and I hope dmd eventually fixes this.


For instance, add this to the end:


v = function(int a) { writeln("whoa: ", a); };
v(10);



And the stupid compiler thinks v(10) is calling the
struct's constructor again.

Why would you /ever/ want that on an instance?


It also complains if you declare opCall and static opCall
separately. Why?



You can work around this by making MyVariant a class. No
constructor (that apparently doesn't work right either. This
is bug city!), just opAssign.

Then you can do:
==
auto v = new MyVariant();

v = { writefln("Hello, world!"); };
v(); // says hello

v = function(int a) { writeln("whoa: ", a); };
v(10); // says whoa: 10


// look, a std.variant bug too while we're at it
// fix this in std.variant tho, and it will work too
// v("12"); //  Type immutable(char)[] does not convert 
to int

==


This isn't something I use every day, but even in bug city,
it isn't /too/ hard to make it work in D, including weak
typing and variable argument lists, just like Javascript if
we want to. Or, we can go tougher with minor changes.


D rox despite bugs.

Re: Interesting Memory Optimization

[H. S. Teoh]

On Fri, Mar 16, 2012 at 08:24:34AM -0400, Kevin Cox wrote:
[...]
> And the previous examples were language agnostic.  In D and other
> languages where the length of a string is stored we can nest strings
> anywhere inside other strings.
> 
> const char[] a = "foofoo";
> const char[] b = "oof";
> 
> Those can't be nested in null terminated strings, bit they can where
> strings have an explicit length.

More to the point, does dmd perform this optimization currently?


T

-- 
Mediocrity has been pushed to extremes.

Re: Ideas for Phobos., u++ STL speed comparison

[Andrei Alexandrescu]

On 3/16/12 8:39 AM, Jay Norwood wrote:

On Friday, 16 March 2012 at 13:20:39 UTC, Jay Norwood wrote:

btw, the u++ page claims in the link below to be faster than D by 70% on
some operations, which they attribute to their STL rewrite. Maybe
someone should take a look at what they've done. Or maybe this
comparison is out of date...

http://www.ultimatepp.org/www$uppweb$vsd$en-us.html


The test uses a specific data structure, an indexed contiguous array. To 
conclude from here that C++ is faster than D is quite a stretch.


Andrei

Re: Proposal: user defined attributes

[Adam D. Ruppe]

On Friday, 16 March 2012 at 14:11:35 UTC, Manu wrote:

Surely the term you're looking for here is @annotate(...) ?


Meh, I don't care that much about names. I went
with "note" anticipating people would complain about
@add_user_defined_attribute() being too long :)



What if you want to annotate with a variable?


That *might* work because a variable is an expression too.
I'm not sure though. Will probably have to implement to
know for sure.

Of course, a constant can be represented as a struct
for name and value:

struct Description { string s; }

@note(Description("yada yada yada")) int a;



Surely this is just as easy: @modulename.attribute int myThing;


Yeah, I think so. I remember this being a counterpoint
last time we talked about it, but I don't recall the
specific argument made.

Perhaps that's the key distinction between 'annotation' and a 
'custom attributes' .. an annotation this way is a shared 
compile time constant, associating with its type info, as you 
suggest. A custom attribute is an instance-specific association 
vontaining variable data.


Yeah, "annotation" might be the better word. That's
what I want here, but too late to change the subject name
now.



attribute myAttribute


I think this could be done as a struct, but I haven't
used this kind of attribute at all so not sure...

But what I'm thinking is:

struct myAttribute(Type) {
   Type value;
   alias value this;

   bool bNeedsAttention;
   @property void refresh(bool bRefresh) { bNeedsAttention = 
bRefresh; }

}

myAttribute!int thing;
thing.refresh = true;

and thing can be substituted for an int anywhere else.

Re: Proposal: user defined attributes

[Manu]

On 16 March 2012 16:51, Adam D. Ruppe  wrote:

> On Friday, 16 March 2012 at 14:11:35 UTC, Manu wrote:
>
>> Surely the term you're looking for here is @annotate(...) ?
>>
>
> Meh, I don't care that much about names. I went
> with "note" anticipating people would complain about
> @add_user_defined_attribute() being too long :)
>
>
>
>  What if you want to annotate with a variable?
>>
>
> That *might* work because a variable is an expression too.
> I'm not sure though. Will probably have to implement to
> know for sure.
>
> Of course, a constant can be represented as a struct
> for name and value:
>
> struct Description { string s; }
>
> @note(Description("yada yada yada")) int a;
>
>
>
>  Surely this is just as easy: @modulename.attribute int myThing;
>>
>
> Yeah, I think so. I remember this being a counterpoint
> last time we talked about it, but I don't recall the
> specific argument made.
>
>
>  Perhaps that's the key distinction between 'annotation' and a 'custom
>> attributes' .. an annotation this way is a shared compile time constant,
>> associating with its type info, as you suggest. A custom attribute is an
>> instance-specific association vontaining variable data.
>>
>
> Yeah, "annotation" might be the better word. That's
> what I want here, but too late to change the subject name
> now.
>
>
>  attribute myAttribute
>>
>
> I think this could be done as a struct, but I haven't
> used this kind of attribute at all so not sure...
>
> But what I'm thinking is:
>
> struct myAttribute(Type) {
>   Type value;
>   alias value this;
>
>   bool bNeedsAttention;
>   @property void refresh(bool bRefresh) { bNeedsAttention = bRefresh; }
> }
>
> myAttribute!int thing;
> thing.refresh = true;
>
> and thing can be substituted for an int anywhere else.
>

Interesting approach, how will that affect 'thing's type?

Re: Proposal: user defined attributes

[Adam D. Ruppe]

Another argument against would be "can we do
this in the language today?"

And the answer is "sort of, but not really":

void a(@note(...) int arg) {}


You could perhaps do something like:

void a(int arg) {}
mixin("enum " ~ a.mangleof ~ "_arg = " ~ ...);

and then get the listing by looking at allMembers
and comparing the name... but, it gets messy
fast - the attribute is somewhat far from the declaration,
so I betcha it will get out of sync.


Getting the attribute on param 0 too would consist
of using stringof tricks to get the name, then mixing
it in to get that variable.


This isn't a proper tuple either - more care would be
needed to handle multiple notes.



So, you could make it work, but it is hideous, fragile,
and probably less useful even if you look past that.

I've seen some nice implementations of struct level annotations,
using mixin templates, but the killer feature for me, personally,
is putting it on function parameters as well.


I think the language addition (which breaks nothing existing
today; it is purely additive) is necessary to get something
generally useful, not just useful in a few cases.

Re: Proposal: user defined attributes

[Adam D. Ruppe]

On Friday, 16 March 2012 at 15:10:06 UTC, Manu wrote:

Interesting approach, how will that affect 'thing's type?


It will strictly be myAttribute!int, but alias this
means that you can pass it anywhere an int is expected
too (and assign ints to it all the same).

Check it:

void cool(int a) {}
void main() {
myAttribute!int thing;
thing.refresh = true;

thing = 10; // we can assign ints to it, like if it was 
an int

assert(thing.bNeedsAttention); // should be unchanged

int a = thing; // no problem, thing is usable as an int
assert(a == 10);

cool(thing); // ditto
}

Re: Proposal: user defined attributes

[Manu]

On 16 March 2012 17:14, Adam D. Ruppe  wrote:

> On Friday, 16 March 2012 at 15:10:06 UTC, Manu wrote:
>
>> Interesting approach, how will that affect 'thing's type?
>>
>
> It will strictly be myAttribute!int, but alias this
> means that you can pass it anywhere an int is expected
> too (and assign ints to it all the same).
>
> Check it:
>
> void cool(int a) {}
> void main() {
>
>myAttribute!int thing;
>thing.refresh = true;
>
>thing = 10; // we can assign ints to it, like if it was an int
>assert(thing.bNeedsAttention); // should be unchanged
>
>int a = thing; // no problem, thing is usable as an int
>assert(a == 10);
>
>cool(thing); // ditto
> }
>

I can see that it might work nicely in very simple cases, but it could get
nasty in complex constructs. If some template tries to take the typeof for
instance, now I'm cloning the attributes functionality too, which I don't
think is desirable...

Re: Proposal: user defined attributes

[Piotr Szturmaj]

Adam D. Ruppe wrote:

On the ride over here today, I had a thought that
I think neatly solves the user defined attribute
question.

enum Serializable { yes, no }

@note(Serializable.yes) int a;


This is just enum. If you use struct or class attributes (like in C#) 
then direct @Struct(constructor args..) might be better.


Moreover, structs and classes may have special member which validates 
attribute target:


struct MyAttribute
{
template canAttach(alias Symbol)
{
// attribute is only valid on structs and
// may be used only once per symbol
enum canAttach = is(Symbol == struct) &&
 !__traits(hasNotes, Symbol);
}
}

It should be automatically evaluated by the compiler after attribute is 
attached.


Alternatively it may be written like this:

template validate(alias Symbol)
{
static assert(is(Symbol == struct), "MyAttribute must be used with 
structs");

}


We introduce two new things to the language:

1) the @note(expression) attribute. You can put
as many "notes" on a declaration as you want by
simply listing them.

The expression inside is appended to a list on
the declaration.

This would be valid on variables, functions,
function parameters, struct members, etc.

2) __traits(getNotes, decl). This returns a tuple
of all the note expressions.

foreach(i, exp; __traits(getNotes, a)) {
static assert(is(typeof(exp) == Serializable);
static assert(exp == Serializable.yes);
}


This is nice. Also it's base for library functions like hasNotes or 
getNotes!(Symbol, MyAttribute).



This simple extension to the language enables libraries,
using existing traits to navigate symbols, to get
additional information about things and implement it
however.

The lack of user defined attributes is D's biggest missed
opportunity right now, and I think this simple proposal
will plug that hole.


Yes, it's big drawback for serialization and data binding code.


Previous user-defined attribute proposals have had counter
arguments like these:

1) how do you define what is and is not a valid attribute?

Here, the answer is pretty simple: you can put whatever notes
you want on the thing. Whether the library uses it or not
is up to it.

It has to be a valid type - so the compiler will catch
typos and whatnot - but it doesn't have to be used unless
you ask for it.


It should be any user-defined type that may be used at compile-time. For 
example @UUID("...") should be available out of the box.



2) OK, how do you namespace things so different libraries don't
get different results?

That's where the beauty of the expression type comes in: D
already has namespaces. foo.Serializable != bar.Serializable,
so there's no conflict.

We simply declare types. The enum X {yes, no} pattern is already
common in Phobos, and is also the best way to express a bool condition
here. (Technically, @note(true) would compile, but it'd be much less
useful than declaring a name for the note too, with an enum.)

Name conflicts is a problem already solved by the language.


Yes, it should be possible to write @std.UUID("").


3) Can we have shared attributes, with declared names so people
know what to use in their own libraries?


Of course, for example consider a validating attribute "Flags":

@Flags
enum SomeFlags
{
a = 1,
b = 2,
c = 4,
d = 8
}

During attachment it would check if enum member's bits don't overlap.

Re: Interesting Memory Optimization

[Jakob Ovrum]

On Friday, 16 March 2012 at 12:24:45 UTC, Kevin Cox wrote:
On Mar 16, 2012 7:45 AM, "Alex Rønne Petersen" 
 wrote


I don't see any reason why c couldn't point to element number 
3 of b, and

have its length set to 3...


--
- Alex


And the previous examples were language agnostic.  In D and 
other languages
where the length of a string is stored we can nest strings 
anywhere inside

other strings.

const char[] a = "foofoo";
const char[] b = "oof";

Those can't be nested in null terminated strings, bit they can 
where

strings have an explicit length.


All compile-time generated strings (like literals) in D are 
(guaranteed to be?) null-terminated as well.

Re: OpenBSD port of dmd?

[Martin Nowak]

On Fri, 16 Mar 2012 15:53:45 +0100, Andrei Alexandrescu  
 wrote:



Just found this, has anyone tried dmd or friends on OpenBSD?

http://stackoverflow.com/questions/9698581/programming-in-d-for-openbsd


OpenBSD would need some druntime work.

Re: Interesting Memory Optimization

[Timon Gehr]

On 03/16/2012 03:28 PM, H. S. Teoh wrote:

On Fri, Mar 16, 2012 at 08:24:34AM -0400, Kevin Cox wrote:
[...]

And the previous examples were language agnostic.  In D and other
languages where the length of a string is stored we can nest strings
anywhere inside other strings.

const char[] a = "foofoo";
const char[] b = "oof";

Those can't be nested in null terminated strings, bit they can where
strings have an explicit length.


More to the point, does dmd perform this optimization currently?


T



No.

immutable string a = "123";
immutable string b = a;

void main(){writeln(a.ptr is b.ptr);} // "false"

Re: Proposal: user defined attributes

[Andrei Alexandrescu]

On 3/16/12 8:35 AM, Adam D. Ruppe wrote:

enum Serializable { yes, no }

@note(Serializable.yes) int a;

[...]

foreach(i, exp; __traits(getNotes, a)) {
static assert(is(typeof(exp) == Serializable);
static assert(exp == Serializable.yes);
}


So we have:

class A {
@note(Serializable.yes) int a;
...
}

vs. a hypothetical in-language solution:

class A {
int a;
mixin(note("a", Serializable.yes));
...
}

I wonder to what extent the in-language solution can be made to work.


Andrei

Re: Proposal: user defined attributes

[Adam D. Ruppe]

On Friday, 16 March 2012 at 16:09:55 UTC, Andrei Alexandrescu 
wrote:
I wonder to what extent the in-language solution can be made to 
work.


It can sort of work, but it isn't very good.

(I thought you might say this too; check out this post:
http://forum.dlang.org/thread/bccwycoexxykfgxve...@forum.dlang.org#post-gmtawdmaihzgxnvezfrf:40forum.dlang.org 
)



In that other post, I talked about function parameters (which
is what I really want it for). The in-language solution for that
can only be made to work with a pile of fragile hacks.

But, even for functions, you just wrote:

int a;
mixin(note("a", Serializable.yes));

OK, that works... but what about:

int a() { return 0; }
mixin(note("a", Serializable.yes));


We're good so far... until:

int a() { return 0; }
int a(int b) { return 0; }
mixin(note("a", Serializable.yes)); // which a?


You could potentially solve that by using the mangle of
instead of the string, and doing an alias template rather
than passing a string directly, but I'm not sure if we actually
can in today's dmd (I don't even know how to refer to
the proper overload...)

Also, what if the declaration is anonymous? You could
still see it in reflection - a ParameterTypeTuple doesn't
care about names - but you couldn't annotate it this
way. I guess a workaround there would be giving it a
name like _param_0.



Moreover, the mixin adds some junk to the struct. If
you iterate over allMembers, will you see

  enum _note_a_serializable;

in there? If there's a consistent naming convention,
we could skip it (my web.d ignores everything with a
leading underscore, for example), but it is nevertheless
letting implementation details slip out in reflection.

Seeing how the whole point of this is to be used in reflection,
that's a case I think is likely to cause annoyance in practice.



The current language solution isn't really *bad* with enough
library help, but it isn't particularly *good* either and I
don't think it can be. I've tried a few things, and I still
see the lack of user annotations as D's biggest miss right now.

Re: Multiple return values...

[Andrei Alexandrescu]

On 3/16/12 6:29 AM, Manu wrote:

On 16 March 2012 04:26, Andrei Alexandrescu
mailto:seewebsiteforem...@erdani.org>>
wrote:

A good design should strive to provide general features instead of
special cases (E.g. swap is limited to the 2-tuple case). Also, why
force an overhead of a function call on such a basic feature as
assignment? Is swap usually inlined by the compiler?


Sorry, this is grasping at straws.

1. swap can be easily generalized to take any number of arguments.
I'm very happy that's possible, we've expended great efforts on
making variadic functions as powerful as they are. But nobody asked
for swap with many arguments until now. Which segues into...

2. When was the last time you needed to swap arbitrary numbers of
elements, and so badly and frequently, you needed a new language
feature for that?


This is called a swizzle. And constantly comes up when dealing with
x,y,z,w, or r,g,b,a.
It could just as easily be expressed this way:
   a,b = tuple(b,a); // swap
   r,g,b,a = tuple(a,r,g,b); // swizzle
At which point this multi assignment boils down to the exact same
question of syntax as MRV return assignment. I don't really distinguish
this swap/swizzle from MRV. It all comes back to the return assignment
syntax.


Actually, as has been mentioned, swizzling can be done very nicely 
inside the language.



3. Function overhead is solved by inlining, not by adding new
features. That improves all functions, not only swap.

Requiring inlining to make it efficient is not enough. The proposed MRV
ABI would solve this not only for inlines, but for all multi-assignment
type constructs, including distant function calls.


If changing the ABI is on the table, I wonder whether we can improve it 
for all structures, not only for multiple return types. Overall I agree 
that defining a specialized ABI for leaving multiple values on the stack 
would be marginally more efficient, but (a) I don't know by how much, 
and (b) I don't know whether it's worth changing the language.



Andrei

Re: Multiple return values...

[Iain Buclaw]

On 16 March 2012 16:37, Andrei Alexandrescu
 wrote:
> On 3/16/12 6:29 AM, Manu wrote:
>>
>> On 16 March 2012 04:26, Andrei Alexandrescu
>> mailto:seewebsiteforem...@erdani.org>>
>>
>> wrote:
>>
>>        A good design should strive to provide general features instead of
>>        special cases (E.g. swap is limited to the 2-tuple case). Also, why
>>        force an overhead of a function call on such a basic feature as
>>        assignment? Is swap usually inlined by the compiler?
>>
>>
>>    Sorry, this is grasping at straws.
>>
>>    1. swap can be easily generalized to take any number of arguments.
>>    I'm very happy that's possible, we've expended great efforts on
>>    making variadic functions as powerful as they are. But nobody asked
>>    for swap with many arguments until now. Which segues into...
>>
>>    2. When was the last time you needed to swap arbitrary numbers of
>>    elements, and so badly and frequently, you needed a new language
>>    feature for that?
>>
>>
>> This is called a swizzle. And constantly comes up when dealing with
>> x,y,z,w, or r,g,b,a.
>> It could just as easily be expressed this way:
>>   a,b = tuple(b,a); // swap
>>   r,g,b,a = tuple(a,r,g,b); // swizzle
>> At which point this multi assignment boils down to the exact same
>> question of syntax as MRV return assignment. I don't really distinguish
>> this swap/swizzle from MRV. It all comes back to the return assignment
>> syntax.
>
>
> Actually, as has been mentioned, swizzling can be done very nicely inside
> the language.
>
>>    3. Function overhead is solved by inlining, not by adding new
>>    features. That improves all functions, not only swap.
>>
>> Requiring inlining to make it efficient is not enough. The proposed MRV
>> ABI would solve this not only for inlines, but for all multi-assignment
>> type constructs, including distant function calls.
>
>
> If changing the ABI is on the table, I wonder whether we can improve it for
> all structures, not only for multiple return types. Overall I agree that
> defining a specialized ABI for leaving multiple values on the stack would be
> marginally more efficient, but (a) I don't know by how much, and (b) I don't
> know whether it's worth changing the language.
>
>
> Andrei


If you were to forget all about MRV for a brief moment, the change
request being proposed here is to return *all* structures (including
delegates, complex types and vectors) in registers if at all possible
even if the underlying ABI default is to return it in memory.


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

Re: Multiple return values...

[Andrei Alexandrescu]

On 3/16/12 3:48 AM, Iain Buclaw wrote:

This could also be done for arrays too.

(int a, b) = arr[];

->

static assert(arr.length == 2);
int a = arr[0];
int b = arr[1];


Yah, the rewrite is purely syntactic, not tuple-specific. That's a major 
thing I like about it.



Or possibly a use in variadic templates, which could make D act more
like how some scripting languages work.

void conn(T ...)(T args) {
   // vars get default init if value wasn't passed to function.
   (string server, port, username, password) = args[];
}


I fear this is a bit error-prone.


Andrei

Re: Multiple return values...

[Andrei Alexandrescu]

On 3/16/12 11:50 AM, Iain Buclaw wrote:

If you were to forget all about MRV for a brief moment, the change
request being proposed here is to return *all* structures (including
delegates, complex types and vectors) in registers if at all possible
even if the underlying ABI default is to return it in memory.


That sounds great. Must have missed this point, this is a weird 
discussion in which one sentence is about machine code and the next 
about syntax.


Andrei

Re: Proposal: user defined attributes

[Steven Schveighoffer]

On Fri, 16 Mar 2012 09:35:54 -0400, Adam D. Ruppe  
 wrote:



On the ride over here today, I had a thought that
I think neatly solves the user defined attribute
question.

enum Serializable { yes, no }

@note(Serializable.yes) int a;


I thought @ was supposed to be a user-defined annotation.   
Otherwise, why did we introduce @syntax?


I'd rather see something like this:

@annotation serializable(bool x = true) {return x ? Serializable.yes :  
Serializable.no;}  // implicit auto


@serializable int a;
@serializable(false) int b;

Where annotations have to be CTFE-able (because they are constructed at  
compile-time)


-Steve

Re: Standalone AA implementation ready for review (Was: Re:

[H. S. Teoh]

On Fri, Mar 16, 2012 at 08:25:08AM -0400, bearophile wrote:
> H. S. Teoh:
> 
> > Alright, I've made a preliminary implementation of AA literals as a
> > function that constructs an AA given an array of keys and and an array
> > of values (just like the current aaA.d implementation).
> 
> See also:
> http://d.puremagic.com/issues/show_bug.cgi?id=5502
> http://d.puremagic.com/issues/show_bug.cgi?id=5466
[...]

I took a look at these issues, but they seem tricky to implement in
druntime because they depend on phobos features. So probably
constructing an AA from zip() should be in phobos; the current AA
methods should be already be good enough for implementing this.

For iterating AA's as key/value pairs, though, I'll have to think about
how to do it in a nice way. Internally, there's already a Range struct
that iterates by Slot (which amounts to the same thing as iterating by
pairs), so it's just a matter of exposing this in the right way to the
phobos code that will implement by-pair iteration.


T

-- 
This is a tpyo.

Re: Changing the name of the language?

[Steven Schveighoffer]

On Thu, 15 Mar 2012 22:42:15 -0400, Andrej Mitrovic  
 wrote:



On 16-03-2012 03:17, ixid wrote:
Do you think a minor renaming like using Dlang as the name consistently
would be damaging?


But what about all those people who have D tattooed on their necks?
D is awesome. De.


Just add lang.  Problem solved.

On to more serious threads...

-Steve

Re: Multiple return values...

[Iain Buclaw]

On 16 March 2012 16:53, Andrei Alexandrescu
 wrote:
> On 3/16/12 11:50 AM, Iain Buclaw wrote:
>>
>> If you were to forget all about MRV for a brief moment, the change
>> request being proposed here is to return *all* structures (including
>> delegates, complex types and vectors) in registers if at all possible
>> even if the underlying ABI default is to return it in memory.
>
>
> That sounds great. Must have missed this point, this is a weird discussion
> in which one sentence is about machine code and the next about syntax.
>
> Andrei
>
>

Indeed it is.  Though in all honesty, I'm not sure how we can address
this. X86 and X86_64 architectures already return small structures
(less or equal to than 8 bytes iirc) in registers as an optimisation
trick if the function is private/static, and optimisations are of
course turned on.

Implementing this for other architectures would require explicitly
patching each backend architecture, which is simply not feasible to
do, especially when such patches may likely get rejected (A
'reg_return' attribute for ARM has been submitted before back in 2007,
but has never been accepted despite after several revisions).


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

Re: Multiple return values...

[Manu]

On 16 March 2012 18:37, Andrei Alexandrescu
wrote:

> Actually, as has been mentioned, swizzling can be done very nicely inside
> the language.
>

How? The only example I saw in this thread was your from()/to() approach,
which Timon said didn't actually work...?


On 3/16/12 6:29 AM, Manu wrote:
>
>> Requiring inlining to make it efficient is not enough. The proposed MRV
>
> ABI would solve this not only for inlines, but for all multi-assignment
>> type constructs, including distant function calls.
>>
>
> If changing the ABI is on the table, I wonder whether we can improve it
> for all structures, not only for multiple return types. Overall I agree
> that defining a specialized ABI for leaving multiple values on the stack
> would be marginally more efficient, but (a) I don't know by how much, and
> (b) I don't know whether it's worth changing the language.


It might be that this technology is simpler to implement as applied to all
structs (which would include tuples). That way it may additionally address
the current problem with slices and delegates. If it applies too all
structs, there probably needs to be a cut-off heuristic though, since
explicit structs would tend to be a lot bigger than a few MRV values, and
named return values is probably better in that context. Implementation
details would reveal themselves when trying to write the code I think, ie,
where to draw the line (structure size/recursion, etc).

(a) 'Marginally' spread across the entire program eventually adds up to a
lot, especially if it finds its self in hot loops. C/C++ compilers have
extremely aggressive low level optimisers. There is obviously someone who
agrees that that effort and reduction in compiler performance is
worthwhile, or they wouldn't do it...
In terms of benchmarks (the quantity of value you are looking for), it
probably won't make so much difference to existing code, because people
avoid returning structs by value like the plague It's just something you
simply don't do. But if it were a real feature that were reliable, I can
see it quickly replace returning through references passed in the parameter
list (a horrible concept conceptually, effectively a hack), and it would
start to show its value as more and more code were written that way. We
free up an argument register in the call where we would have previously
passed the ref/pointer, and the return doesn't produce a memory write+read
(an LHS hazard). This is a good few opcodes, memory access, and elimination
of a major architectural hazard. Repeat this throughout your code base...
the only reason it's not in C, is because the ABI far too engraved and can
never be changed.

(b) Is it a change to the language? Just a change to the ABI with respect
to returning a tuple.
The change to the language is the unpack syntax, which should be argued on
a completely separate basis.

Re: OpenBSD port of dmd?

[Paulo Pinto]

Am 16.03.2012 15:53, schrieb Andrei Alexandrescu:

Just found this, has anyone tried dmd or friends on OpenBSD?

http://stackoverflow.com/questions/9698581/programming-in-d-for-openbsd


Thanks,

Andrei




It is a bit off-topic, but I have started to look at a possible port to 
Minix 3.2.0, which now has NetBSD userland.


But currently I am only playing around with the dmd source code.

--
Paulo

Re: Multiple return values...

[Manu]

On 16 March 2012 18:53, Andrei Alexandrescu
wrote:

> On 3/16/12 11:50 AM, Iain Buclaw wrote:
>
>> If you were to forget all about MRV for a brief moment, the change
>> request being proposed here is to return *all* structures (including
>> delegates, complex types and vectors) in registers if at all possible
>> even if the underlying ABI default is to return it in memory.
>>
>
> That sounds great. Must have missed this point, this is a weird discussion
> in which one sentence is about machine code and the next about syntax.


Haha, it's true, there are 2 completely distinct, but intrinsically
connected problems being debated here :)

Thrift bindings for D review?

[Andrei Alexandrescu]

David Nadlinger's GSoC 2011 code is now pending acceptance in Apache Thrift:

https://issues.apache.org/jira/browse/THRIFT-1500

A couple of people at Facebook and Apache have looked at it, but the 
reviews of a few more people who know D would be useful. I'll try to 
make the time to give it a thorough review. If you could, that would 
greatly help push the patch forward.



Thanks,

Andrei

Re: Proposal: user defined attributes

[Adam D. Ruppe]

On Friday, 16 March 2012 at 16:57:26 UTC, Steven Schveighoffer 
wrote:
I thought @ was supposed to be a user-defined 
annotation.  Otherwise, why did we introduce @syntax?


idk, to "reduce" the number of keywords or somethiny.

This is why I call it a mistake or missed opportunity
right now though: @property, @safe, @disable, @system,
and @trusted have already made a claim on the @syntax.

Now, we have to work around that, which is why I'm
thinking @note(expression) rather than @.


I'd rather see something like this:


I could live with that too, but I think it'd be harder
to make happen due to potential clashes with the current
thing @ is used for.

Re: Multiple return values...

[Manu]

On 16 March 2012 19:13, Iain Buclaw  wrote:

> On 16 March 2012 16:53, Andrei Alexandrescu
>  wrote:
> > On 3/16/12 11:50 AM, Iain Buclaw wrote:
> >>
> >> If you were to forget all about MRV for a brief moment, the change
> >> request being proposed here is to return *all* structures (including
> >> delegates, complex types and vectors) in registers if at all possible
> >> even if the underlying ABI default is to return it in memory.
> >
> >
> > That sounds great. Must have missed this point, this is a weird
> discussion
> > in which one sentence is about machine code and the next about syntax.
> >
> > Andrei
> >
> >
>
> Indeed it is.  Though in all honesty, I'm not sure how we can address
> this. X86 and X86_64 architectures already return small structures
> (less or equal to than 8 bytes iirc) in registers as an optimisation
> trick if the function is private/static, and optimisations are of
> course turned on.
>

It's good for a pair of ints, but still inefficient for a struct with
smaller data types, each of which could occupy their own register, avoiding
the pack and unpack before and after the return...

Implementing this for other architectures would require explicitly
> patching each backend architecture, which is simply not feasible to
> do, especially when such patches may likely get rejected (A
> 'reg_return' attribute for ARM has been submitted before back in 2007,
> but has never been accepted despite after several revisions).
>

Brutal. LLVM supports this efficiently out of the box.
It'd be interesting to have the GCC people weigh in on this argument
actually. I wonder if they'd see the merit here... ie, presenting it as a
fundamental language feature, it has a potential of offering a lot more
value than it would applied to C.

Scala macros

[bearophile]

There are plans of adding macros to Scala language, and I think they are 
already partially implemented:

https://docs.google.com/document/d/1O879Iz-567FzVb8kw6N5OBpei9dnbW0ZaT7-XNSa6Cs/edit?hl=en_US


>From the article:

<<
Here is a prototypical macro definition:

def m(x: T): R = macro implRef

At first glance macro definitions are equivalent to normal function 
definitions, except for their body, which starts with the conditional keyword 
macro and is followed by a possibly qualified identifier that refers to a 
static macro implementation method.

If, during type-checking, the compiler encounters an application of the macro 
m(args), it will expand that application by invoking the corresponding macro 
implementation method, with the abstract-syntax trees of the argument 
expressions args as arguments. The result of the macro implementation is 
another abstract syntax tree, which will be inlined at the call site and will 
be type-checked in turn.
>>

Bye,
bearophile

Re: Changing the name of the language?

[Manu]

On 16 March 2012 03:23, ixid  wrote:

> D is a very poor name for a language. I appreciate it's late in the day
> for this and that it has probably been discussed before (not that I could
> find such a discussion with Google which relates to my point). Although the
> results for D are fine when googling for things like "D tutorial", more
> obscure terms are hard to find because "d" is so commonly used as a
> variable name. Searchability is important though I understand that this
> might be seen as a trivial point, it is a major human factor. The language
> would be far better off with a 3 to 5 letter identifier. It will succeed or
> fail for other reasons but an easily searchable name would help. Dlang as
> the search term isn't good enough because it's not actually the language's
> name, people don't use it that much when referring to D, nor do they
> usually use D2.
>

Do you have trouble googling for C? I find that D related results are
currently only around 4-5 down the google results list, and it'll only get
higher as it get's more popular.
C searches are fine... I am often surprised just how much influence
programmers seem to have on search results placement.

Re: Multiple return values...

[Timon Gehr]

On 03/16/2012 06:33 PM, Manu wrote:

On 16 March 2012 18:37, Andrei Alexandrescu
mailto:seewebsiteforem...@erdani.org>>
wrote:

Actually, as has been mentioned, swizzling can be done very nicely
inside the language.


How?


Use opDispatch.

a = a.yxwz;


The only example I saw in this thread was your from()/to()
approach, which Timon said didn't actually work...?



It does work for assigning to simple variables, but not for assigning to 
more general expressions.



...
In terms of benchmarks (the quantity of value you are looking for), it
probably won't make so much difference to existing code, because people
avoid returning structs by value like the plague It's just something you
simply don't do. But if it were a real feature that were reliable, I can
see it quickly replace returning through references passed in the
parameter list (a horrible concept conceptually, effectively a hack),


DMD does that for you (Walter is the inventor of NRVO).

Re: Multiple return values...

[Manu]

On 16 March 2012 19:53, Timon Gehr  wrote:

> On 03/16/2012 06:33 PM, Manu wrote:
>
>> On 16 March 2012 18:37, Andrei Alexandrescu
>> > > >>
>>
>> wrote:
>>
>>Actually, as has been mentioned, swizzling can be done very nicely
>>inside the language.
>>
>>
>> How?
>>
>
> Use opDispatch.
>
> a = a.yxwz;


The simplest possible example (I've done this is std.simd)... but if I have
a few different loosely related things?
My personal most frequent problem case is collision/physics. pos, 't',
velocity, intersectionFlag, intersection target pointer, etc.. lots of
loosely related stuff, always results in inefficient function calls in some
of the hottest code in the engine.


DMD does that for you (Walter is the inventor of NRVO).
>

Which is awesome for returning larger structs, but not good for returning
just a couple of unrelated things that will persist as locals in the
calling function.

Re: Proposal: user defined attributes

[Steven Schveighoffer]

On Fri, 16 Mar 2012 13:36:42 -0400, Adam D. Ruppe  
 wrote:



On Friday, 16 March 2012 at 16:57:26 UTC, Steven Schveighoffer wrote:
I thought @ was supposed to be a user-defined annotation.   
Otherwise, why did we introduce @syntax?


idk, to "reduce" the number of keywords or somethiny.


Quote from TDPL (section 5.9.1 on page 156):

"Attributes, always introduced with @, are simple adornments specifying  
certain features for the symbol being defined.  Some attributes are  
recognized by the compiler; some are defined and used by the programmer  
alone."


I assumed this was true, and thought so even before TDPL came out.  See  
http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6



This is why I call it a mistake or missed opportunity
right now though: @property, @safe, @disable, @system,
and @trusted have already made a claim on the @syntax.


I think those are just compiler-defined attributes.  They aren't keywords  
in the sense that the parser doesn't treat them as special.  They are just  
another type of symbol.



I could live with that too, but I think it'd be harder
to make happen due to potential clashes with the current
thing @ is used for.


meh, just don't use @safe, @property, @disable, @system, and @trusted.  I  
don't see a huge number of compiler-defined attributes springing up.  Nor  
do I see a huge number of library or user-defined ones springing up.


-Steve

Re: Proposal: user defined attributes

[Andrej Mitrovic]

On 3/16/12, Adam D. Ruppe  wrote:
> The current language solution isn't really *bad* with enough
> library help, but it isn't particularly *good* either and I
> don't think it can be. I've tried a few things, and I still
> see the lack of user annotations as D's biggest miss right now.

Yeah, but I would say if we had even better compile-time introspection
we could have the freedom to implement any number of annotation
implementations in library code. When you put something into the
language you have to depend on C++ hackers to implement and then
inevitably fix the upcoming bugs in the front-end (ICEs are an
annoying blocker), and there's always that issue where the devs are
against adding new features to an existing language feature. (say
annotations were implemented, soon enough someone is going to complain
it doesn't have enough functionality and that it needs to be
extended).

Personally I'd love it if we had more __traits and compile-time
introspection abilities.

Re: Proposal: user defined attributes

[Adam D. Ruppe]

On Friday, 16 March 2012 at 18:07:18 UTC, Steven Schveighoffer 
wrote:

Quote from TDPL (section 5.9.1 on page 156):


Huh. There's nothing I can see in the compiler that even
hints at this. The @ thing is just another storage class
as far as it's concerned right now.

Nor do I see a huge number of library or user-defined ones 
springing up.


Yeah.

I still really like my expression idea though, but
thinking about your strategy, we could say:

When you see @, if it is a compiler word after it,
parse it that way. Otherwise, try to get a function
call out of it.

Treat the function call as an enum and add it to the
list. Thus, it is CTFE, namespaced, etc. like normal.

The return value is appended to the declaration's
attribute expression list (so the end result is the same
as I was thinking.)


I'm pretty sure that'd work..

Re: Interesting Memory Optimization

[Xinok]

On Friday, 16 March 2012 at 15:41:32 UTC, Timon Gehr wrote:

On 03/16/2012 03:28 PM, H. S. Teoh wrote:
More to the point, does dmd perform this optimization 
currently?



T



No.

immutable string a = "123";
immutable string b = a;

void main(){writeln(a.ptr is b.ptr);} // "false"


It actually does, but only identical strings. It doesn't seem to 
do strings within strings.


void foo(string a){
string b = "123";
writeln(a is b);
}

void main(){
string a = "123";
string b = "456";
string c = "123456";
foo(a);
foo(b);
foo(c);
}

Prints:
true
false
false

Re: Interesting Memory Optimization

[Xinok]

On Friday, 16 March 2012 at 18:44:53 UTC, Xinok wrote:

On Friday, 16 March 2012 at 15:41:32 UTC, Timon Gehr wrote:

On 03/16/2012 03:28 PM, H. S. Teoh wrote:
More to the point, does dmd perform this optimization 
currently?



T



No.

immutable string a = "123";
immutable string b = a;

void main(){writeln(a.ptr is b.ptr);} // "false"


It actually does, but only identical strings. It doesn't seem 
to do strings within strings.


void foo(string a){
string b = "123";
writeln(a is b);
}

void main(){
string a = "123";
string b = "456";
string c = "123456";
foo(a);
foo(b);
foo(c);
}

Prints:
true
false
false


Captain obvious to the rescue, 'is' is false if the strings are 
of different lengths >.<. But it still stands, D doesn't dedup 
strings within strings.


void main(){
string a = "123";
string b = "123456";
writeln(a.ptr);
writeln(b.ptr);
writeln(a.ptr);
writeln(b.ptr);
}

Prints:
44F080
44F090
44F080
44F090

I printed it twice to ensure it wasn't duping the strings.

Re: Interesting Memory Optimization

[Adam D. Ruppe]

On Friday, 16 March 2012 at 18:44:53 UTC, Xinok wrote:
It actually does, but only identical strings. It doesn't seem 
to do strings within strings.


Don't forget that "123" is /not/ a substring of "123456"
because of the invisible 0 terminator (which is there
for easy compatibility with C functions).

Re: Interesting Memory Optimization

[Timon Gehr]

On 03/16/2012 07:52 PM, Xinok wrote:

On Friday, 16 March 2012 at 18:44:53 UTC, Xinok wrote:

On Friday, 16 March 2012 at 15:41:32 UTC, Timon Gehr wrote:

On 03/16/2012 03:28 PM, H. S. Teoh wrote:

More to the point, does dmd perform this optimization currently?


T



No.

immutable string a = "123";
immutable string b = a;

void main(){writeln(a.ptr is b.ptr);} // "false"


It actually does, but only identical strings. It doesn't seem to do
strings within strings.

void foo(string a){
string b = "123";
writeln(a is b);
}

void main(){
string a = "123";
string b = "456";
string c = "123456";
foo(a);
foo(b);
foo(c);
}

Prints:
true
false
false


Captain obvious to the rescue, 'is' is false if the strings are of
different lengths >.<. But it still stands, D doesn't dedup strings
within strings.

void main(){
string a = "123";
string b = "123456";
writeln(a.ptr);
writeln(b.ptr);
writeln(a.ptr);
writeln(b.ptr);
}

Prints:
44F080
44F090
44F080
44F090

I printed it twice to ensure it wasn't duping the strings.


It can't because there must be a terminating zero byte. It does not do 
it even if it could though.



immutable string x = "123";
immutable string y = "123";

void foo(string a){
string b = "123";
writeln(a is b);
}

void main(){
string a = "123";
string b = "456";
string c = "456123";
foo(c[3..$]);// false
writeln(x is y); // false
writeln(a is x); // false
writeln(b is x); // false
writeln(a is y); // false
writeln(b is y); // false
foo(a);  // true
foo(b);  // false
}

Re: Interesting Memory Optimization

[Xinok]

On Friday, 16 March 2012 at 18:56:00 UTC, Timon Gehr wrote:
It can't because there must be a terminating zero byte. It does 
not do it even if it could though.



immutable string x = "123";
immutable string y = "123";

void foo(string a){
string b = "123";
writeln(a is b);
}

void main(){
string a = "123";
string b = "456";
string c = "456123";
foo(c[3..$]);// false
writeln(x is y); // false
writeln(a is x); // false
writeln(b is x); // false
writeln(a is y); // false
writeln(b is y); // false
foo(a);  // true
foo(b);  // false
}


So while D does pool strings, it doesn't seem to optimize 
globals. I couldn't find anything about it on the bug tracker.

Re: OpenBSD port of dmd?

[Walter Bright]

On 3/16/2012 7:53 AM, Andrei Alexandrescu wrote:

Just found this, has anyone tried dmd or friends on OpenBSD?

http://stackoverflow.com/questions/9698581/programming-in-d-for-openbsd


There was a start on an OpenBSD port, but it hasn't progressed very far. It 
shouldn't be hard - if someone wants to pick up the flag on this and run with 
it, I'd be happy to fold in the changes.

Re: "Improve this page"

[Simon]

On 16/03/2012 04:27, James Miller wrote:

On 16 March 2012 17:14, Brad Anderson  wrote:

I have a pending pull request

which adds an "Improve this page" button to the upper right corner all pages
on the website.  From the pull request description: "It essentially turns
the website into a moderated wiki. How it works is for each page it links to
a special URL on GitHub that will offer to fork the repository, open an
online text editor, and create a pull request in one easy process."

It's meant for simple changes (typos, rewording stuff, minor bugs in code
examples, etc.). I got the idea after using the GitHub online editor myself
to make website and Phobos documentation change pull requests and finding it
to be very easy way to contribute. Even people who are unfamiliar with git
can use it.

Andrei seemed to like it when I showed him but asked me to get Walter and
whoever else's opinions on it before he'd be willing to merged it.

You can try a live demo here: http://gnuk.net/d/index.html

Clicking the button will open the appropriate file in an editor on GitHub.
Feel free to click the button to see what the editor is like. Nothing
happens until you choose to submit your changes at which point it lets you
enter a pull request description, then it finally makes the request.

This would probably have been difficult to implement if it weren't for Ddoc
so +1 for Ddoc.

Regards,
Brad Anderson


Seems ok, though the styling isn't amazing, maybe tone the size of the
buttons down.

Also, Github does not exactly give a useful message when you aren't
logged in (404), but that isn't your fault.

--
James Miller


I think it looks fine and it's a great idea. At least for those of us 
with git hub accounts.


--
My enormous talent is exceeded only by my outrageous laziness.
http://www.ssTk.co.uk

Re: Unified toHash() for all native types

[H. S. Teoh]

On Thu, Mar 15, 2012 at 04:55:09PM -0700, H. S. Teoh wrote:
> I'm working on making AA literals work with my new AA implementation,
> and ran into a major roadblock with using CTFE to compute AA literals:
> currently built-in types like arrays require TypeInfo in order to
> compute the hash, but TypeInfo's are not accessible during CTFE.
> 
> Since it's a lot of work (arguably too much work) to make TypeInfo's
> usable during CTFE, I'm thinking of making use of UFCS to declare
> toHash() methods for *all* native types.
[...]

Alright, I've starting a git branch to experiment with this idea:

https://github.com/quickfur/New-AA-implementation/tree/ctfelit

I've gotten it to the point where all current AA unittests work (but
full coverage of all built-in types is not quite there yet).

Getting rid of the calls to typeinfo.getHash() already has the very nice
side-effect of making almost all AA methods that should be pure nothrow
@safe, actually pure nothrow @safe. (Due to the mess in the current
getHash(), toString(), etc., getHash is impure and throwing, even though
the hash computation itself never throws, so anything that uses getHash
can't be pure nothrow.)

I've also written a bunch of unittests to ensure that the new toHash()
methods return the same value as typeinfo.getHash(). (OT: My favorite
line in the unittests is:

checkNumericArrays!(byte, ubyte, short, ushort, int, uint,
float, double, real)();

which checks T[], const(T)[], and immutable(T)[] for all the above
types, and is a testament to just how much D's variadic templates
r0x0rs.)

Anyway. One weird thing I came across was the fact that char[] and
immutable(char)[] (aka string) have a different hash computation than
every other array (including const(char)[], strangely enough).

What's the rationale for this strange special case? Is it safe to get
rid of this inconsistency and make all arrays use rt.util.hash.hashOf()?


T

-- 
"Real programmers can write assembly code in any language. :-)" -- Larry Wall

Re: Multiple return values...

[Simen Kjærås]

On Fri, 16 Mar 2012 03:26:55 +0100, Andrei Alexandrescu  
 wrote:



I think this is a reasonable request:

(auto a, b) = fun();

--->

static assert(fun().length == 2);
auto __t = fun();
auto a = __t[0];
auto b = __t[1];


That would be nice. As was mentioned in a later post, this works for  
static arrays, too.
Now, a pattern that our productive friend bearophile posted earlier was  
this:


int[] foo();

(auto a, b) = foo();

--->

auto __t = foo();
assert( __t.length > 0 );
auto a = __t[0];
auto b = __t[1..$];

Is this something we might also want?

Re: Dynamic language

[Simon]

On 16/03/2012 02:28, Nick Sabalausky wrote:

"James Miller"  wrote in message
news:mailman.733.1331853568.4860.digitalmar...@puremagic.com...


I hate the fact that Flash games are created the way they are. For
one, it's impenetrable to try and learn properly, I had so much
trouble figuring out how to do things properly, you can attach scripts
to almost any object, but sometimes it might be shared over all of the
same objects, and other times only on that instance, depending on how
you've placed them on the canvas.

I probably wrote some terrible code when I started making Flash games,
and now Actionscript is so foreign to me that i can barely understand
where to start.




One thing I learned though, is that if you're going to make something in
Flash, your best bet is to use as *little* of what Adobe provides as
possible:


You're being rather unfair to Adobe. It was Macromedia that where the 
original perpetrators of flash; Adobe brought Macromedia in 2005.
I guessing that they only brought Macromedia for the market share rather 
than because they thought flash was actually any good.


I suffered through a module of Flash/Director around 1999. Action script 
was fecking awful but Director actually wasn't that bad.
It was pretty easy to do some neat things so it was easy to see why it 
was so popular with *web devs* and mouth breathing marketing types.


--
My enormous talent is exceeded only by my outrageous laziness.
http://www.ssTk.co.uk

Re: Proposal: user defined attributes

[Steven Schveighoffer]

On Fri, 16 Mar 2012 14:33:37 -0400, Adam D. Ruppe  
 wrote:



On Friday, 16 March 2012 at 18:07:18 UTC, Steven Schveighoffer wrote:

Quote from TDPL (section 5.9.1 on page 156):


Huh. There's nothing I can see in the compiler that even
hints at this. The @ thing is just another storage class
as far as it's concerned right now.


Right, the user-defined portion is not implemented.




Nor do I see a huge number of library or user-defined ones springing up.


Yeah.

I still really like my expression idea though, but
thinking about your strategy, we could say:

When you see @, if it is a compiler word after it,
parse it that way. Otherwise, try to get a function
call out of it.


The way I'd like to see it work (and not being a compiler writer, I have  
no idea if/how this would work) is:


When you see @, call a CTFE function with that name.

The compiler defines intrinsic functions @property, @disable, etc.  which  
return intrinsic data types that get appended to the attribute list.  Then  
the compiler recognizes those data types in the attribute list when  
deciding how things should be compiled.


This might not be feasible given the current implementation, or how  
compilers are designed, I have no idea.



The return value is appended to the declaration's
attribute expression list (so the end result is the same
as I was thinking.)


Yes.  And I'd like to see the other intrinsic attributes appended (and  
queryable) as well.


What we also may need in the @annotation declaration is an alias of the  
thing being compiled (again, don't know how feasible this is)


for example:

@annotation property(alias sym)() { static assert(is(sym == function));  
return INTRINSIC.isProperty;}


Maybe that's going too far :)

-Steve

Re: OpenBSD port of dmd?

[Nick Sabalausky]

"Martin Nowak"  wrote in message 
news:op.wa9r9izqsqugbd@localhost...
> On Fri, 16 Mar 2012 15:53:45 +0100, Andrei Alexandrescu 
>  wrote:
>
>> Just found this, has anyone tried dmd or friends on OpenBSD?
>>
>> http://stackoverflow.com/questions/9698581/programming-in-d-for-openbsd
>>
> OpenBSD would need some druntime work.

Do you have anything in particular in mind?

Re: Dynamic language

[Nick Sabalausky]

"Simon"  wrote in message 
news:jk053b$sg0$1...@digitalmars.com...
> On 16/03/2012 02:28, Nick Sabalausky wrote:
>> "James Miller"  wrote in message
>> news:mailman.733.1331853568.4860.digitalmar...@puremagic.com...
>>>
>>> I hate the fact that Flash games are created the way they are. For
>>> one, it's impenetrable to try and learn properly, I had so much
>>> trouble figuring out how to do things properly, you can attach scripts
>>> to almost any object, but sometimes it might be shared over all of the
>>> same objects, and other times only on that instance, depending on how
>>> you've placed them on the canvas.
>>>
>>> I probably wrote some terrible code when I started making Flash games,
>>> and now Actionscript is so foreign to me that i can barely understand
>>> where to start.
>>>
>
>> One thing I learned though, is that if you're going to make something in
>> Flash, your best bet is to use as *little* of what Adobe provides as
>> possible:
>
> You're being rather unfair to Adobe. It was Macromedia that where the 
> original perpetrators of flash; Adobe brought Macromedia in 2005.
> I guessing that they only brought Macromedia for the market share rather 
> than because they thought flash was actually any good.
>
> I suffered through a module of Flash/Director around 1999. Action script 
> was fecking awful but Director actually wasn't that bad.
> It was pretty easy to do some neat things so it was easy to see why it was 
> so popular with *web devs* and mouth breathing marketing types.
>

Well, yea Macromedia created most of it, but Adobe now *provides* it ;) And 
they did choose to buy it. Anyway though, yea, you're right it is mostly 
Macromedia. Actually the version I started using was still pre-Adobe: MX 
2004. But still, it's been about 6 years and Adobe, well they promtly added 
AS3 (which like I said, I admit I don't know much about since I haven't used 
it) and then ever since then they seem to have mostly just added bloat. 
Again though, you're right, Macromedia's responsible for most of what I hate 
about Flash (Apperently even Flex is their fault, too. I didn't even know 
that until I looked it up just now).

Re: OpenBSD port of dmd?

[Jonathan M Davis]

On Friday, March 16, 2012 16:00:47 Nick Sabalausky wrote:
> "Martin Nowak"  wrote in message
> news:op.wa9r9izqsqugbd@localhost...
> 
> > On Fri, 16 Mar 2012 15:53:45 +0100, Andrei Alexandrescu
> > 
> >  wrote:
> >> Just found this, has anyone tried dmd or friends on OpenBSD?
> >> 
> >> http://stackoverflow.com/questions/9698581/programming-in-d-for-openbsd
> > 
> > OpenBSD would need some druntime work.
> 
> Do you have anything in particular in mind?

Probably everything that's not straight Posix would require changes. For 
instance, every place that has a version(FreeBSD) block would probably need a 
version(OpenBSD) block. It's probably not all that hard to make the changes, 
but they'd still need to be done.

The very fact that Walter pushes for the model of

version(A) {}
else version(B) {}
else static assert("Unsupported OS");

means that _any_ new OS requires druntime work, even if it's minimal. That's 
not necessarily a bad thing, since there's a definite chance that the new OS 
requires additional changes specific to it anyway, but as long as there is 
sections of druntime are OS-specific without generic versions provided (which 
isn't going to change), you can't just use druntime with a new OS without 
updating druntime.

- Jonathan M Davis

Re: std.simd

[Robert Jacques]

On Fri, 16 Mar 2012 08:24:58 -0500, David Nadlinger   
wrote:



On Thursday, 15 March 2012 at 23:32:29 UTC, Robert Jacques wrote:

Then you should to leave namespace room for that higher level library.


What makes you thing that there would be only one such high-level  
library wanting to define a floatN type?


The fact that several people have proposed unifying the existing libraries  
any putting them into phobos :)




There is no such thing as a global namespace in D (well, one could  
probably argue that the things defined in object are). Thus, I don't see  
a problem with re-using a name in a third-party library, if its a good  
fit in both places – and you'll probably have a hard time coming up with  
a better name for SIMD stuff than float4.


If at some point you want to mix types from both modules, you could  
always use static or renamed imports. For example, »import lowlevel =  
std.simd« would give you »lowlevel.float4 upVector;«, which might be  
clearer in the context of your application than any longer, pre-defined  
name could ever be.


True, we shouldn't generally pick very likely-to-collide names by  
default just because we can so, but denying the existence of the D  
module system altogether is going to set us back to using library name  
prefixes everywhere, like in C (and sometimes C++) code.


David


Unrelated libraries using the same name is relatively painless. Highly  
related libraries that conflict, on the other hand, are generally painful.  
Yes, there are a lot of mechanisms available to work around this, but  
selective imports and renaming all add to the cognitive load of using and  
writing the code.


To me float4 isn't a SIMD name; its a vector name and if it's implemented  
using SIMD, great, but that's an implementation detail. I can understand a  
close to the metal SIMD library and encourage the work. But if it isn't  
also going to be a vector library, if possible, it shouldn't use the  
vector names.

Something wrong with win32 dmd 2.059head?

[Dmitry Olshansky]

I meant to ask this before, but am I the only one seeing pages of error 
messages on win32 while showing reasonable few lines on pretty much any 
other platform?
Compare my failing (due to wrong predicate passed to assertSorted) pull 
462 test runs:

win32:
http://d.puremagic.com/test-results/pull.ghtml?runid=96548
linux32:
http://d.puremagic.com/test-results/pull.ghtml?runid=96533

Code and error in it is system agnostic here.

--
Dmitry Olshansky

Re: Something wrong with win32 dmd 2.059head?

[Dmitry Olshansky]

On 17.03.2012 0:43, Dmitry Olshansky wrote:

I meant to ask this before, but am I the only one seeing pages of error
messages on win32 while showing reasonable few lines on pretty much any
other platform?
Compare my failing (due to wrong predicate passed to assertSorted) pull
462 test runs:
win32:
http://d.puremagic.com/test-results/pull.ghtml?runid=96548
linux32:
http://d.puremagic.com/test-results/pull.ghtml?runid=96533

Code and error in it is system agnostic here.



s/showing/getting
s/assertSorted/assumeSorted/

Ah, the joy of posting past the midnight :)

--
Dmitry Olshansky

Re: Proposal: user defined attributes

[Johannes Pfau]

Am Fri, 16 Mar 2012 16:21:41 +0100
schrieb Piotr Szturmaj :

> > @note(Serializable.yes) int a;
> 
> This is just enum. If you use struct or class attributes (like in C#) 
> then direct @Struct(constructor args..) might be better.
> 
> 
+1

> > The expression inside is appended to a list on
> > the declaration.
> >
> > This would be valid on variables, functions,
> > function parameters, struct members, etc.
> >
> > 2) __traits(getNotes, decl). This returns a tuple
> > of all the note expressions.
> >
> > foreach(i, exp; __traits(getNotes, a)) {
> > static assert(is(typeof(exp) == Serializable);
> > static assert(exp == Serializable.yes);
> > }
> 
> This is nice. Also it's base for library functions like hasNotes or 
> getNotes!(Symbol, MyAttribute).
+1

> > 1) how do you define what is and is not a valid attribute?
> >
> 
> It should be any user-defined type that may be used at compile-time.
> For example @UUID("...") should be available out of the box.

Or we could add a @attribute attribute:

@attribute struct Test
{
this(int a) {}...
}

@Test(99)
string someTestVal;

> > 2) OK, how do you namespace things so different libraries don't
> > get different results?
> >
> > That's where the beauty of the expression type comes in: D
> > already has namespaces. foo.Serializable != bar.Serializable,
> > so there's no conflict.
> >
> > We simply declare types. The enum X {yes, no} pattern is already
> > common in Phobos, and is also the best way to express a bool
> > condition here. (Technically, @note(true) would compile, but it'd
> > be much less useful than declaring a name for the note too, with an
> > enum.)
> >
> > Name conflicts is a problem already solved by the language.
> 
> Yes, it should be possible to write @std.UUID("").
> 
And all normal import rules should work for user defined attributes as
well (renamed imports, static imports, ...).

Re: OpenBSD port of dmd?

[Johannes Pfau]

Am Fri, 16 Mar 2012 12:08:01 -0700
schrieb Walter Bright :

> On 3/16/2012 7:53 AM, Andrei Alexandrescu wrote:
> > Just found this, has anyone tried dmd or friends on OpenBSD?
> >
> > http://stackoverflow.com/questions/9698581/programming-in-d-for-openbsd
> 
> There was a start on an OpenBSD port, but it hasn't progressed very
> far. It shouldn't be hard - if someone wants to pick up the flag on
> this and run with it, I'd be happy to fold in the changes.

AFAICS OpenBSD doesn't support TLS (the __thread tls, posix
pthread_getspecific works of course). Can D work at all without TLS
support?

(We have a similar problem with Android, I know for sure TLS isn't
supported there.)

Re: Something wrong with win32 dmd 2.059head?

[Jonathan M Davis]

On Saturday, March 17, 2012 00:43:48 Dmitry Olshansky wrote:
> I meant to ask this before, but am I the only one seeing pages of error
> messages on win32 while showing reasonable few lines on pretty much any
> other platform?
> Compare my failing (due to wrong predicate passed to assertSorted) pull
> 462 test runs:
> win32:
> http://d.puremagic.com/test-results/pull.ghtml?runid=96548
> linux32:
> http://d.puremagic.com/test-results/pull.ghtml?runid=96533
> 
> Code and error in it is system agnostic here.

Well, I believe that the error gagging was temporarily turned off (with the 
idea of re-enabling closer to the release of 2.059), so you do get a ton of 
error messages when there's anything wrong with a template. I don't know why 
you'd be seeing more on Windows though.

- Jonathan M Davis

Re: Changing the name of the language?

[Nick Sabalausky]

"Manu"  wrote in message 
news:mailman.778.1331920080.4860.digitalmar...@puremagic.com...
> On 16 March 2012 03:23, ixid  wrote:
>
>> D is a very poor name for a language. I appreciate it's late in the day
>> for this and that it has probably been discussed before (not that I could
>> find such a discussion with Google which relates to my point). Although 
>> the
>> results for D are fine when googling for things like "D tutorial", more
>> obscure terms are hard to find because "d" is so commonly used as a
>> variable name. Searchability is important though I understand that this
>> might be seen as a trivial point, it is a major human factor. The 
>> language
>> would be far better off with a 3 to 5 letter identifier. It will succeed 
>> or
>> fail for other reasons but an easily searchable name would help. Dlang as
>> the search term isn't good enough because it's not actually the 
>> language's
>> name, people don't use it that much when referring to D, nor do they
>> usually use D2.
>>
>
> Do you have trouble googling for C? I find that D related results are
> currently only around 4-5 down the google results list, and it'll only get
> higher as it get's more popular.
> C searches are fine... I am often surprised just how much influence
> programmers seem to have on search results placement.
>

Google search results are different for everybody. They tailor the search 
results they give you based on your past search (and clickthrough) history. 
If you're doing a lot of programmer searches, they're going to start giving 
you more programmer results.

That's one of many reasons I used to use Scroogle, and now that Scroogle's 
dead (RIP), IxQuick and StartPage.

See also "Filter bubble": http://en.wikipedia.org/wiki/Filter_bubble

Re: OpenBSD port of dmd?

[Sean Kelly]

On Mar 16, 2012, at 2:19 PM, Johannes Pfau wrote:

> Am Fri, 16 Mar 2012 12:08:01 -0700
> schrieb Walter Bright :
> 
>> On 3/16/2012 7:53 AM, Andrei Alexandrescu wrote:
>>> Just found this, has anyone tried dmd or friends on OpenBSD?
>>> 
>>> http://stackoverflow.com/questions/9698581/programming-in-d-for-openbsd
>> 
>> There was a start on an OpenBSD port, but it hasn't progressed very
>> far. It shouldn't be hard - if someone wants to pick up the flag on
>> this and run with it, I'd be happy to fold in the changes.
> 
> AFAICS OpenBSD doesn't support TLS (the __thread tls, posix
> pthread_getspecific works of course). Can D work at all without TLS
> support?
> 
> (We have a similar problem with Android, I know for sure TLS isn't
> supported there.)

OSX pre-Lion doesn't support __thread either, so DMD rolls its own there.  The 
same functionality could probably be used for OpenBSD.

Re: std.simd

[Manu]

On 16 March 2012 22:39, Robert Jacques  wrote:

> On Fri, 16 Mar 2012 08:24:58 -0500, David Nadlinger 
> wrote:
>
>  On Thursday, 15 March 2012 at 23:32:29 UTC, Robert Jacques wrote:
>>
>>> Then you should to leave namespace room for that higher level library.
>>>
>>
>> What makes you thing that there would be only one such high-level library
>> wanting to define a floatN type?
>>
>
> The fact that several people have proposed unifying the existing libraries
> any putting them into phobos :)


I personally can't see it happening. Above the most primitive level that
I've tried to cover with std.simd, I think it'll be very hard to find
agreement on what that API should look like.
If you can invent a proposal that everyone agrees on, I'd be very
interested to see it. Perhaps if you extend the fairly raw and D-ish API
that I've tried to use in std.simd it could work, but I don't think many
people will like using that in their code. I anticipate std.simd will be
wrapped in some big bloated class by almost everyone that uses it, so why
bother to add the emulation at that level?


There is no such thing as a global namespace in D (well, one could probably
>> argue that the things defined in object are). Thus, I don't see a problem
>> with re-using a name in a third-party library, if its a good fit in both
>> places – and you'll probably have a hard time coming up with a better name
>> for SIMD stuff than float4.
>>
>> If at some point you want to mix types from both modules, you could
>> always use static or renamed imports. For example, »import lowlevel =
>> std.simd« would give you »lowlevel.float4 upVector;«, which might be
>> clearer in the context of your application than any longer, pre-defined
>> name could ever be.
>>
>> True, we shouldn't generally pick very likely-to-collide names by default
>> just because we can so, but denying the existence of the D module system
>> altogether is going to set us back to using library name prefixes
>> everywhere, like in C (and sometimes C++) code.
>>
>> David
>>
>
> Unrelated libraries using the same name is relatively painless. Highly
> related libraries that conflict, on the other hand, are generally painful.
> Yes, there are a lot of mechanisms available to work around this, but
> selective imports and renaming all add to the cognitive load of using and
> writing the code.
>
> To me float4 isn't a SIMD name; its a vector name and if it's implemented
> using SIMD, great, but that's an implementation detail. I can understand a
> close to the metal SIMD library and encourage the work. But if it isn't
> also going to be a vector library, if possible, it shouldn't use the vector
> names.
>

Can you give me an example of a non-simd context where this is the case?
Don't say shaders, because that is supported in hardware, and that's my
point.
Also there's nothing stopping a secondary library adding/emulating the
additional types. They could work seamlessly together. flaot4 may come from
std.simd, float3/float2 may be added by a further lib that simply extends
std.simd.

Re: Changing the name of the language?

[Manu]

On 16 March 2012 23:29, Nick Sabalausky  wrote:

> "Manu"  wrote in message
> news:mailman.778.1331920080.4860.digitalmar...@puremagic.com...
> > On 16 March 2012 03:23, ixid  wrote:
> >
> >> D is a very poor name for a language. I appreciate it's late in the day
> >> for this and that it has probably been discussed before (not that I
> could
> >> find such a discussion with Google which relates to my point). Although
> >> the
> >> results for D are fine when googling for things like "D tutorial", more
> >> obscure terms are hard to find because "d" is so commonly used as a
> >> variable name. Searchability is important though I understand that this
> >> might be seen as a trivial point, it is a major human factor. The
> >> language
> >> would be far better off with a 3 to 5 letter identifier. It will succeed
> >> or
> >> fail for other reasons but an easily searchable name would help. Dlang
> as
> >> the search term isn't good enough because it's not actually the
> >> language's
> >> name, people don't use it that much when referring to D, nor do they
> >> usually use D2.
> >>
> >
> > Do you have trouble googling for C? I find that D related results are
> > currently only around 4-5 down the google results list, and it'll only
> get
> > higher as it get's more popular.
> > C searches are fine... I am often surprised just how much influence
> > programmers seem to have on search results placement.
> >
>
> Google search results are different for everybody. They tailor the search
> results they give you based on your past search (and clickthrough) history.
> If you're doing a lot of programmer searches, they're going to start giving
> you more programmer results.
>

Perfect! So no problem then! Use D for a couple of months, and your search
results will sort themselves out :)

Re: Something wrong with win32 dmd 2.059head?

[Vladimir Panteleev]

On Friday, 16 March 2012 at 21:26:40 UTC, Jonathan M Davis wrote:
Well, I believe that the error gagging was temporarily turned 
off (with the idea of re-enabling closer to the release of 
2.059), so you do get a ton of error messages when there's 
anything wrong with a template. I don't know why you'd be 
seeing more on Windows though.


I'm seeing this too. The thing is, though, that the error 
messages that follow are completely disconnected with any 
problems in the source code (e.g. you'd get errors inside Phobos, 
and not with template instantiations with your types either).

Re: OpenBSD port of dmd?

[Walter Bright]

On 3/16/2012 1:38 PM, Jonathan M Davis wrote:

That's not necessarily a bad thing,


It's very deliberate, and it's *certainly* not a bad thing. No ifs, ands, or 
buts about it.


Supporting a new OS by assuming that declarations for some other random OS will 
work is a recipe for unending frustration and disaster. For example, suppose 
there is a subtle difference in the layout of the FILE* struct. OOPS!


The way the versioning is done it:

1. forces the porter to check that stuff.

2. exposes all the places in the library where there is OS dependent code

There should never, EVER, in the library code be something like:

  version (FreeBSD)
... do something weird with FreeBSD ...
  else
... do the default ...

If you find any code like this in the library, please file a bugzilla entry for 
it.

Instead:

  version (FreeBSD)
... do something weird with FreeBSD ...
  else
static assert(0, "OS not supported");

Re: Dynamic language

[F i L]

On Friday, 16 March 2012 at 14:23:20 UTC, Adam D. Ruppe wrote:

On Friday, 16 March 2012 at 09:12:57 UTC, F i L wrote:
Alright I give up dammit! How do you use opCall() to make 
a.cool() work?


I was a little unclear... but you'll have to modify
std.variant and/or wrap it.

Here's a solution that wraps it:
[snip]


Thank you for all the code. :)



D rox despite bugs.


Yes it does. I'm sure it wont be too long before all this stuff 
is fixed up a bit.

Re: Ideas for Phobos., u++ STL speed comparison

[Jay Norwood]

On Friday, 16 March 2012 at 14:26:19 UTC, Andrei Alexandrescu 
wrote:

http://www.ultimatepp.org/www$uppweb$vsd$en-us.html


The test uses a specific data structure, an indexed contiguous 
array. To conclude from here that C++ is faster than D is quite 
a stretch.


Andrei


In fact the claim is no longer true.  I pulled down their latest 
build and tested with a large Alice (duplicated many times to get 
it up to measureable consistently). I used the library stopwatch 
measurements for each.  The results come out about the same ... 
theirs is a few msec faster on 10MB of input with their 
optimizations for speed turned on. This is on a win7-64 corei7 
box, but compiling for 32 bit with msvc for their code.


this is for upp, 4193 build
G:\upp\out\MyApps\MSC9.Force_Speed.Sse2>alice2
 lines  words  bytes file
2241601825140   10050960 alice2.txt
time: 93 ms
skey: zip sval: 60
map size;3482


this is for d 2.058
G:\d\alice2\alice2\alice2\Release>alice2
 lines  words  bytes file
224160   1825140  10050960 alice2.txt
time: 97 ms
skey: zip sval: 60
dictionary length:3482

Re: OpenBSD port of dmd?

[Andrei Alexandrescu]

On 3/16/12 5:27 PM, Walter Bright wrote:

There should never, EVER, in the library code be something like:

version (FreeBSD)
... do something weird with FreeBSD ...
else
... do the default ...

If you find any code like this in the library, please file a bugzilla
entry for it.

Instead:

version (FreeBSD)
... do something weird with FreeBSD ...
else
static assert(0, "OS not supported");


Never say never. There are I/O routines that are specialized for several 
OSs and fall back to a generic (slower) implementation.


Andrei

Re: OpenBSD port of dmd?

[Walter Bright]

On 3/16/2012 4:04 PM, Andrei Alexandrescu wrote:

Never say never. There are I/O routines that are specialized for several OSs and
fall back to a generic (slower) implementation.


I'm going to suggest that is wrong as well. It's fine for a new port to use a 
generic slow implementation, but that ought to be a deliberate choice, *not* a 
default that went unnoticed during the porting process.

Re: OpenBSD port of dmd?

[Walter Bright]

On 3/16/2012 4:18 PM, Walter Bright wrote:

On 3/16/2012 4:04 PM, Andrei Alexandrescu wrote:

Never say never. There are I/O routines that are specialized for several OSs and
fall back to a generic (slower) implementation.


I'm going to suggest that is wrong as well. It's fine for a new port to use a
generic slow implementation, but that ought to be a deliberate choice, *not* a
default that went unnoticed during the porting process.



I should explain this better. Having a default is wrong because:

1. as mentioned, it can be overlooked in the porting process

2. if the default doesn't work right for some system, the temptation will be to 
'fix' the default in ways that are untested (and therefore broken) on other 
systems. Working on one system's code should not affect other systems!


3. it leaves unknown to the reader what systems that may apply to

I know the powerful temptation to avoid copypasta. But I have decades of trying 
it that way, and it just leads to lots of time wasted tracking down bugs. This 
includes historical bugs from doing it that way with druntime & phobos.

Re: Dynamic language

[Adam D. Ruppe]

On Friday, 16 March 2012 at 22:48:44 UTC, F i L wrote:
Yes it does. I'm sure it wont be too long before all this stuff 
is fixed up a bit.


Aye. I just sent a pull request for the minor std.variant
thing (so strings can be converted to ints - we can do
weak typing more easily now if we want).

The opCall stuff is probably a lot harder to fix. Much
of it is legacy from D1 I think.


But it is pretty usable today, anyway. Use the class
and assignment operator and it works well.

The biggest annoyance is that @property doesn't work
right (not even with -property). So, if you merge
this with the opDispatch code from an earlier post,
you can do:


a.myProperty = { writeln("hello!"); }

a.myProperty(); // does nothing because it thinks you are doing 
the getter...


a.myProperty()(); // this work. first paren does get, second does 
call.

Re: Dynamic language

[Adam D. Ruppe]

On Friday, 16 March 2012 at 11:22:07 UTC, Boscop wrote:
How would it be possible, the type of the delegate can't be 
typechecked at the call-site, because the type info is lost in 
the variant.


The trick is to build wrapper functions at the assignment
point, where you still have all the type info.

I showed that with the wrap() template in the implementation
in a previous post - std.traits.ReturnType and
std.traits.ParameterTypeTuple help a lot there.

This same technique can do all kinds of conversions: I
use it to do strings -> calls for web apps and Variant ->
calls for this dynamic thing, weak typing, and script
interaction.

Remember, that while the wrapper is showed at the
assignment type, it is a compile time thing to
build the wrapper, so the assignment is still cheap.

The call has a small runtime hit though, since it does
the type conversions or checks there.

If you wanted strict type checking, it could probably
be fast; Variant.get() has a small cost.

Re: Multiple return values...

[bearophile]

Simen K.:

> Now, a pattern that our productive friend bearophile posted earlier was  
> this:
> 
> int[] foo();
> 
> (auto a, b) = foo();
> 
> --->
> 
> auto __t = foo();
> assert( __t.length > 0 );
> auto a = __t[0];
> auto b = __t[1..$];
> 
> Is this something we might also want?

That's not a good idea, because you don't know much about what 'b' contains.

Time ago I have written an example vaguely like that, but it was in the Python3 
version. So a more similar translation is:

auto (a, $b) = foo();

The $ means: 'unpack all the remaining items inside the b tuple'. A similar 
syntax is cute to have, but it's not that important because it's not a very 
common need. And if people think it's so important, then it's possible to add 
it later (it's a purely incremental feature over the basic tuple unpacking 
syntax).

What's more commonly userful instead is tuple unpacking in foreach (this isn't 
the final syntax, it's just an idea) (Hara is willing to support this first 
one):

void spam((int x, int y)) {}
auto bar = [tuple(1,2,), tuple(3,4)];
foreach (tuple(x, y); bar) {}

And in function signatures (this is not the same as using tupleof at the call 
point):

void spam(tuple(int x, int y)) {}
spam(tuple(1,2))

Bye,
bearophile

Re: Dynamic language

[bearophile]

so:

> Not related to D but this is a community which i can find at 
> least a few objective person. I want to invest some "quality" 
> time on a dynamic language but i am not sure which one. Would you 
> please suggest one?
> 
> To give you an idea what i am after:
> Of all one-liners i have heard only one gets me.
> "The programmable programming language". Is it true? If so Lisp 
> will be my first choice.

There are several dynamic languages available, and different ones are better 
for different purposes.

The general purpose dynamic language that I suggest is Python, because it's 
very readable, it's very handy to write prototypes in, it allows a low bug 
count, it's widespread and you can find all kind of libs for it.

Lua is better for interfacing with C, and the small size makes it good to write 
the logic for games, and its JIT is the best.

Clojure seems nice for low-performance parallel code. It's a bug un-prone 
language.

Qi and its derivatives have the most powerful type system.

Bye,
bearophile

Re: OpenBSD port of dmd?

[Andrei Alexandrescu]

On 3/16/12 6:30 PM, Walter Bright wrote:

On 3/16/2012 4:18 PM, Walter Bright wrote:

On 3/16/2012 4:04 PM, Andrei Alexandrescu wrote:

Never say never. There are I/O routines that are specialized for
several OSs and
fall back to a generic (slower) implementation.


I'm going to suggest that is wrong as well. It's fine for a new port
to use a
generic slow implementation, but that ought to be a deliberate choice,
*not* a
default that went unnoticed during the porting process.



I should explain this better. Having a default is wrong because:

1. as mentioned, it can be overlooked in the porting process

2. if the default doesn't work right for some system, the temptation
will be to 'fix' the default in ways that are untested (and therefore
broken) on other systems. Working on one system's code should not affect
other systems!

3. it leaves unknown to the reader what systems that may apply to

I know the powerful temptation to avoid copypasta. But I have decades of
trying it that way, and it just leads to lots of time wasted tracking
down bugs. This includes historical bugs from doing it that way with
druntime & phobos.


Not convinced. They call it specialization, and it's a powerful concept. 
We use it in std.algorithm all over the place.


Andrei

Re: Proposal: user defined attributes

[Kapps]

On Friday, 16 March 2012 at 16:09:55 UTC, Andrei Alexandrescu 
wrote:

So we have:

class A {
@note(Serializable.yes) int a;
...
}

vs. a hypothetical in-language solution:

class A {
int a;
mixin(note("a", Serializable.yes));
...
}

I wonder to what extent the in-language solution can be made to 
work.



Andrei


This gets to an unreasonable amount of noise and complexity. 
First, you have the issue of using mixins. Using mixins is quite 
ugly. It's very tool unfriendly. It's not easily readable. It can 
mess up line numbers. It may or may not be limited in situations 
such as with parameters.


In language solutions should be preferred for many things, but 
ultimately, not everything is a nail to hammer.


Ultimately, I'd like to see being able to use any CTFE capable 
struct/class for an attribute with a constructor, ideally with 
access to the symbol it's defined on. This allows things like (if 
my unchecked code was correct):


@attribute struct WebForm {
string FormName;
this(string FormName) {
this.FormName = FormName;
static assert(is(typeof(Symbol) : struct));
static assert(__traits(getAllMembers, Symbol).length > 0);
// TODO: Make sure at least one member set to 
Browsable(true).

}
}

@attribute struct Validate {
string Pattern;
this(string Pattern) {
this.Pattern = Pattern;
static assert(isValidRegex(Pattern));
}
}

@WebForm("Account");
@PostTo("Services/CreateAccount")
@SecureOnly(true)
struct CreateAccountForm {

@Description("The name of your account. Must be between 3 and 
12 letters.");

@Validate(r"\w{3,12}")
string Username;

@Validate(r"\w+@\w+.\w+");
@Description("The email address to associate with this 
account.");

string Email;

}

While it's a bit of boiler plate to create the library and 
attributes, you only need to do it once. Then you can make a very 
nice form that automatically validates fields both clientside 
(where JS and/or CSS3 is supported) and serverside (when posted 
to Services/CreateAccount). You can verify a bunch of things at 
compile-time, including that the service exists or that the 
validation contains valid regex. And best of all, it's actually 
readable unlike if you went with a mixin approach. You would end 
up having 7 random mixins in that above form, and have to 
manually check each one to see if it's creating code or just 
creating an attribute. This way, you can see the @ and know it's 
an attribute immediately.


Another thing that doesn't come up yet but may in the future: 
reflection. It seems worrying to have random mixins adding 
reflection info, as that's a job for the compiler. It knows about 
when reflection is enabled, it knows how much it needs to 
generate, if things exist after optimization, etc. There's no 
point leaving that to a mixin and having to keep it in sync with 
the compiler. This way though, there's no need. The reflection 
data would just have an annotations property that can be accessed.