www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Array operation for computing the dot product?

reply Trass3r <un known.com> writes:
I wonder if an array operation could be reasonably included.
It's a quite common case and there are direct SSE instructions for it  
since SSE 4.1.
Feb 03 2010
next sibling parent reply Don <nospam nospam.com> writes:
Trass3r wrote:

 I wonder if an array operation could be reasonably included.
 It's a quite common case and there are direct SSE instructions for it 
 since SSE 4.1.


Indeed. The difficult question is, what would the syntax be?
Feb 03 2010
next sibling parent BCS <none anon.com> writes:
Hello Don,


 Trass3r wrote:
 

 I wonder if an array operation could be reasonably included.
 It's a quite common case and there are direct SSE instructions for it
 since SSE 4.1.


 Indeed. The difficult question is, what would the syntax be?
 


Make it an intrinsic?

--

<IXOYE><
Feb 03 2010
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Don:

 Indeed. The difficult question is, what would the syntax be?


What about the simper:
x.dot(y)

Bye,
bearophile
Feb 03 2010
next sibling parent reply Michiel Helvensteijn <m.helvensteijn.remove gmail.com> writes:
bearophile wrote:


 Indeed. The difficult question is, what would the syntax be?


 
 What about the simper:
 x.dot(y)


I don't like symmetric operations with an asymmetric syntax.

Better:      dot(x, y)
Even better: dot_product(x, y)
Funner:      sum(x .* y)

-- 
Michiel Helvensteijn
Feb 03 2010
next sibling parent reply "Simen kjaeraas" <simen.kjaras gmail.com> writes:
On Wed, 03 Feb 2010 21:19:57 +0100, Michiel Helvensteijn  =

<m.helvensteijn.remove gmail.com> wrote:


 bearophile wrote:


 Indeed. The difficult question is, what would the syntax be?


 What about the simper:
 x.dot(y)


 I don't like symmetric operations with an asymmetric syntax.

 Better:      dot(x, y)
 Even better: dot_product(x, y)
 Funner:      sum(x .* y)


Weirder:

x =C2=B7 y

-- =

Simen
Feb 03 2010
parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 02/03/2010 03:09 PM, Simen kjaeraas wrote:

 On Wed, 03 Feb 2010 21:19:57 +0100, Michiel Helvensteijn
 <m.helvensteijn.remove gmail.com> wrote:


 bearophile wrote:


 Indeed. The difficult question is, what would the syntax be?


 What about the simper:
 x.dot(y)


 I don't like symmetric operations with an asymmetric syntax.

 Better: dot(x, y)
 Even better: dot_product(x, y)
 Funner: sum(x .* y)


 Weirder:

 x · y


I vote obscure unicode character \u2743: heavy chevron snowflake

x ❆ y
Feb 03 2010
next sibling parent reply BCS <none anon.com> writes:
Hello Ellery,


 On 02/03/2010 03:09 PM, Simen kjaeraas wrote:
 

 On Wed, 03 Feb 2010 21:19:57 +0100, Michiel Helvensteijn
 <m.helvensteijn.remove gmail.com> wrote:
 

 bearophile wrote:
 

 Indeed. The difficult question is, what would the syntax be?
 


 What about the simper:
 x.dot(y)


 I don't like symmetric operations with an asymmetric syntax.
 
 Better: dot(x, y)
 Even better: dot_product(x, y)
 Funner: sum(x .* y)


 Weirder:
 
 x · y
 


 I vote obscure unicode character \u2743: heavy chevron snowflake
 
 x ❆ y
 


or why not: x ♣ y;

no wait that would delete y and assign x to it.


--

<IXOYE><
Feb 03 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
BCS wrote:

 Hello Ellery,
 

 On 02/03/2010 03:09 PM, Simen kjaeraas wrote:


 On Wed, 03 Feb 2010 21:19:57 +0100, Michiel Helvensteijn
 <m.helvensteijn.remove gmail.com> wrote:


 bearophile wrote:


 Indeed. The difficult question is, what would the syntax be?


 What about the simper:
 x.dot(y)


 I don't like symmetric operations with an asymmetric syntax.

 Better: dot(x, y)
 Even better: dot_product(x, y)
 Funner: sum(x .* y)


 Weirder:

 x · y


 I vote obscure unicode character \u2743: heavy chevron snowflake

 x ❆ y


 
 or why not: x ♣ y;
 
 no wait that would delete y and assign x to it.


Before we solve the difficult problem of naming the thing could we first 
go through the trivial part of optimizing it under its current name.

http://www.digitalmars.com/d/2.0/phobos/std_numeric.html#dotProduct


Andrei
Feb 03 2010
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 Before we solve the difficult problem of naming the thing could we first 
 go through the trivial part of optimizing it under its current name.


In this case finding a good syntax before D2 is out of alpha stage is more
important than implementing that efficiently.
The user interface is often very important for the usage and success of a
machine. And the interface of a computer language is its syntax.

