Re: D-etractions A real world programmers view on D

[Jacob Carlborg]

On 2012-09-05 07:55, Nick Sabalausky wrote:


I don't know if maybe my experience is different from usual, but
personally, I haven't *ever* wished I had dynamic typing in D.
Templates and (on rare occasion) variants have always been perfectly
sufficient (and even preferable) in any cases I've ever had.


As I replied to Adam, "dynamic typing" was a bit misleading. It's more 
the dynamic nature of Ruby I like. For example:


* Open classes
* Reflection
* Eval
* Executable code in all levels of scope

So if D had something comparable, like AST-macros, better reflection and 
annotations I would be more happy.


--
/Jacob Carlborg

Re: D-etractions A real world programmers view on D

[Jacob Carlborg]

On 2012-09-05 08:17, Nick Sabalausky wrote:


Wow, now *that's* hard-core static typing fan :)

Languages like ActionScript 2 and PHP (ie, the worst of the dynamic
bunch - or at least I *hope*) have conditioned me to develop a severe
allergic reaction to any and all dynamic typing. But if my only static
choice were Java, I think it's very possible I'd end up a dynamic guy
(but with something more sensible than AS2 or PHP, of course).
Dynamic has major flaws IMO, but Java's a pedantic rubber-coated pain.


ActionScript and PHP are probably two of the worst languages. Ruby is 
way better.


--
/Jacob Carlborg

Re: D-etractions A real world programmers view on D

[Jacob Carlborg]

On 2012-09-04 22:44, SomeDude wrote:


The only experience I've had with dynamic typing (in Python), I can say
I hated it. I prefer to write Java code, which I think tells a lot about
my love for dynamic typing. I probably wouldn't mind writing some Lua
code, but not in the large. Unless you are working in an environment
which changes all the time, so that you need to adapt your code very
quickly, dynamic languages are a waste of time above ~10,000 lines of
code in my opinion.


I see your point. But I think Java is a bad example, it's too verbose 
and doesn't give you enough features to express the code you want to write.


--
/Jacob Carlborg

Re: D-etractions A real world programmers view on D

[Jacob Carlborg]

On 2012-09-04 21:39, Adam D. Ruppe wrote:

On Tuesday, 4 September 2012 at 19:18:05 UTC, Jacob Carlborg wrote:

I've also wished quite many times I had dynamic typing in D.


I think we're *fairly* close with things like std.variant,
especially combined with some helpers. Take a look:

Variant a = 10;
string b = a; // can't, and I say that's good, usually
b = a.coerce!string; // works

But, to get a dynamic feel, you don't want to write
out coerce!type. I kinda want it to be auto. So,

Variant a = 10;
string b;

b.dset = a; // dset means dynamic set

This is pretty doable in D today.


When I said "dynamic typing" that was a bit misleading. It's more the 
dynamic nature of Ruby I like. For example:


* Open classes
* Reflection - adding methods, calling a method via a string, introspection
* Have executing code in all level of scopes
* Eval

The comparable features in a static language would probably AST-macros, 
annotations and similar features. If D had those features then I 
probably wouldn't want dynamic typing that much.


--
/Jacob Carlborg

Re: D-etractions A real world programmers view on D

[Nick Sabalausky]

On Tue, 04 Sep 2012 22:44:07 +0200
"SomeDude"  wrote:
>
> The only experience I've had with dynamic typing (in Python), I 
> can say I hated it. I prefer to write Java code, which I think 
> tells a lot about my love for dynamic typing.
> 

Wow, now *that's* hard-core static typing fan :)

Languages like ActionScript 2 and PHP (ie, the worst of the dynamic
bunch - or at least I *hope*) have conditioned me to develop a severe
allergic reaction to any and all dynamic typing. But if my only static
choice were Java, I think it's very possible I'd end up a dynamic guy
(but with something more sensible than AS2 or PHP, of course).
Dynamic has major flaws IMO, but Java's a pedantic rubber-coated pain.

But I can still relate, though. As much as I hate C++ (How much? This
much:
),
I'm actually still *happier* using C++ on my current "real world"
project than I was with the dynamic languages I've used in other
projects. C++ sucks, but as long I stick mainly to "C with classes",
I find it more manageable than dynamic weirdness. (But I grew up with
C/C++, so that probably does help me tolerate it.)

> Unless you are 
> working in an environment which changes all the time, so that you 
> need to adapt your code very quickly, dynamic languages are a 
> waste of time above ~10,000 lines of code in my opinion.


Personally, I'd knock a zero or two off that figure.

Re: D-etractions A real world programmers view on D

[Nick Sabalausky]

On Tue, 04 Sep 2012 21:18:41 +0200
Jacob Carlborg  wrote:

> On 2012-09-04 15:59, Steven Schveighoffer wrote:
> >
> > This, of course, all comes from two guys who really like static
> > typing :)  We *may* have a biased view.
> 

I like to think it's the other way around: I like static typing
*because* it's better ;)

> I can tell you this, I've wished many times that I had static typing
> in Ruby. I've also wished quite many times I had dynamic typing in D.
> I think optional static typing, like Dart, sounds like a good idea.
> 

I don't know if maybe my experience is different from usual, but
personally, I haven't *ever* wished I had dynamic typing in D.
Templates and (on rare occasion) variants have always been perfectly
sufficient (and even preferable) in any cases I've ever had.

Re: scope for array parameters

[Jonathan M Davis]

On Wednesday, September 05, 2012 01:50:12 bearophile wrote:
> > I believe that the only case that
> > has _any_ protection at all with scope right now is delegates,
> > which almost never should be const.
> 
> Do you mean code like this? What's bad about this? My delegate
> arguments
> /function pointer arguments are usually const.
> 
> void foo(const int delegate(int) dg) {}
> void main() {
> foo((int x) => x);
> }

If you have delegates that work with const, then great, but in my experience 
(which frequently involves storing the delegate as a member variable), const 
doesn't play nicely at all with delegates.

- Jonathan M Davis

Re: scope for array parameters

[Jonathan M Davis]

On Wednesday, September 05, 2012 01:13:00 ixid wrote:
> What does -property supposedly solve?

