Re: About switch case statements...
Derek Parnell wrote: On Mon, 16 Nov 2009 14:34:37 +0100, Don wrote: bearophile wrote: Don: (providing that empty fall-through case statements remain valid; disallowing them would be really annoying). What's bad about forcing people to write: case A, B, C: Instead of: case A: case B: case C: ? Bye, bearophile (1) case A, B, C: implies a relationship between A, B, and C, which might not exist. They may have nothing in common. (2) it's an extremely common coding style in C, C++. (3) it's more difficult to read. (1) case A: case B: case C: implies that there is no relationship between A,B, and C, but which might actually exist. They may have something common. Yes, of course! In which situation, you use case A, B, C: I'm not arguing AGAINST that syntax, which already exists! Your other two comments aren't worth responding to.
Re: Ansi vs Unicode API
Steven Schveighoffer wrote: On Mon, 16 Nov 2009 16:07:56 -0500, Walter Bright newshou...@digitalmars.com wrote: Backward compatibility doesn't mean that the old systems have to support new features. It just means that the old features continue to work on the new systems. I have a lot of software built for Win95 that still works fine g. Even the DOS programs still work. Your argument was about building programs on MacOS 10.5 that crash on 10.4. That's like building programs on Windows XP and expecting them to run flawlessly on Windows 98. Although, I will say, having a Hello World executable throw a bus error is a little over the top in breaking backwards compatibility :) -Steve Apple is a bit over the top. It really seems they don't give a damn about backwards compatibility. Yet they've stayed in business. I think there's a lesson in that.
Re: static interface
Bill Baxter wrote:
On Mon, Nov 16, 2009 at 9:25 AM, Leandro Lucarella llu...@gmail.com wrote:
This topic is actually very close to a discussion last week about
retrieving error messages from failures of __traits(compiles, xxx).
My question is: is it really that much of an improvement?
I've rearranged your code to see the equivalent snippets side-by-side:
static interface InputRange(T) {
bool empty();
T front();
void popFront();
}
template isInputRange(R)
{
enum bool isInputRange = is(typeof(
{
R r;
if (r.empty) {}
r.popFront;
auto h = r.front;
}()));
}
There's actually not that much difference here. Of course we would
like several general improvements that have been discussed before:
1) some kind of template 'this' so we don't have to repeat the template name.
2) something better than is(typeof()) (or __traits(compiles, ...)) to
check if code is ok. [hoping for meta.compiles(...)]
In some ways the current code is better, because it actually checks if
a construct works or not, rather than requiring a specific function
signature. Whether the code will work is really the minimal
restriction you can place on the interface. A specific may be too
tight. For instance, above you don't really care if empty returns
bool or not. Just if you can test it in an if.
Another, related way in which the current code is better is that it
doesn't care whether empty, front, and popFront are functions or
variables. As we know, the standard trick for infinite ranges is to
declare empty as an enum, not a function.
BTW, I find it interesting that I see meta.* being mentioned in
discussions and even used in code snippets all over the NG these days.
It seems to be a popular proposal. I hope it gets implemented too. :)
-Lars
Re: About switch case statements...
On Tue, 17 Nov 2009 09:05:48 +0100, Don wrote: Your other two comments aren't worth responding to. I apologize. I also don't know what I said to offend you. I've taken steps to make sure it doesn't happen again. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: Making alloca more safe
On Mon, 16 Nov 2009 12:48:51 -0800, Walter Bright newshou...@digitalmars.com wrote: If you've got a system that relies on the software continuing to function after an unexpected null seg fault, you have a VERY BADLY DESIGNED and COMPLETELY UNSAFE system. I really cannot emphasize this enough. I have an example of such a software: http://www.steinberg.net/en/products/audiopostproduction_product/nuendo4.html It loads third-party plugins into the host process's address space, an consequently it may fail at any moment. The software's design is not the best ever but it gives the user last chance to save his work in case of fatal error. This feature has saved my back a couple of times. P.S. I worked for Boeing for years on flight critical systems. Normally I eschew credentialism, but I feel very strongly about this issue and wish to point out that my knowledge on this is based on decades of real world experience by aviation companies who take this issue extremely seriously. Then, instead of sticking with Windows and the likes, you may want to think about porting dmd to a more serious environment specifically designed for developing such systems. What about a real-time microkernel OS like this one: http://www.qnx.com/products/neutrino_rtos/ ?
Re: Should the comma operator be removed in D2?
Robert Jacques wrote:
On Tue, 17 Nov 2009 00:06:27 -0500, Yigal Chripun yigal...@gmail.com
wrote:
Robert Jacques wrote:
On Mon, 16 Nov 2009 17:53:45 -0500, Stewart Gordon
smjg_1...@yahoo.com wrote:
dsimcha wrote:
snip
Axe. Looks like the only things it's good for are making code
undreadable and
abusing for loop syntax to...
Make code unreadable.
snip
Suppose you want the increment of a for loop to change two variables
in parallel. I don't call that making code unreadable.
Stewart.
Yes the classic use case of the comma operator is multi-variable
declarations/increments in a for loop.
This was argued before and as I and others said before, this is *not*
a use case for the comma separator.
e.g.
for (int a = 0, b = 1; condition(); a++, b++) {...}
int a = 0, b = 1 // this is a declaration and not an expression
a++, b++ // isn't assigned to any variable and can be treated as a tuple
the only use case that will break is if the two increments are
dependent on the order (unless tuples are also evaluated from left to
right):
e.g.
a + 5, b + a //
I doubt it very much that anyone ever uses this, it's too unreadable
to be useful.
However, I imagine tuple(a++,b++) would have some overhead, which is
exactly what someone is trying to avoid by using custom for loops.
Personally, I like using a..b = tuple(a,b), since it also solves the
multi-dimensional slicing and mixed indexing and slicing problems.
Zero overhead. Tuples are flat compile-time entities.
Re: Making alloca more safe
Max Samukha wrote: On Mon, 16 Nov 2009 12:48:51 -0800, Walter Bright newshou...@digitalmars.com wrote: If you've got a system that relies on the software continuing to function after an unexpected null seg fault, you have a VERY BADLY DESIGNED and COMPLETELY UNSAFE system. I really cannot emphasize this enough. I have an example of such a software: http://www.steinberg.net/en/products/audiopostproduction_product/nuendo4.html It loads third-party plugins into the host process's address space, an consequently it may fail at any moment. The software's design is not the best ever but it gives the user last chance to save his work in case of fatal error. This feature has saved my back a couple of times. I suppose nobody much cares if it writes out a corrupted audio file. People care very much if their airplane suddenly dives into the ground. Be that as it may, it is certainly possible to catch seg faults in an exception handler and write files out. That would be an unacceptable behavior, though, in a system that needs to be safe. P.S. I worked for Boeing for years on flight critical systems. Normally I eschew credentialism, but I feel very strongly about this issue and wish to point out that my knowledge on this is based on decades of real world experience by aviation companies who take this issue extremely seriously. Then, instead of sticking with Windows and the likes, you may want to think about porting dmd to a more serious environment specifically designed for developing such systems. What about a real-time microkernel OS like this one: http://www.qnx.com/products/neutrino_rtos/ ? dmd targets Windows because that's where probably half the programmers are. I'd certainly like to do embedded systems, too, but realistically that's going to be the purview of gdc or ldc.
Re: XMLP
F:\DLang\DEx\D2ExF:\laguangeD\dlang\dtwo\dmd\windows\bin\dmd anoy.d object.d: Error: module object cannot read file 'object.d' F:\DLang\DEx\D2Ex What does this mean?I can compile all my d2 programs just use: dmd *.d under any path: I remember getting that same message compiling with DMD. Especially if I had played around with the D compiler sc.ini file trying to compile Tango from source with the latest D compiler. What it means is the compiler tries to search its imports paths, which is set in the sc.ini file with -I and can be overridden in the command line. I then searched for files called object.* in src and imports and pointed the -I paths there to see what would happen. After it goes away I forget about it. My latest sc.ini says. DFLAGS=-...@p%\..\..\src\phobos -...@p%\..\..\src\druntime\import Now there is a file called object.di inside ..\src\druntime\import. Nowadays I just take the plain vanilla setup, keeping seperate distribution trees for phobos dmd dmd2, and dmd tango. My basic windows dmd setup. When I test with a new version of dmd2, say 2.036, I replace an entire C:\D\dmd2 folder with the new distribution zip. I run the command prompt cmd.exe, CD to the source directory where I have a build*.bat files. The batch files run the dmd compiler by calling it with its full path C:\D\dmd2\windows\bin\dmd.exe , and usually the dmd2 compiler figures out the standard import locations and libraries from its relative path using the command line invocation argument. If I am using tango I have downloaded the current approved windows binary release complete with matching dmd 1.xxx version. Since it also works out of the box, my tango batch path is C:\D\tango\bin\dmd.exe, and the sc.ini therein does tango paths. If I want a convenience of typing dmd directly , I set up batch files to configure the current PATH. REM StartMyD2Env.bat in C:\bin\codeblocks\ PATH=c:\D\dmd2\windows\bin;c:\D\dm\bin;%windir%\system32;%windir%;%windir% \system32\wbem start D2 environment Codeblocks.exe and run it from a shortcut cmd.exe /K c:\bin\StartMyD2Env.bat Otherwise every old dmd.exe and dll, and other developments systems in forgotten folders in my system path want to get in on the act. -- michael *^^*
Re: String Mixins
On Mon, Nov 16, 2009 at 3:42 PM, Travis Boucher
boucher.tra...@gmail.com wrote:
I've been playing with string mixins, and they are very powerful.
One thing I can't figure out is what exactly can and cannot be evaluated at
compile time.
For example:
char[] myFunc1() {
return int a = 1;;
}
char[] myFunc2() {
char[] myFunc3() {
return int b = 2;;
}
return myFunc3();
}
void main() {
mixin(myFunc1());
mixin(myFunc2());
}
myFunc1() can be used as a string mixin.
myFunc2() can't be.
I'm sure there are other things that I'll run into, but I figure there is
some simple set of rules of what can and can't be used as a string mixin.
Unfortunately there aren't any easy rules to go by. If it doesn't
work CTFE, and a bug hasn't already been filed, then you could file a
bug, especially if you find the problem blocking your progress.
However, at this point there are plenty of things that don't work that
are known and being targeted by Don already. So a flood of this and
that don't work in CTFE bug reports may not be so useful just yet.
Anyway, just be thankful that it now at least tells you what can't be
evaluated. That's a vast improvement over the old days when the
compiler would just give a generic error message about CTFE and leave
you guessing about which line it didn't like!
--bb
Re: Should the comma operator be removed in D2?
On Mon, 16 Nov 2009 18:57:13 -0600, Ellery Newcomer wrote:
Bill Baxter wrote:
Note that if comma-as-sequencer was removed, and repurposed as a tuple
literal (with a,b making a tuple), and if we specify that tuple
elements are evaluated in order, then I think this would work as a
replacement for the current comma operator:
(expr1,expr2,expr3)[$-1]
But the nice thing is you can get the effect of a comma operator that
evaluates to the value of any expression in the sequence, just using
different indices.
Not sure how odious people would find forcing an order of eval on
tuples, though.
I wouldn't mind.
you'd also have to swap the precedence of assignment and comma, or
a,b = b,a;
isn't going to do anything useful. But then you can't have
foo(a = b);
unless the entire argument list is a tuple. But then you'd have to
change {something or another} or you can't have nested tuples.
backing up, assuming you don't allow unpareth'd tuples, then what is
( exp )
? Is it a tuple, or a scalar?
I think my personal preference at the moment would be to have tuples of
the form
(, exp , exp ... )
In the context of a for-loop, you don't care what the value is, so it
would work as a tuple as-is. The tuple itself would be the value:
for(; i10; ++i,++j) // just works
for should be a special case
I read about it in the D Programming Language rough cut draft.
2.4.1 The Comma Operator
Expressions separated by commas are evaluated in sequence. The result of
the entire expression is the result of the rightmost expression. Example:
int a = 5;
int b = 10;20
int c = ( a = b, b = 7, 8);
After executing the snippet above, the values of a, b, and c are 10, 7,
and 8 respectively.
Thats all there is!
But the expressions may be as complex as you like?
Its syntactic sugar folks.
Nowhere says you absolutely need it to generate a particular compiled
code.
But where is the harmful example?
Some may want to remove it , in case it can be better used in a future
more useful role, or for enforcing source code readability standards.
But right now, its in the book!
--
michael *^^*
Re: XMLP
Michael Rynn Wrote: My latest sc.ini says. DFLAGS=-...@p%\..\..\src\phobos -...@p%\..\..\src\druntime\import -- michael *^^* sc.ini for DMD2.036: [Version] version=7.51 Build 020 [Environment] LIB=%...@p%\..\lib;%...@p%\..\..\..\dsss\lib DFLAGS=-...@p%\..\..\src\phobos -...@p%\..\..\src\druntime\import -...@p%\..\..\..\dsss\include\d -...@p%\..\..\import linkcm...@p%\link.exe D2 folder structure: \Dlang\ \Dlang\dtwo \Dlang\dtwo\dmd\windows\bin \Dlang\dtwo\dmd\import\dfl \Dlang\dtwo\dsss\bin D1,Tango: \Dlang\tangoD\ \Dlang\tangoD\dmd\windows\bin \Dlang\tangod\dsss\bin The system environment path only includes d2 configuration: \Dlang\dtwo\dmd\windows\bin \Dlang\dtwo\dsss\bin So was I missing something? Thank you so much for your help!
Re: String Mixins
Bill Baxter wrote:
On Mon, Nov 16, 2009 at 3:42 PM, Travis Boucher
boucher.tra...@gmail.com wrote:
I've been playing with string mixins, and they are very powerful.
One thing I can't figure out is what exactly can and cannot be evaluated at
compile time.
For example:
char[] myFunc1() {
return int a = 1;;
}
char[] myFunc2() {
char[] myFunc3() {
return int b = 2;;
}
return myFunc3();
}
void main() {
mixin(myFunc1());
mixin(myFunc2());
}
myFunc1() can be used as a string mixin.
myFunc2() can't be.
I'm sure there are other things that I'll run into, but I figure there is
some simple set of rules of what can and can't be used as a string mixin.
Unfortunately there aren't any easy rules to go by. If it doesn't
work CTFE, and a bug hasn't already been filed, then you could file a
bug, especially if you find the problem blocking your progress.
However, at this point there are plenty of things that don't work that
are known and being targeted by Don already. So a flood of this and
that don't work in CTFE bug reports may not be so useful just yet.
Anyway, just be thankful that it now at least tells you what can't be
evaluated. That's a vast improvement over the old days when the
compiler would just give a generic error message about CTFE and leave
you guessing about which line it didn't like!
--bb
Don responded in D.learn. The examples above should work on recent
(=1.047) DMD, I happen to be using gdc with 1.020. Right now I am just
seeing how far I can push it and how weird I can make code that works.
Re: String Mixins
On Mon, Nov 16, 2009 at 8:44 PM, Travis Boucher
boucher.tra...@gmail.com wrote:
Bill Baxter wrote:
On Mon, Nov 16, 2009 at 3:42 PM, Travis Boucher
boucher.tra...@gmail.com wrote:
I've been playing with string mixins, and they are very powerful.
One thing I can't figure out is what exactly can and cannot be evaluated
at
compile time.
For example:
char[] myFunc1() {
return int a = 1;;
}
char[] myFunc2() {
char[] myFunc3() {
return int b = 2;;
}
return myFunc3();
}
void main() {
mixin(myFunc1());
mixin(myFunc2());
}
myFunc1() can be used as a string mixin.
myFunc2() can't be.
I'm sure there are other things that I'll run into, but I figure there is
some simple set of rules of what can and can't be used as a string mixin.
Unfortunately there aren't any easy rules to go by. If it doesn't
work CTFE, and a bug hasn't already been filed, then you could file a
bug, especially if you find the problem blocking your progress.
However, at this point there are plenty of things that don't work that
are known and being targeted by Don already. So a flood of this and
that don't work in CTFE bug reports may not be so useful just yet.
Anyway, just be thankful that it now at least tells you what can't be
evaluated. That's a vast improvement over the old days when the
compiler would just give a generic error message about CTFE and leave
you guessing about which line it didn't like!
--bb
Don responded in D.learn. The examples above should work on recent
(=1.047) DMD, I happen to be using gdc with 1.020. Right now I am just
seeing how far I can push it and how weird I can make code that works.
Makes more sense now. I *thought* nested functions had been fixed to
work recently.
The list Don pointed you to is a good guideline, but still you can
expect to find other things not on that list that the compiler can't
handle. For instance, another big category not mentioned there is C
functions. You can't call C functions at compile time.
--bb
Re: About switch case statements...
Walter Bright wrote:
Don wrote:
That's not fall-through, one case is *inside* the 'if' clause of
another one!! Wow. Do you really want to encourage that sort of thing?
I think it's more the #if that obfuscates the code. After long
experience with #if, I really don't like it, which is why I adamantly
resist having fine-grained conditional compilation in D.
I'm used to that. If you take out the #if, it's still wierd. That one
really ought to be a goto. It's the presence of the 'else' in particular:
case A:
if (xxx)
{
case B:
yyy;
}
else
{
zzz;
}
break;
I had to read it several times before I could make sense of it. Although
the zzz; looks like it's part of the B case, it's only part of the A case.
An oddity is that this compiles:
switch(x) {
case 1:
if (x10)
Lcase2:
writefln(yyy);
else
writefln(zzz);
break;
}
and so does this:
switch(x) {
case 1:
if (x10)
case 2:
writefln(yyy);
}
but this doesn't:
switch(x) {
case 1:
if (x10)
case 2:
writefln(yyy);
else
writefln(zzz);
break;
}
Re: String Mixins
Travis Boucher wrote: Bill Baxter wrote: On Mon, Nov 16, 2009 at 3:42 PM, Travis Boucher boucher.tra...@gmail.com wrote: I've been playing with string mixins, and they are very powerful. One thing I can't figure out is what exactly can and cannot be evaluated at compile time. I'm sure there are other things that I'll run into, but I figure there is some simple set of rules of what can and can't be used as a string mixin. Don responded in D.learn. The examples above should work on recent (=1.047) DMD, I happen to be using gdc with 1.020. Right now I am just seeing how far I can push it and how weird I can make code that works. Great; saw you reposted and got your answers on D.learn. Good luck with your further D adventures on FreeBSD*! (* if I remember correctly your intro post said that's your platform.) Justin
Going from CTFE-land to Template-land
Currently this doesn't work, because the CTFE function doesn't know
that it's running compile-time:
int templ_incr(int x)() {
return x+1;
}
int ctfe_incr(int x) {
return templ_incr!(x);
}
Seems common to write a function that you know is only intended to be
used compile-time.
But it can't compile because the compiler doesn't know you only plan
to call it at compile-time.
Is something version(__ctfe) might help with? E.g.
version(__ctfe) {
// only allow cfte_incr to be called at compile-time so it can use templates
int ctfe_incr(int x) {
return templ_incr!(x);
}
}
Or is there something more fundamental preventing CTFE funcs from
instantiating templates?
--bb
Re: Going from CTFE-land to Template-land
On Tue, 17 Nov 2009 08:14:55 -0500, Bill Baxter wbax...@gmail.com wrote:
Currently this doesn't work, because the CTFE function doesn't know
that it's running compile-time:
int templ_incr(int x)() {
return x+1;
}
int ctfe_incr(int x) {
return templ_incr!(x);
}
Seems common to write a function that you know is only intended to be
used compile-time.
But it can't compile because the compiler doesn't know you only plan
to call it at compile-time.
Is something version(__ctfe) might help with? E.g.
version(__ctfe) {
// only allow cfte_incr to be called at compile-time so it can use
templates
int ctfe_incr(int x) {
return templ_incr!(x);
}
}
Or is there something more fundamental preventing CTFE funcs from
instantiating templates?
I think it may be a valid point, but it also may be a case of factoring.
Do you have a real example? In the one you posted, you can trivially
rewrite
ctfe_incr(x);
as
templ_incr!(x)(); // not sure if parens are optional there...
or trivially rewrite ctfe_incr as:
int ctfe_incr(int x) {
return x + 1;
}
A real example would go a long way in furthering the cause...
-Steve
Re: Going from CTFE-land to Template-land
On Tue, Nov 17, 2009 at 5:28 AM, Steven Schveighoffer
schvei...@yahoo.com wrote:
On Tue, 17 Nov 2009 08:14:55 -0500, Bill Baxter wbax...@gmail.com wrote:
Currently this doesn't work, because the CTFE function doesn't know
that it's running compile-time:
int templ_incr(int x)() {
return x+1;
}
int ctfe_incr(int x) {
return templ_incr!(x);
}
Seems common to write a function that you know is only intended to be
used compile-time.
But it can't compile because the compiler doesn't know you only plan
to call it at compile-time.
Is something version(__ctfe) might help with? E.g.
version(__ctfe) {
// only allow cfte_incr to be called at compile-time so it can use
templates
int ctfe_incr(int x) {
return templ_incr!(x);
}
}
Or is there something more fundamental preventing CTFE funcs from
instantiating templates?
I think it may be a valid point, but it also may be a case of factoring. Do
you have a real example? In the one you posted, you can trivially rewrite
ctfe_incr(x);
as
templ_incr!(x)(); // not sure if parens are optional there...
or trivially rewrite ctfe_incr as:
int ctfe_incr(int x) {
return x + 1;
}
A real example would go a long way in furthering the cause...
For instance there's a handy Format!(A...) template in std.metastrings.
But it works on template arguments. So you can't call it from a CTFE function.
Though, there the correct solution is probably rewrite Format!() as a
CTFE function.
I don't really know if this is a fundamentally a limitation or not.
But I would like to why not if it is not a problem.
It just seems like an artificial barrier. If I prefer to write
something as a template seems like I should be able to. Perhaps this
is just something that should become an Effective D tip: always prefer
CTFE over templates where possible. Templates also have the
disadvantage of bloating up your binaries.
A related thing is the inability to effectively use pragma(msg, ...)
inside a ctfe function. (It's related in the sense that if you
*could* instantiate a template from CTFE then you could make a
template that calls pragma(msg,...) to print something useful).
--bb
Re: static interface
Bill Baxter, el 16 de noviembre a las 15:42 me escribiste:
On Mon, Nov 16, 2009 at 9:25 AM, Leandro Lucarella llu...@gmail.com wrote:
This topic is actually very close to a discussion last week about
retrieving error messages from failures of __traits(compiles, xxx).
My question is: is it really that much of an improvement?
I've rearranged your code to see the equivalent snippets side-by-side:
static interface InputRange(T) {
bool empty();
T front();
void popFront();
}
template isInputRange(R)
{
enum bool isInputRange = is(typeof(
{
R r;
if (r.empty) {}
r.popFront;
auto h = r.front;
}()));
}
There's actually not that much difference here. Of course we would
like several general improvements that have been discussed before:
1) some kind of template 'this' so we don't have to repeat the template name.
2) something better than is(typeof()) (or __traits(compiles, ...)) to
check if code is ok. [hoping for meta.compiles(...)]
In some ways the current code is better, because it actually checks if
a construct works or not, rather than requiring a specific function
signature. Whether the code will work is really the minimal
restriction you can place on the interface. A specific may be too
tight. For instance, above you don't really care if empty returns
bool or not. Just if you can test it in an if.
I think one could argue if being more restrictive is actually good or bad.
Being more restrictive cold lead to less errors. Maybe if a struct empty()
method returns, say, a pointer, I don't want to think it is *really*
a range. Maybe that method is doing a lot of work and removing stuff, and
then returning a pointer to some removed stuff. Anyway, I'm not saying
that that couldn't happen even if empty() return bool (that's a risk when
duck-typing, always :), I'm just saying I'm not so sure that being more
restrictive is really a *bad thing*.
And about what's nice or ugly, I agree the current way of doing stuff is
not too bad, there are a few details that are not *that* nice. But with
duck-typing I think the same that with tuples: those little details makes
you feel that D doesn't support the concept so well, and make people
resistant to use them. When something feels natural in a language, you use
it all the time, for me, the current way to do tuples and duck-typing
looks very artificial and harder than it should.
But in terms of functionality it seems we cover pretty much everything
static interface gives you.
I know that, I started this proposal just saying that =) Again, this
proposal is about what I say in the previous paragraphs.
--
Leandro Lucarella (AKA luca) http://llucax.com.ar/
--
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
--
Be nice to nerds
Chances are you'll end up working for one
Re: static interface
Lars T. Kyllingstad, el 17 de noviembre a las 09:54 me escribiste:
In some ways the current code is better, because it actually checks if
a construct works or not, rather than requiring a specific function
signature. Whether the code will work is really the minimal
restriction you can place on the interface. A specific may be too
tight. For instance, above you don't really care if empty returns
bool or not. Just if you can test it in an if.
Another, related way in which the current code is better is that it
doesn't care whether empty, front, and popFront are functions or
variables. As we know, the standard trick for infinite ranges is to
declare empty as an enum, not a function.
Is not that hard to write:
bool empty() { return false; }
instead of
enum bool empty = false;
BTW, I find it interesting that I see meta.* being mentioned in
discussions and even used in code snippets all over the NG these
days. It seems to be a popular proposal. I hope it gets implemented
too. :)
We all do ;)
--
Leandro Lucarella (AKA luca) http://llucax.com.ar/
--
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
--
FALTAN 325 DIAS PARA LA PRIMAVERA
-- Crónica TV
Re: static interface
Jesse Phillips, el 16 de noviembre a las 19:14 me escribiste:
Leandro Lucarella Wrote:
The problem is regular interfaces provide dynamic dispatch. Andrei could
implement all the range stuff using interfaces, but that would mean:
1) You have to inherit from the interface (i.e., you can't use arrays)
2) All calls to ranges functions are virtual (inefficient; this is
particularly relevant since they are called inside loops = lot of
times)
A static interface don't have those problems, and I don't see a way to mix
static and dynamic interfaces without introducing a new type of
interfaces (static interface).
I realize that a class that inherits an interface would have these
issues, but if you aren't required to inherit the interface and the use
of interface in a function parameter constitutes a compile-time check
instead of inheritance check...
But this does bring up the question in your suggestion the following
code couldn't compile, but based on the signature it looks like it
should:
size_t walkLength(InputRange range, size_t upTo = size_t.max)
{
InputRange temp = range;
// implementation
}
That can be translated to something like:
size_t walkLength(Range)(Range range, size_t upTo = size_t.max)
if (isInputRange!(Range))
{
Range temp = range;
// implementation
}
--
Leandro Lucarella (AKA luca) http://llucax.com.ar/
--
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
--
DETUVIERON BANDA DE PIRATAS DEL ASFALTO
SON TODOS URUGUAYOS Y ROBARON MILES DE LITROS DE CERVEZA
-- Crónica TV
Re: Should the comma operator be removed in D2?
Lutger, el 16 de noviembre a las 23:27 me escribiste: dsimcha wrote: == Quote from Lutger (lutger.blijdest...@gmail.com)'s article ... int a = 1; int b = --a, ++a; assert(b == 1); assert(a == 1); Axe. Looks like the only things it's good for are making code undreadable and abusing for loop syntax to... Make code unreadable. When the heck would this be significantly more readable, safer, or more concise than doing the equivalent without it? Also, from previous discussions I vaguely remember it's constraining other parts of the syntax. Those discussions were about nice native tuple syntax. The only argument in favor of the comma operator I can remember is code-generation. Which is a very dumb one. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Y cuando llegamos a nuestro hogar ella saca de su bolsillo derecho un casete de Ricardo Montaner y nos dice: Ponelo! Ponelo!; nos desilusionamos un poco, pero a esa altura... Todo da igual. -- Sidharta Kiwi
Re: Should the comma operator be removed in D2?
Yigal Chripun, el 17 de noviembre a las 07:06 me escribiste:
Robert Jacques wrote:
On Mon, 16 Nov 2009 17:53:45 -0500, Stewart Gordon
smjg_1...@yahoo.com wrote:
dsimcha wrote:
snip
Axe. Looks like the only things it's good for are making code
undreadable and
abusing for loop syntax to...
Make code unreadable.
snip
Suppose you want the increment of a for loop to change two
variables in parallel. I don't call that making code
unreadable.
Stewart.
Yes the classic use case of the comma operator is multi-variable
declarations/increments in a for loop.
This was argued before and as I and others said before, this is
*not* a use case for the comma separator.
e.g.
for (int a = 0, b = 1; condition(); a++, b++) {...}
int a = 0, b = 1 // this is a declaration and not an expression
a++, b++ // isn't assigned to any variable and can be treated as a tuple
Exactly, all valid used of the comma operator can still be covered if the
comma becomes a tuple literal.
--
Leandro Lucarella (AKA luca) http://llucax.com.ar/
--
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
--
A heart that's full up like a landfill,
a job that slowly kills you,
bruises that won't heal.
Re: Should the comma operator be removed in D2?
Ellery Newcomer, el 16 de noviembre a las 19:02 me escribiste: Justin Johansson wrote: Great. Sounds like problem solved in that there is no problem. So how do people feel about bill's suggestion to progress the issue further? Be good to get some comments from higher-up (Walter, Andrei)? Predict bearophile will chime in on this one too? The real problem is you'd end up with a tuple syntax identical to a valid c syntax. If D silently accepts it, but does something different, it's a no go. Code ported from C should not compile if the comma expression is converted to a tuple literal because if a and b are int, typeof(a,b) is int now and will be Tuple!(int, int) in the future, and I don't think a Tuple!(anything) could be implicitly casted to anything, except, maybe, another tuple, but you don't have tuples in C, so there is no risk on that. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- I always get the feeling that when lesbians look at me, they're thinking, '*That's* why I'm not a heterosexual.' -- George Constanza
Re: static interface
Leandro Lucarella wrote:
Lars T. Kyllingstad, el 17 de noviembre a las 09:54 me escribiste:
In some ways the current code is better, because it actually checks if
a construct works or not, rather than requiring a specific function
signature. Whether the code will work is really the minimal
restriction you can place on the interface. A specific may be too
tight. For instance, above you don't really care if empty returns
bool or not. Just if you can test it in an if.
Another, related way in which the current code is better is that it
doesn't care whether empty, front, and popFront are functions or
variables. As we know, the standard trick for infinite ranges is to
declare empty as an enum, not a function.
Is not that hard to write:
bool empty() { return false; }
instead of
enum bool empty = false;
That's why I mentioned infinite ranges. An infinite range is *defined*
as a range where empty is implemented as
enum bool empty = false;
isInfinite(Range) tests whether this is the case, which it wouldn't be
able to do if empty() was a function.
-Lars
Re: static interface
== Quote from Leandro Lucarella (llu...@gmail.com)'s article
Lars T. Kyllingstad, el 17 de noviembre a las 09:54 me escribiste:
In some ways the current code is better, because it actually checks if
a construct works or not, rather than requiring a specific function
signature. Whether the code will work is really the minimal
restriction you can place on the interface. A specific may be too
tight. For instance, above you don't really care if empty returns
bool or not. Just if you can test it in an if.
Another, related way in which the current code is better is that it
doesn't care whether empty, front, and popFront are functions or
variables. As we know, the standard trick for infinite ranges is to
declare empty as an enum, not a function.
Is not that hard to write:
bool empty() { return false; }
instead of
enum bool empty = false;
Yes, but there's a reason to use enum: This convention enables compile time
introspection as to whether the ranges are infinite. It's also more efficient
when inlining is disabled.
Re: Go: A new system programing language
Walter Bright Wrote: This is very interesting to hear. If there is anything I can do to help any adoption of D at Google, please let me know. Thanks, I will. Off hand the only thing I can think of is finish D2 and commit to it being supported/stable for a few years :-) I realize there are already interesting ideas kicking around for D3 but if they can be integrated in a backwards compatible way Anyway, the amount of work required to integrate a new general purpose language at Google is pretty big, it'd probably be several 20% projects worth of work over a period of about half a year. For illustration here are a few of the tasks that'd be either required or strongly wanted (some stuff is still confidential and I can't mention). I'm not suggesting this list is typical of large companies but it might prove interesting anyway. - Integration of a compiler with our in-house build system (proprietary). If it's GCC based that's better. - Some kind of standard unit testing framework that the testing infrastructure knows how to drive. If it works similar to the ones we use for C++ that's better: http://code.google.com/p/googletest/ http://code.google.com/p/googlemock/ - Protocol buffer support http://code.google.com/p/protobuf/ - google style command line flags implementation: http://code.google.com/p/google-gflags/ - Style guide: It's an open question whether this would purely be how code looks or like the C++ guide also restrict some features. D is a very feature rich language even compared to C++. I'm not sure if expecting developers and reviewers to be familiar with *every* feature is realistic or worth the cost. http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml - The aforementioned readability reviews, reviewers need to be found (they are volunteers) and trained, Perforce needs to be taught about the new filetypes: http://1-800-magic.blogspot.com/2008/01/after-8-months-no-longer-noogler.html - Training materials so engineers who haven't encountered D before can get up to speed quickly, at least to the level where they can do code reviews even if they aren't a master of all the features. - By default emacs/vim at google import customizations for our environment, integrating a d-mode with that would be nice. - Bindings to the core libraries for accessing things like GFS/BigTable and doing RPCs: optional but the utility of any language that can't use them is limited. C++ compatibility would certainly make this easier but SWIG integration would make it even easier still, as we already have SWIG set up for Python. Figuring out an easy way to integrate the garbage collected world with the manually managed world is also a trick. I presume the Python bindings already figured this out but it'd obviously be nice if the bindings could be as thin as possible. Of all those, the last would be the most work. The google standard library is a huge collection of robust and well written code - everything from well known stuff like BigTable down to custom threading and malloc libraries. The nice things D brings to the table can't compensate for the loss of that codebase. I haven't tried binding stuff into D, although given that it's got some C/C++ compatibility it's way ahead of Python and Java already.
Re: static interface
Lars T. Kyllingstad, el 17 de noviembre a las 15:12 me escribiste:
Leandro Lucarella wrote:
Lars T. Kyllingstad, el 17 de noviembre a las 09:54 me escribiste:
In some ways the current code is better, because it actually checks if
a construct works or not, rather than requiring a specific function
signature. Whether the code will work is really the minimal
restriction you can place on the interface. A specific may be too
tight. For instance, above you don't really care if empty returns
bool or not. Just if you can test it in an if.
Another, related way in which the current code is better is that it
doesn't care whether empty, front, and popFront are functions or
variables. As we know, the standard trick for infinite ranges is to
declare empty as an enum, not a function.
Is not that hard to write:
bool empty() { return false; }
instead of
enum bool empty = false;
That's why I mentioned infinite ranges. An infinite range is
*defined* as a range where empty is implemented as
enum bool empty = false;
isInfinite(Range) tests whether this is the case, which it wouldn't
be able to do if empty() was a function.
OK, there are way to fix that too, but I see your point now.
--
Leandro Lucarella (AKA luca) http://llucax.com.ar/
--
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
--
The Guinness Book of Records holds the record for being the most
stolen book in public libraries
Mac OS X and backward compatibility
On 2009-11-17 03:19:39 -0500, Don nos...@nospam.com said: Steven Schveighoffer wrote: On Mon, 16 Nov 2009 16:07:56 -0500, Walter Bright newshou...@digitalmars.com wrote: Backward compatibility doesn't mean that the old systems have to support new features. It just means that the old features continue to work on the new systems. I have a lot of software built for Win95 that still works fine g. Even the DOS programs still work. Your argument was about building programs on MacOS 10.5 that crash on 10.4. That's like building programs on Windows XP and expecting them to run flawlessly on Windows 98. Although, I will say, having a Hello World executable throw a bus error is a little over the top in breaking backwards compatibility :) -Steve Apple is a bit over the top. It really seems they don't give a damn about backwards compatibility. Yet they've stayed in business. I think there's a lesson in that. I'm not sure to what extent that's true. I can still compile my apps for Mac OS X 10.1 in the latest Xcode by setting MACOSX_DEPLOYMENT_TARGET to 10.1. This prevents the resulting binary from using linker features not available in 10.1. To ensure availability for each symbol, Apple headers use macros (MAC_OS_X_VERSION_MIN_REQUIRED and MAC_OS_X_VERSION_MAX_ALLOWED, mapped to compiler flags −mmacosx-version-min=X and −mmacosx-version-max=X) to hide APIs not available for a given target OS version, and the compiler can then issue errors if you try to use them. Or it can weak-link symbols, allowing you to check at runtime for their availability. In the latest Mac OS X (10.4 forward), those two macros also control renaming at compile time of some symbols in the standard C library. This is because they changed things for UNIX conformance but didn't want to change the behavior for previously compiled programs. So if you don't set correctly MAC_OS_X_VERSION_MIN_REQUIRED at compile time you might also get a non-working executable in older Mac OS X versions. For instance, here's the declaration for fdopen on Mac OS X 10.6: #if defined(__DARWIN_10_6_AND_LATER) (defined(_DARWIN_UNLIMITED_STREAMS) || defined(_DARWIN_C_SOURCE)) FILE*fdopen(int, const char *) __DARWIN_EXTSN(fdopen); #else /* 10.6 || !_DARWIN_UNLIMITED_STREAMS !_DARWIN_C_SOURCE */ FILE *fdopen(int, const char *) __DARWIN_10_6_AND_LATER_ALIAS(__DARWIN_ALIAS(fdopen)); #endif /* = 10.6 _(DARWIN_UNLIMITED_STREAMS || _DARWIN_C_SOURCE) */ If you dig the macros a little, you see it can remap the function to symbol _fdopen$DARWIN_EXTSN, _fdopen$UNIX2003 or keep the original name, all depending on what the MAC_OS_X_VERSION_MIN_REQUIRED macro and others are set to. Compiling a hello world with the MACOSX_DEPLOYMENT_TARGET environment variable set to 10.4 and both MAC_OS_X_VERSION_MIN_REQUIRED and MAC_OS_X_VERSION_MAX_ALLOWED set to 1040 should result in a binary compatible with 10.4. Or you can compile against the Mac OS X 10.4 SDK to get the same result. It's true that backward compatibility isn't the default setting when compiling a program in Mac OS X: you must explicitly ask for it. But I don't think it's fair to say that Apple doesn't give a damn, otherwise all this complicated stuff wouldn't exist. Here are some more details (although some things in this article are outdated): http://developer.apple.com/mac/library/technotes/tn2002/tn2064.html And this one is documenting symbol renaming: http://developer.apple.com/mac/library/releasenotes/Darwin/SymbolVariantsRelNotes/index.html -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: Should the comma operator be removed in D2?
Testing - ignore this post Leandro Lucarella Wrote: Lutger, el 16 de noviembre a las 23:27 me escribiste: dsimcha wrote: == Quote from Lutger (lutger.blijdest...@gmail.com)'s article ... int a = 1; int b = --a, ++a; assert(b == 1); assert(a == 1); Axe. Looks like the only things it's good for are making code undreadable and abusing for loop syntax to... Make code unreadable. When the heck would this be significantly more readable, safer, or more concise than doing the equivalent without it? Also, from previous discussions I vaguely remember it's constraining other parts of the syntax. Those discussions were about nice native tuple syntax. The only argument in favor of the comma operator I can remember is code-generation. Which is a very dumb one. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Y cuando llegamos a nuestro hogar ella saca de su bolsillo derecho un casete de Ricardo Montaner y nos dice: Ponelo! Ponelo!; nos desilusionamos un poco, pero a esa altura... Todo da igual. -- Sidharta Kiwi
Re: static interface
On 2009-11-17 09:12:04 -0500, Lars T. Kyllingstad pub...@kyllingen.nospamnet said: That's why I mentioned infinite ranges. An infinite range is *defined* as a range where empty is implemented as enum bool empty = false; isInfinite(Range) tests whether this is the case, which it wouldn't be able to do if empty() was a function. Which makes me think: what about a range that can but may not necessarily be infinite depending on runtime parameters? For instance, you could have a range returning a rational number as decimal digits: some will be infinite and others will be finite depending on the rational number (like 1/3 vs. 1/4). You can't express that with an enum. I guess you could fix that by overloading isInfinite for your specific range type though. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: static interface
On Tue, Nov 17, 2009 at 5:51 AM, Leandro Lucarella llu...@gmail.com wrote:
Bill Baxter, el 16 de noviembre a las 15:42 me escribiste:
On Mon, Nov 16, 2009 at 9:25 AM, Leandro Lucarella llu...@gmail.com wrote:
This topic is actually very close to a discussion last week about
retrieving error messages from failures of __traits(compiles, xxx).
My question is: is it really that much of an improvement?
I've rearranged your code to see the equivalent snippets side-by-side:
static interface InputRange(T) {
bool empty();
T front();
void popFront();
}
template isInputRange(R)
{
enum bool isInputRange = is(typeof(
{
R r;
if (r.empty) {}
r.popFront;
auto h = r.front;
}()));
}
There's actually not that much difference here. Of course we would
like several general improvements that have been discussed before:
1) some kind of template 'this' so we don't have to repeat the template name.
2) something better than is(typeof()) (or __traits(compiles, ...)) to
check if code is ok. [hoping for meta.compiles(...)]
In some ways the current code is better, because it actually checks if
a construct works or not, rather than requiring a specific function
signature. Whether the code will work is really the minimal
restriction you can place on the interface. A specific may be too
tight. For instance, above you don't really care if empty returns
bool or not. Just if you can test it in an if.
I think one could argue if being more restrictive is actually good or bad.
Being more restrictive cold lead to less errors. Maybe if a struct empty()
method returns, say, a pointer, I don't want to think it is *really*
a range. Maybe that method is doing a lot of work and removing stuff, and
then returning a pointer to some removed stuff. Anyway, I'm not saying
that that couldn't happen even if empty() return bool (that's a risk when
duck-typing, always :), I'm just saying I'm not so sure that being more
restrictive is really a *bad thing*.
If that's what you want, the D way gives you the option of checking
is(typeof(R.empty)==bool)
But yeh, that is klunkier than just writing out the function signature
you're expecting.
And about what's nice or ugly, I agree the current way of doing stuff is
not too bad, there are a few details that are not *that* nice. But with
duck-typing I think the same that with tuples: those little details makes
you feel that D doesn't support the concept so well, and make people
resistant to use them. When something feels natural in a language, you use
it all the time, for me, the current way to do tuples and duck-typing
looks very artificial and harder than it should.
Agreed. But as for the duck typing aspect, I think there isn't
necessarily an either-or choice here.
For instance, in D, we could allow a static interface to have a static
assert block:
static interface InputRange(T) {
static assert (meta.compiles({
if (this.empty) {}; // this is a shortcut for T.init
}));
T front();
void popFront();
}
Or something like that. Invariant {} might be better there.
But in terms of functionality it seems we cover pretty much everything
static interface gives you.
I know that, I started this proposal just saying that =)
Ah. Sorry, I missed that comment.
--bb
Re: Should the comma operator be removed in D2?
On Tue, Nov 17, 2009 at 6:06 AM, Leandro Lucarella llu...@gmail.com wrote:
Ellery Newcomer, el 16 de noviembre a las 19:02 me escribiste:
Justin Johansson wrote:
Great. Sounds like problem solved in that there is no problem.
So how do people feel about bill's suggestion to progress the issue
further?
Be good to get some comments from higher-up (Walter, Andrei)?
Predict bearophile will chime in on this one too?
The real problem is you'd end up with a tuple syntax identical to a
valid c syntax. If D silently accepts it, but does something different,
it's a no go.
Code ported from C should not compile if the comma expression is converted
to a tuple literal because if a and b are int, typeof(a,b) is int now and
will be Tuple!(int, int) in the future, and I don't think
a Tuple!(anything) could be implicitly casted to anything, except, maybe,
another tuple, but you don't have tuples in C, so there is no risk on that.
Good point! A trick like this:
if (ok=func1(), b=func2(), ok) { ... }
Will not compile if that's an (int,int,int) tuple. Brilliant. So
anywhere you're actually using the value in C is covered, it'll be an
error in D.
And for places where you're not using the value, it'll do the right
thing as long as we define the order of evaluation to be left to
right.
I think Walter wants to have the evaluation order for most everything
defined in D, anyway. Just to avoid having implementation-defined or
non-deterministic behavior.
--bb
Re: D array expansion and non-deterministic re-allocation
Walter Bright Wrote: Denis Koroskin wrote: It is *non*-deterministic. The decision to reallocate depends (or will depend) on LRU and it may be cleared by another thread (e.g. another thread may reset it manually or via a GC cycle run). The LRU is thread local. It will then prevent a moving GC from being possible in D. Otherwise, moving a block of data will invalidate LRU which will result in non-deterministic reallocation.
Re: Going from CTFE-land to Template-land
Bill Baxter wrote:
Currently this doesn't work, because the CTFE function doesn't know
that it's running compile-time:
int templ_incr(int x)() {
return x+1;
}
int ctfe_incr(int x) {
return templ_incr!(x);
}
Seems common to write a function that you know is only intended to be
used compile-time.
But it can't compile because the compiler doesn't know you only plan
to call it at compile-time.
Is something version(__ctfe) might help with? E.g.
version(__ctfe) {
// only allow cfte_incr to be called at compile-time so it can use templates
int ctfe_incr(int x) {
return templ_incr!(x);
}
}
No. Here's the only functionality you'll get. This works by exploiting
bug 1330. It's inefficient: the inCTFE function gets called all the
time. Should just be a bool value, which will be constant-folded away.
Otherwise, it's the same as this:
// true if evaluated in CTFE, false if called at runtime.
bool inCTFE()
{
int [1] x = [1];
int [] y = x;
y[0] = 2;
return x[0]!=2;
}
static assert(inCTFE());
void main()
{
assert(!inCTFE());
}
Re: Go: A new system programing language
Mike Hearn: With a few minor improvements (eg namespace support) that'd save a lot of time. This change to D language is not planned. You can explain why you think namespace support is useful (and you can explain those other minor improvements too). - Integration of a compiler with our in-house build system (proprietary). If it's GCC based that's better. There's a D compiled based on GCC, but at the moment the best D1 compiler is LDC, based on LLVM, especially if you care for top performance of the binary. If it works similar to the ones we use for C++ that's better: I hope D will do better here :-) But it will take time. D is a very feature rich language even compared to C++. But usually D features are designed to be safer, higher level, less tricky and more handy, and sometimes slower. Go designers have removed almost everything, so when you use Go you don't need a restrictive style guide like Google C++ one that forbids people to use several language features :-) - By default emacs/vim at google import customizations for our environment, integrating a d-mode with that would be nice. This is something that probably needs to be done regardless possible D usage at Google. I haven't tried binding stuff into D, although given that it's got some C/C++ compatibility it's way ahead of Python and Java already. C compatibility of D is good. C++ compatibility is currently limited by design. If Google hires Walter he may use 50% of his free time developing D2 (as Guido has 50% for Python itself, and 50% developing Python code). Bye, bearophile
Re: Should the comma operator be removed in D2?
On Tue, 17 Nov 2009 05:44:31 -0500, downs default_357-l...@yahoo.de
wrote:
Robert Jacques wrote:
On Tue, 17 Nov 2009 00:06:27 -0500, Yigal Chripun yigal...@gmail.com
wrote:
Robert Jacques wrote:
On Mon, 16 Nov 2009 17:53:45 -0500, Stewart Gordon
smjg_1...@yahoo.com wrote:
dsimcha wrote:
snip
Axe. Looks like the only things it's good for are making code
undreadable and
abusing for loop syntax to...
Make code unreadable.
snip
Suppose you want the increment of a for loop to change two variables
in parallel. I don't call that making code unreadable.
Stewart.
Yes the classic use case of the comma operator is multi-variable
declarations/increments in a for loop.
This was argued before and as I and others said before, this is *not*
a use case for the comma separator.
e.g.
for (int a = 0, b = 1; condition(); a++, b++) {...}
int a = 0, b = 1 // this is a declaration and not an expression
a++, b++ // isn't assigned to any variable and can be treated as a
tuple
the only use case that will break is if the two increments are
dependent on the order (unless tuples are also evaluated from left to
right):
e.g.
a + 5, b + a //
I doubt it very much that anyone ever uses this, it's too unreadable
to be useful.
However, I imagine tuple(a++,b++) would have some overhead, which is
exactly what someone is trying to avoid by using custom for loops.
Personally, I like using a..b = tuple(a,b), since it also solves the
multi-dimensional slicing and mixed indexing and slicing problems.
Zero overhead. Tuples are flat compile-time entities.
There are compile time tuples and runtime tuples. D already has a form of
compile-time tuples. This discussion seems to be about runtime tuples
which currently don't have a nice syntax: you have to use tuple(a,b). And
tuple(a,b) does have runtime overhead.
Re: Going from CTFE-land to Template-land
On Tue, 17 Nov 2009 18:07:03 +0300, Don nos...@nospam.com wrote:
Bill Baxter wrote:
Currently this doesn't work, because the CTFE function doesn't know
that it's running compile-time:
int templ_incr(int x)() {
return x+1;
}
int ctfe_incr(int x) {
return templ_incr!(x);
}
Seems common to write a function that you know is only intended to be
used compile-time.
But it can't compile because the compiler doesn't know you only plan
to call it at compile-time.
Is something version(__ctfe) might help with? E.g.
version(__ctfe) {
// only allow cfte_incr to be called at compile-time so it can use
templates
int ctfe_incr(int x) {
return templ_incr!(x);
}
}
No. Here's the only functionality you'll get. This works by exploiting
bug 1330. It's inefficient: the inCTFE function gets called all the
time. Should just be a bool value, which will be constant-folded away.
Otherwise, it's the same as this:
// true if evaluated in CTFE, false if called at runtime.
bool inCTFE()
{
int [1] x = [1];
int [] y = x;
y[0] = 2;
return x[0]!=2;
}
static assert(inCTFE());
void main()
{
assert(!inCTFE());
}
Haha, nice one!
Re: Go: A new system programing language
Mike Hearn Wrote: - Bindings to the core libraries for accessing things like GFS/BigTable and doing RPCs: optional but the utility of any language that can't use them is limited. C++ compatibility would certainly make this easier but SWIG integration would make it even easier still, as we already have SWIG set up for Python. Figuring out an easy way to integrate the garbage collected world with the manually managed world is also a trick. I presume the Python bindings already figured this out but it'd obviously be nice if the bindings could be as thin as possible. RPC should be a part of messaging support, though possibly not right away. Socket IO in Phobos kind of stinks right now so that would need an overhaul first. Of all those, the last would be the most work. The google standard library is a huge collection of robust and well written code - everything from well known stuff like BigTable down to custom threading and malloc libraries. The nice things D brings to the table can't compensate for the loss of that codebase. I haven't tried binding stuff into D, although given that it's got some C/C++ compatibility it's way ahead of Python and Java already. Sounds like Google may want to use a custom runtime. It's pretty trivial to replace core.thread from a project perspective, but dropping in a custom thread implementation could take some work--the GC integration is tricky.
Re: Making alloca more safe
On Tue, Nov 17, 2009 at 11:51 AM, Walter Bright newshou...@digitalmars.com wrote: Max Samukha wrote: On Mon, 16 Nov 2009 12:48:51 -0800, Walter Bright newshou...@digitalmars.com wrote: If you've got a system that relies on the software continuing to function after an unexpected null seg fault, you have a VERY BADLY DESIGNED and COMPLETELY UNSAFE system. I really cannot emphasize this enough. I have an example of such a software: http://www.steinberg.net/en/products/audiopostproduction_product/nuendo4.html It loads third-party plugins into the host process's address space, an consequently it may fail at any moment. The software's design is not the best ever but it gives the user last chance to save his work in case of fatal error. This feature has saved my back a couple of times. I suppose nobody much cares if it writes out a corrupted audio file. People care very much if their airplane suddenly dives into the ground. Be that as it may, it is certainly possible to catch seg faults in an exception handler and write files out. That would be an unacceptable behavior, though, in a system that needs to be safe. You spent quite a bit of effort explaining that segfaults never cause memory corruption, so it seems fairly reasonable to assume that some parts of the application state could still be valid and useful not to throw away. P.S. I worked for Boeing for years on flight critical systems. Normally I eschew credentialism, but I feel very strongly about this issue and wish to point out that my knowledge on this is based on decades of real world experience by aviation companies who take this issue extremely seriously. Then, instead of sticking with Windows and the likes, you may want to think about porting dmd to a more serious environment specifically designed for developing such systems. What about a real-time microkernel OS like this one: http://www.qnx.com/products/neutrino_rtos/ ? dmd targets Windows because that's where probably half the programmers are. I'd certainly like to do embedded systems, too, but realistically that's going to be the purview of gdc or ldc. I'm not sure if LDC will ever support D2 (at least wont be by my hand)
Re: Should the comma operator be removed in D2?
Leandro Lucarella wrote: Ellery Newcomer, el 16 de noviembre a las 19:02 me escribiste: Justin Johansson wrote: Great. Sounds like problem solved in that there is no problem. So how do people feel about bill's suggestion to progress the issue further? Be good to get some comments from higher-up (Walter, Andrei)? Predict bearophile will chime in on this one too? The real problem is you'd end up with a tuple syntax identical to a valid c syntax. If D silently accepts it, but does something different, it's a no go. Code ported from C should not compile if the comma expression is converted to a tuple literal because if a and b are int, typeof(a,b) is int now and will be Tuple!(int, int) in the future, and I don't think a Tuple!(anything) could be implicitly casted to anything, except, maybe, another tuple, but you don't have tuples in C, so there is no risk on that. void fun1(int a); void fun1(Tuple!(int,int) a); fun1( (a=fizbang(), a+b) );
Re: Making alloca more safe
== Quote from Tomas Lindquist Olsen (tomas.l.ol...@gmail.com)'s article I'm not sure if LDC will ever support D2 (at least wont be by my hand) What is it about D2 that makes this unlikely? I thought after LDC D1 support was stable and the D2 spec and front end were stable, the natural progression of things would be for LDC to support D2.
Re: Making alloca more safe
On Tue, Nov 17, 2009 at 4:45 PM, dsimcha dsim...@yahoo.com wrote: == Quote from Tomas Lindquist Olsen (tomas.l.ol...@gmail.com)'s article I'm not sure if LDC will ever support D2 (at least wont be by my hand) What is it about D2 that makes this unlikely? I thought after LDC D1 support was stable and the D2 spec and front end were stable, the natural progression of things would be for LDC to support D2. LDC requires a lot of changes to the frontend. * DMD is not written as a cross compiler * The runtime interfaces are hardcoded into the frontend semantics * The ast rewrites dmd does are destructive and buggy * The dmd codegen is all over the frontend code, it wasn't meant to be used with another backend But most of all: someone has to do it. Keeping the two in sync is a major PITA, the original merge of our frontend changes, to the D2 frontend was done in a error prone way, which introduced a lot of bugs, codegen that worked in D1 still compiles, and generates code that compiles, but the code doesn't run. This requires time consuming debugging/reviewing and of course fixing. So most of all, like most of things D, it's about a lack of manpower. I personally no longer have the time to maintain LDC besides critical bugfixes now and then, and other devs are in similar situations. Another factor may be more ideological (or something), not everyone is happy about how D evolved, and who want to implement something they don't really care about ? -Tomas
Re: Should the comma operator be removed in D2?
On Tue, Nov 17, 2009 at 7:09 AM, Robert Jacques sandf...@jhu.edu wrote:
On Tue, 17 Nov 2009 05:44:31 -0500, downs default_357-l...@yahoo.de wrote:
Robert Jacques wrote:
On Tue, 17 Nov 2009 00:06:27 -0500, Yigal Chripun yigal...@gmail.com
wrote:
Robert Jacques wrote:
On Mon, 16 Nov 2009 17:53:45 -0500, Stewart Gordon
smjg_1...@yahoo.com wrote:
dsimcha wrote:
snip
Axe. Looks like the only things it's good for are making code
undreadable and
abusing for loop syntax to...
Make code unreadable.
snip
Suppose you want the increment of a for loop to change two variables
in parallel. I don't call that making code unreadable.
Stewart.
Yes the classic use case of the comma operator is multi-variable
declarations/increments in a for loop.
This was argued before and as I and others said before, this is *not*
a use case for the comma separator.
e.g.
for (int a = 0, b = 1; condition(); a++, b++) {...}
int a = 0, b = 1 // this is a declaration and not an expression
a++, b++ // isn't assigned to any variable and can be treated as a tuple
the only use case that will break is if the two increments are
dependent on the order (unless tuples are also evaluated from left to
right):
e.g.
a + 5, b + a //
I doubt it very much that anyone ever uses this, it's too unreadable
to be useful.
However, I imagine tuple(a++,b++) would have some overhead, which is
exactly what someone is trying to avoid by using custom for loops.
Personally, I like using a..b = tuple(a,b), since it also solves the
multi-dimensional slicing and mixed indexing and slicing problems.
Zero overhead. Tuples are flat compile-time entities.
There are compile time tuples and runtime tuples. D already has a form of
compile-time tuples. This discussion seems to be about runtime tuples which
currently don't have a nice syntax: you have to use tuple(a,b). And
tuple(a,b) does have runtime overhead.
I think the point is that in something like this:
auto foo = (a,b);
foo.a += 2;
foo.b += foo.a;
// etc
The tuple foo is allocated on the stack and the compiler knows where
the a part and b part are, so the code generated should be absolutely
no different from the code generated for:
auto foo_a = a;
auto foo_b = b;
foo_a += 2;
foo_b += foo_a;
// etc
So there doesn't need to be any tuple overhead.
--bb
Re: D array expansion and non-deterministic re-allocation
Denis Koroskin Wrote: Walter Bright Wrote: Denis Koroskin wrote: It is *non*-deterministic. The decision to reallocate depends (or will depend) on LRU and it may be cleared by another thread (e.g. another thread may reset it manually or via a GC cycle run). The LRU is thread local. It will then prevent a moving GC from being possible in D. Otherwise, moving a block of data will invalidate LRU which will result in non-deterministic reallocation. It won't work with the existing GC either. If a page is completely emptied then it can be re-used for different sized allocations. This is why the current cache is wiped during a collection.
Re: Go: A new system programing language
On Tue, Nov 17, 2009 at 7:07 AM, bearophile bearophileh...@lycos.com wrote:
Mike Hearn:
With a few minor improvements (eg namespace support) that'd save a lot of
time.
This change to D language is not planned. You can explain why you think
namespace support is useful (and you can explain those other minor
improvements too).
To be more specific, Walter thinks is good enough namespace support
(in addition to the fact that every module is a namespace).
struct Namespace {
static:
// ...
}
If you need something more, then it would be great if you could explain it.
--bb
Re: Making alloca more safe
Tomas Lindquist Olsen Wrote: On Tue, Nov 17, 2009 at 11:51 AM, Walter Bright newshou...@digitalmars.com wrote: I suppose nobody much cares if it writes out a corrupted audio file. People care very much if their airplane suddenly dives into the ground. Be that as it may, it is certainly possible to catch seg faults in an exception handler and write files out. That would be an unacceptable behavior, though, in a system that needs to be safe. You spent quite a bit of effort explaining that segfaults never cause memory corruption, so it seems fairly reasonable to assume that some parts of the application state could still be valid and useful not to throw away. At the moment the segfault occurs, sure. But if the process eats the segfault and continues, what happens? If an app is programmed in such a way that segfaults are a part of normal processing (I worked on a DB that performed dynamic loading this way) that's one thing. But other apps are almost definitely going to try and write data near 0x00 after such an occurrence.
Re: Going from CTFE-land to Template-land
On Tue, Nov 17, 2009 at 7:07 AM, Don nos...@nospam.com wrote:
Bill Baxter wrote:
Currently this doesn't work, because the CTFE function doesn't know
that it's running compile-time:
int templ_incr(int x)() {
return x+1;
}
int ctfe_incr(int x) {
return templ_incr!(x);
}
Seems common to write a function that you know is only intended to be
used compile-time.
But it can't compile because the compiler doesn't know you only plan
to call it at compile-time.
Is something version(__ctfe) might help with? E.g.
version(__ctfe) {
// only allow cfte_incr to be called at compile-time so it can use
templates
int ctfe_incr(int x) {
return templ_incr!(x);
}
}
No. Here's the only functionality you'll get. This works by exploiting bug
1330. It's inefficient: the inCTFE function gets called all the time. Should
just be a bool value, which will be constant-folded away. Otherwise, it's
the same as this:
// true if evaluated in CTFE, false if called at runtime.
bool inCTFE()
{
int [1] x = [1];
int [] y = x;
y[0] = 2;
return x[0]!=2;
}
static assert(inCTFE());
void main()
{
assert(!inCTFE());
}
After pondering it some more, I'm inclined to think CTFE-Template
calls are not really needed.
Templates are at their heart supposed to offer computations on types.
Sometimes types involve values, so they need to be able to do some
compute with values too.
CTFE on the other hand is all about doing compute on values. So if
you're in a CTFE function you're definitely in value-land. There
shouldn't be any reason to need to pass your CTFE values to a
template. By definition you're only dealing with values, so you don't
need the type computation features of templates.
--bb
Re: Making alloca more safe
Sean Kelly wrote: Tomas Lindquist Olsen Wrote: On Tue, Nov 17, 2009 at 11:51 AM, Walter Bright newshou...@digitalmars.com wrote: I suppose nobody much cares if it writes out a corrupted audio file. People care very much if their airplane suddenly dives into the ground. Be that as it may, it is certainly possible to catch seg faults in an exception handler and write files out. That would be an unacceptable behavior, though, in a system that needs to be safe. You spent quite a bit of effort explaining that segfaults never cause memory corruption, so it seems fairly reasonable to assume that some parts of the application state could still be valid and useful not to throw away. At the moment the segfault occurs, sure. But if the process eats the segfault and continues, what happens? If an app is programmed in such a way that segfaults are a part of normal processing (I worked on a DB that performed dynamic loading this way) that's one thing. But other apps are almost definitely going to try and write data near 0x00 after such an occurrence. I think throwing an Error object instead of failing immediately would be occasionally useful. (Same goes about other trapped errors such as integral division by zero.) There are applications out there that want to partially recover from a null pointer error. I wrote a few, so it's difficult to convince me they don't exist. Andrei
lexertl
Hi there, My name is Ben Hanson and I am the author of lexertl (http://www.benhanson.net/lexertl.html), a lexical analyser generator written in C++. As the generator is modular, code generators can be added easily as separate files which means it is easy to output code for any language. I am interested in producing code generators for D and was wondering if this is interesting for anyone. If there is interest in lexertl, I would also be interested in rewriting the entire thing in D. Please let me know if anyone is interested in this. Thanks, Ben
D2 front-end for LLVM (Was: Re: Making alloca more safe)
Tomas Lindquist Olsen: LDC requires a lot of changes to the frontend. * DMD is not written as a cross compiler * The runtime interfaces are hardcoded into the frontend semantics * The ast rewrites dmd does are destructive and buggy * The dmd codegen is all over the frontend code, it wasn't meant to be used with another backend LLVM is one of the best thing happened to D1, so maybe Walter can improve the situation, to allow a simpler/better attach of the D2 front-end to LLVM. If you keep your muzzle shut things will never improve. Maybe someone can write a list of all the points where D2 causes such port problems, so Walter may improve/fix them some. This is quite important, more than most syntax details discussed in the last weeks. Bye, bearophile
Re: Should the comma operator be removed in D2?
On Tue, 17 Nov 2009 11:38:19 -0500, Bill Baxter wbax...@gmail.com wrote:
On Tue, Nov 17, 2009 at 7:09 AM, Robert Jacques sandf...@jhu.edu wrote:
On Tue, 17 Nov 2009 05:44:31 -0500, downs default_357-l...@yahoo.de
wrote:
Robert Jacques wrote:
On Tue, 17 Nov 2009 00:06:27 -0500, Yigal Chripun yigal...@gmail.com
wrote:
Robert Jacques wrote:
On Mon, 16 Nov 2009 17:53:45 -0500, Stewart Gordon
smjg_1...@yahoo.com wrote:
dsimcha wrote:
snip
Axe. Looks like the only things it's good for are making code
undreadable and
abusing for loop syntax to...
Make code unreadable.
snip
Suppose you want the increment of a for loop to change two
variables
in parallel. I don't call that making code unreadable.
Stewart.
Yes the classic use case of the comma operator is multi-variable
declarations/increments in a for loop.
This was argued before and as I and others said before, this is *not*
a use case for the comma separator.
e.g.
for (int a = 0, b = 1; condition(); a++, b++) {...}
int a = 0, b = 1 // this is a declaration and not an expression
a++, b++ // isn't assigned to any variable and can be treated as a
tuple
the only use case that will break is if the two increments are
dependent on the order (unless tuples are also evaluated from left to
right):
e.g.
a + 5, b + a //
I doubt it very much that anyone ever uses this, it's too unreadable
to be useful.
However, I imagine tuple(a++,b++) would have some overhead, which is
exactly what someone is trying to avoid by using custom for loops.
Personally, I like using a..b = tuple(a,b), since it also solves the
multi-dimensional slicing and mixed indexing and slicing problems.
Zero overhead. Tuples are flat compile-time entities.
There are compile time tuples and runtime tuples. D already has a form
of
compile-time tuples. This discussion seems to be about runtime tuples
which
currently don't have a nice syntax: you have to use tuple(a,b). And
tuple(a,b) does have runtime overhead.
I think the point is that in something like this:
auto foo = (a,b);
foo.a += 2;
foo.b += foo.a;
// etc
The tuple foo is allocated on the stack and the compiler knows where
the a part and b part are, so the code generated should be absolutely
no different from the code generated for:
auto foo_a = a;
auto foo_b = b;
foo_a += 2;
foo_b += foo_a;
// etc
So there doesn't need to be any tuple overhead.
--bb
But that isn't the expansion:
for (int a = 0, b = 1; condition(); a++, b++) =
int a = 0;
int b = 0;
while(condition) {
auto temp = tuple(a++,b++); // creation of a struct on the stack
}
Now the optimizer might get rid of that temporary struct. Then again it
might not (or its presence interferes with other optimizations). At the
very least, some amount of code profiling or disassembly needs to be done.
Re: Should the comma operator be removed in D2?
On Nov 17, 09 23:44, Ellery Newcomer wrote: Leandro Lucarella wrote: Ellery Newcomer, el 16 de noviembre a las 19:02 me escribiste: Justin Johansson wrote: Great. Sounds like problem solved in that there is no problem. So how do people feel about bill's suggestion to progress the issue further? Be good to get some comments from higher-up (Walter, Andrei)? Predict bearophile will chime in on this one too? The real problem is you'd end up with a tuple syntax identical to a valid c syntax. If D silently accepts it, but does something different, it's a no go. Code ported from C should not compile if the comma expression is converted to a tuple literal because if a and b are int, typeof(a,b) is int now and will be Tuple!(int, int) in the future, and I don't think a Tuple!(anything) could be implicitly casted to anything, except, maybe, another tuple, but you don't have tuples in C, so there is no risk on that. void fun1(int a); void fun1(Tuple!(int,int) a); fun1( (a=fizbang(), a+b) ); These are not code ported from *C*.
Re: Should the comma operator be removed in D2?
On Tue, 17 Nov 2009 01:44:30 -0500, yigal chripun yigal...@gmail.com wrote: Robert Jacques Wrote: However, I imagine tuple(a++,b++) would have some overhead, which is exactly what someone is trying to avoid by using custom for loops. Personally, I like using a..b = tuple(a,b), since it also solves the multi-dimensional slicing and mixed indexing and slicing problems. what overhead? It's all in your imagination :) a..b is confusing and bad UI. a..b means for humans the range of a till b and not the tuple of the two. if I see something like hello..42 I would assume the person who wrote this was high on something. multi dimentinal slicing should accept an integer range type and NOT a tuple. The unnecessary creation and setting of a tuple struct is by definition overhead. Also, containers will have non-integer slices, e.g. dictionary[hello..world], and strided ranges would even mix types: hello..42..world. My point isn't that '..' was a better syntax than '(,)'. It's that '..' needs to change to something very much like a tuple and therefore could be used to kill two birds with one stone.
Re: D2 front-end for LLVM (Was: Re: Making alloca more safe)
On Tue, Nov 17, 2009 at 5:58 PM, bearophile bearophileh...@lycos.com wrote: Tomas Lindquist Olsen: LDC requires a lot of changes to the frontend. * DMD is not written as a cross compiler * The runtime interfaces are hardcoded into the frontend semantics * The ast rewrites dmd does are destructive and buggy * The dmd codegen is all over the frontend code, it wasn't meant to be used with another backend LLVM is one of the best thing happened to D1, so maybe Walter can improve the situation, to allow a simpler/better attach of the D2 front-end to LLVM. If you keep your muzzle shut things will never improve. Maybe someone can write a list of all the points where D2 causes such port problems, so Walter may improve/fix them some. Walter seems to be fairly rigid to work with. While the latest improvements, like DMD in a SVN repo, is a great step, I just don't have as much time for LDC as I used to, so the little difference it makes doesn't really help me that much. I agree it would be good with more developer documentation. But LDC is really not implemented very cleanly and writing such would be a huge amount of work. When I started on LDC I had no idea how DMD worked, and I made a lot of mistakes along the way. Now, since then, a lot of people have joined, and helped out. But it still suffers from some of the issues introduced very early. Another point is motivation. Personally, I've achieved what I originally planned for LDC, and quite a lot more. New projects await out there. Don't get me wrong. I *use* D (1.0 + Tango). And I need a x86-64 compatible D compiler, so I'm not abandoning LDC. But other people will have to step in for D2 support. Unless of course I somehow magically convert to liking D2. But I doubt that's going to happen. -Tomas P.S. LDC is an open source project, and while I started it, many other people now have write access to the repository. I'm not holding anyone back from making the changes needed for D2 support. And in case someone out there wants it, I'll be happy to give you access as well (after seeing a first patch).
Re: Making alloca more safe
Tomas Lindquist Olsen wrote: You spent quite a bit of effort explaining that segfaults never cause memory corruption, so it seems fairly reasonable to assume that some parts of the application state could still be valid and useful not to throw away. When a seg fault occurs, it is because your program is in a state that you, the programmer, never anticipated. Therefore, you cannot know what state your data is in. Therefore, your data is unreliable. While it may not be in a bad state from memory corruption, it could very well be in a bad state from your program's logic being wrong. Do you want to bet your life on assuming your program and its data is still valid?
Re: Making alloca more safe
Tomas Lindquist Olsen wrote: LDC requires a lot of changes to the frontend. If you send me the changes, I can incorporate at least some of them, making subsequent versions easier to port to LDC.
Re: Should the comma operator be removed in D2?
KennyTM~ wrote: On Nov 17, 09 23:44, Ellery Newcomer wrote: Leandro Lucarella wrote: Ellery Newcomer, el 16 de noviembre a las 19:02 me escribiste: Justin Johansson wrote: Great. Sounds like problem solved in that there is no problem. So how do people feel about bill's suggestion to progress the issue further? Be good to get some comments from higher-up (Walter, Andrei)? Predict bearophile will chime in on this one too? The real problem is you'd end up with a tuple syntax identical to a valid c syntax. If D silently accepts it, but does something different, it's a no go. Code ported from C should not compile if the comma expression is converted to a tuple literal because if a and b are int, typeof(a,b) is int now and will be Tuple!(int, int) in the future, and I don't think a Tuple!(anything) could be implicitly casted to anything, except, maybe, another tuple, but you don't have tuples in C, so there is no risk on that. void fun1(int a); void fun1(Tuple!(int,int) a); fun1( (a=fizbang(), a+b) ); These are not code ported from *C*. all but the second fun1 are, and it could easily exist in D
Re: struct mixins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bill Baxter wrote: On Mon, Nov 16, 2009 at 11:32 AM, div0 d...@users.sourceforge.net wrote: snip vote++ I was going to suggest it when I finished my spirit port, but I was too lazy to in the end. It would be very handy as currently the only way support multiple policies is to use member vars which are basically pointers to empty classes, so it looks rather more ugly than it needs to be. Mixin should really go hog wild I think and let you mixin anything anywhere. I have wanted this kind of thing before too. I can't recall the exact reason, but it had something to do with traits structs. I hit it when I was porting OpenMesh to D. There's some base set of traits provided by the library as a struct that you may want to add too in user code. But I think alias this would probably serve that need just fine. What use cases are served by the mixin that 'alias this' does not? It looks like this was an attempt to explain, but I don't understand: See how a struct mixin could add an implicit/explicit cast to the mixed in structs. I guess mixin struct could allow a kind of static multiple inheritance. But if that's desirable, then probably alias this should just be extended to enable that. Seems like the two are so similar that whatever alias this lacks in features could just be added rather than introducing a new construct. --bb Well at the moment you only get one alias this. I suppose you could allow multiple alias this, but then what happens with multiple symbols with the same name? At least with mixins you can disambiguate. Still using member vars worked for me; there's more important stuff to be doing at the moment. - -- My enormous talent is exceeded only by my outrageous laziness. http://www.ssTk.co.uk -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFLAvMpT9LetA9XoXwRAuIZAKCyRCfzrXGEPJeH7n1zC/UcrHvsKACdFX8F qp4lpEqHtf0ruF0XSHVQUXM= =2zvO -END PGP SIGNATURE-
Re: D array expansion and non-deterministic re-allocation
Sean Kelly wrote: Denis Koroskin Wrote: Walter Bright Wrote: Denis Koroskin wrote: It is *non*-deterministic. The decision to reallocate depends (or will depend) on LRU and it may be cleared by another thread (e.g. another thread may reset it manually or via a GC cycle run). The LRU is thread local. It will then prevent a moving GC from being possible in D. Otherwise, moving a block of data will invalidate LRU which will result in non-deterministic reallocation. It won't work with the existing GC either. If a page is completely emptied then it can be re-used for different sized allocations. This is why the current cache is wiped during a collection. In both cases, the LRU can be adjusted rather than wiped to account for it.
Re: Making alloca more safe
On Tue, 17 Nov 2009 02:51:13 -0800, Walter Bright newshou...@digitalmars.com wrote: I suppose nobody much cares if it writes out a corrupted audio file. People care very much if their airplane suddenly dives into the ground. Be that as it may, it is certainly possible to catch seg faults in an exception handler and write files out. That would be an unacceptable behavior, though, in a system that needs to be safe. Yeah, you are right. It was just one example where continuing the execution after failure makes sense. Then, instead of sticking with Windows and the likes, you may want to think about porting dmd to a more serious environment specifically designed for developing such systems. What about a real-time microkernel OS like this one: http://www.qnx.com/products/neutrino_rtos/ ? dmd targets Windows because that's where probably half the programmers are. I'd certainly like to do embedded systems, too, but realistically that's going to be the purview of gdc or ldc. Ok.
Re: Should the comma operator be removed in D2?
Ellery Newcomer, el 17 de noviembre a las 12:58 me escribiste: Code ported from C should not compile if the comma expression is converted to a tuple literal because if a and b are int, typeof(a,b) is int now and will be Tuple!(int, int) in the future, and I don't think a Tuple!(anything) could be implicitly casted to anything, except, maybe, another tuple, but you don't have tuples in C, so there is no risk on that. void fun1(int a); void fun1(Tuple!(int,int) a); fun1( (a=fizbang(), a+b) ); These are not code ported from *C*. all but the second fun1 are, and it could easily exist in D We agree except for the *easily*. On the contrary, I think it would be extremely rare. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- CIRILO Y SIRACUSA DE SEÑORITA MAESTRA: UNO MUERTO Y OTRO PRESO -- Crónica TV
Re: lexertl
Ben Hanson Wrote: Hi there, My name is Ben Hanson and I am the author of lexertl (http://www.benhanson.net/lexertl.html), a lexical analyser generator written in C++. As the generator is modular, code generators can be added easily as separate files which means it is easy to output code for any language. I am interested in producing code generators for D and was wondering if this is interesting for anyone. If there is interest in lexertl, I would also be interested in rewriting the entire thing in D. Please let me know if anyone is interested in this. Thanks, Ben Looks very interesting. Zz
Re: Making alloca more safe
Andrei Alexandrescu Wrote: Sean Kelly wrote: Tomas Lindquist Olsen Wrote: On Tue, Nov 17, 2009 at 11:51 AM, Walter Bright newshou...@digitalmars.com wrote: I suppose nobody much cares if it writes out a corrupted audio file. People care very much if their airplane suddenly dives into the ground. Be that as it may, it is certainly possible to catch seg faults in an exception handler and write files out. That would be an unacceptable behavior, though, in a system that needs to be safe. You spent quite a bit of effort explaining that segfaults never cause memory corruption, so it seems fairly reasonable to assume that some parts of the application state could still be valid and useful not to throw away. At the moment the segfault occurs, sure. But if the process eats the segfault and continues, what happens? If an app is programmed in such a way that segfaults are a part of normal processing (I worked on a DB that performed dynamic loading this way) that's one thing. But other apps are almost definitely going to try and write data near 0x00 after such an occurrence. I think throwing an Error object instead of failing immediately would be occasionally useful. (Same goes about other trapped errors such as integral division by zero.) There are applications out there that want to partially recover from a null pointer error. I wrote a few, so it's difficult to convince me they don't exist. I'd love to! And this is how Windows works. But throwing an exception from a signal handler invokes undefined behavior. Last time I googled this I saw as many accounts of it failing horribly as working.
Re: Should the comma operator be removed in D2?
Leandro Lucarella wrote: Ellery Newcomer, el 17 de noviembre a las 12:58 me escribiste: void fun1(int a); void fun1(Tuple!(int,int) a); fun1( (a=fizbang(), a+b) ); These are not code ported from *C*. all but the second fun1 are, and it could easily exist in D We agree except for the *easily*. On the contrary, I think it would be extremely rare. I think by 'easily', I didn't exactly mean 'likely'. Sure it would be rare. Use of comma operator is pretty uncommon itself, from what I've seen (which doesn't include a lot of C code, however). I'm just saying this is one instance where it would cause problems. want another? how about this? int fizzbizz; int* bar; int i = (fizzbizz, bar)[0];
Re: Should the comma operator be removed in D2?
On Nov 18, 09 02:58, Ellery Newcomer wrote: KennyTM~ wrote: On Nov 17, 09 23:44, Ellery Newcomer wrote: Leandro Lucarella wrote: Ellery Newcomer, el 16 de noviembre a las 19:02 me escribiste: Justin Johansson wrote: Great. Sounds like problem solved in that there is no problem. So how do people feel about bill's suggestion to progress the issue further? Be good to get some comments from higher-up (Walter, Andrei)? Predict bearophile will chime in on this one too? The real problem is you'd end up with a tuple syntax identical to a valid c syntax. If D silently accepts it, but does something different, it's a no go. Code ported from C should not compile if the comma expression is converted to a tuple literal because if a and b are int, typeof(a,b) is int now and will be Tuple!(int, int) in the future, and I don't think a Tuple!(anything) could be implicitly casted to anything, except, maybe, another tuple, but you don't have tuples in C, so there is no risk on that. void fun1(int a); void fun1(Tuple!(int,int) a); fun1( (a=fizbang(), a+b) ); These are not code ported from *C*. all but the second fun1 are, and it could easily exist in D The only guarantee I knew is code valid in C either gives the same result in C, or fails to compile. Removing the 2nd fun1 which is invalid in C anyway, having a tuple syntax, fun1 simply fails to compile. I see no problem here.
Re: Should the comma operator be removed in D2?
Robert Jacques wrote:
On Tue, 17 Nov 2009 01:44:30 -0500, yigal chripun yigal...@gmail.com
wrote:
Robert Jacques Wrote:
However, I imagine tuple(a++,b++) would have some overhead, which is
exactly what someone is trying to avoid by using custom for loops.
Personally, I like using a..b = tuple(a,b), since it also solves the
multi-dimensional slicing and mixed indexing and slicing problems.
what overhead? It's all in your imagination :)
a..b is confusing and bad UI. a..b means for humans the range of a
till b and not the tuple of the two.
if I see something like hello..42 I would assume the person who
wrote this was high on something.
multi dimentinal slicing should accept an integer range type and NOT a
tuple.
The unnecessary creation and setting of a tuple struct is by definition
overhead. Also, containers will have non-integer slices, e.g.
dictionary[hello..world], and strided ranges would even mix types:
hello..42..world. My point isn't that '..' was a better syntax than
'(,)'. It's that '..' needs to change to something very much like a
tuple and therefore could be used to kill two birds with one stone.
what tuple struct are you talking about?
we are discussing real true tuples that are supported by the language
type system (meaning at compile-time), not some library struct type.
let me rephrase my sentence regarding slicing:
struct R { int start, stride, end; }
arrays should accept a list of the above R and a Dictionary should *not*
implement slicing since that requires an order which dictionaries have
no business to require.
OrderedDictionary!(T) (if you really want such a beast) would accept:
struct RR(T) {
T start, end;
int stride;
}
R and RR above are simplistic, real world impl. should make stride
optional but the main point is that it is by no means a tuple.
I see what you're saying about two birds with one stone but from my POV
instead of replacing old cruft with a useful and friendly to use new
feature you just added more cruft and hacks to poorly support said
feature with unfriendly and confusing syntax.
alignment on stack-allocated arrays/structs
I originally posted a question about this in D.learn. bearophile advised me to ask for that feature here. Original post: == OpenCL requires all types to be naturally aligned. The D specs state: AlignAttribute is ignored when applied to declarations that are not struct members. Could there arise any problems translating the following /* * Vector types * * Note: OpenCL requires that all types be naturally aligned. * This means that vector types must be naturally aligned. * For example, a vector of four floats must be aligned to * a 16 byte boundary (calculated as 4 * the natural 4-byte * alignment of the float). The alignment qualifiers here * will only function properly if your compiler supports them * and if you don't actively work to defeat them. For example, * in order for a cl_float4 to be 16 byte aligned in a struct, * the start of the struct must itself be 16-byte aligned. * * Maintaining proper alignment is the user's responsibility. */ typedef double cl_double2[2] __attribute__((aligned(16))); typedef double cl_double4[4] __attribute__((aligned(32))); typedef double cl_double8[8] __attribute__((aligned(64))); typedef double cl_double16[16] __attribute__((aligned(128))); into just alias double[2]cl_double2; alias double[4]cl_double4; alias double[8]cl_double8; alias double[16] cl_double16; ?
Re: Should the comma operator be removed in D2?
Robert Jacques wrote:
On Tue, 17 Nov 2009 11:38:19 -0500, Bill Baxter wbax...@gmail.com wrote:
On Tue, Nov 17, 2009 at 7:09 AM, Robert Jacques sandf...@jhu.edu wrote:
On Tue, 17 Nov 2009 05:44:31 -0500, downs default_357-l...@yahoo.de
wrote:
Robert Jacques wrote:
On Tue, 17 Nov 2009 00:06:27 -0500, Yigal Chripun yigal...@gmail.com
wrote:
Robert Jacques wrote:
On Mon, 16 Nov 2009 17:53:45 -0500, Stewart Gordon
smjg_1...@yahoo.com wrote:
dsimcha wrote:
snip
Axe. Looks like the only things it's good for are making code
undreadable and
abusing for loop syntax to...
Make code unreadable.
snip
Suppose you want the increment of a for loop to change two
variables
in parallel. I don't call that making code unreadable.
Stewart.
Yes the classic use case of the comma operator is multi-variable
declarations/increments in a for loop.
This was argued before and as I and others said before, this is *not*
a use case for the comma separator.
e.g.
for (int a = 0, b = 1; condition(); a++, b++) {...}
int a = 0, b = 1 // this is a declaration and not an expression
a++, b++ // isn't assigned to any variable and can be treated as a
tuple
the only use case that will break is if the two increments are
dependent on the order (unless tuples are also evaluated from left to
right):
e.g.
a + 5, b + a //
I doubt it very much that anyone ever uses this, it's too unreadable
to be useful.
However, I imagine tuple(a++,b++) would have some overhead, which is
exactly what someone is trying to avoid by using custom for loops.
Personally, I like using a..b = tuple(a,b), since it also solves the
multi-dimensional slicing and mixed indexing and slicing problems.
Zero overhead. Tuples are flat compile-time entities.
There are compile time tuples and runtime tuples. D already has a
form of
compile-time tuples. This discussion seems to be about runtime tuples
which
currently don't have a nice syntax: you have to use tuple(a,b). And
tuple(a,b) does have runtime overhead.
I think the point is that in something like this:
auto foo = (a,b);
foo.a += 2;
foo.b += foo.a;
// etc
The tuple foo is allocated on the stack and the compiler knows where
the a part and b part are, so the code generated should be absolutely
no different from the code generated for:
auto foo_a = a;
auto foo_b = b;
foo_a += 2;
foo_b += foo_a;
// etc
So there doesn't need to be any tuple overhead.
--bb
But that isn't the expansion:
for (int a = 0, b = 1; condition(); a++, b++) =
int a = 0;
int b = 0;
while(condition) {
auto temp = tuple(a++,b++); // creation of a struct on the stack
}
Now the optimizer might get rid of that temporary struct. Then again it
might not (or its presence interferes with other optimizations). At the
very least, some amount of code profiling or disassembly needs to be done.
why would it create a struct?
it would probably do:
int a = 0, b = 0;
while (condition) {
int temp_a = (a++); // temp_a == a + 1
int temp_b = (b++);
}
the above would most like be optimized by away.
you can also take advantage of tuples with for loops, something like:
for ( auto t = (0, 0); condition(); (t[1]++, t[2]++) ) {...}
this is more flexible since you can't do with the current system:
for (int a = 0, char b = 'a'; ; ) {...}
because int a = 0 is a declaration and not an expression.
with tuples:
for (auto t = (0, 'a'); ; ) {...}
OSS memory management
Found on Lambda the Ultimate, Thirty person-years of memory management development goes Open Source: http://www.ravenbrook.com/project/mps/doc/2002-01-30/ismm2002-paper/ Bye, bearophile
Re: struct mixins
On Tue, Nov 17, 2009 at 11:02 AM, div0 d...@users.sourceforge.net wrote: I guess mixin struct could allow a kind of static multiple inheritance. But if that's desirable, then probably alias this should just be extended to enable that. Seems like the two are so similar that whatever alias this lacks in features could just be added rather than introducing a new construct. --bb Well at the moment you only get one alias this. I suppose you could allow multiple alias this, but then what happens with multiple symbols with the same name? At least with mixins you can disambiguate. I don't see why you couldn't allow alias this to give you the same disambiguation capability. Or just get rid of alias this in favor of type mixins. Doesn't really matter to me. But I'm not seeing any reason to have both constructs when they do almost the same thing. --bb
Re: alignment on stack-allocated arrays/structs
On Tue, Nov 17, 2009 at 9:12 PM, Trass3r mrmoc...@gmx.de wrote: I originally posted a question about this in D.learn. bearophile advised me to ask for that feature here. Original post: == OpenCL requires all types to be naturally aligned. The D specs state: AlignAttribute is ignored when applied to declarations that are not struct members. Could there arise any problems translating the following /* * Vector types * * Note: OpenCL requires that all types be naturally aligned. * This means that vector types must be naturally aligned. * For example, a vector of four floats must be aligned to * a 16 byte boundary (calculated as 4 * the natural 4-byte * alignment of the float). The alignment qualifiers here * will only function properly if your compiler supports them * and if you don't actively work to defeat them. For example, * in order for a cl_float4 to be 16 byte aligned in a struct, * the start of the struct must itself be 16-byte aligned. * * Maintaining proper alignment is the user's responsibility. */ typedef double cl_double2[2] __attribute__((aligned(16))); typedef double cl_double4[4] __attribute__((aligned(32))); typedef double cl_double8[8] __attribute__((aligned(64))); typedef double cl_double16[16] __attribute__((aligned(128))); into just alias double[2] cl_double2; alias double[4] cl_double4; alias double[8] cl_double8; alias double[16] cl_double16; ? yep, D provides no way to do this, they'd all align to 4 bytes (at least on x86-32)
Re: Should the comma operator be removed in D2?
On Tue, Nov 17, 2009 at 11:30 AM, Ellery Newcomer ellery-newco...@utulsa.edu wrote: Leandro Lucarella wrote: Ellery Newcomer, el 17 de noviembre a las 12:58 me escribiste: void fun1(int a); void fun1(Tuple!(int,int) a); fun1( (a=fizbang(), a+b) ); These are not code ported from *C*. all but the second fun1 are, and it could easily exist in D We agree except for the *easily*. On the contrary, I think it would be extremely rare. I think by 'easily', I didn't exactly mean 'likely'. Sure it would be rare. Use of comma operator is pretty uncommon itself, from what I've seen (which doesn't include a lot of C code, however). I'm just saying this is one instance where it would cause problems. want another? how about this? int fizzbizz; int* bar; int i = (fizzbizz, bar)[0]; Now *that* looks like a winner. Good one. The last one that required a mix of C and D does not violate the rules. But this one does. However, I think for the good of humanity we can accept that one little bizarre example of legal C syntax not doing the same thing in D. I bet if we search hard enough we can find other examples of bizarre C that get interpreted differently by D. Probably you could concoct something based on the different interpretations of this declaration: int *a, b; I just recalled, though, that the comma operator can be overloaded in C++. What's D's policy on C++ code? --bb
Re: alignment on stack-allocated arrays/structs
Tomas Lindquist Olsen: yep, D provides no way to do this, they'd all align to 4 bytes (at least on x86-32) The idea, that I suggested to the LDC team too, is to extend the semantics of align, no new syntax seems needed: align(8) alias int[4] Foo; align(8) double good; Bye, bearophile
Re: Should the comma operator be removed in D2?
On Tue, Nov 17, 2009 at 1:02 PM, Bill Baxter wbax...@gmail.com wrote:
I bet if we search hard enough we can find other examples of bizarre C
that get interpreted differently by D.
Here's a biggie: the value type fixed-size arrays recently introduced.
It aint hard to find examples of C code like this that will now
compile, but malfunction, in D:
void setValue(float x[4], int el, float val) { x[el] = val; }
Yet despite that, the decision was made to go for it because on the
whole it's better for the language.
--bb
Re: Should the comma operator be removed in D2?
Bill Baxter wrote: Not sure how odious people would find forcing an order of eval on tuples, though. I've been looking at forcing an order of eval on all expressions. This will improve portability and repeatability. In some experiments I've done, the effect on performance is minimal.
Re: Should the comma operator be removed in D2?
Bill Baxter wrote: However, I think for the good of humanity we can accept that one little bizarre example of legal C syntax not doing the same thing in D. int[] i; auto a = (i)[0]; what does this do?
Re: Should the comma operator be removed in D2?
On Nov 18, 09 05:40, Ellery Newcomer wrote: Bill Baxter wrote: However, I think for the good of humanity we can accept that one little bizarre example of legal C syntax not doing the same thing in D. int[] i; auto a = (i)[0]; what does this do? (i) should not construct a tuple. Probably (i,).
Re: alignment on stack-allocated arrays/structs
On Tue, 17 Nov 2009 15:12:50 -0500, Trass3r mrmoc...@gmx.de wrote: I originally posted a question about this in D.learn. bearophile advised me to ask for that feature here. Original post: == OpenCL requires all types to be naturally aligned. The D specs state: AlignAttribute is ignored when applied to declarations that are not struct members. Could there arise any problems translating the following /* * Vector types * * Note: OpenCL requires that all types be naturally aligned. * This means that vector types must be naturally aligned. * For example, a vector of four floats must be aligned to * a 16 byte boundary (calculated as 4 * the natural 4-byte * alignment of the float). The alignment qualifiers here * will only function properly if your compiler supports them * and if you don't actively work to defeat them. For example, * in order for a cl_float4 to be 16 byte aligned in a struct, * the start of the struct must itself be 16-byte aligned. * * Maintaining proper alignment is the user's responsibility. */ typedef double cl_double2[2] __attribute__((aligned(16))); typedef double cl_double4[4] __attribute__((aligned(32))); typedef double cl_double8[8] __attribute__((aligned(64))); typedef double cl_double16[16] __attribute__((aligned(128))); into just alias double[2]cl_double2; alias double[4]cl_double4; alias double[8]cl_double8; alias double[16] cl_double16; ? To the best of my knowlegde, D only supports align(1) and align(4). On the other hand, compile time introspection allows my CUDA api to convert alignment correctly for any given struct. As for your question, yes, there's lot's of trouble using simple aliases. You'll run into alignment issues with both function calling and if you use cl_double2, etc in structs. Of course, alignment issues only raise their ugly heads some of the time, which often leads to brittle code. A robust OpenCL binding for D needs to do alignment correction.
Re: OSS memory management
On Tue, 17 Nov 2009 23:42:06 +0300, bearophile bearophileh...@lycos.com wrote: Found on Lambda the Ultimate, Thirty person-years of memory management development goes Open Source: http://www.ravenbrook.com/project/mps/doc/2002-01-30/ismm2002-paper/ Bye, bearophile Hmm, looks *very* interesting, thanks for a link, it's definitely worth a close look!
Re: Should the comma operator be removed in D2?
On Tue, Nov 17, 2009 at 1:51 PM, KennyTM~ kenn...@gmail.com wrote: On Nov 18, 09 05:40, Ellery Newcomer wrote: Bill Baxter wrote: However, I think for the good of humanity we can accept that one little bizarre example of legal C syntax not doing the same thing in D. int[] i; auto a = (i)[0]; what does this do? (i) should not construct a tuple. Probably (i,). That's Python's solution and it seems to work out ok. --bb
Re: OSS memory management
Denis Koroskin wrote: On Tue, 17 Nov 2009 23:42:06 +0300, bearophile bearophileh...@lycos.com wrote: Found on Lambda the Ultimate, Thirty person-years of memory management development goes Open Source: http://www.ravenbrook.com/project/mps/doc/2002-01-30/ismm2002-paper/ Bye, bearophile Hmm, looks *very* interesting, thanks for a link, it's definitely worth a close look! A bit dated though. I think there have been some developments in memory managers in the past 7 years. Andrei
Re: Should the comma operator be removed in D2?
Bill Baxter: (i) should not construct a tuple. Probably (i,). That's Python's solution and it seems to work out ok. Tuple syntax for 0, 1, n items is one of the few things that I don't like of Python :-) In Python this is an empty tuple: () Or: tuple() This is a tuple with 1 item: x, This is a tuple with 3 items x,y,z Parentheses are not necessary unless you want an empty tuple. Bye, bearophile
Re: Should the comma operator be removed in D2?
Walter Bright: I've been looking at forcing an order of eval on all expressions. This will improve portability and repeatability. In some experiments I've done, the effect on performance is minimal. I/we can do some benchmarks... I am curious. But I agree that forcing an order of expression eval is very good. Bye, bearophile
Re: Should the comma operator be removed in D2?
KennyTM~ wrote: On Nov 18, 09 05:40, Ellery Newcomer wrote: Bill Baxter wrote: However, I think for the good of humanity we can accept that one little bizarre example of legal C syntax not doing the same thing in D. int[] i; auto a = (i)[0]; what does this do? (i) should not construct a tuple. Probably (i,). I agree, a tuple of one element (doesn't matter what type, array in this case) should be semantically identical to that single element. proper semantics for language supported tuples should IMO include: 1) syntax to explicitly [de]construct tuples and no auto-flattening 2) a tuple of one element is identical to a scalar: int a = 5; // scalar integer auto b = (5); // tuple of one integer a == b // is true 3) function's argument list is a tuple like in ML: void foo(int a, char b); int a = 5; char b ='a'; auto tup = (5, 'a'); foo(a, b) is identical to foo(t); 4) unit type defined by the empty tuple instead of c-like void
Re: Should the comma operator be removed in D2?
I agree, a tuple of one element (doesn't matter what type, array in this case) should be semantically identical to that single element. proper semantics for language supported tuples should IMO include: 1) syntax to explicitly [de]construct tuples and no auto-flattening 2) a tuple of one element is identical to a scalar: int a = 5; // scalar integer auto b = (5); // tuple of one integer a == b // is true Interesting. It does kinda make sense. So should indexing work too? And properties? 5[0] == 5? 5.length == 1? If not that could be painful for functions that process generic N-tuples. If so then what does that do if the scalar type happens to be float*? 3) function's argument list is a tuple like in ML: void foo(int a, char b); int a = 5; char b ='a'; auto tup = (5, 'a'); foo(a, b) is identical to foo(t); That seems like a kind of auto-flattening. Shouldn't (t) be a tuple of a tuple? What if you have an actual tuple in the signature, like void foo((int a,char b))? Or you have both overloads -- foo(int,char) and foo((int,char)) I think I like Python's explicit explode tuple syntax better. foo(*t) Probably that syntax won't work for D, but I'd prefer explicit flattening over implicit. 4) unit type defined by the empty tuple instead of c-like void This is kind of neat, but does it actually change anything? Or just give an aesthetically pleasing meaning to void/unit? --bb
Re: Should the comma operator be removed in D2?
On Tue, 17 Nov 2009 15:20:06 -0500, Yigal Chripun yigal...@gmail.com
wrote:
Robert Jacques wrote:
On Tue, 17 Nov 2009 11:38:19 -0500, Bill Baxter wbax...@gmail.com
wrote:
On Tue, Nov 17, 2009 at 7:09 AM, Robert Jacques sandf...@jhu.edu
wrote:
On Tue, 17 Nov 2009 05:44:31 -0500, downs default_357-l...@yahoo.de
wrote:
Robert Jacques wrote:
On Tue, 17 Nov 2009 00:06:27 -0500, Yigal Chripun
yigal...@gmail.com
wrote:
Robert Jacques wrote:
On Mon, 16 Nov 2009 17:53:45 -0500, Stewart Gordon
smjg_1...@yahoo.com wrote:
dsimcha wrote:
snip
Axe. Looks like the only things it's good for are making code
undreadable and
abusing for loop syntax to...
Make code unreadable.
snip
Suppose you want the increment of a for loop to change two
variables
in parallel. I don't call that making code unreadable.
Stewart.
Yes the classic use case of the comma operator is multi-variable
declarations/increments in a for loop.
This was argued before and as I and others said before, this is
*not*
a use case for the comma separator.
e.g.
for (int a = 0, b = 1; condition(); a++, b++) {...}
int a = 0, b = 1 // this is a declaration and not an expression
a++, b++ // isn't assigned to any variable and can be treated as a
tuple
the only use case that will break is if the two increments are
dependent on the order (unless tuples are also evaluated from left
to
right):
e.g.
a + 5, b + a //
I doubt it very much that anyone ever uses this, it's too
unreadable
to be useful.
However, I imagine tuple(a++,b++) would have some overhead, which is
exactly what someone is trying to avoid by using custom for loops.
Personally, I like using a..b = tuple(a,b), since it also solves
the
multi-dimensional slicing and mixed indexing and slicing problems.
Zero overhead. Tuples are flat compile-time entities.
There are compile time tuples and runtime tuples. D already has a
form of
compile-time tuples. This discussion seems to be about runtime tuples
which
currently don't have a nice syntax: you have to use tuple(a,b). And
tuple(a,b) does have runtime overhead.
I think the point is that in something like this:
auto foo = (a,b);
foo.a += 2;
foo.b += foo.a;
// etc
The tuple foo is allocated on the stack and the compiler knows where
the a part and b part are, so the code generated should be absolutely
no different from the code generated for:
auto foo_a = a;
auto foo_b = b;
foo_a += 2;
foo_b += foo_a;
// etc
So there doesn't need to be any tuple overhead.
--bb
But that isn't the expansion:
for (int a = 0, b = 1; condition(); a++, b++) =
int a = 0;
int b = 0;
while(condition) {
auto temp = tuple(a++,b++); // creation of a struct on the stack
}
Now the optimizer might get rid of that temporary struct. Then again
it might not (or its presence interferes with other optimizations). At
the very least, some amount of code profiling or disassembly needs to
be done.
why would it create a struct?
it would probably do:
int a = 0, b = 0;
while (condition) {
int temp_a = (a++); // temp_a == a + 1
int temp_b = (b++);
}
the above would most like be optimized by away.
you can also take advantage of tuples with for loops, something like:
for ( auto t = (0, 0); condition(); (t[1]++, t[2]++) ) {...}
this is more flexible since you can't do with the current system:
for (int a = 0, char b = 'a'; ; ) {...}
because int a = 0 is a declaration and not an expression.
with tuples:
for (auto t = (0, 'a'); ; ) {...}
*sigh* The reason the compiler would have to create a temporary struct, is
because that's what a tuple is at runtime. Tuples need to be compact (like
structs) so that they can be passed to functions, etc.
Re: Should the comma operator be removed in D2?
On Tue, Nov 17, 2009 at 2:53 PM, Robert Jacques sandf...@jhu.edu wrote:
On Tue, 17 Nov 2009 15:20:06 -0500, Yigal Chripun yigal...@gmail.com
wrote:
Robert Jacques wrote:
On Tue, 17 Nov 2009 11:38:19 -0500, Bill Baxter wbax...@gmail.com
wrote:
On Tue, Nov 17, 2009 at 7:09 AM, Robert Jacques sandf...@jhu.edu
wrote:
On Tue, 17 Nov 2009 05:44:31 -0500, downs default_357-l...@yahoo.de
wrote:
Robert Jacques wrote:
On Tue, 17 Nov 2009 00:06:27 -0500, Yigal Chripun
yigal...@gmail.com
wrote:
Robert Jacques wrote:
On Mon, 16 Nov 2009 17:53:45 -0500, Stewart Gordon
smjg_1...@yahoo.com wrote:
dsimcha wrote:
snip
Axe. Looks like the only things it's good for are making code
undreadable and
abusing for loop syntax to...
Make code unreadable.
snip
Suppose you want the increment of a for loop to change two
variables
in parallel. I don't call that making code unreadable.
Stewart.
Yes the classic use case of the comma operator is multi-variable
declarations/increments in a for loop.
This was argued before and as I and others said before, this is
*not*
a use case for the comma separator.
e.g.
for (int a = 0, b = 1; condition(); a++, b++) {...}
int a = 0, b = 1 // this is a declaration and not an expression
a++, b++ // isn't assigned to any variable and can be treated as a
tuple
the only use case that will break is if the two increments are
dependent on the order (unless tuples are also evaluated from left
to
right):
e.g.
a + 5, b + a //
I doubt it very much that anyone ever uses this, it's too unreadable
to be useful.
However, I imagine tuple(a++,b++) would have some overhead, which is
exactly what someone is trying to avoid by using custom for loops.
Personally, I like using a..b = tuple(a,b), since it also solves the
multi-dimensional slicing and mixed indexing and slicing problems.
Zero overhead. Tuples are flat compile-time entities.
There are compile time tuples and runtime tuples. D already has a form
of
compile-time tuples. This discussion seems to be about runtime tuples
which
currently don't have a nice syntax: you have to use tuple(a,b). And
tuple(a,b) does have runtime overhead.
I think the point is that in something like this:
auto foo = (a,b);
foo.a += 2;
foo.b += foo.a;
// etc
The tuple foo is allocated on the stack and the compiler knows where
the a part and b part are, so the code generated should be absolutely
no different from the code generated for:
auto foo_a = a;
auto foo_b = b;
foo_a += 2;
foo_b += foo_a;
// etc
So there doesn't need to be any tuple overhead.
--bb
But that isn't the expansion:
for (int a = 0, b = 1; condition(); a++, b++) =
int a = 0;
int b = 0;
while(condition) {
auto temp = tuple(a++,b++); // creation of a struct on the stack
}
Now the optimizer might get rid of that temporary struct. Then again it
might not (or its presence interferes with other optimizations). At the very
least, some amount of code profiling or disassembly needs to be done.
why would it create a struct?
it would probably do:
int a = 0, b = 0;
while (condition) {
int temp_a = (a++); // temp_a == a + 1
int temp_b = (b++);
}
the above would most like be optimized by away.
you can also take advantage of tuples with for loops, something like:
for ( auto t = (0, 0); condition(); (t[1]++, t[2]++) ) {...}
this is more flexible since you can't do with the current system:
for (int a = 0, char b = 'a'; ; ) {...}
because int a = 0 is a declaration and not an expression.
with tuples:
for (auto t = (0, 'a'); ; ) {...}
*sigh* The reason the compiler would have to create a temporary struct, is
because that's what a tuple is at runtime. Tuples need to be compact (like
structs) so that they can be passed to functions, etc.
Sigh back at ya. I think all of us are just assuming that the
compiler will be smart enough to realize that the tuple value is not
being used and optimize it away.
It should be fairly trivial to detect and handle appropriately. At
least in the case of that for loop there. I think unused value
elimination is probably one of the first things you study in compiler
classes on optimization. It must be because even *I* know about it
and I've only taken one compiler class that barely touched on
optimization at all. :-)
--bb
Re: Should the comma operator be removed in D2?
Ellery Newcomer wrote:
Bill Baxter wrote:
On Tue, Nov 17, 2009 at 1:51 PM, KennyTM~ kenn...@gmail.com wrote:
On Nov 18, 09 05:40, Ellery Newcomer wrote:
Bill Baxter wrote:
However, I think for the good of humanity we can accept that one
little bizarre example of legal C syntax not doing the same thing in
D.
int[] i;
auto a = (i)[0];
what does this do?
(i) should not construct a tuple. Probably (i,).
That's Python's solution and it seems to work out ok.
--bb
How do we express tuple types? Since we have tuple expression syntactic
support, we should have tuple type syntactic support. Cuz I'm going to
want stuff like
Tuple!(int,int) [] lst;
These won't work:
[int,int] [] lst;
(int,int) [] lst; //want
{int,int} [] lst;
these might:
@(int,int) [] lst; //bleach, regardless of what symbol '@' is
(,int,int) [] lst; //bleach
alias (int,int) T; T [] lst; //bleach bleach bleach
int,int [] lst; //requires tuple expressions be enclosed in () h...
and you'd have to enclose the types in () in nonstatement locations
actually, types vs expressions are already syntactically ambiguous, so
(int,int) [] lst; doesn't lose much. It's not the kind of thing we
should be encouraging, though.
Re: Should the comma operator be removed in D2?
Bill Baxter wrote:
On Tue, Nov 17, 2009 at 1:51 PM, KennyTM~ kenn...@gmail.com wrote:
On Nov 18, 09 05:40, Ellery Newcomer wrote:
Bill Baxter wrote:
However, I think for the good of humanity we can accept that one
little bizarre example of legal C syntax not doing the same thing in
D.
int[] i;
auto a = (i)[0];
what does this do?
(i) should not construct a tuple. Probably (i,).
That's Python's solution and it seems to work out ok.
--bb
How do we express tuple types? Since we have tuple expression syntactic
support, we should have tuple type syntactic support. Cuz I'm going to
want stuff like
Tuple!(int,int) [] lst;
These won't work:
[int,int] [] lst;
(int,int) [] lst; //want
{int,int} [] lst;
these might:
@(int,int) [] lst; //bleach, regardless of what symbol '@' is
(,int,int) [] lst; //bleach
alias (int,int) T; T [] lst; //bleach bleach bleach
int,int [] lst; //requires tuple expressions be enclosed in () h...
actually, types vs expressions are already syntactically ambiguous, so
(int,int) [] lst; doesn't lose much. It's not the kind of thing we
should be encouraging, though.
Re: Should the comma operator be removed in D2?
Ellery Newcomer wrote:
Ellery Newcomer wrote:
Bill Baxter wrote:
On Tue, Nov 17, 2009 at 1:51 PM, KennyTM~ kenn...@gmail.com wrote:
On Nov 18, 09 05:40, Ellery Newcomer wrote:
Bill Baxter wrote:
However, I think for the good of humanity we can accept that one
little bizarre example of legal C syntax not doing the same thing in
D.
int[] i;
auto a = (i)[0];
what does this do?
(i) should not construct a tuple. Probably (i,).
That's Python's solution and it seems to work out ok.
--bb
How do we express tuple types? Since we have tuple expression syntactic
support, we should have tuple type syntactic support. Cuz I'm going to
want stuff like
Tuple!(int,int) [] lst;
These won't work:
[int,int] [] lst;
(int,int) [] lst; //want
{int,int} [] lst;
these might:
@(int,int) [] lst; //bleach, regardless of what symbol '@' is
(,int,int) [] lst; //bleach
alias (int,int) T; T [] lst; //bleach bleach bleach
int,int [] lst; //requires tuple expressions be enclosed in () h...
and you'd have to enclose the types in () in nonstatement locations
which is a big bleach
actually, types vs expressions are already syntactically ambiguous, so
(int,int) [] lst; doesn't lose much. It's not the kind of thing we
should be encouraging, though.
Re: Should the comma operator be removed in D2?
On Tue, Nov 17, 2009 at 3:01 PM, Ellery Newcomer ellery-newco...@utulsa.edu wrote: Bill Baxter wrote: On Tue, Nov 17, 2009 at 1:51 PM, KennyTM~ kenn...@gmail.com wrote: On Nov 18, 09 05:40, Ellery Newcomer wrote: Bill Baxter wrote: However, I think for the good of humanity we can accept that one little bizarre example of legal C syntax not doing the same thing in D. int[] i; auto a = (i)[0]; what does this do? (i) should not construct a tuple. Probably (i,). That's Python's solution and it seems to work out ok. --bb How do we express tuple types? ... These won't work: ... (int,int) [] lst; //want Why won't that work? You may be right, but that particular declaration doesn't seem ambiguous to me. --bb
Re: Should the comma operator be removed in D2?
Bill Baxter wrote: On Tue, Nov 17, 2009 at 3:01 PM, Ellery Newcomer ellery-newco...@utulsa.edu wrote: Bill Baxter wrote: On Tue, Nov 17, 2009 at 1:51 PM, KennyTM~ kenn...@gmail.com wrote: On Nov 18, 09 05:40, Ellery Newcomer wrote: Bill Baxter wrote: However, I think for the good of humanity we can accept that one little bizarre example of legal C syntax not doing the same thing in D. int[] i; auto a = (i)[0]; what does this do? (i) should not construct a tuple. Probably (i,). That's Python's solution and it seems to work out ok. --bb How do we express tuple types? ... These won't work: ... (int,int) [] lst; //want Why won't that work? You may be right, but that particular declaration doesn't seem ambiguous to me. --bb foo!( (i,i) ) (); compiler doesn't know if 'i' is a type or a variable. Like I said, the problem already exists for eg foo!( i ) (); and isn't semantically ambiguous (as far as I know..), so it is doable. at statement level, it would require a lot of lookahead to distinguish eg (i,i)[0] = blah; (i,i)[0] blah; Not my idea of good language design (one character deep in the production - can you say fortran :) actually fortran is worse, it discards whitespace as token separators)
Re: Should the comma operator be removed in D2?
Ellery Newcomer wrote: Bill Baxter wrote: On Tue, Nov 17, 2009 at 3:01 PM, Ellery Newcomer ellery-newco...@utulsa.edu wrote: Bill Baxter wrote: On Tue, Nov 17, 2009 at 1:51 PM, KennyTM~ kenn...@gmail.com wrote: On Nov 18, 09 05:40, Ellery Newcomer wrote: Bill Baxter wrote: However, I think for the good of humanity we can accept that one little bizarre example of legal C syntax not doing the same thing in D. int[] i; auto a = (i)[0]; what does this do? (i) should not construct a tuple. Probably (i,). That's Python's solution and it seems to work out ok. --bb How do we express tuple types? ... These won't work: ... (int,int) [] lst; //want Why won't that work? You may be right, but that particular declaration doesn't seem ambiguous to me. --bb foo!( (i,i) ) (); compiler doesn't know if 'i' is a type or a variable. by compiler I mean parser. compiler eventually will figure it out. Like I said, the problem already exists for eg foo!( i ) (); and isn't semantically ambiguous (as far as I know..), so it is doable. at statement level, it would require a lot of lookahead to distinguish eg (i,i)[0] = blah; (i,i)[0] blah; Not my idea of good language design (one character deep in the production - can you say fortran :) actually fortran is worse, it discards whitespace as token separators)
Re: Should the comma operator be removed in D2?
Tue, 17 Nov 2009 15:04:01 -0800, Bill Baxter wrote: On Tue, Nov 17, 2009 at 2:53 PM, Robert Jacques sandf...@jhu.edu *sigh* The reason the compiler would have to create a temporary struct, is because that's what a tuple is at runtime. Tuples need to be compact (like structs) so that they can be passed to functions, etc. Sigh back at ya. I think all of us are just assuming that the compiler will be smart enough to realize that the tuple value is not being used and optimize it away. It should be fairly trivial to detect and handle appropriately. At least in the case of that for loop there. I think unused value elimination is probably one of the first things you study in compiler classes on optimization. It must be because even *I* know about it and I've only taken one compiler class that barely touched on optimization at all. :-) Elimination of unused values has been one of the basic optimizations in C compilers for decades. E.g. gcc 4.4 does tremendous amounts of optimizations and the constant folding logic might even optimize away the whole 'for' loop, the function containing the for loop or even the whole object file containing the function. If this kind of argumentation is used against new features, almost every high level feature in D should be shaved off - classes, scope statements, all literals etc. There is a serious amount of extra code those produce compared to a hand crafted asm version of the program.
Re: alignment on stack-allocated arrays/structs
Robert Jacques schrieb: To the best of my knowlegde, D only supports align(1) and align(4). On the other hand, compile time introspection allows my CUDA api to convert alignment correctly for any given struct. gotta look that up in your code. Maybe I also find some other ideas for writing my wrapper. It currently is a plain OO-approach using classes for platform, device, kernel, etc. But maybe one can exploit D's capabilities to make things easier to program. Something along the lines of http://ochafik.free.fr/blog/?p=207 while not retricting what can be done with the wrapper compared to plain OpenCL...
Re: Should the comma operator be removed in D2?
Mon, 16 Nov 2009 17:08:58 -0600, Ellery Newcomer wrote:
dsimcha wrote:
Axe. Looks like the only things it's good for are making code
undreadable and abusing for loop syntax to...
Make code unreadable.
When the heck would this be significantly more readable, safer, or more
concise than doing the equivalent without it? Also, from previous
discussions I vaguely remember it's constraining other parts of the
syntax.
I've used them occasionally with regard to ref parameters
Object foo(Object bar, ref bool flag);
while( guard(bizz) (fizz = foo(bizz,ok), ok)){}
although I suppose it doesn't score so highly on the readable scale..
This kind of code wouldn't go pass the code review process at my
workplace. It might be valuable principle for your employer if you're
paid by the line, though..
Re: Should the comma operator be removed in D2?
Tue, 17 Nov 2009 22:01:37 +0200, Yigal Chripun wrote: I see what you're saying about two birds with one stone but from my POV instead of replacing old cruft with a useful and friendly to use new feature you just added more cruft and hacks to poorly support said feature with unfriendly and confusing syntax. Hear, hear. Someone is really attempting to *remove* cruft instead of adding it.
Re: Should the comma operator be removed in D2?
Mon, 16 Nov 2009 18:22:24 -0500, Adam D. Ruppe wrote: On Mon, Nov 16, 2009 at 05:00:56PM -0600, Ellery Newcomer wrote: wrong. assignment has higher precedence than comma. Oh, duh. And I use that fact in for loops all the time too... change the first to a = (b, c); Right - this illustrates what I had in mind. I think this pretty much sums up how error prone the feature can be even in the hands of an experienced programmer..
Re: Should the comma operator be removed in D2?
retard wrote: workplace. It might be valuable principle for your employer mah wut? :)