Bye,
bearophile
Feb 03 2010
prev sibling parent Trass3r <un known.com> writes:
 Before we solve the difficult problem of naming the thing could we first  
 go through the trivial part of optimizing it under its current name.

 http://www.digitalmars.com/d/2.0/phobos/std_numeric.html#dotProduct


it's not like it couldn't be done in parallel :)
Feb 04 2010
prev sibling parent Daniel Keep <daniel.keep.lists gmail.com> writes:
Ellery Newcomer wrote:

 On 02/03/2010 03:09 PM, Simen kjaeraas wrote:

 On Wed, 03 Feb 2010 21:19:57 +0100, Michiel Helvensteijn
 <m.helvensteijn.remove gmail.com> wrote:


 bearophile wrote:


 Indeed. The difficult question is, what would the syntax be?


 What about the simper:
 x.dot(y)


 I don't like symmetric operations with an asymmetric syntax.

 Better: dot(x, y)
 Even better: dot_product(x, y)
 Funner: sum(x .* y)


 Weirder:

 x · y


 
 I vote obscure unicode character \u2743: heavy chevron snowflake
 
 x ❆ y


Considering TeX was invented (in part) to handle typesetting of
mathematical formulae, one might imagine it would be a good idea to use
its syntax...

x \mdot y

Yeah, maybe not...
Feb 03 2010
prev sibling parent Chad J <chadjoan __spam.is.bad__gmail.com> writes:
Michiel Helvensteijn wrote:

 bearophile wrote:
 

 Indeed. The difficult question is, what would the syntax be?


 What about the simper:
 x.dot(y)


 
 I don't like symmetric operations with an asymmetric syntax.
 
 Better:      dot(x, y)
 Even better: dot_product(x, y)
 Funner:      sum(x .* y)
 


Fine stuff.

This reminds me of a discussion we had a year or more ago about offering
abstract operators purely for the purpose of overloading.  We can use
things like (+), (*), (-), (&), and so on.  It'd probably be fine to use
one for dot product.  Probably a dream though.  It looks like it's very
hard to get new tokens/syntax into the language at this point.  I
suppose annotations and exponentiation managed it, but with no shortage
of blood, sweat, and tears.
Feb 03 2010
prev sibling next sibling parent BCS <none anon.com> writes:
Hello bearophile,


 Don:
 

 Indeed. The difficult question is, what would the syntax be?
 


 What about the simper:
 x.dot(y)


How about: x.y;

It reads correctly.

OK, bad idea. :)


--
<IXOYE><
Feb 03 2010
prev sibling parent reply Don <nospam nospam.com> writes:
bearophile wrote:

 Don:

 Indeed. The difficult question is, what would the syntax be?


 
 What about the simper:
 x.dot(y)
 
 Bye,
 bearophile


x.dot(y) and dot(x,y) are already implementable without language change.
Feb 03 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Don wrote:

 bearophile wrote:

 Don:

 Indeed. The difficult question is, what would the syntax be?


 What about the simper:
 x.dot(y)

 Bye,
 bearophile


 
 x.dot(y) and dot(x,y) are already implementable without language change.


As is std.numeric.dotProduct(x, y) without language _or_ library change :o).


Andrei
Feb 03 2010
parent Trass3r <un known.com> writes:
 What about the simper:
 x.dot(y)


  x.dot(y) and dot(x,y) are already implementable without language  
 change.


 As is std.numeric.dotProduct(x, y) without language _or_ library change  
 :o).


That's why I wondered if it could be reasonably included (without  
introducing a ton of new stuff to the language).

so it should be usable like x.dotProduct(y), right?
sounds fine for me.

Unfortunately I can't even try to implement it cause my Core 2 is slightly  
too old ;)
Was introduced with Penryn architecture.
Feb 05 2010
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Unicode operators are good for Fortress, but not for D.
x.dot(y) is good because it's short and easy to read&understand.

Another silly possibility:
x ^^^ y

:-)
Bye,
bearophile
Feb 03 2010
prev sibling parent retard <re tard.com.invalid> writes:
Wed, 03 Feb 2010 20:55:46 +0100, Don wrote:


 Trass3r wrote:

 I wonder if an array operation could be reasonably included. It's a
 quite common case and there are direct SSE instructions for it since
 SSE 4.1.


 
 Indeed. The difficult question is, what would the syntax be?


a · b
Feb 04 2010
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Chad J:

 This reminds me of a discussion we had a year or more ago about offering
 abstract operators purely for the purpose of overloading.  We can use
 things like (+), (*), (-), (&), and so on.  It'd probably be fine to use
 one for dot product.


This looks acceptable as dot product:
x (*) y
but to me it doesn't look that much better than the simple:
x.dot(y)