It's supposed to make it so that property functions are used as variables and 
non-property functions are used as functions, since the point of property 
functions is to emulate variables. It's very buggy at the moment though, so it 
doesn't really enforce everything that it's supposed to enforce. IIRC, it only 
enforces that non-property functions are called with parens and not that 
property functions are called without them.

> It creates a horrid mess of
> brackets that ruin the elegance of UFCS code.

You mean parens? Regardless, it means that you using functions as if there 
were variables, which I'm very much against. They're functions and should be 
called as such. But not everyone agrees.

I think that it's pretty much a guarantee that we're eventually going to end 
up with @property functions having to be called without parens (I don't think 
that very many people disagree on that). The bigger question is whether we're 
going to follow TDPL and also make it so that non-property functions must be 
called with them (as -property currently checks for). The number of parens 
required with UFCS (particularly with functions requiring template arguments) 
is one of the reasons that some people give that they think that non-property 
functions shouldn't be forced to be called with parens.

- Jonathan M Davis

Re: scope for array parameters

[bearophile]

Jonathan M Davis:

That's part of why I keep saying not to use in whenever it 
comes up. scope is
very broken, so in is very broken. And honestly, given how 
often arrays are
used in structs, I suspect that it's not at all uncommon for in 
to be used incorrectly.


The situation with "in"/"scope" is worse than just deprecated 
stuff like "delete" or "typedef". I know those things are going 
away, so I don't use them, and this avoids the problem.




I believe that the only case that
has _any_ protection at all with scope right now is delegates, 
which almost never should be const.


Do you mean code like this? What's bad about this? My delegate 
arguments

/function pointer arguments are usually const.

void foo(const int delegate(int) dg) {}
void main() {
foo((int x) => x);
}

Bye,
bearophile

Re: scope for array parameters

[ixid]

What does -property supposedly solve? It creates a horrid mess of 
brackets that ruin the elegance of UFCS code.

Re: scope for array parameters

[Jonathan M Davis]

On Tuesday, September 04, 2012 23:42:33 bearophile wrote:
> Jonathan M Davis:
> > Once scope is properly enforced, then optimizing based on it
> > would be great, but until it is, it's a _bad_ idea.
> 
> Today we use "in" often for function arguments, and it implies
> "scope". Surely some of those programs use the arguments wrongly,
> this means they probably sometime escape. So are those programs
> someday going to become compilation errors? For the "-property"
> and for the arguments of delegate/function pointers the idea of
> turning some code currently used in errors is failing...
> Such things need to be implemented early in a language.

That's part of why I keep saying not to use in whenever it comes up. scope is 
very broken, so in is very broken. And honestly, given how often arrays are 
used in structs, I suspect that it's not at all uncommon for in to be used 
incorrectly.

I'd actually argue to _never_ to use in at this point. If you want const, then 
use const. If you want scope, then use scope. But using scope on anything 
which isn't checked properly by the compiler is just asking for it. You _will_ 
have code that breaks when scope is fixed. I believe that the only case that 
has _any_ protection at all with scope right now is delegates, which almost 
never should be const. So, using in makes little to no sense to me.

- Jonathan M Davis

Re: scope for array parameters

[Jonathan M Davis]

On Tuesday, September 04, 2012 23:57:24 Peter Alexander wrote:
> It's very unfortunate because it puts us in a lose-lose
> situations where we can't fix the language without breaking
> people's code. I think the best course of action is to fix these
> things as soon as possible and get the problem out of the way.

Indeed. The same goes for stuff like deprecating things that we've long said 
was going to be deprecated but hasn't yet been deprecated (e.g. delete). Lots 
of code is going to break when it happens, and the longer that we wait, the 
worse it's going to be. But until someone takes the time to fix it (and Walter 
is constantly busy on other things), it's not going to happen, which is 
obviously a big problem.

- Jonathan M Davis

Re: D-etractions A real world programmers view on D

[Chris Cain]

On Tuesday, 4 September 2012 at 21:46:12 UTC, bearophile wrote:

Fundamentalism has no place in engineering.


It just made me smile. I still sometimes use Python for small 
projects and I'm going to be getting more serious about learning 
Javascript (and maybe a variant like CoffeeScript). However, 
dynamic typing has frustrated me plenty of times in the past... 
Mr. Davis' statement reflects my feelings for it.

Re: scope for array parameters

[Peter Alexander]

On Tuesday, 4 September 2012 at 21:41:58 UTC, bearophile wrote:

Jonathan M Davis:

Once scope is properly enforced, then optimizing based on it 
would be great, but until it is, it's a _bad_ idea.


Today we use "in" often for function arguments, and it implies 
"scope". Surely some of those programs use the arguments 
wrongly, this means they probably sometime escape. So are those 
programs someday going to become compilation errors?


Yep.


Such things need to be implemented early in a language.


Yep.

It's very unfortunate because it puts us in a lose-lose 
situations where we can't fix the language without breaking 
people's code. I think the best course of action is to fix these 
things as soon as possible and get the problem out of the way.

Re: D-etractions A real world programmers view on D

[bearophile]

Chris Cain:


This is now my email signature. Thanks.


Fundamentalism has no place in engineering.

Bye,
bearophile

Re: scope for array parameters

[bearophile]

Jonathan M Davis:

Once scope is properly enforced, then optimizing based on it 
would be great, but until it is, it's a _bad_ idea.


Today we use "in" often for function arguments, and it implies 
"scope". Surely some of those programs use the arguments wrongly, 
this means they probably sometime escape. So are those programs 
someday going to become compilation errors? For the "-property" 
and for the arguments of delegate/function pointers the idea of 
turning some code currently used in errors is failing...

Such things need to be implemented early in a language.

Bye,
bearophile

Re: D-etractions A real world programmers view on D

[Chris Cain]

On Tuesday, 4 September 2012 at 21:08:42 UTC, Jonathan M Davis 
wrote:

Dynamic typing is evil.
- Jonathan M Davis


This is now my email signature. Thanks.

Re: scope for array parameters

[Jonathan M Davis]

On Tuesday, September 04, 2012 22:13:44 Benjamin Thaut wrote:
> What do you think about this idea?