Bye,
bearophile
Feb 04 2010
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Trass3r wrote:

 I wonder if an array operation could be reasonably included.
 It's a quite common case and there are direct SSE instructions for it 
 since SSE 4.1.


This would be achieved by adding array aggregate properties, an idea 
that has cropped up a few times, though I can't seem to find anything 
other than
http://www.digitalmars.com/webnews/newsgroups.php?art_group=D&article_id=21671
at the moment.

And then add using these properties as something you can do with array 
operations besides slice assignment.

It's much more general than inventing a new operator just for dot product.

But there are more important things to do than adding yet more features 
to the language....

Stewart.
Feb 04 2010
parent reply retard <re tard.com.invalid> writes:
Fri, 05 Feb 2010 02:42:53 +0000, Stewart Gordon wrote:


 Trass3r wrote:

 I wonder if an array operation could be reasonably included. It's a
 quite common case and there are direct SSE instructions for it since
 SSE 4.1.


 
 This would be achieved by adding array aggregate properties, an idea
 that has cropped up a few times, though I can't seem to find anything
 other than
 http://www.digitalmars.com/webnews/newsgroups.php?


art_group=D&article_id=21671

 at the moment.
 
 And then add using these properties as something you can do with array
 operations besides slice assignment.
 
 It's much more general than inventing a new operator just for dot
 product.
 
 But there are more important things to do than adding yet more features
 to the language....


The funny thing about D is that if you start writing a book about it, 
there's a high desire to change the core features and add more of them in 
the community. You can't even list all the D1 features at the moment, 
because we don't know what they are. Example:

class bar {}
class foo : private bar {}

Another one:

pragma(msg, mystruct.tupleof.stringof);

I can easily come up with 100 other such features. Some time ago I really 
wanted to write a wikibook about D. I also wanted to write a new 
compiler. It's just that D is a shitty language to work with because even 
the stable version is a moving target and/or many features are 
unspecified.
Feb 05 2010
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
retard wrote:

 I can easily come up with 100 other such features.


Please do so, and submit them to bugzilla.



 Some time ago I really 
 wanted to write a wikibook about D. I also wanted to write a new 
 compiler. It's just that D is a shitty language to work with because even 
 the stable version is a moving target and/or many features are 
 unspecified.


How is D1 a moving target?
Feb 05 2010
next sibling parent retard <re tard.com.invalid> writes:
Fri, 05 Feb 2010 03:20:35 -0800, Walter Bright wrote:


 retard wrote:

 I can easily come up with 100 other such features.


 
 Please do so, and submit them to bugzilla.


OK

 
 

 Some time ago I really
 wanted to write a wikibook about D. I also wanted to write a new
 compiler. It's just that D is a shitty language to work with because
 even the stable version is a moving target and/or many features are
 unspecified.


 
 How is D1 a moving target?


Bugfixes in specification make those programs break that had to rely on 
broken semantics.
Feb 05 2010
prev sibling parent reply grauzone <none example.net> writes:
Walter Bright wrote:

 retard wrote:

 I can easily come up with 100 other such features.


 
 Please do so, and submit them to bugzilla.


You know, the problem with Bugzilla is, that most entries simply remain 
unreplied. Especially when they inquire about strange language features 
or dark corner cases.


 

 Some time ago I really wanted to write a wikibook about D. I also 
 wanted to write a new compiler. It's just that D is a shitty language 
 to work with because even the stable version is a moving target and/or 
 many features are unspecified.


 
 How is D1 a moving target?


Nobody knows how D actually works. Due to the incomplete specification, 
it's like a blackbox. All you can do is to give dmd some code using 
under-specified features, and when dmd accepts it, people have to assume 
the program is correct.