scope on function parameters is supposed to prevent any reference to that data 
escaping from the function. e.g. scope on a delegate would make it an error to 
assign that delegate to anything which could escape the function. It is my 
understanding that this is also supposed to include arrays such that if you 
mark an array parameter with scope, it should be illegal for any references to 
it (including slices of it or references to its elements) to escape the 
function, which _would_ allow compiler optimizations. But the compiler doesn't 
seem to properly check for much with regards to scope right now. A _lot_ of 
code is going to break once it does, particularly since some people seem to 
think that it's a good idea to use in (which is the same as const scope) 
everywhere.

- Jonathan M Davis

Re: D-etractions A real world programmers view on D

[Jonathan M Davis]

On Tuesday, September 04, 2012 22:44:07 SomeDude wrote:
> The only experience I've had with dynamic typing (in Python), I
> can say I hated it. I prefer to write Java code, which I think
> tells a lot about my love for dynamic typing. I probably wouldn't
> mind writing some Lua code, but not in the large. Unless you are
> working in an environment which changes all the time, so that you
> need to adapt your code very quickly, dynamic languages are a
> waste of time above ~10,000 lines of code in my opinion.

Agreed. I avoid dynamic languages like the plague. I'll only touch them when I 
have to or when I need a script which won't require recompilation to run (and 
if D ever becomes widespread enough that you can reasonably rely on it being 
on a Linux system, then all of my scripts will probably be written in D). 
Dynamic typing is evil.

- Jonathan M Davis

Re: D-etractions A real world programmers view on D

[SomeDude]

On Tuesday, 4 September 2012 at 19:18:05 UTC, Jacob Carlborg 
wrote:

On 2012-09-04 15:59, Steven Schveighoffer wrote:

I have on occasion had the benefit of simply adding a member 
variable to
instances of a class when I needed it without having to burden 
the rest
of the code with knowing about that variable.  I felt dirty 
doing it...


But I think you are right -- "fake" static typing does not 
come close to
actual static typing.  If I could count all the time I've 
wasted because
I mistyped a member variable name, and it "just worked", 
blissfully
reading null instead of the variable I've set, it would 
probably add up
to days.  Thankfully, netbeans 7 is better at telling me that 
a variable

is previously unset or is never used, but it can't be perfect,
especially with this mess I inherited.  The original author 
thought
"modularity" meant importing large pieces of functions from 
other files,

which the IDE refuses to correctly interpret.

This, of course, all comes from two guys who really like 
static typing

:)  We *may* have a biased view.


I can tell you this, I've wished many times that I had static 
typing in Ruby. I've also wished quite many times I had dynamic 
typing in D. I think optional static typing, like Dart, sounds 
like a good idea.


I'm currently updating a Rails project to Ruby 1.9 and I really 
wished I had static typing. Just that fact that it won't load 
file until it's actually needed is quite annoying. Finding all 
the corner cases can be quite a lot of work. For example, a 
partial that is loaded when the rendering is triggered by an 
Ajax request.


In any case, it is what it is -- the existing code-base is 
huge, and I
have no real desire to rewrite all of it :)  The best I can do 
is add
some typing comments and hobble through it (cursing as I go).  
If I had

a year of spare time, I could rewrite it all in D!

-Steve


The only experience I've had with dynamic typing (in Python), I 
can say I hated it. I prefer to write Java code, which I think 
tells a lot about my love for dynamic typing. I probably wouldn't 
mind writing some Lua code, but not in the large. Unless you are 
working in an environment which changes all the time, so that you 
need to adapt your code very quickly, dynamic languages are a 
waste of time above ~10,000 lines of code in my opinion.

Re: scope for array parameters

[Jonathan M Davis]

On Tuesday, September 04, 2012 22:19:55 Benjamin Thaut wrote:
> Am 04.09.2012 22:18, schrieb Alex Rønne Petersen:
> > On 04-09-2012 22:13, Benjamin Thaut wrote:
> > This is already what scope does today. See http://dlang.org/function.html:
> > 
> > "references in the parameter cannot be escaped (e.g. assigned to a
> > global variable)"
> > 
> > It's just that the compiler doesn't actually enforce it fully.
> 
> Does the compiler already use this information to optimize array literals?

It had better not (I doubt that it does though). Unless scope is actually 
properly enforced, then you're going to have major bugs if you use scope and 
then escape references to that data anyway. And without the compiler checks, 
that _will_ happen (especially when some folks use in all over the place).

Once scope is properly enforced, then optimizing based on it would be great, 
but until it is, it's a _bad_ idea.

- Jonathan M Davis

Re: scope for array parameters

[Benjamin Thaut]

Am 04.09.2012 22:18, schrieb Alex Rønne Petersen:

On 04-09-2012 22:13, Benjamin Thaut wrote:
This is already what scope does today. See http://dlang.org/function.html:

"references in the parameter cannot be escaped (e.g. assigned to a
global variable)"

It's just that the compiler doesn't actually enforce it fully.



Does the compiler already use this information to optimize array literals?

Kind Regards
Benjamin Thaut

Re: scope for array parameters

[Alex Rønne Petersen]

On 04-09-2012 22:13, Benjamin Thaut wrote:

To make functions definitions more expressive and give the compiler more
information to optimize I propose to make array function parameters
extendable with 'scope' such as follows:

size_t find(scope float[] haystack, float needle){ ... }

This would give the compiler the information that the array haystack
only has to be valid as long as the scope of the function find is valid.
As soon as the function scope is left, the array does not need to be
valid any more. This would greatly help when programming without a GC to
know, if the array one passes to the function will be saved internally
or if it only needs to be valid for the duration in which the function
is executed. Also it would allow the compiler to optimize array literals
such as:

find([1,2,3,4,5], 5)

The function call would not allocate on the heap, but would allocate the
array literal on the stack, as the compiler knows that is only has to be
valid for the scope of find.

Passing a scope array to another function which does not have the scope
annotation should be an error. Assining a a scope array to a non local
variable should be an error too. You could go really fancy on checking
scoped function parameters but for a start simple rules should be enough.