Also, I have regressions in almost any dmd release. (I always have to 
change my code, or wait for later bug fixes. Sometimes the outcome is 
that a specific thing just wasn't supposed to work.)

Even more so, D1 seems like a dead horse, and D2 just again is a really 
fast moving target. Give us a stable language, Walter! And by stable, I 
don't just mean an arbitrary frozen "snapshot" of the language. It has 
to be stable, but alive. Other languages are also doing it without 
breaking backward compatibility to all existing programs.

I'm already hysterically laughing from the thought of an incompatible D3 
in some years.
Feb 05 2010
parent Walter Bright <newshound1 digitalmars.com> writes:
grauzone wrote:

 Walter Bright wrote:

 retard wrote:

 I can easily come up with 100 other such features.


 Please do so, and submit them to bugzilla.


 
 You know, the problem with Bugzilla is, that most entries simply remain 
 unreplied. Especially when they inquire about strange language features 
 or dark corner cases.


Being in Bugzilla means they will not be forgotten, and will eventually 
get addressed. All spec problems are answerable by anyone willing to 
make the effort, and supply a documentation patch.




 How is D1 a moving target?


 
 Nobody knows how D actually works. Due to the incomplete specification, 
 it's like a blackbox. All you can do is to give dmd some code using 
 under-specified features, and when dmd accepts it, people have to assume 
 the program is correct.


There's more that can be done than that - file the issue in bugzilla. If 
you want to go further, include a patch to the specification.



 Also, I have regressions in almost any dmd release. (I always have to 
 change my code, or wait for later bug fixes. Sometimes the outcome is 
 that a specific thing just wasn't supposed to work.)


It's true that sometimes bug fixes will cause other bugs, this isn't 
just a spec problem. It's a problem that the test suite isn't thorough 
enough.



 Even more so, D1 seems like a dead horse, and D2 just again is a really 
 fast moving target. Give us a stable language, Walter! And by stable, I 
 don't just mean an arbitrary frozen "snapshot" of the language. It has 
 to be stable, but alive. Other languages are also doing it without 
 breaking backward compatibility to all existing programs.


It's not possible to have a stable language that gets regular new 
features. Even innocuous new features risk breaking things in unexpected 
ways. Even just a new keyword.

Other languages do it by taking many years to fold in even very minor 
changes.
Feb 05 2010
prev sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
retard wrote:

 The funny thing about D is that if you start writing a book about it,
 there's a high desire to change the core features and add more of 


them in

 the community.


I have started writing a D book in June and have not desired to change 
much about the language. I did find the half-reference behavior of 
slices weird and voiced my opinion about it.

If you meant Andrei's book; he is not changing the language just because 
he is writing a book about it. The design of the language and the book 
happen together.

My book targets the Turkish speaking novice programmer, and I am sure is 
tainted by my C++ experience. D is an excellent language to teach 
programming with. There is very little cruft in the language when doing 
the simple things. There is very little to make novice mistakes with.


 It's just that D is a shitty language to work with because even
 the stable version is a moving target and/or many features are
 unspecified.


I did need to change my text only a few times, e.g. when constant-sized 
arrays became value types.

Shitty is in the eye of the beholder. Someone else may call C++ shitty 
just for the opposite reason: it is too stable. Years go by without any 
addition to the language. Even more years go by for the compiler vendors 
to catch up. That's not productive.

D is great because it is being designed openly by great programmers: the 
person with the longest C++ compiler writing experience, the person who 
has pushed C++ templates beyond their limits and introduced needs for 
stronger templates, many others who contribute to the language at 
various levels. Heck, even my naive voice has an effect on the language.

D2 obviously must stabilize before being useful; but it is great that it 
moves fast before that happens.

Ali
Feb 05 2010
next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-02-05 14:35:20 -0500, Ali ehreli <acehreli yahoo.com> said:


 D2 obviously must stabilize before being useful; but it is great that 
 it moves fast before that happens.


D2 is already useful for small scale projects. I wrote the system to 
manage license codes for my Mac shareware (Magic Launch) with D2. It's 
in production since January running as a CGI on my website, and is 
working great. My only wish in relation to that is that SafeD be more 
usable.


-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Feb 05 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Michel Fortin wrote:

 My only wish in relation to that is that SafeD be more 
 usable.


I know safe D isn't fully implemented, but can you say which missing 
part of it you need?
Feb 05 2010
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-02-05 15:22:44 -0500, Walter Bright <newshound1 digitalmars.com> said:


 Michel Fortin wrote:

 My only wish in relation to that is that SafeD be more usable.


 
 I know safe D isn't fully implemented, but can you say which missing 
 part of it you need?


First, I'd like to say that language itself isn't too bad. I think 
SafeD as currently implemented has the right design, except when it 
comes to passing delegates and functions as arguments to templates or 
functions. But I abandoned using this so it's not a pressing need for 
me currently. Still, I think that's an important issue to solve 
otherwise it'll be difficult to make std.algorithm safe and at the same 
time usable from unsafe code (as it relies heavily on predicates).

So basically in the implementation there's just one big annoyance for 
me right now (but the workaround is easy):
http://d.puremagic.com/issues/show_bug.cgi?id=3636

Most of the problems come from Phobos not being safe. I'm using a 
couple of things scattered in std.range, std.string, std.file, 
std.stdio, std.path, and to!X in std.conv.

So what's the plan? Should everything theoretically safe in Phobos be 
 trusted to avoid complains about unnecessary checks in programs that 
don't bother about safety? Or should we make things  safe and promote 
them to  trusted (for performance) only after a careful review? I'm a 
proponent of not making anything  trusted in Phobos until it has been 
reviewed and approved by someone else than the author.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Feb 05 2010
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Michel Fortin wrote:

 So what's the plan? Should everything theoretically safe in Phobos be 
  trusted to avoid complains about unnecessary checks in programs that 
 don't bother about safety? Or should we make things  safe and promote 
 them to  trusted (for performance) only after a careful review? I'm a 
 proponent of not making anything  trusted in Phobos until it has been 
 reviewed and approved by someone else than the author.


Every function in Phobos needs to be reviewed and tagged as safe, 
trusted or system as appropriate.
Feb 05 2010
next sibling parent reply strtr <strtr spam.com> writes:
Walter Bright Wrote:

 Every function in Phobos needs to be reviewed and tagged as safe, 
 trusted or system as appropriate.


I am sorry if this is totally stupid, but shouldn't it be possible for the
compiler to do this? addition to -profile maybe

It might also be interesting if the compiler were to generate the most
restrictive protection attributes for everything, which would still compile or
course ;)
Feb 05 2010
next sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
On Sat, 06 Feb 2010 01:43:27 +0100, strtr <strtr spam.com> wrote:


 Walter Bright Wrote:

 Every function in Phobos needs to be reviewed and tagged as safe,
 trusted or system as appropriate.


 I am sorry if this is totally stupid, but shouldn't it be possible for  
 the compiler to do this? addition to -profile maybe

 It might also be interesting if the compiler were to generate the most  
 restrictive protection attributes for everything, which would still  
 compile or course ;)