The same could be done with references and pointers. The purpose of this
would be to allow the compiler to do more static checking on the usage
of the passed arguments and make the function definitions contain
information if the passed references will be saved internally or not.

I do understand that non-gc programming is not considered often for the
D-Programming Language, but it would be nice if this idea does not get
ignored completely.

What do you think about this idea?

Kind Regards
Benjamin Thaut


This is already what scope does today. See http://dlang.org/function.html:

"references in the parameter cannot be escaped (e.g. assigned to a 
global variable)"


It's just that the compiler doesn't actually enforce it fully.

--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org

scope for array parameters

[Benjamin Thaut]

To make functions definitions more expressive and give the compiler more 
information to optimize I propose to make array function parameters 
extendable with 'scope' such as follows:


size_t find(scope float[] haystack, float needle){ ... }

This would give the compiler the information that the array haystack 
only has to be valid as long as the scope of the function find is valid. 
As soon as the function scope is left, the array does not need to be 
valid any more. This would greatly help when programming without a GC to 
know, if the array one passes to the function will be saved internally 
or if it only needs to be valid for the duration in which the function 
is executed. Also it would allow the compiler to optimize array literals 
such as:


find([1,2,3,4,5], 5)

The function call would not allocate on the heap, but would allocate the 
array literal on the stack, as the compiler knows that is only has to be 
valid for the scope of find.


Passing a scope array to another function which does not have the scope 
annotation should be an error. Assining a a scope array to a non local 
variable should be an error too. You could go really fancy on checking 
scoped function parameters but for a start simple rules should be enough.


The same could be done with references and pointers. The purpose of this 
would be to allow the compiler to do more static checking on the usage 
of the passed arguments and make the function definitions contain 
information if the passed references will be saved internally or not.


I do understand that non-gc programming is not considered often for the 
D-Programming Language, but it would be nice if this idea does not get 
ignored completely.


What do you think about this idea?

Kind Regards
Benjamin Thaut

Re: D-etractions A real world programmers view on D

[Adam D. Ruppe]

On Tuesday, 4 September 2012 at 19:18:05 UTC, Jacob Carlborg 
wrote:

I've also wished quite many times I had dynamic typing in D.


I think we're *fairly* close with things like std.variant,
especially combined with some helpers. Take a look:

Variant a = 10;
string b = a; // can't, and I say that's good, usually
b = a.coerce!string; // works

But, to get a dynamic feel, you don't want to write
out coerce!type. I kinda want it to be auto. So,

Variant a = 10;
string b;

b.dset = a; // dset means dynamic set

This is pretty doable in D today.

auto dset(T, U)(ref T t, U u) {
return t = to!T(u);
}

Then call with UFCS + property getter syntax.


The other thing is to do function calls. And we might
be able to pull that off too with something like

void foo(string a, string b) {}

auto dcall(alias func, T...)(T args) {
import std.traits;
ParameterTypeTuple!func typedArgs;
foreach(i, ref arg; typedArgs)
arg.dset = args[i];
return func(typedArgs);
}

dcall!foo(a, b);



Thus your user code is pretty type-agnostic, with loose
types when requested.

Re: D-etractions A real world programmers view on D

[Jacob Carlborg]

On 2012-09-04 15:59, Steven Schveighoffer wrote:


I have on occasion had the benefit of simply adding a member variable to
instances of a class when I needed it without having to burden the rest
of the code with knowing about that variable.  I felt dirty doing it...

But I think you are right -- "fake" static typing does not come close to
actual static typing.  If I could count all the time I've wasted because
I mistyped a member variable name, and it "just worked", blissfully
reading null instead of the variable I've set, it would probably add up
to days.  Thankfully, netbeans 7 is better at telling me that a variable
is previously unset or is never used, but it can't be perfect,
especially with this mess I inherited.  The original author thought
"modularity" meant importing large pieces of functions from other files,
which the IDE refuses to correctly interpret.

This, of course, all comes from two guys who really like static typing
:)  We *may* have a biased view.


I can tell you this, I've wished many times that I had static typing in 
Ruby. I've also wished quite many times I had dynamic typing in D. I 
think optional static typing, like Dart, sounds like a good idea.


I'm currently updating a Rails project to Ruby 1.9 and I really wished I 
had static typing. Just that fact that it won't load file until it's 
actually needed is quite annoying. Finding all the corner cases can be 
quite a lot of work. For example, a partial that is loaded when the 
rendering is triggered by an Ajax request.



In any case, it is what it is -- the existing code-base is huge, and I
have no real desire to rewrite all of it :)  The best I can do is add
some typing comments and hobble through it (cursing as I go).  If I had
a year of spare time, I could rewrite it all in D!

-Steve



--
/Jacob Carlborg

Re: pointers, functions, and uniform call syntax

[Era Scarecrow]

On Tuesday, 4 September 2012 at 10:51:36 UTC, Artur Skawina wrote:

On 09/03/12 20:45, Jonathan M Davis wrote:


It's a  perfectly valid enhancement request to want

void func(S s, int i) {...}

to be be callable with S*, given that normally function calls 
on an S* don't require you to dereference anything.


No, it's not. See 
http://d.puremagic.com/issues/show_bug.cgi?id=8490 for why
this would be a very bad idea. However 'void func(ref S s, 
...){}' should (be made to) work, at least for the UFCS case - if 
it already doesn't (old compiler here...) - if 'func' is supposed 
to emulate a method then it should behave like one.


 Hmmm... And here i consider the opposite true. With ref as it 
works, you can only pass 'live' (absolutely guaranteed to be 
allocated) variables to work, you can't guarantee that with a 
normal pointer.


 On the other hand. Let's consider the two calls.

  struct S {
int x, y;
int gety(){ return y;}
  }

  int getx(S s) {return s.x;}

  S ss;
  S *sp = &ss; //without errors for now

  writeln(ss.gety());
  writeln(sp.gety()); /*pointer but as it currently works,
the same (technically) */

  writeln(ss.getx());
  writeln(sp.getx()); //currently breaks without dereferencing

  If getx is valid with a pointer, it will be more consistent 