Theoretically possible, yes. However, that would require whole-program
analysis, which is not always possible.

-- 
Simen
Feb 05 2010
prev sibling parent dsimcha <dsimcha yahoo.com> writes:
== Quote from strtr (strtr spam.com)'s article

 Walter Bright Wrote:

 Every function in Phobos needs to be reviewed and tagged as safe,
 trusted or system as appropriate.


 I am sorry if this is totally stupid, but shouldn't it be possible for the


compiler to do this? addition to -profile maybe

 It might also be interesting if the compiler were to generate the most


restrictive protection attributes for everything, which would still compile or
course ;)

Actually, more generally a generate-attributes flag for the compiler might be a
pretty useful thing.  I have no idea how feasible this would be at an
implementation level, but it would definitely work at a theoretical level
(except
for  trusted, which needs to be checked manually).  It would spit out the same
source files, but with any attribute that would compile added.  For example, all
functions that would compile as pure would be marked pure.  All functions that
would compile as nothrow would be marked nothrow.  All unannotated member
functions that would compile as const would be marked inout (once inout is
implemented for member functions).  All function parameters that could be const
without breaking anything would be marked as such.  This assumes that noone
overloaded const and non-const versions of some member function to do
semantically
different things, but if they did they deserve what they get.
Feb 05 2010
prev sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2010-02-05 18:59:00 -0500, Walter Bright <newshound1 digitalmars.com> said:


 Michel Fortin wrote:

 So what's the plan? Should everything theoretically safe in Phobos be 
  trusted to avoid complains about unnecessary checks in programs that 
 don't bother about safety? Or should we make things  safe and promote 
 them to  trusted (for performance) only after a careful review? I'm a 
 proponent of not making anything  trusted in Phobos until it has been 
 reviewed and approved by someone else than the author.


 
 Every function in Phobos needs to be reviewed and tagged as safe, 
 trusted or system as appropriate.


But is it okay to label most of Phobos  safe knowing that it'll reduce 
performance? I was under the impression that we would want to make most 
of Phobos  trusted for performance.

Also, I'm now realizing that  safe might be difficult to add to many 
templates. For instance, this template function from std.range doesn't 
know if the functions it calls on the range (length, empty, popFront) 
are safe or not. Labeling it  safe will make it not work with unsafe 
ranges while not labeling it  safe will make it uncallable from safe 
functions (and making it trusted will make it blindly trust the range), 
neither of which is very compelling.

	size_t walkLength(Range)(Range range, size_t upTo = size_t.max)
	if (isInputRange!(Range))
	{
	    static if (hasLength!(Range))
	    {
	        return range.length;
	    }
	    else
	    {
	        size_t result;
	        for (; result < upTo && !range.empty; range.popFront) ++result;
	        return result;
	    }
	}


I'm starting to think that templates should inherit the  safe attribute 
from the context they're instantiated in, not from where they're 
defined. This would solve the above problem nicely as well as the 
problem of string predicates in std.algorithm:

	sort!"a < b"(array);
	// whether "a < b" needs to be safe depends on the context


-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Feb 06 2010
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Michel Fortin:

 I think SafeD as currently implemented has the right design, except
 when it comes to passing delegates and functions as arguments to
 templates or functions.


The less significant bit of the function/delegate pointer can be used to denote
safe/unsafe :o)

Bye,
bearophile
Feb 08 2010
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-02-08 14:31:06 -0500, bearophile <bearophileHUGS lycos.com> said:


 Michel Fortin:

 I think SafeD as currently implemented has the right design, except
 when it comes to passing delegates and functions as arguments to
 templates or functions.


 
 The less significant bit of the function/delegate pointer can be used 
 to denote safe/unsafe :o)


What would be the point?