(and doesn't change anything). Now let's void it.


  sp = null;

  writeln(sp.gety()); //null pointer, refers to calling site
  writeln(sp.getx()); /*null pointer, breaks during copying and
should refer to calling site*/

 This I think is totally acceptable since it would be the same 
error and the same reason. If we take ref and allow that, you may 
as well allow referencing variables (and not just in the function 
signature)


  struct S {
//may as well allow during building of struct,
//it's just as safe as the rest of the ref calls now.
ref S prev;  //defaults to null
this (ref S s) {prev = s};

int x;
  }

  int getx(ref S s) {return s.x}

  //now breaks inside getx
  writeln(sp.getx());
  writeln(getx(sp));

  //might compile?; More likely it's no longer a named variable
  writeln((*sp).getx());
  writeln(getx(*sp));

  //might compile, but now it's old C/C++ pointers. Very risky?
  writeln(getx(sp[0]));

 I ask you, how do you check if it's a null pointer? &s?

  int getx(ref S s)
  //How does this make sense?? it looks wrong and is misleading
  in {assert(&s); }
  body {return s.x); }

 More importantly, if it's now a possibility do we have to start 
adding checks everywhere?


  int getx(S *s)
  in {assert(s); } //perfectly acceptable check, we know it's a 
pointer

  body {return s.x); }

Re: pointers, functions, and uniform call syntax

[Jonathan M Davis]

On Tuesday, September 04, 2012 12:51:53 Artur Skawina wrote:
> On 09/03/12 20:45, Jonathan M Davis wrote:
> > It's a perfectly valid enhancement request to want
> > 
> > void func(S s, int i) {...}
> > 
> > to be be callable with S*, given that normally function calls on an S*
> > don't require you to dereference anything.
> 
> No, it's not. See http://d.puremagic.com/issues/show_bug.cgi?id=8490 for why
> this would be a very bad idea.

I completely disagree with that assessment. You already get copies with UFCS 
all over the place. It's just that if you could use a function which took the 
struct as a value with a pointer to the struct with UFCS, then you'd get a 
copy whereas if it's taking it by pointer, you wouldn't.

> However 'void func(ref S s, ...){}' should
> (be made to) work, at least for the UFCS case - if it already doesn't (old
> compiler here...) 

I completely disagree with this as well. If using UFCS with an S* and a 
function which takes an S works, then it should work with a function which 
takes ref S, but pointers are _not_ the same as ref at all, and I completely 
disagree with anything which try and make pointers convert to ref in the 
general case. It only makes sense in this particular case, because of how 
calling member functions on pointers to struct works, and in that case, the 
ref is irrelevant IMHO. Having functions take ref is _annoying_, because you 
can't pass rvalues to them, and so ref should be used sparingly.

I don't see any real difference between having a function which takes an S 
being used with UFCS and having that same function used with an S*. A copy 
occurs in both cases. It's just that with S*, it means that the compiler has 
to implicitly dereference it for you (as it already does when accessing the 
struct's members). Other than that, the semantics are identical.

> - if 'func' is supposed to emulate a method then it
> should behave like one.

Which is exactly the point of this enhancement request. If you call a member 
function on a struct pointer, you don't need to dereference anything or really 
care that it's a pointer, but with UFCS, all of a sudden you do, which breaks 
the abstraction that UFCS is trying to provide.

- Jonathan M Davis

Re: D and SCons

[Chris Holdsworth]

On 04/09/2012 17:01, H. S. Teoh wrote:

On Tue, Sep 04, 2012 at 09:06:56AM +0100, Russel Winder wrote:
[...]

What is comes down to is whether people testing the evolution of D
tooling would be happy to work with a fork of SCons or whether it is
necessary to work with a separate package and a distributed SCons.

[...]

I'm OK to use a fork of SCons as long as it doesn't disrupt my non-D
projects.


T

+1. I'm happy to accept a reasonable amount of pain to help the 
evolution of D+Scons.

Re: Embedded non-assignable containers

[José Armando García Sancio]

On Sat, Sep 1, 2012 at 6:40 PM, bearophile  wrote:

> José Armando García Sancio:
>
>  I recently read an interesting blog Why should I have written ZeroMQ in C,
>> not C++ (part II)  by Martin Sústrik. The
>>
>> title is misleading; to me its main observation is that object oriented
>> program may not lead to the most performant implementation.
>>
>
> Isn't he talking about Boost intrusive lists?
>
> http://www.boost.org/doc/libs/**1_51_0/doc/html/intrusive/**
> intrusive_vs_nontrusive.html
>
> Basically.


> One advantage of the NOT intrusive stl list is that if you have to
> transverse the linked list very often, the L1 cache only sees the smal(ler)
> "helpers" (see this image: http://250bpm.wdfiles.com/**
> local--files/blog:8/cpp1.png)
>  this probably leads to faster traversal times.
>

Maybe. But I suspect that you are traversing the list to at least read into
the object so I think this become a wash if not worst.


>

On the other hand linked lists are kind of dead, today their need is
> uncommon.
>

How so? Immutable single linked list are nice for multi-threaded
programming. They are heavily used by functional languages like Haskell,
Scala, Clojure, etc.

Bye,
> bearophile
>

Re: Embedded non-assignable containers

[José Armando García Sancio]

On Sun, Sep 2, 2012 at 12:39 AM, Philippe Sigaud
wrote:

>
> > To make a type "double linkable" the developer needs to mixin the
> following mixin template:
> >
> >> mixin template DoubleLinkable()
> >> {
> >>   typeof(this) next;
> >>   typeof(this) prev;
> >> }
> >
> >
> > The next and prev pointer can be access with the help of mixin by using
> the following templates:
> >
> >> T* next(T, string name)(T node) pure nothrow const
> >>
> >> {
> >>
> >>   mixin("return &(node." ~ name ~ ".next);");
> >>
> >> }
>
> These are free functions? Why not put them in the mixin templates?
>

They are actually part of the DoubleLinkedList template but I put them as
free functions because it is easier to read. My motivation for putting them
in the DoubleLinkedList template and class is because they are part of the
Container logic. For example they may need to be synchronized if you want a
concurrent data structure.

> > To use the above abstraction the developer just needs to do the
> following:
> >
> >> class Person
> >> {
> >>   int age;
> >>   int weight;
> >>   mixin DoubleLinkable people;
> >> }
>
> Oh, named mixins! Yet another D feature I totally forgot. Hey, those
> reading this, who here knew you could do 'mixin someTemplate someName;' to
> refer to the template scope by the given name?
>
> > I am not a big fan of the template signature 'class DoubleLinkedList(T,
> string name)' but I couldn't figure out a better way of allowing one object
> to be embedded in multiple containers. Thoughts? Any idea how this can be
> improved so that it is easier to use and read?
>
> I didn't read the blog post, but any reason why you do not put all the
> list machinery in a mixin template and refer directly to next/prev?
>
I think I answer this above.