The problem is when you have a safe function taking a delegate, like this:

	 safe void test(void delegate() run) {
		run();
	}

	void main() {
		test({ writeln("hello world"); });
	}

Here, the delegate literal is unsafe and you give it to a safe 
function. The compiler disallow test() from calling run() because it is 
unsafe. This is just too restricting. Do we really want to have to 
create two versions of test(), one with a safe delegate the other with 
an unsafe one?

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Feb 08 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
Michel Fortin:

 This is just too restricting. Do we really want to have to 
 create two versions of test(), one with a safe delegate the other with 
 an unsafe one?


What's the point of having safe code? If safe code can run unsafe code in a so
simple and clean way (with no casts, etc), then there's little point in having
safe annotations.

Extra notes:
- In some situations with a bit of flow analysis the compiler can avoid to test
the safe bit of the pointer.
- If the D compiler gets good at separating safe code from unsafe one at
compile time, then then GC might even move safe class instances in memory. I am
not sure.

Bye,
bearophile
Feb 08 2010
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-02-08 15:51:35 -0500, bearophile <bearophileHUGS lycos.com> said:


 What's the point of having safe code? If safe code can run unsafe code 
 in a so simple and clean way (with no casts, etc), then there's little 
 point in having safe annotations.


Safe functions are safe only when you give them safe arguments. Passing 
an unsafe delegate to a safe function is not much different from 
passing a pointer: both can cause memory corruption. But unsafe 
functions can give whatever pointer they want to a safe function, so 
why that restriction for delegates? When is that restriction helpful?

I think that restriction is not helpful and only gets in the way. But 
please show me otherwise.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Feb 08 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
Michel Fortin:

 But unsafe functions can give whatever pointer they want to a safe function,<


Can pointers be used in safe modules/functions?

Bye,
bearophile
Feb 08 2010
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-02-08 16:21:31 -0500, bearophile <bearophileHUGS lycos.com> said:


 Michel Fortin:

 But unsafe functions can give whatever pointer they want to a safe function,<


 
 Can pointers be used in safe modules/functions?


Yes. And object references too. And arrays. All those are pointers of 
some sort. You wouldn't go very far without them.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Feb 08 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Michel Fortin wrote:

 On 2010-02-08 16:21:31 -0500, bearophile <bearophileHUGS lycos.com> said:
 

 Michel Fortin:

 But unsafe functions can give whatever pointer they want to a safe 
 function,<


 Can pointers be used in safe modules/functions?


 
 Yes. And object references too. And arrays. All those are pointers of 
 some sort. You wouldn't go very far without them.


Pointers undergo significantly less control than arrays and object 
references.

Andrei
Feb 08 2010
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 Pointers undergo significantly less control than arrays and object 
 references.


Thanks Epona I've recently shown here a safer ranged pointer struct for D2.

Bye,
bearophile
Feb 08 2010
prev sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-02-08 17:20:21 -0500, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:


 Michel Fortin wrote:

 On 2010-02-08 16:21:31 -0500, bearophile <bearophileHUGS lycos.com> said:
 

 Michel Fortin:

 But unsafe functions can give whatever pointer they want to a safe function,<


 
 Can pointers be used in safe modules/functions?


 
 Yes. And object references too. And arrays. All those are pointers of 
 some sort. You wouldn't go very far without them.


 
 Pointers undergo significantly less control than arrays and object references.


Yes. But an unsafe function can still give a bad pointer to a safe 
function and have the safe function corrupt some memory.

The whole point is that you don't have a "safe pointer" type for giving 
only safe pointers to safe functions: a safe function will accept any 
pointer. The same should be true for delegates: an unsafe function 
should be able to call any delegate you feed it with. But only unsafe 
functions should be allowed to create an unsafe delegate in the first 
place.

It could be achieved simply by abolishing the  safe qualifier for 
variables of type delegate or function pointer and restricting  safe 
code so that it can only get the address of another  safe function.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Feb 08 2010
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Michel Fortin wrote:

 On 2010-02-08 17:20:21 -0500, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> said:
 

 Michel Fortin wrote:

 On 2010-02-08 16:21:31 -0500, bearophile <bearophileHUGS lycos.com> 
 said:


 Michel Fortin:

 But unsafe functions can give whatever pointer they want to a safe 
 function,<


 Can pointers be used in safe modules/functions?


 Yes. And object references too. And arrays. All those are pointers of 
 some sort. You wouldn't go very far without them.


 Pointers undergo significantly less control than arrays and object 
 references.


 
 Yes. But an unsafe function can still give a bad pointer to a safe 
 function and have the safe function corrupt some memory.


This is irrelevant because once you have one unsafe function, you have 
one unsafe program.

Andrei
Feb 08 2010
prev sibling parent reply retard <re tard.com.invalid> writes:
Fri, 05 Feb 2010 11:35:20 -0800, Ali Çehreli wrote:


 I did need to change my text only a few times, e.g. when constant-sized
 arrays became value types.