> I'm on a pad, so typing is not so easy, but like this:
>
> mixin template NodeImplementation()
> {
> // should detect if typeof(this) is a reference type or a value type.
> // for a reference type, we should not use pointers.
> typeof(this) next() @property { return *_next;}
> typeof(this) prev() @property { return *_prev;}
> /// + setters also
> private *typeof(this) _next,_prev;
> }
>
> struct Person()
> {
> mixin NodeImplementation;
> string name;
> int age;
> }
>
> And DoublyLinkedList(Node) if (isNode!Node)
>
> with
>
> /**
> A node is a type T that has .next and .prev fields
> that return another T.
> */
> isNode(T)
> {
> enum isNode = __traits(compiles, { T p = T.init.prev; T n =
> T.init.next;});
> }
>

Yep. DoubleLinkedList should have a template constraint but I didn't want
to add to many D features as I plan to post this as a comment in the blog.
All the C/C++ would have a harder time understanding the D code. ;)

Thanks!
-Jose

Re: D and SCons

[H. S. Teoh]

On Tue, Sep 04, 2012 at 09:06:56AM +0100, Russel Winder wrote:
[...]
> What is comes down to is whether people testing the evolution of D
> tooling would be happy to work with a fork of SCons or whether it is
> necessary to work with a separate package and a distributed SCons.
[...]

I'm OK to use a fork of SCons as long as it doesn't disrupt my non-D
projects.


T

-- 
In a world without fences, who needs Windows and Gates? -- Christian Surchi

Re: D-etractions A real world programmers view on D

[Steven Schveighoffer]

On Sat, 01 Sep 2012 21:21:50 -0400, Nick Sabalausky  
 wrote:



On Thu, 30 Aug 2012 09:35:31 -0400
"Steven Schveighoffer"  wrote:


For example, I use netbeans to write php -- a dynamic language.
There are no real variable type declarations, so when you start
typing, auto-complete sucks unless you have told the IDE what a
variable is.  You do so like this:

/**
  @var Type
  */
var $varname;

And now the IDE assumes you have stored a Type into $varname, so when
you type $this->varname->, it completes with the members of Type.



Wow, so it's basically reinventing static typing poorly. You've got
the boilerplate and verbosity of a poorly-made static type system, with
very few of the benefits (ie, IDE-awareness and nothing else).

I'll never understand the dynamic world.


I have on occasion had the benefit of simply adding a member variable to  
instances of a class when I needed it without having to burden the rest of  
the code with knowing about that variable.  I felt dirty doing it...


But I think you are right -- "fake" static typing does not come close to  
actual static typing.  If I could count all the time I've wasted because I  
mistyped a member variable name, and it "just worked", blissfully reading  
null instead of the variable I've set, it would probably add up to days.   
Thankfully, netbeans 7 is better at telling me that a variable is  
previously unset or is never used, but it can't be perfect, especially  
with this mess I inherited.  The original author thought "modularity"  
meant importing large pieces of functions from other files, which the IDE  
refuses to correctly interpret.


This, of course, all comes from two guys who really like static typing :)   
We *may* have a biased view.


In any case, it is what it is -- the existing code-base is huge, and I  
have no real desire to rewrite all of it :)  The best I can do is add some  
typing comments and hobble through it (cursing as I go).  If I had a year  
of spare time, I could rewrite it all in D!


-Steve

Re: Trouble creating a formatted assert wrapper

[Don Clugston]

On 04/09/12 11:43, Chris Nicholson-Sauls wrote:

On Tuesday, 4 September 2012 at 09:24:26 UTC, Don Clugston wrote:

On 03/09/12 23:48, Chris Nicholson-Sauls wrote:

I reiterate my impression that magical __FILE__ and
__LINE__ should be provided by some other means.


It was a special-case hack to fix a special-case need. It was
extremely easy to implement (about 2 hours work) and has been very
successful in fixing that need. Everything else that anyone has talked
about is at least ten times as complicated, and doesn't seem to offer
significant advantages.

It's really easy to come up with over-engineered solutions to these
sorts of things.


How difficult would hidden params, triggered by usage, be?  Ie: my
function makes use of __CALL_FILE and __CALL_LINE variables by name,
therefore they are tacked on  (as const, presumably) and always passed,
thanks to diabolic compiler sorcery.  The current solution is fine in a
majority of cases, at least so far, but there are going to be moments
like what the OP had, and these moments are discouraging especially to
newcomers.


I don't know how that could be done. You need to know the function 
signature whenever you call the function. If you make the signature 
dependent on the function body, it cannot work unless you have the 
source code of the function. The compiler is able to add hidden 
variables for things like 'this' because it can work out if it is 
required just by looking at the types involved in the function 
declaration. But in this case, it can't get it from the signature.


The default argument method we are currently using is a nice trick, 
because even though default arguments aren't part of the function type, 
the compiler still sees them in the function signature, so it knows to 
do a bit of magic.


It's also easy to get nasty forward reference errors when you do that 
sort of thing.





I won't pretend to know if it would be easy or not; you're a heck of a
lot more familiar with the compiler's code than I am.  But it certainly
seems straightforward.

Re: Vote for std.digest: ACCEPTED!

[Johannes Pfau]

Am Fri, 31 Aug 2012 01:37:10 +0400
schrieb Dmitry Olshansky :

> On 30-Aug-12 12:33, Johannes Pfau wrote:
> > Am Thu, 30 Aug 2012 00:55:40 +0400
> [snip]
> 
> >> The end result is we need to get a version of copy that:
> >> - doesn't break existing code
> >> - takes destination by ref when possible thus fixing this pattern.
> >>
> >
> > Would it be good enough if we special cased arrays to have the same
> > behavior as now and used 'auto ref' for all other output ranges?
> >
> > I think we can't avoid breaking some code though. If some code
> > relied on the second parameter being passed by value, there's
> > nothing we can do?
> >
> 
> Yes, that's the catch. Even introducing special case for arrays
> doesn't prevent code breakage.
> 
> > E.g:
> > 
> > auto a = copy([0], start); // a = start ~ 0
> > auto b = copy([1], start); // b = start ~ 1
> > auto c = copy([2], start); // c = start ~ 2
> >
> 
> Then it seems to me that the only way out is to 'educate the masses'
> on the proper copy idiom. And we already have sort of the same thing
> with std.algorithm.remove.
> Interestingly, copy documentation doesn't indicate how output ranges 
> work with it, instead focusing on arrays and (probably) forward
> ranges. AFAICT output range doesn't have a "leftover" portion.
> 
> What about adding copyInto algorithm that requires output range and 
> leaves the usual copy to work on forward ones? (it then would require 
> ref argument or class instance obviously).
> 
> A couple of releases ago I actually added one function in what I was 
> meant to be a family of functions. The aim of *Into was to fix 
> allocation happiness of e.g. replace and similar algorithms when the 
> resulting object is created only to be forwarded to some output range:
> 
> http://dlang.org/phobos/std_array.html#replaceInto
> (that reminds me to add std.regex.replaceInto)
> 
> The other use case is e.g. preallocated buffers, and ATM it seems the 
> only way to get GC-free replace/join etc. before we get allocators.
> 

First attempt to implement copyInto:
https://github.com/D-Programming-Language/phobos/pull/772

Re: pointers, functions, and uniform call syntax

[Artur Skawina]

On 09/03/12 23:19, Carl Sturtivant wrote:
> So I'm wondering if a language extension along the following lines would 
> solve your problem, simply asking the compiler to use heap allocation when 
> the variable is declared, e.g.
> 
>  @heap auto s = S(); //secretly allocated with new, but used as if local
> 
> where the compiler would know that s is valid, just as in a normal 
> declaration. And the compiler would automatically deallocate the variable's 
> heap storage when it goes out of scope. Otherwise the variable would behave 
> like a normal local variable as far as inference of any kind made by the 
> compiler in a wider context goes.

It could be part of the type (annotating the object/instance isn't really any
better than just using 'new'...), so

   struct S {
  new this(/*...*/) {/*...*/}
  /*...*/
   }

would let you skip the 'new' keyword. Might be useful when used with templates
(and a 'scope this(){}' ctor could ensure stack allocation). But as right now
struct allocations aren't properly supported yet (no custom allocators) adding
something like that shouldn't have high priority, even if it can be done w/o
breaking existing code (which does not use this feature).

artur

Re: pointers, functions, and uniform call syntax

[Artur Skawina]

On 09/03/12 20:45, Jonathan M Davis wrote:
>
> It's a  perfectly valid enhancement request to want
> 
> void func(S s, int i) {...}
> 
> to be be callable with S*, given that normally function calls on an S* don't 
> require you to dereference anything.

No, it's not. See http://d.puremagic.com/issues/show_bug.cgi?id=8490 for why
this would be a very bad idea. However 'void func(ref S s, ...){}' should (be
made to) work, at least for the UFCS case - if it already doesn't (old compiler
here...) - if 'func' is supposed to emulate a method then it should behave like
one.

artur

Re: pointers, functions, and uniform call syntax

[monarch_dodra]

On Tuesday, 4 September 2012 at 02:42:42 UTC, Jonathan M Davis
wrote:

On Monday, September 03, 2012 14:13:10 monarch_dodra wrote:

I was playing around with a very big struct, and told myself I
wanted it allocated on the heap. This meant I was now
manipulating S* instead of an S.

[snip]

Enhancement Request:

http://d.puremagic.com/issues/show_bug.cgi?id=8616

- Jonathan M Davis


That is a very well worded ER. Thank you.

Re: pointers, functions, and uniform call syntax

[monarch_dodra]

On Monday, 3 September 2012 at 21:18:28 UTC, Carl Sturtivant 
wrote:
On Monday, 3 September 2012 at 12:12:46 UTC, monarch_dodra 
wrote:

[SNIP]


In a nutshell, I think you're broadly saying that you want to 
program with a struct S the same way whether it's stack or heap 
allocated. (Good code reuse, and no duplication of semantics 
with -> as in C++.) From this perspective the trouble is that 
"S()" and "new S()" don't have the same effect except for 
allocating one on the stack and one on the heap, and the 
language forbids you from overcoming this via reference 
variables, except by calling a function and passing "*r" to a 
"ref S" parameter.


[SNIP]


Yeah, in a nut shell, that is pretty much it. There are several 
ways to "work around it", but, IMO, none are good enough:
*Function with ref: Too intrusive, especially for more 
complicated functions.
*Structs that implicitly alias This (such as RefCounted): Ref 
Counted itself I'm not a huge fan of, since I don't see why I'd 
pay for RAII when I have a GC. As for the rest, it is not in the 
library, so I wouldn't want to roll one out myself.
**Furthermore, these wrapper structs have a way of "tainting" the 
type system: When you pass your struct to a template, the 
template will instantiate on your struct itself, and not on the 
wrapped type.
*structs with explicit dereference (those that have "get", for 
instance): That's just trading "*" for "get".


For now, I'll just (*s) it. It isn't broken or anything...



What I regret though, is that since D is Garbage Collected, it is 
just screaming to be able to write:


S& val = *(new S);
val.doSomthing();
doSomething(s);
...

This is legal in C++, but it leaks* :/ D should be able to 
harness such expressiveness with no problems whatsoever though.


*Actually, I've done this in C++ for classes that have hefty 
attributes that need to be allocated, but otherwise don't need 
pointer functionalities. You just have to make sure to correctly 
implement the CC to avoid aliasing, and to "delete &val;" in the 
destructor. Once you've done this though, then for all intents 
and purposes, "val" is a value attribute. Nifty.