You can easily check from the changelogs what happened between dmd 1.00 
and 1.056. Quite a lot changed. You could even write a 200 page book 
about the changes.


 D is great because it is being designed openly by great programmers: the
 person with the longest C++ compiler writing experience, the person who
 has pushed C++ templates beyond their limits and introduced needs for
 stronger templates, many others who contribute to the language at
 various levels. Heck, even my naive voice has an effect on the language.


Heh, whatever. But the problem is, when I write a book about C, C++, 
Java, or some other language, I do know how it behaves. I can write 
informal programming books for novices or exact academic text with full 
description of the grammar rules, type system, and e.g. denotational or 
operational semantics. A D book is like a c++0x, Java7 or Haskell 2010 
book - you constantly need to update it to reflect the changes in the 
next spec update.

Now with D this isn't the case. I have to participate in the spec writing 
process no matter what I do. I do know how lazily Walter responds to 
queries and I do know that even though many have complained about 
semantics of the protection attributes in class inheritance several times 
during the past 10 years, nothing has changed. I don't want to write 
books that say

1. Classes
----------

1.1. Inheritance
----------------

Classes in D can inherit from a base class. [snip] The syntax below shows 
how to do this:

class {classname} : {protection-attr} {baseclassname} {
}

  {classname} == name of the new class, represents the type name

  {baseclassname} == name of the base class

  {protection-attr} == perhaps one of these {public|protected|package|
private} - I have no effing clue what this does and neither does anyone 
else but isn't this a cool feature that somehow proves that D is very 
practical language and also implementing your own compiler is so damn easy
Feb 05 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
retard wrote:

   {protection-attr} == perhaps one of these {public|protected|package|
 private} - I have no effing clue what this does


It actually does the same thing as it does in C++ (with the addition of 
package).
Feb 05 2010
next sibling parent reply retard <re tard.com.invalid> writes:
Fri, 05 Feb 2010 13:24:44 -0800, Walter Bright wrote:


 retard wrote:

   {protection-attr} == perhaps one of these {public|protected|package|
 private} - I have no effing clue what this does


 
 It actually does the same thing as it does in C++ (with the addition of
 package).


I see. I only noticed now that dmd actually does enforce this rule in 
some cases. Unfortunately the rule is checked only statically when it can 
be checked. If you access the object via base class or interface type 
reference, a runtime check is not made unlike in c++.
Feb 05 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
retard wrote:

 Fri, 05 Feb 2010 13:24:44 -0800, Walter Bright wrote:
 

 retard wrote:

   {protection-attr} == perhaps one of these {public|protected|package|
 private} - I have no effing clue what this does


 It actually does the same thing as it does in C++ (with the addition of
 package).


 
 I see. I only noticed now that dmd actually does enforce this rule in 
 some cases. Unfortunately the rule is checked only statically when it can 
 be checked. If you access the object via base class or interface type 
 reference, a runtime check is not made unlike in c++.


There must be some misunderstanding here. There are no runtime access 
checks in C++, it is all done statically at compile time.
Feb 05 2010
parent reply retard <re tard.com.invalid> writes:
Fri, 05 Feb 2010 16:03:22 -0800, Walter Bright wrote:


 retard wrote:

 Fri, 05 Feb 2010 13:24:44 -0800, Walter Bright wrote:
 

 retard wrote:

   {protection-attr} == perhaps one of these
   {public|protected|package|
 private} - I have no effing clue what this does


 It actually does the same thing as it does in C++ (with the addition
 of package).


 
 I see. I only noticed now that dmd actually does enforce this rule in
 some cases. Unfortunately the rule is checked only statically when it
 can be checked. If you access the object via base class or interface
 type reference, a runtime check is not made unlike in c++.


 
 There must be some misunderstanding here. There are no runtime access
 checks in C++, it is all done statically at compile time.


Thanks. It seems I have been testing this with a buggy c++ compiler or 
can't remember what was the problem previously. I now tried with gcc 
4.4.3 and this is how D and C++ differ:

---

class Foo {
  public:
  void bar() {}
};

class Bar : private Foo {
};

int main() {
  Foo *a = new Bar();
  a->bar();
}

test.cpp: In function ‘int main()’:
test.cpp:10: error: ‘Foo’ is an inaccessible base of ‘Bar’

---

module m1;

class Foo {
  public void bar() {}
}

class Bar : private foo {
}

module m2;
import m1;

void main() {
  Foo a = new Bar();
  a.bar();
}

// compiles and runs just fine
// Changing the 'Foo a = ...' into 'Bar a = ...' makes this an error
Feb 05 2010
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
retard wrote:

 Fri, 05 Feb 2010 16:03:22 -0800, Walter Bright wrote:
 

 retard wrote:

 Fri, 05 Feb 2010 13:24:44 -0800, Walter Bright wrote:


 retard wrote:

   {protection-attr} == perhaps one of these
   {public|protected|package|
 private} - I have no effing clue what this does


 It actually does the same thing as it does in C++ (with the addition
 of package).


 I see. I only noticed now that dmd actually does enforce this rule in
 some cases. Unfortunately the rule is checked only statically when it
 can be checked. If you access the object via base class or interface
 type reference, a runtime check is not made unlike in c++.


 There must be some misunderstanding here. There are no runtime access
 checks in C++, it is all done statically at compile time.


 
 Thanks. It seems I have been testing this with a buggy c++ compiler or 
 can't remember what was the problem previously. I now tried with gcc 
 4.4.3 and this is how D and C++ differ:
 
 ---
 
 class Foo {
   public:
   void bar() {}
 };
 
 class Bar : private Foo {
 };
 
 int main() {
   Foo *a = new Bar();
   a->bar();
 }
 
 test.cpp: In function ‘int main()’:
 test.cpp:10: error: ‘Foo’ is an inaccessible base of ‘Bar’
 
 ---
 
 module m1;
 
 class Foo {
   public void bar() {}
 }
 
 class Bar : private foo {
 }
 
 module m2;
 import m1;
 
 void main() {
   Foo a = new Bar();
   a.bar();
 }
 
 // compiles and runs just fine


That's a bug in dmd. It should behave like the C++ does.


 // Changing the 'Foo a = ...' into 'Bar a = ...' makes this an error
Feb 05 2010
parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
Walter Bright wrote:

 retard wrote:

 module m1;

 class Foo {
   public void bar() {}
 }

 class Bar : private foo {
 }

 module m2;
 import m1;

 void main() {
   Foo a = new Bar();
   a.bar();
 }

 // compiles and runs just fine


 That's a bug in dmd. It should behave like the C++ does.


It would be different from C++ if everything were in the same module, right?

If I understand it correctly, private is not honored for the code in the 
same module. Is that for all uses of private?

Ali
Feb 05 2010
parent Walter Bright <newshound1 digitalmars.com> writes:
Ali Çehreli wrote:

 It would be different from C++ if everything were in the same module, 
 right?


Right.


 If I understand it correctly, private is not honored for the code in the 
 same module. Is that for all uses of private?


Yes.
Feb 05 2010
prev sibling next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
retard wrote:

 // compiles and runs just fine


http://d.puremagic.com/issues/show_bug.cgi?id=3774
Feb 05 2010
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2/6/10 01:25, retard wrote:

 Fri, 05 Feb 2010 16:03:22 -0800, Walter Bright wrote:


 retard wrote:

 Fri, 05 Feb 2010 13:24:44 -0800, Walter Bright wrote:


 retard wrote:

    {protection-attr} == perhaps one of these
    {public|protected|package|
 private} - I have no effing clue what this does


 It actually does the same thing as it does in C++ (with the addition
 of package).


 I see. I only noticed now that dmd actually does enforce this rule in
 some cases. Unfortunately the rule is checked only statically when it
 can be checked. If you access the object via base class or interface
 type reference, a runtime check is not made unlike in c++.


 There must be some misunderstanding here. There are no runtime access
 checks in C++, it is all done statically at compile time.


 Thanks. It seems I have been testing this with a buggy c++ compiler or
 can't remember what was the problem previously. I now tried with gcc
 4.4.3 and this is how D and C++ differ:

 ---

 class Foo {
    public:
    void bar() {}
 };

 class Bar : private Foo {
 };

 int main() {
    Foo *a = new Bar();
    a->bar();
 }

 test.cpp: In function ‘int main()’:
 test.cpp:10: error: ‘Foo’ is an inaccessible base of ‘Bar’

 ---

 module m1;

 class Foo {
    public void bar() {}
 }

 class Bar : private foo {
 }

 module m2;
 import m1;

 void main() {
    Foo a = new Bar();
    a.bar();
 }

 // compiles and runs just fine
 // Changing the 'Foo a = ...' into 'Bar a = ...' makes this an error


Is there any use to make the base class non public in D? I mean you will 
also make the Object part inaccessible. Another thing to remove in D2?
Feb 06 2010
parent Walter Bright <newshound1 digitalmars.com> writes:
Jacob Carlborg wrote:

 Is there any use to make the base class non public in D? I mean you will 
 also make the Object part inaccessible. Another thing to remove in D2?


It's possible it's a useless feature. Apparently, nobody has found a use 
for it yet in D.
Feb 06 2010
prev sibling parent strtr <strtr spam.com> writes:
Walter Bright Wrote:


 retard wrote:

   {protection-attr} == perhaps one of these {public|protected|package|
 private} - I have no effing clue what this does


 
 It actually does the same thing as it does in C++ (with the addition of 
 package).


I didn't know I could protect a superclass like that, where can I read about
this?
Feb 05 2010