Re: Trouble creating a formatted assert wrapper

[Chris Nicholson-Sauls]

On Tuesday, 4 September 2012 at 09:24:26 UTC, Don Clugston wrote:

On 03/09/12 23:48, Chris Nicholson-Sauls wrote:

I reiterate my impression that magical __FILE__ and
__LINE__ should be provided by some other means.


It was a special-case hack to fix a special-case need. It was 
extremely easy to implement (about 2 hours work) and has been 
very successful in fixing that need. Everything else that 
anyone has talked about is at least ten times as complicated, 
and doesn't seem to offer significant advantages.


It's really easy to come up with over-engineered solutions to 
these sorts of things.


How difficult would hidden params, triggered by usage, be?  Ie: 
my function makes use of __CALL_FILE and __CALL_LINE variables by 
name, therefore they are tacked on  (as const, presumably) and 
always passed, thanks to diabolic compiler sorcery.  The current 
solution is fine in a majority of cases, at least so far, but 
there are going to be moments like what the OP had, and these 
moments are discouraging especially to newcomers.


I won't pretend to know if it would be easy or not; you're a heck 
of a lot more familiar with the compiler's code than I am.  But 
it certainly seems straightforward.

Re: Trouble creating a formatted assert wrapper

[Don Clugston]

On 03/09/12 23:48, Chris Nicholson-Sauls wrote:

On Monday, 3 September 2012 at 11:17:39 UTC, Chris Nicholson-Sauls wrote:

1) Empty array stands in for empty variadic. [snip]

In reality, though, we have neither of these things. [snip]


Turns out, I was quite wrong, and I'm happy to be.  Empty array is
accepted for typesafe variadics just fine ... I'm not sure now why I
thought otherwise.

Of course, our tangent is really sort of moot, since the brackets would
be required for any pattern with a suffix matching the optional
arguments anyhow, at which point there's little point in having the
variadic argument.  I reiterate my impression that magical __FILE__ and
__LINE__ should be provided by some other means.


It was a special-case hack to fix a special-case need. It was extremely 
easy to implement (about 2 hours work) and has been very successful in 
fixing that need. Everything else that anyone has talked about is at 
least ten times as complicated, and doesn't seem to offer significant 
advantages.


It's really easy to come up with over-engineered solutions to these 
sorts of things.

Re: The review of std.hash package

[Johannes Pfau]

Am Wed, 29 Aug 2012 04:57:32 +0200
schrieb "Jesse Phillips" :

> All this discussion on the use of auto in the docs made me notice 
> something else about the docs I missed.
> 
> I like how ranges are documented and think digest could do the 
> same. Instead of an ExampleDigest, just write the details under 
> isDigest.

I had a look at how std.range documents the range interfaces, but the
std.digest API forces more details on the implementation
(@trusted, exact parameter types for put, return type of finish,...)
so I think simply writing a text paragraph could get confusing.

But if someone posts a pull request which replaces the ExampleDigest
with something else I'm all for it.
> 
> I don't see a need for template the constraint example (D idiom).
> 
> This would require changing examples which use ExampleDigest, but 
> maybe that should happen anyway since it doesn't exist.

Yes, I'll change the examples (this also makes them runnable in theory.
Although I have not found any documentation about making examples
runnable on dlang.org)
> 
> I don't see a reason to change my vote because of this, its all 
> documentation.

Re: pointers, functions, and uniform call syntax

[Regan Heath]

On Mon, 03 Sep 2012 21:04:56 +0100, Era Scarecrow   
wrote:



On Monday, 3 September 2012 at 18:45:42 UTC, Jonathan M Davis wrote:
However, one thing to remember that complicates this a bit is that it's  
perfectly possible to declare a function which is overloaded with one  
function taking a pointer and one not.


void func(S* s, int i) {...}
void func(S s, int i) {...}

in which case, there's an ambiguity, and I would then expect UFCS to  
_not_ compile when using S*, or you'd risk function call hijacking.  
That's not necessarily a big deal, but it _does_ complicate things a  
bit.


- Jonathan M Davis


  I think moreso is would if it would convert to ref automatically or  
not rather than worry about pointers. True if you wanted all three, then  
the language has to keep them all distinctly different; But if it  
silently converts it should be okay (so long as constness/immutable is  
honored). Assuming that's the case:


   //these two effectively identical
   void func(S* s, int i) {...}
   void func(ref S s, int i) {...}


What if the first function is in library A and the 2nd function in library  
B and they do two totally different things?


R

--
Using Opera's revolutionary email client: http://www.opera.com/mail/

Re: Can DMD be built with g++?

[Don Clugston]

On 30/08/12 22:21, Andrej Mitrovic wrote:

On 8/30/12, Alex Rønne Petersen  wrote:

How are you building, what platform, etc...


Ah geez I forgot there's a makefile (doh!), I need to look into
passing the right flags first. I'm trying this on win32 via MinGW btw.



That's a different story. Dunno if anyone has tried that before.
It would be a miracle if the Windows makefile worked with g++, and AFAIK 
the Posix makefile is only set up for posix.

Re: D and SCons

[Russel Winder]

Chris, (and T),

> I'm using Scons for a couple of toy D projects. What's the best channel 
> for feedback/bug reports?

Thanks for getting back to me. The reasons for calling for the attention
of people using SCons for D building is because I think I need to change
the way the D tools are developed for SCons.  Currently the idea is to
have a separate package so that people can just have the working D tools
with their current version of SCons. However since D can be linked with
C and C++ (also Fortran?) I am more and more thinking that D should be
made a real peer to C, C++ and Fortran in SCons, which means working in
the SCons core codebase. This allows for D in the smart linking bits of
SCons. This isn't absolutely necessary, which leads to choice and hence
doubt about way forward.

What is comes down to is whether people testing the evolution of D
tooling would be happy to work with a fork of SCons or whether it is
necessary to work with a separate package and a distributed SCons.

Thanks.
-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


signature.asc
Description: This is a digitally signed message part