Re: String Mixins
Travis Boucher 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.
Hi Travis,
I've only been 'round here for a few months myself and often find myself
in need of answers to such questions. I believe, though, that this is
the sort of question that the group prefers to have asked on D.learn.
That's also a better forum for other newbies to find answers as well.
Regards,
Justin Johansson
Re: Should the comma operator be removed in D2?
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.
String Mixins
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.
Re: About switch case statements...
grauzone wrote: Walter Bright wrote: Reminds me a bit of D a few years back, when people would say D didn't have lambda's. But D did have them! The problem was the syntax was a bit verbose. Simplified the syntax, and suddenly the lambda's got noticed and got used. D has no tuples. I see what you did there.
Re: Should the comma operator be removed in D2?
On Tue, 17 Nov 2009 00:06:27 -0500, Yigal Chripun
wrote:
Robert Jacques wrote:
On Mon, 16 Nov 2009 17:53:45 -0500, Stewart Gordon
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.
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.
Re: Should the comma operator be removed in D2?
Robert Jacques wrote:
On Mon, 16 Nov 2009 17:53:45 -0500, Stewart Gordon
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.
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.
Re: Should the comma operator be removed in D2?
== Quote from Robert Jacques (sandf...@jhu.edu)'s article
> On Mon, 16 Nov 2009 17:53:45 -0500, Stewart Gordon
> 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.
> >
> >
> > 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.
But in D we have the scope statement that makes incrementing multiple variables
trivial even in the presence of breaks and continues:
for(size_t i = 0; i <= 10; i++) {
scope(exit) otherVariable++;
}
It would be one thing if the comma operator were an innocent feature that wasn't
hurting anything, but it uses up a very nice piece of syntax on something that
usually serves to make code much less readable.
Re: XMLP
Jesse Phillips Wrote:
>
> This really sounds like a DMD installation issue than XMLP. Create a
> hello world program in an arbitrary location and try this command.
>
> F:\laguangeD\DLang\DTwo\dmd\windows\bin\dmd hello.d
F:\DLang\DEx\D2Ex\anoy.d:
module anoy;
import std.stdio;
void pause()
{
writeln("Press any key to continue...");
readln;
}
int main(string[] args)
{
int a=12;
string str="hello";
int b=24;
int c={return a+b;}();
writefln("The result is %d",c);
pause;
return 0;
}
F:\DLang\DEx\D2Ex>F:\DLang\DTwo\dmd\windows\bin\dmd anoy.d
F:\DLang\DEx\D2Ex>dmd
Digital Mars D Compiler v2.036
Copyright (c) 1999-2009 by Digital Mars written by Walter Bright
Documentation: http://www.digitalmars.com/d/2.0/index.html
Usage:
dmd files.d ... { -switch }
files.dD source files
@cmdfile read arguments from cmdfile
-c do not link
-cov do code coverage analysis
-D generate documentation
-Dddocdir write documentation file to docdir directory
-Dffilenamewrite documentation file to filename
-d allow deprecated features
-debug compile in debug code
-debug=level compile in debug code <= level
-debug=ident compile in debug code identified by ident
-debuglib=nameset symbolic debug library to name
-defaultlib=name set default library to name
-deps=filename write module dependencies to filename
-g add symbolic debug info
-gcadd symbolic debug info, pretend to be C
-H generate 'header' file
-Hddirectory write 'header' file to directory
-Hffilenamewrite 'header' file to filename
--help print help
-Ipath where to look for imports
-ignoreignore unsupported pragmas
-inlinedo function inlining
-Jpath where to look for string imports
-Llinkerflag pass linkerflag to link
-lib generate library rather than object files
-man open web browser on manual page
-nofloat do not emit reference to floating point
-O optimize
-o-do not write object file
-odobjdir write object & library files to directory objdir
-offilenamename output file to filename
-opdo not strip paths from source file
-profile profile runtime performance of generated code
-quiet suppress unnecessary messages
-release compile release version
-run srcfile args... run resulting program, passing args
-safe safe memory model
-unittest compile in unit tests
-v verbose
-version=level compile in version code >= level
-version=ident compile in version code identified by ident
-vtls list all variables going into thread local storage
-w enable warnings
-X generate JSON file
-Xffilenamewrite JSON file to filename
F:\DLang\DEx\D2Ex>F:\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:
Regards,
Sam
Re: D array expansion and non-deterministic re-allocation
BCS wrote: would you agree that it is not something the programer can predict in advance? He can, but it is not reasonable to expect him to. But it's still deterministic.
Re: D array expansion and non-deterministic re-allocation
Hello Walter, Nick Sabalausky wrote: Deterministic? Only in the same sense that "resize or realloc upon appending" is deterministic. It's deterministic in the sense that if you run the program again with the same inputs, you will get the same result. This is a highly useful attribute for testing and debugging. A non-deterministic problem will give you a different result every time you run it. Threading problems are an example of this, as are any dependencies on uninitialized data. This particular issue is implementation-defined. would you agree that it is not something the programer can predict in advance?
Re: XMLP
On Mon, 16 Nov 2009 21:15:22 -0500, Sam Hu wrote: > Denis Koroskin Wrote: >> Could you please check you DMD installation? Does a trivial Hello, >> World! application work? > > Sure .it work fine. > This really sounds like a DMD installation issue than XMLP. Create a hello world program in an arbitrary location and try this command. F:\laguangeD\DLang\DTwo\dmd\windows\bin\dmd hello.d
Re: Should the comma operator be removed in D2?
On Mon, 16 Nov 2009 17:53:45 -0500, Stewart Gordon 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. 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.
Re: XMLP
Denis Koroskin Wrote: > Could you please check you DMD installation? Does a trivial Hello, World! > application work? Sure .it work fine. Below is the build message: F:\laguangeD\xmlp\trunk>build2 F:\laguangeD\xmlp\trunk>set DROOT=F:\laguangeD\DLang\DTwo\ F:\laguangeD\xmlp\trunk>set PLIB=F:\laguangeD\DLang\DTwo\dmd\src\phobos\ F:\laguangeD\xmlp\trunk>set XP=xmlp\ F:\laguangeD\xmlp\trunk>set DCOMP=F:\laguangeD\DLang\DTwo\dmd\windows\bin\dmd F:\laguangeD\xmlp\trunk>set src=xmlp\format.d xmlp\xmlrules.d xmlp\recode.d xmlp \except.d xmlp\xmldom.d xmlp\input.d xmlp\pieceparser.d xmlp\delegater.d F:\laguangeD\xmlp\trunk>F:\laguangeD\DLang\DTwo\dmd\windows\bin\dmd -g -ofTestXm lConf xmlp\format.d xmlp\xmlrules.d xmlp\recode.d xmlp\except.d xmlp\xmldom.d xm lp\input.d xmlp\pieceparser.d xmlp\delegater.d F:\laguangeD\DLang\DTwo\dmd\src\p hobos\std/file.d XmlConf.d" object.d: Error: module object cannot read file 'object.d' F:\laguangeD\xmlp\trunk>F:\laguangeD\DLang\DTwo\dmd\windows\bin\dmd -g -ofTestBo oks xmlp\format.d xmlp\xmlrules.d xmlp\recode.d xmlp\except.d xmlp\xmldom.d xmlp \input.d xmlp\pieceparser.d xmlp\delegater.d F:\laguangeD\DLang\DTwo\dmd\src\pho bos\std/file.d ElementHandler.d" object.d: Error: module object cannot read file 'object.d' F:\laguangeD\xmlp\trunk>F:\laguangeD\DLang\DTwo\dmd\windows\bin\dmd -release -of RelXmlConf xmlp\format.d xmlp\xmlrules.d xmlp\recode.d xmlp\except.d xmlp\xmldom .d xmlp\input.d xmlp\pieceparser.d xmlp\delegater.d F:\laguangeD\DLang\DTwo\dmd\ src\phobos\std/file.d XmlConf.d" object.d: Error: module object cannot read file 'object.d' F:\laguangeD\xmlp\trunk>F:\laguangeD\DLang\DTwo\dmd\windows\bin\dmd -release -of RelBooks xmlp\format.d xmlp\xmlrules.d xmlp\recode.d xmlp\except.d xmlp\xmldom.d xmlp\input.d xmlp\pieceparser.d xmlp\delegater.d F:\laguangeD\DLang\DTwo\dmd\sr c\phobos\std/file.d ElementHandler.d" object.d: Error: module object cannot read file 'object.d' F:\laguangeD\xmlp\trunk>
Re: XMLP
Denis Koroskin Wrote: > Could you please check you DMD installation? Does a trivial Hello, World! > application work? Yes.sure it works fine. ^-^
Re: Should the comma operator be removed in D2?
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.
Re: Should the comma operator be removed in D2?
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(; i<10; ++i,++j) // just works
for should be a special case
Re: XMLP
On Tue, 17 Nov 2009 03:49:25 +0300, Sam Hu wrote: Michael Rynn Wrote: The XMLP project is on DSource. http://www.dsource.org/projects/xmlp michael *^&^* I already downloaded and trie the test,but it seems it can't get passed under DMD2.036 due to "can not find object.d". Could you please check you DMD installation? Does a trivial Hello, World! application work?
Re: Should the comma operator be removed in D2?
grauzone 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. 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(; i<10; ++i,++j) // just works That's nice. Though, probably this case needs some special treatment to continue working: int i=0,j=0 Does it need to be a special case? "int i=0,j=0" is one declaration (with variables separated by a comma), not something glued together with the comma operator. Of course normal declarations like "int i, j;" also would continue to work. Not all commas are part of a comma expression. 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?
Re: XMLP
Michael Rynn Wrote: > The XMLP project is on DSource. > > http://www.dsource.org/projects/xmlp > > michael *^&^* I already downloaded and trie the test,but it seems it can't get passed under DMD2.036 due to "can not find object.d".
Re: Should the comma operator be removed in D2?
"Justin Johansson" wrote in message news:hdskj6$12b...@digitalmars.com... > Nick Sabalausky wrote: >> "Justin Johansson" wrote in message >> news:hdsi9d$uf...@digitalmars.com... >>> Mentioned in the switch case statements thread, this probably should be >>> a separate discussion thread. >>> >>> Is the comma operator "another piece of C cruft" that needs to be >>> removed from D(2)? >>> >> >> Aside from the for loop (which could be special cased or just simply >> rewritten), I've never used, or had reason to use, the comma operator in >> all the programming I've ever done in D, C/C++ (which I used to use all >> the time), or any other language. I strongly vote "ditch it". There are >> far better potential uses for a comma anyway. >> >> Speaking of C cruft, why the hell do we still have C's god-awful octal >> syntax? Everyone but Walter's complained about it. And I don't want to >> hear "to help port C code", because the whole reason I got started on D >> in the first place was to get away from idiotic C designs. Besides, it's >> not like "0([0-9]+)" is hard to grep for. > > Hey, Nick. Don't try and hijack *my* thread; go get your own deleted> thread. Ha. :-) > Heh, that is actually a good point. My apologies. :)
Re: Making alloca more safe
Walter Bright: >is that biology achieves reliability by using redundancy, not by requiring >individual components to be perfect. The redundancy goes down to the DNA >level, even. Another way is it uses quantity, rather than quality. Many >organisms produce millions of offspring in the hope that one or two survive.< Quantity is a form of redundancy. In biology reliability is achieved in many ways. Your genetic code is degenerated, so many single letter mutations lead to no mutated proteins. This leads to neural mutations. Bones and tendons use redundancy too to be resilient, but they aren't flat organizations, they are hierarchies of structures inside larger structures, at all levels, from the molecular level up; this allows for a different kind of failures, like in earthquakes (many small ones, few large ones, with a power law distribution). A protein is a chain of small parts, and its function is partially determined by its form. This forms is mostly self-created. But once in a while few other proteins help shape up the other proteins, especially when the temperature is too much high. Most biological systems are able to self-repair, that usually means cells that die and duplicate and sometimes they build harder structures like bones. This happens at a sub-cellular level too, cells have many systems to repair and clean themselves, they keep destroying and rebuilding their parts at all levels, and you can see it among neurons too: your memory is encoded (among other things) by the connections between neurons, but they die. So new connections among even very old neurons can be created, and they replace the missing wiring, keeping the distributed memory functional even 100 years after the events, in very old people. Genetic information is encoded in multiple copies, and sometimes in bacteria distribuited in the population. Reliability is necessary when you copy or read the genetic information, this comes from a balance from the energy used to copy and how much reliable you want such read/copy, and how much fast you want it (actually ribosomes and DNA polymerase are about on the theoretical minimum of this 3-variable optimization, you can't do better even in theory). Control systems, like those in the brain, seek reliability in several different ways. One of them is encoding vectors in a small population of neurons. The final direction of where your finger points is found by such vectorized average. Parkinson's disease can kill 90% of the cells in certain zones, yet I can keep being able to move the hand to grab a glass of water (a little shaky, because the average is computed on much less vectors). There is enough stuff to write more than one science popularization article :-) >how would you write a program that would be expected to survive having a >random bit in it flipped at random intervals?< That's a nice question. The program and all its data is stored somewhere, usually on RAM, caches, and registers. How can you use a program if bits in your RAM can flip at random with a certain (low) probability? There are error-correction RAM memories, based on redundancy codes, like Reed-Solomon one. ECC memory is today common enough. Similar error correction schemes can be added to inner parts of the CPU too (and probably someone has done it, for example in CPUs that must work in space on satellites, where the Sun radiation is not shielded by the earth atmosphere). I am sure related schemes can be used to test if a CPU instruction has done its purpose of if during its execution something has gone wrong. You can fix such things in hardware too. But there are other solutions beside fixing all errors. Today chips keep getting smaller, and power for each transistor keeps going down. Eventually noise and errors will start to grow. Recently some people have realized that on the screen of a mobile telephone you can tolerate few wrongly decompressed pixels from a video, if this allows the chip to use only 1/10 of the normal energy used. Sometimes you want few wrong pixels here and there if they allow you to keep seeing videos on your mobile telephone for twice long. In future CPUs will probably become less reliable, so they software (mostly operating system, I think) will need to invent ways to fix those errors. This will allow to keep programs globally reliable even with fast low powered CPUs. Molecular-scale adders will need software to fix their errors. Eventually this is going to become more and more like cellular biochemistry, with all its active redundancy :-) There's no end to the amount of things you can say on this topic. Bye, bearophile
Re: Should the comma operator be removed in D2?
Bill Baxter wrote: On Mon, Nov 16, 2009 at 2:04 PM, Justin Johansson wrote: Mentioned in the switch case statements thread, this probably should be a separate discussion thread. Is the comma operator "another piece of C cruft" that needs to be removed from D(2)? grauzone wrote: Justin Johansson wrote: bearophile wrote: What's bad about forcing people to write: case A, B, C: Instead of: case A: case B: case C: ? Bye, bearophile I don't know about "forcing people" to write such but perhaps it could be an "option for people" :-) Actually I quite like the brevity you propose but would it be a challenge for the comma operator? While ago, I got D multi-dimensional array syntax messed up and declared such an animal as int[3,4,5] which effectively ended up declaring the beast as int[5]. The comma operator is another piece of C cruft that needs to go. 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. 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(; i<10; ++i,++j) // just works That's nice. Though, probably this case needs some special treatment to continue working: int i=0,j=0 Does it need to be a special case? "int i=0,j=0" is one declaration (with variables separated by a comma), not something glued together with the comma operator. Of course normal declarations like "int i, j;" also would continue to work. Not all commas are part of a comma expression. --bb
Re: Should the comma operator be removed in D2?
Bill Baxter wrote: On Mon, Nov 16, 2009 at 2:04 PM, Justin Johansson wrote: Mentioned in the switch case statements thread, this probably should be a separate discussion thread. Is the comma operator "another piece of C cruft" that needs to be removed from D(2)? grauzone wrote: Justin Johansson wrote: bearophile wrote: What's bad about forcing people to write: case A, B, C: Instead of: case A: case B: case C: ? Bye, bearophile I don't know about "forcing people" to write such but perhaps it could be an "option for people" :-) Actually I quite like the brevity you propose but would it be a challenge for the comma operator? While ago, I got D multi-dimensional array syntax messed up and declared such an animal as int[3,4,5] which effectively ended up declaring the beast as int[5]. The comma operator is another piece of C cruft that needs to go. 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. 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(; i<10; ++i,++j) // just works Though, probably this case needs some special treatment to continue working: int i=0,j=0 --bb Whilst I still have some affection for the C-style comma operator (particularly wrt for loop construct), but since the Waterfront Real Estate of operators is extremely limited (borrowing a phrase from Walter), I think this is an excellent suggestion to re-purpose the comma operator for higher-value utilization by tuples. Would the "special treatments" be not too difficult to resolve? beers, Justin
Re: static interface
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
}
I only know enough about the inner workings of compiling Classes to be able to
follow explanation why my ideas won't work. This could give a very clear
compiler error, but just doesn't appear wrong outside of that.
Re: Should the comma operator be removed in D2?
On Mon, Nov 16, 2009 at 2:04 PM, Justin Johansson wrote: > Mentioned in the switch case statements thread, this probably should be a > separate discussion thread. > > Is the comma operator "another piece of C cruft" that needs to be removed > from D(2)? > > > grauzone wrote: >> Justin Johansson wrote: >>> bearophile wrote: What's bad about forcing people to write: case A, B, C: Instead of: case A: case B: case C: ? Bye, bearophile >>> >>> I don't know about "forcing people" to write such but perhaps it could >>> be an "option for people" :-) >>> >>> Actually I quite like the brevity you propose but would it be a >>> challenge for the comma operator? >>> >>> While ago, I got D multi-dimensional array syntax messed up and >>> declared such an animal as >>> int[3,4,5] which effectively ended up declaring the beast as int[5]. >> >> The comma operator is another piece of C cruft that needs to go. 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. 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(; i<10; ++i,++j) // just works Though, probably this case needs some special treatment to continue working: int i=0,j=0 --bb
Re: Should the comma operator be removed in D2?
Jason House wrote: > Lutger Wrote: > >> dsimcha wrote: >> >> > == Quote from Justin Johansson (n...@spam.com)'s article >> >> Mentioned in the switch case statements thread, this probably should >> >> be a separate discussion thread. >> >> Is the comma operator "another piece of C cruft" that needs to be >> >> removed from D(2)? >> >> grauzone wrote: >> >> > Justin Johansson wrote: >> >> >> bearophile wrote: >> >> >>> What's bad about forcing people to write: >> >> >>> case A, B, C: >> >> >>> >> >> >>> Instead of: >> >> >>> case A: >> >> >>> case B: >> >> >>> case C: >> >> >>> ? >> >> >>> >> >> >>> Bye, >> >> >>> bearophile >> >> >> >> >> >> I don't know about "forcing people" to write such but perhaps it >> >> >> could be an "option for people" :-) >> >> >> >> >> >> Actually I quite like the brevity you propose but would it be a >> >> >> challenge for the comma operator? >> >> >> >> >> >> While ago, I got D multi-dimensional array syntax messed up and >> >> >> declared such an animal as >> >> >> int[3,4,5] which effectively ended up declaring the beast as >> >> >> int[5]. >> >> > >> >> > The comma operator is another piece of C cruft that needs to go. >> >> > >> >> >> Cheers Justin >> > >> > Can someone please explain to me what the comma operator does? I've >> > seen this >> > mentioned here before, but I really don't know. Then again, if the >> > only people who use it are crufty old C language lawyers and people who >> > have never programmed seriously in C before don't know about it, I >> > guess that's an indicator that it's not worth much. >> >> It is very simple, evaluates the expression before the comma and after >> the comma. The result is the value of the expression after the comma. >> >> int a = 1; >> int b = --a, ++a; >> assert(b == 1); >> assert(a == 1); > > I'm no language lawyer, but I'm pretty sure that's not right. I don't > think there's an order of evaluation rules. b could just as easilly end up > with a value of 2. No I think it's right, also in C++: http://www.digitalmars.com/d/2.0/expression.html http://en.wikipedia.org/wiki/Sequence_point
Re: Should the comma operator be removed in D2?
Lutger Wrote: > dsimcha wrote: > > > == Quote from Justin Johansson (n...@spam.com)'s article > >> Mentioned in the switch case statements thread, this probably should be > >> a separate discussion thread. > >> Is the comma operator "another piece of C cruft" that needs to be > >> removed from D(2)? > >> grauzone wrote: > >> > Justin Johansson wrote: > >> >> bearophile wrote: > >> >>> What's bad about forcing people to write: > >> >>> case A, B, C: > >> >>> > >> >>> Instead of: > >> >>> case A: > >> >>> case B: > >> >>> case C: > >> >>> ? > >> >>> > >> >>> Bye, > >> >>> bearophile > >> >> > >> >> I don't know about "forcing people" to write such but perhaps it > >> >> could be an "option for people" :-) > >> >> > >> >> Actually I quite like the brevity you propose but would it be a > >> >> challenge for the comma operator? > >> >> > >> >> While ago, I got D multi-dimensional array syntax messed up and > >> >> declared such an animal as > >> >> int[3,4,5] which effectively ended up declaring the beast as int[5]. > >> > > >> > The comma operator is another piece of C cruft that needs to go. > >> > > >> >> Cheers Justin > > > > Can someone please explain to me what the comma operator does? I've seen > > this > > mentioned here before, but I really don't know. Then again, if the only > > people who use it are crufty old C language lawyers and people who have > > never programmed seriously in C before don't know about it, I guess that's > > an indicator that it's not worth much. > > It is very simple, evaluates the expression before the comma and after the > comma. The result is the value of the expression after the comma. > > int a = 1; > int b = --a, ++a; > assert(b == 1); > assert(a == 1); I'm no language lawyer, but I'm pretty sure that's not right. I don't think there's an order of evaluation rules. b could just as easilly end up with a value of 2.
Re: static interface
On Mon, Nov 16, 2009 at 9:25 AM, Leandro Lucarella 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".
>
> struct Stride(T): InputRange(T) {
> // implementation
> }
>
> struct Stride(T) if (isInputRange!(T)) {
> // implementation
> }
There's really not a significant difference in those two.
> size_t walkLength(InputRange range, size_t upTo = size_t.max)
> {
>// implementation
> }
> size_t walkLength(Range)(Range range, size_t upTo = size_t.max)
> if (isInputRange!(Range))
> {
>// implementation
> }
Here is the only one where I see a significant improvement. Basically
that all comes from not having to repeat yourself.
So maybe we'd be better off attacking that repetitiveness directly.
But in terms of functionality it seems we cover pretty much everything
static interface gives you.
The only exception may be that static interfaces could give you better
error messages about why your type doesn't satisfy the requirements.
That's where better ways to get the error messages from
__traits(compiles,...) errors come in. But it's harder to make that
useful in D without giving up overloading. In D if T doesn't satisfy
isInputRange!(T), it might satisfy some other overload of the
template.
--bb
Re: About switch case statements...
Ellery Newcomer wrote: Andrei Alexandrescu wrote: Ellery Newcomer wrote: Andrei Alexandrescu wrote: Ellery Newcomer wrote: KennyTM~ wrote: throw ...; assert(...); you can call functions which do these... ... which is where the "none"/"bottom" type comes into play! Andrei What what? http://en.wikipedia.org/wiki/Bottom_type http://www.cs.washington.edu/research/projects/cecil/www/Release/doc-cecil-stdlib/node4.html I gave a talk about similar stuff once but I don't know where it is. I also have 70% of an article on it written (and with a funny introduction to boot) but I couldn't find the time * interest to finish. Andrei So a function that always throws should have a result type (maximal type?) of bottom type? Yah, because it never actually returns. Functions like abort() or exit() would return bottom in a type system that supports it. Andrei
Re: About switch case statements...
Andrei Alexandrescu wrote: > Ellery Newcomer wrote: >> Andrei Alexandrescu wrote: >>> Ellery Newcomer wrote: KennyTM~ wrote: > throw ...; > assert(...); > you can call functions which do these... >>> ... which is where the "none"/"bottom" type comes into play! >>> >>> Andrei >> >> What what? > > http://en.wikipedia.org/wiki/Bottom_type > http://www.cs.washington.edu/research/projects/cecil/www/Release/doc-cecil-stdlib/node4.html > > > I gave a talk about similar stuff once but I don't know where it is. I > also have 70% of an article on it written (and with a funny introduction > to boot) but I couldn't find the time * interest to finish. > > > Andrei So a function that always throws should have a result type (maximal type?) of bottom type?
Re: About switch case statements...
Ellery Newcomer wrote: Andrei Alexandrescu wrote: Ellery Newcomer wrote: KennyTM~ wrote: throw ...; assert(...); you can call functions which do these... ... which is where the "none"/"bottom" type comes into play! Andrei What what? http://en.wikipedia.org/wiki/Bottom_type http://www.cs.washington.edu/research/projects/cecil/www/Release/doc-cecil-stdlib/node4.html I gave a talk about similar stuff once but I don't know where it is. I also have 70% of an article on it written (and with a funny introduction to boot) but I couldn't find the time * interest to finish. Andrei
Re: About switch case statements...
Andrei Alexandrescu wrote: > Ellery Newcomer wrote: >> KennyTM~ wrote: >>> throw ...; >>> assert(...); >>> >> >> you can call functions which do these... > > ... which is where the "none"/"bottom" type comes into play! > > Andrei What what?
Re: Making alloca more safe
Denis Koroskin wrote:
On Mon, 16 Nov 2009 20:39:57 +0300, Andrei Alexandrescu
wrote:
Denis Koroskin wrote:
On Mon, 16 Nov 2009 19:27:41 +0300, Andrei Alexandrescu
wrote:
bearophile wrote:
Walter Bright:
A person using alloca is expecting stack allocation, and that it
goes away after the function exits. Switching arbitrarily to the
gc will not be detected and may hide a programming error (asking
for a gigantic piece of memory is not anticipated for alloca, and
could be caused by an overflow or logic error in calculating its
size).
There's another solution, that I'd like to see more often used in
Phobos: you can add another function to Phobos, let's call it
salloca (safe alloca) that does what Denis Koroskin asks for (it's
a very simple function).
Can't be written. Try it.
Andrei
It's tricky. It can't be written *without a compiler support*,
because it is considered special for a compiler (it always inlines
the call to it). It could be written otherwise.
I was thinking about proposing either an inline keyword in a
language (one that would enforce function inlining, rather than
suggesting it to compiler), or allways inline all the functions that
make use of alloca. Without either of them, it is impossible to
create wrappers around alloca (for example, one that create arrays on
stack type-safely and without casts):
T[] array_alloca(T)(size_t size) { ... }
or one that would return GC-allocated memory when stack allocation
fails:
void* salloca(size_t size) {
void* ptr = alloca(size);
if (ptr is null) return (new void[size]).ptr;
return ptr;
}
The problem of salloca is that alloca's memory gets released when
salloca returns.
Andrei
You missed the point of my post. I know it can't be implemented, and I
told just that. I also told about 2 possible solutions to this issue.
I see now. Apologies.
Andrei
Re: static interface
Leandro Lucarella wrote: Andrei Alexandrescu, el 16 de noviembre a las 12:19 me escribiste: grauzone wrote: Leandro Lucarella wrote: Why not? ;) The actual question is if Andrei/Walter are interested at all in this. Because they didn't show any interest so far. D will probably be doomed to compile time bug-typing I mean duck-typing forever. There's an embarrassment of riches when it comes to finding stuff to work on for D2. I think we need to resign ourselves to the idea that we need to focus only on one subset of the stream of good ideas that are being proposed. I completely agree and understand. I wish I had the time to make patches myself for the things I propose. But it's very different if something is not implemented because it sucks or just because the lack of men power :) If some good feature has Walter's blessing, maybe other person can implement it. Nobody wants to implement something if it doesn't have Walter's blessing, because we all know he's very tough to convince, and nobody wants to work on something it won't get accepted. What I can tell is that Walter's keenness on adding/changing something has a 10-fold improvement if a patch is present. For example Walter was sort of ambivalent about opDollar and opDollar!(dim)() until Don simply added it. FWIW I was keen on structs interacting in interesting ways with interfaces (and submitted a number of enhancements in that directions) but then realized there are a number of problems that structs/interfaces cannot solve. I believe that a better path to pursue in checking interface conformance is via reflection. But that's very laborious, to be honest, I saw some points in std.range that would be hard to cover with static interfaces, but for those things you have all the flexibility you're already using. But static interfaces could cover a wide range of applications, making static duck-typing very easy to use. There's a saying that most all girls may look good in the dark. Paraphrasing that, I'd say all language features look nice and easy when (a) detail is not discussed, (b) all the rest of the language is assumed to be mastered. There are places in D where we can't do what we want to do. Those are top priority. Those that do easier what we can do anyway (struct mixins, static interfaces, even the better switch which I actually personally like) are below top priority. The barrier is fuzzy because either I, Walter, or Don may suddenly catch fancy to a specific thing to work on, but I wish we were more, not less disciplined about that. Andrei
Re: Should the comma operator be removed in D2?
On Mon, Nov 16, 2009 at 11:06:28PM +, Stewart Gordon wrote: > Expression: > AssignExpression > AssignExpression , Expression > > So it's the same as > > a = b; > c; Right, moment of stupidity there for me. I should have put it in parenthesis. > > Stewart. -- Adam D. Ruppe http://arsdnet.net
Re: Should the comma operator be removed in D2?
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. -- Adam D. Ruppe http://arsdnet.net
Re: Should the comma operator be removed in D2?
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..
Re: Should the comma operator be removed in D2?
Adam D. Ruppe wrote: On Mon, Nov 16, 2009 at 10:12:57PM +, dsimcha wrote: Can someone please explain to me what the comma operator does? a = b, c; Is the same as: b; a = c; Wrong: Expression: AssignExpression AssignExpression , Expression So it's the same as a = b; c; Stewart.
Re: Std. Lib and Binary Attribution
Hello Robert, The problem is that if std.extra gets statically linked in (i.e. in the normal manner), then you'd have to include the license, even if you don't use the library. phobos.lib and phobos_extra.lib
Re: Should the comma operator be removed in D2?
Adam D. Ruppe wrote: > On Mon, Nov 16, 2009 at 10:12:57PM +, dsimcha wrote: >> Can someone please explain to me what the comma operator does? > > a = b, c; > > Is the same as: > > b; > a = c; > wrong. assignment has higher precedence than comma. change the first to a = (b, c); or the second to a = b; c;
Re: Should the comma operator be removed in D2?
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. Suppose you want the increment of a for loop to change two variables in parallel. I don't call that making code unreadable. Stewart.
Re: Should the comma operator be removed in D2?
Nick Sabalausky wrote: "Justin Johansson" wrote in message news:hdsi9d$uf...@digitalmars.com... Mentioned in the switch case statements thread, this probably should be a separate discussion thread. Is the comma operator "another piece of C cruft" that needs to be removed from D(2)? Aside from the for loop (which could be special cased or just simply rewritten), I've never used, or had reason to use, the comma operator in all the programming I've ever done in D, C/C++ (which I used to use all the time), or any other language. I strongly vote "ditch it". There are far better potential uses for a comma anyway. Speaking of C cruft, why the hell do we still have C's god-awful octal syntax? Everyone but Walter's complained about it. And I don't want to hear "to help port C code", because the whole reason I got started on D in the first place was to get away from idiotic C designs. Besides, it's not like "0([0-9]+)" is hard to grep for. Hey, Nick. Don't try and hijack *my* thread; go get your own thread. Ha. :-)
Re: Should the comma operator be removed in D2?
"Justin Johansson" wrote in message news:hdsi9d$uf...@digitalmars.com... > Mentioned in the switch case statements thread, this probably should be a > separate discussion thread. > > Is the comma operator "another piece of C cruft" that needs to be removed > from D(2)? > Aside from the for loop (which could be special cased or just simply rewritten), I've never used, or had reason to use, the comma operator in all the programming I've ever done in D, C/C++ (which I used to use all the time), or any other language. I strongly vote "ditch it". There are far better potential uses for a comma anyway. Speaking of C cruft, why the hell do we still have C's god-awful octal syntax? Everyone but Walter's complained about it. And I don't want to hear "to help port C code", because the whole reason I got started on D in the first place was to get away from idiotic C designs. Besides, it's not like "0([0-9]+)" is hard to grep for.
Re: Should the comma operator be removed in D2?
Adam D. Ruppe wrote:
On Mon, Nov 16, 2009 at 10:12:57PM +, dsimcha wrote:
Can someone please explain to me what the comma operator does?
a = b, c;
Is the same as:
b;
a = c;
In the comma operation, the first thing is evaluate, and its result discarded.
Then, the second thing (after the comma) is evaluated. The overall result
of the comma operator is the result of the second statement.
1, 2 == 2
The usefulness is putting two statements together, where it only expects
one, like inside the for loop, where the semicolon moves you on from the
initialization to the condition.
Speaking of for loops, it's not uncommon to use the comma operator in
the 1st and 3rd expression places, e.g. (in C), something along the lines:
void fun( char* start, int n) {
int i;
char* p;
for ( i = 0, p = start; (i < n) && (*p != 0); ++i, ++p) {
/* ... */
}
}
Re: Making alloca more safe
On Mon, 16 Nov 2009 20:39:57 +0300, Andrei Alexandrescu
wrote:
Denis Koroskin wrote:
On Mon, 16 Nov 2009 19:27:41 +0300, Andrei Alexandrescu
wrote:
bearophile wrote:
Walter Bright:
A person using alloca is expecting stack allocation, and that it
goes away after the function exits. Switching arbitrarily to the gc
will not be detected and may hide a programming error (asking for a
gigantic piece of memory is not anticipated for alloca, and could be
caused by an overflow or logic error in calculating its size).
There's another solution, that I'd like to see more often used in
Phobos: you can add another function to Phobos, let's call it salloca
(safe alloca) that does what Denis Koroskin asks for (it's a very
simple function).
Can't be written. Try it.
Andrei
It's tricky. It can't be written *without a compiler support*, because
it is considered special for a compiler (it always inlines the call to
it). It could be written otherwise.
I was thinking about proposing either an inline keyword in a language
(one that would enforce function inlining, rather than suggesting it to
compiler), or allways inline all the functions that make use of alloca.
Without either of them, it is impossible to create wrappers around
alloca (for example, one that create arrays on stack type-safely and
without casts):
T[] array_alloca(T)(size_t size) { ... }
or one that would return GC-allocated memory when stack allocation
fails:
void* salloca(size_t size) {
void* ptr = alloca(size);
if (ptr is null) return (new void[size]).ptr;
return ptr;
}
The problem of salloca is that alloca's memory gets released when
salloca returns.
Andrei
You missed the point of my post. I know it can't be implemented, and I
told just that. I also told about 2 possible solutions to this issue.
Re: Should the comma operator be removed in D2?
dsimcha wrote: >> While ago, I got D multi-dimensional array syntax messed up and >> declared such an animal as >> int[3,4,5] which effectively ended up declaring the beast as int[5]. > > The comma operator is another piece of C cruft that needs to go. > >> Cheers Justin Can someone please explain to me what the comma operator does? I've seen this mentioned here before, but I really don't know. Then again, if the only people who use it are crufty old C language lawyers and people who have never programmed seriously in C before don't know about it, I guess that's an indicator that it's not worth much. When (sub)expressions are separated with the comma operator, each (sub)expression is evaluated from left to right in turn (as if the individual (sub)expressions where separated by ; (semicolon) statement separator. The result returned by the overall expression is the result returned by the last (sub)expression (i.e., following the last comma). In the array example above, int[3,4,5], the dimension expression 3,4,5 evaluates 3 (a constant), then 4 (another constant), and then 5 (yet another constant) and returns 5, this being the last subexpression evaluated. This is why the array ended up being effectively a single dimension array of length 5. Justin
Re: Should the comma operator be removed in D2?
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.
Re: Should the comma operator be removed in D2?
== Quote from Lutger (lutger.blijdest...@gmail.com)'s article > dsimcha wrote: > > == Quote from Justin Johansson (n...@spam.com)'s article > >> Mentioned in the switch case statements thread, this probably should be > >> a separate discussion thread. > >> Is the comma operator "another piece of C cruft" that needs to be > >> removed from D(2)? > >> grauzone wrote: > >> > Justin Johansson wrote: > >> >> bearophile wrote: > >> >>> What's bad about forcing people to write: > >> >>> case A, B, C: > >> >>> > >> >>> Instead of: > >> >>> case A: > >> >>> case B: > >> >>> case C: > >> >>> ? > >> >>> > >> >>> Bye, > >> >>> bearophile > >> >> > >> >> I don't know about "forcing people" to write such but perhaps it > >> >> could be an "option for people" :-) > >> >> > >> >> Actually I quite like the brevity you propose but would it be a > >> >> challenge for the comma operator? > >> >> > >> >> While ago, I got D multi-dimensional array syntax messed up and > >> >> declared such an animal as > >> >> int[3,4,5] which effectively ended up declaring the beast as int[5]. > >> > > >> > The comma operator is another piece of C cruft that needs to go. > >> > > >> >> Cheers Justin > > > > Can someone please explain to me what the comma operator does? I've seen > > this > > mentioned here before, but I really don't know. Then again, if the only > > people who use it are crufty old C language lawyers and people who have > > never programmed seriously in C before don't know about it, I guess that's > > an indicator that it's not worth much. > It is very simple, evaluates the expression before the comma and after the > comma. The result is the value of the expression after the comma. > 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.
Re: About switch case statements...
Denis Koroskin wrote:
BTW, if a macro was declared as
#define BASIC_TYPES\
TOKwchar: case TOKdchar:\
case TOKbit: case TOKbool: case TOKchar:\
case TOKint8: case TOKuns8:\
case TOKint16: case TOKuns16:\
case TOKint32: case TOKuns32:\
case TOKint64: case TOKuns64:\
case TOKfloat32: case TOKfloat64: case TOKfloat80:\
case TOKimaginary32: case TOKimaginary64: case TOKimaginary80:\
case TOKcomplex32: case TOKcomplex64: case TOKcomplex80:\
case TOKvoid
(note an absence of the first case) then it would cause compile-time
error instead of run-time bugs. Usage:
switch (token) {
case TOKidentifier:
case TOKenum:
case TOKstruct:
case TOKimport:
case BASIC_TYPES:
}
I like that. Great suggestion!
Re: Should the comma operator be removed in D2?
dsimcha wrote: > == Quote from Justin Johansson (n...@spam.com)'s article >> Mentioned in the switch case statements thread, this probably should be >> a separate discussion thread. >> Is the comma operator "another piece of C cruft" that needs to be >> removed from D(2)? >> grauzone wrote: >> > Justin Johansson wrote: >> >> bearophile wrote: >> >>> What's bad about forcing people to write: >> >>> case A, B, C: >> >>> >> >>> Instead of: >> >>> case A: >> >>> case B: >> >>> case C: >> >>> ? >> >>> >> >>> Bye, >> >>> bearophile >> >> >> >> I don't know about "forcing people" to write such but perhaps it >> >> could be an "option for people" :-) >> >> >> >> Actually I quite like the brevity you propose but would it be a >> >> challenge for the comma operator? >> >> >> >> While ago, I got D multi-dimensional array syntax messed up and >> >> declared such an animal as >> >> int[3,4,5] which effectively ended up declaring the beast as int[5]. >> > >> > The comma operator is another piece of C cruft that needs to go. >> > >> >> Cheers Justin > > Can someone please explain to me what the comma operator does? I've seen > this > mentioned here before, but I really don't know. Then again, if the only > people who use it are crufty old C language lawyers and people who have > never programmed seriously in C before don't know about it, I guess that's > an indicator that it's not worth much. It is very simple, evaluates the expression before the comma and after the comma. The result is the value of the expression after the comma. int a = 1; int b = --a, ++a; assert(b == 1); assert(a == 1);
Re: Should the comma operator be removed in D2?
On Mon, Nov 16, 2009 at 10:12:57PM +, dsimcha wrote: > Can someone please explain to me what the comma operator does? a = b, c; Is the same as: b; a = c; In the comma operation, the first thing is evaluate, and its result discarded. Then, the second thing (after the comma) is evaluated. The overall result of the comma operator is the result of the second statement. 1, 2 == 2 The usefulness is putting two statements together, where it only expects one, like inside the for loop, where the semicolon moves you on from the initialization to the condition. -- Adam D. Ruppe http://arsdnet.net
XMLP
The XMLP project is on DSource. http://www.dsource.org/projects/xmlp I have got as far getting it to pass all the namespace and XML 1.0/1.1 test cases. I have been having a look at the w3c XPath recommendations, but I am still baulking at getting deep into that. -- michael *^&^*
Re: D array expansion and non-deterministic re-allocation
Nick Sabalausky wrote: Even if it is technically determinate if you run it on the same machine with the same inputs, that still does nothing to address Bartosz's claim that it's a potential security hole - Apps don't always get run on the same machine with the same inputs. It's not a security hole in any more serious manner than any other routine programming bug would be. Very few ordinary programming bugs are exploitable. A buffer overflow, however, is much more of a security hole because they are nearly always exploitable, because it allows arbitrary user data to be executed. This is not the case with the array resizing issue. That's why I drew a distinction between undefined-behavior and implementation-defined behavior. The former is a couple more orders of magnitude more serious.
Re: Should the comma operator be removed in D2?
== Quote from Justin Johansson (n...@spam.com)'s article > Mentioned in the switch case statements thread, this probably should be > a separate discussion thread. > Is the comma operator "another piece of C cruft" that needs to be > removed from D(2)? > grauzone wrote: > > Justin Johansson wrote: > >> bearophile wrote: > >>> What's bad about forcing people to write: > >>> case A, B, C: > >>> > >>> Instead of: > >>> case A: > >>> case B: > >>> case C: > >>> ? > >>> > >>> Bye, > >>> bearophile > >> > >> I don't know about "forcing people" to write such but perhaps it could > >> be an "option for people" :-) > >> > >> Actually I quite like the brevity you propose but would it be a > >> challenge for the comma operator? > >> > >> While ago, I got D multi-dimensional array syntax messed up and > >> declared such an animal as > >> int[3,4,5] which effectively ended up declaring the beast as int[5]. > > > > The comma operator is another piece of C cruft that needs to go. > > > >> Cheers Justin Can someone please explain to me what the comma operator does? I've seen this mentioned here before, but I really don't know. Then again, if the only people who use it are crufty old C language lawyers and people who have never programmed seriously in C before don't know about it, I guess that's an indicator that it's not worth much.
Re: Making alloca more safe
bearophile wrote: They use a different design strategy to be so reliable. My understanding (I am no biologist) is that biology achieves reliability by using redundancy, not by requiring individual components to be perfect. The redundancy goes down to the DNA level, even. Another way is it uses quantity, rather than quality. Many organisms produce millions of offspring in the hope that one or two survive. Software, on the other hand, is notorious for one bit being wrong out of a billion rendering it completely useless. A strategy of independent redundancy is appropriate here. For example, how would you write a program that would be expected to survive having a random bit in it flipped at random intervals?
Re: About switch case statements...
On Mon, 16 Nov 2009 11:58:44 +0300, MIURA Masahiro wrote: On 11/16/2009 02:49 AM, Chad J wrote: So, switch-case statements are a frequent source of nasty bugs. Fixing them (well) requires breaking backwards compatibility. Any chance this will happen for D2? If I remember correctly, one of D's design policies is that a D code that looks like C code should behave like C. Are we giving up that policy? It is a good policy to follow but there are cases where C behavior may differ from D behavior (when code is copy-pasted and not adjusted according to languages difference). I've just posted an example in a different thread: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=101322
Re: About switch case statements...
On Mon, 16 Nov 2009 23:36:38 +0300, 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.
(2) it's an extremely common writing style in human languages, thus aids
readability.
(3) case A:
case B:
case C:
is ambiguous. It looks like the coder put in place markers for
intended
code but forgot the code.
When porting some C++ code to D (okay, it was DMDFE), I had exact same
issue. There is the following macro defined:
#define CASE_BASIC_TYPES\
case TOKwchar: case TOKdchar: \
case TOKbit: case TOKbool: case TOKchar:\
case TOKint8: case TOKuns8: \
case TOKint16: case TOKuns16: \
case TOKint32: case TOKuns32: \
case TOKint64: case TOKuns64: \
case TOKfloat32: case TOKfloat64: case TOKfloat80: \
case TOKimaginary32: case TOKimaginary64: case TOKimaginary80: \
case TOKcomplex32: case TOKcomplex64: case TOKcomplex80:\
case TOKvoid
and if was used (and got translated to D) as follows:
switch (token) {
case TOKidentifier:
case TOKenum:
case TOKstruct:
case TOKimport:
CASE_BASIC_TYPES:
}
Did you noticed it already? It is a valid C code *but* has different
semantics! In D, CASE_BASIC_TYPES is merely a label, and it does just
nothing. Needless to say the code compiled successfully, but produced
weird error messages at run-time.
BTW, if a macro was declared as
#define BASIC_TYPES \
TOKwchar: case TOKdchar: \
case TOKbit: case TOKbool: case TOKchar:\
case TOKint8: case TOKuns8: \
case TOKint16: case TOKuns16: \
case TOKint32: case TOKuns32: \
case TOKint64: case TOKuns64: \
case TOKfloat32: case TOKfloat64: case TOKfloat80: \
case TOKimaginary32: case TOKimaginary64: case TOKimaginary80: \
case TOKcomplex32: case TOKcomplex64: case TOKcomplex80:\
case TOKvoid
(note an absence of the first case) then it would cause compile-time error
instead of run-time bugs. Usage:
switch (token) {
case TOKidentifier:
case TOKenum:
case TOKstruct:
case TOKimport:
case BASIC_TYPES:
}
Should the comma operator be removed in D2?
Mentioned in the switch case statements thread, this probably should be a separate discussion thread. Is the comma operator "another piece of C cruft" that needs to be removed from D(2)? grauzone wrote: > Justin Johansson wrote: >> bearophile wrote: >>> What's bad about forcing people to write: >>> case A, B, C: >>> >>> Instead of: >>> case A: >>> case B: >>> case C: >>> ? >>> >>> Bye, >>> bearophile >> >> I don't know about "forcing people" to write such but perhaps it could >> be an "option for people" :-) >> >> Actually I quite like the brevity you propose but would it be a >> challenge for the comma operator? >> >> While ago, I got D multi-dimensional array syntax messed up and >> declared such an animal as >> int[3,4,5] which effectively ended up declaring the beast as int[5]. > > The comma operator is another piece of C cruft that needs to go. > >> Cheers Justin
Re: Making alloca more safe
Tomas Lindquist Olsen wrote: You sure got all the answers... I had it beaten into my head by people who had 50 years of experience designing reliable airliners - what worked and what didn't work. The consensus on what constitutes best practices for software reliability is steadily improving, but I still think the airliner companies are more advanced in that regard. Even your car has a dual path design (for the brakes)!
Re: Making alloca more safe
I am sorry for having mixed global reliability of a system with the discussion about non nullable class references. It's my fault. Those are two very different topics, as Walter says. Here I give few comments, but please try to keep the two things separated. If that's not possible, feel free to ignore this post... Adam D. Ruppe: >Would you have preferred it to just randomly do its own thing and potentially >end up landing on people?< Your mind is now working in terms of 0/1. But that's not how most things in the universe work. A guide system designed with different design principles may have guided it safely, with a small error in the trajectory, that may be fixed later in orbit. >Even expensive, important pieces of equipment can always be replaced.< The scientific equipment it was carrying is lost, no one has replaced it so far. It was very complex. >What would you have it do? Carry on in the error state, doing Lord knows what? >That's clearly unsafe.< My idea was to have a type system that avoids such errors :-) >Hospitals know their medical machines might screw up, so they keep a nurse on >duty at all times who can handle the situation - restart the failed machine, >or bring in a replacement before it kills someone.< This is not how things are. >I wouldn't say safer, though I will concede that it is easier to debug.< A program that doesn't break in the middle of its run is safer if you have to use it for something more important than a video game :-) --- Walter Bright: >Computers cannot know whether a problem is "small" or not.< The system designer can explain to the computer what "small" means in the specific situation. >This is how you make reliable systems:< I'm a biologist, and I like biology-inspired designs. There is not just 1 way to design reliable systems that must work in the real world. Biology shows several other ways. Today people are starting to copy nature in such regard too, for example designing swarms of very tiny robots that are able to perform a task even if some tiny robot gets damaged or struck, etc. >Pretending a program hasn't failed when it has, and just "soldiering on", is >completely unacceptable behavior in a system that must be reliable.< Well, it's often a matter of degree. On Windows I have amateur-level image editing programs that sometimes have a bug, and one of their windows "dies" or gets struck. I can usually keep working a little with that program and then save the work, and then restart the program. >The Ariane 5 had a backup system which was engaged, but the backup system had >the same software in it, so failed in the same way. That is not how you make >reliable systems.< I have read enough about that case. I agree that it was badly designed. But in our universe there is more than 1 true way to design a reliable system. >You're using two different definitions of the word "safe". Program safety is >about not corrupting memory. System safety (i.e. reliability) is a completely >different thing.< I'd like my programs to be safer in the system safety way. >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.< My idea was to introduce ways to avoid nulls in the first place. >by aviation companies who take this issue extremely seriously.< There are wonderful birds (alatross) that keep flying across thousand of kilometers (and singing&loving to each other and laying large eggs) after 50+ years: http://news.nationalgeographic.com/news/2003/04/0417_030417_oldestbird.html They are biological systems way more complex that a modern aeroplane, they are made of subsystems (like cells in their brain) that are not very reliable. They use a different design strategy to be so reliable. Sorry for mixing two so unrelated topics, my second stupid mistake of today. Bye, bearophile
Re: About switch case statements...
bearophile wrote: Don: (1) "case A, B, C:" implies a relationship between A, B, and C, which might not exist. They may have nothing in common. It's just a list of things, it's a syntax people adapts too. Here too there's no relationship between x and foo: int x, foo; (2) it's an extremely common coding style in C, C++. If automatic fall-through becomes a syntax error, then allowing it for empty case statements is a special case of a special case. This kind of complexity kills languages. As they say in Python Zen: Special cases aren't special enough to break the rules. And this is D. (3) it's more difficult to read. You can put items in one column anyway, so instead of: case someverylongcase: case anotherverylongcase: case thelastverylongcase: You can write: case someverylongcase, anotherverylongcase, thelastverylongcase: This is not so unreadable. -- Justin Johansson: Actually I quite like the brevity you propose but would it be a challenge for the comma operator? That's already standard D syntax :-) http://codepad.org/ByvTAs27 Bye, bearophile > That's already standard D syntax :-) Okay, thanks for reminding me.** > What's bad about forcing people to write case A, B, C So your use of the word "forcing" was quite intentional? Cheers. Must go now to attend to some fall-through cases in my switch statements.** Justin.
Re: About switch case statements...
Walter Bright wrote: Reminds me a bit of D a few years back, when people would say D didn't have lambda's. But D did have them! The problem was the syntax was a bit verbose. Simplified the syntax, and suddenly the lambda's got noticed and got used. D has no tuples.
Re: Ansi vs Unicode API
Andrei Alexandrescu wrote: Wouldn't it have with static data? I know I introduced at least one static variable in a Phobos function. No, Win95 supports static and TLS data.
Re: About switch case statements...
Steven Schveighoffer wrote: You are totally free to make a language that nobody uses :) About 10 years ago, I went out jogging with a colleague who was also a programmer. We were talking about compilers, of course, and he said "what the world really needs is a Java compiler that compiles to native code, not this VM bull." He assured me that such a product would sweep the world. I told him I thought he was right, and so did a lot of people. So right that about 5 years previously, I did just that (for Symantec). Turns out, nobody wanted it. I told him I could get him a copy. He didn't want it either. Another fun story. Back in the 80's, a programmer told a friend that the MOST IMPORTANT thing he looked for in a compiler was compilation speed. My friend told him that was obviously the least important thing to him. Shocked, the programmer asked why? My friend told him that he was using the slowest compiler on the market by a factor of 4. There were several other much faster C++ compilers available, but he stuck with the slow one. The programmer reacted like this thought had never occurred to him. More fun stuff. 10 years ago, I was convinced by many people that the world needed a fast javascript engine. I built one that was twice as fast as Jscript, and twenty (that's right, 20) times faster than Mozilla's javascript engine. It passed all the test suites. I couldn't give it away. On the other hand, the advice I got when starting to write a C compiler was "who the f*** needs another C compiler?" Nobody thought it was a good idea. Turns out, there was a big market for it! Now, I'm not saying you're wrong. I'm just saying that making a product that people want isn't as simple as asking them what they want. With the switch thing, there's a cost to all the solutions proposed here - rather klunky to look at and significant extra work to type them in. Perhaps the reason I don't have trouble with the usual switch statements is because it seems natural to me, as I come from an asm/fortran/basic background, where one would never write: foo(); goto L1; L1: bar(); goto L2; L2: baz(); goto L3; L3: asdf(); return; and case labels look like, well, labels to me. The goto version is ugly and hard to read. Reminds me a bit of D a few years back, when people would say D didn't have lambda's. But D did have them! The problem was the syntax was a bit verbose. Simplified the syntax, and suddenly the lambda's got noticed and got used.
Re: About switch case statements...
Denis Koroskin wrote: On Mon, 16 Nov 2009 15:48:16 +0300, Justin Johansson 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 I don't know about "forcing people" to write such but perhaps it could be an "option for people" :-) Actually I quite like the brevity you propose but would it be a challenge for the comma operator? While ago, I got D multi-dimensional array syntax messed up and declared such an animal as int[3,4,5] which effectively ended up declaring the beast as int[5]. Cheers Justin Wow, this definitely needs to be bug-reported! Wilco. http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.bugs&article_id=19904
Re: struct mixins
Bill Baxter, el 16 de noviembre a las 13:08 me escribiste:
> On Mon, Nov 16, 2009 at 11:32 AM, div0 wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > Leandro Lucarella wrote:
> >> struct inheritance never make it into D, for a good reason: structs are
> >> not supposed to be polymorphic and inheritance is very tied to
> >> polymorphism. But struct inheritance is sometimes very useful for
> >> "composition", avoid an extra member when accessing to the composed type
> >> members.
> >>
> >> Example:
> >>
> >> struct A {
> >> int x;
> >> int y;
> >> }
> >>
> >> struct B {
> >> A a;
> >> int z;
> >> }
> >>
> >> B b;
> >> b.a.x = 5;
> >>
> >> A way to "fix" this is using template mixins:
> >>
> >> template Common() {
> >> int x;
> >> int y;
> >> }
> >>
> >> struct A {
> >> mixin Common;
> >> }
> >>
> >> struct B {
> >> mixin Common;
> >> int z;
> >> }
> >>
> >> B b;
> >> b.x = 5;
> >>
> >> But one can think this is even worse than the previous approach :)
> >>
> >> What if one could use a struct directly with mixin?
> >>
> >> struct A {
> >> int x;
> >> int y;
> >> }
> >>
> >> struct B {
> >> mixin A;
> >> int z;
> >> }
> >>
> >> B b;
> >> b.x = 5;
> >>
> >>
> >> I think this is nice, looks good, is backwards compatible, it might be
> >> easy to implement (not sure about that though) and can be even extended to
> >> classes (not sure about the usefulness of that either).
> >>
> >> The only problem are name collisions, but that can already happen with
> >> template mixins, right? Anyway, collisions can yield a compile error, or
> >> they might be accepted, requiring the full qualified name to access the
> >> attribute, like with classes and inheritance (you can't do a mixin of the
> >> same struct twice). Say A is updated in the future:
> >>
> >> struct A {
> >> int x;
> >> int y;
> >> int z;
> >> }
> >>
> >> b.z = 1; // changes B.z
> >> // to modify B.A.z:
> >> b.A.z = 1;
> >>
> >>
> >> I think collisions should be very rare anyways in structs.
> >>
> >> PS: For those who wonder, yes, this is inspired in the "embedding" feature
> >> of Google's Go, which is basically a mixin, but without adding
> >> template to the mix, it's just this, struct mixins.
> >>
> >>
> >
> > 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 meant to say:
"See how a struct mixin could add an implicit/explicit cast to the mixed
in structs in my previous mail."
Which would be:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=101242
Maybe I don't fully understand alias this. Does alias this can do that?
> 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.
I really didn't thought about alias this when making this proposal (I had
this problem using D1, I'm not using D2 much), so maybe you are right.
--
Leandro Lucarella (AKA luca) http://llucax.com.ar/
--
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
--
EL "PITUFO ENRIQUE" LLEGO A LA BAILANTA
-- Crónica TV
Re: static interface
Andrei Alexandrescu, el 16 de noviembre a las 12:19 me escribiste: > grauzone wrote: > >Leandro Lucarella wrote: > >>Why not? ;) > > > >The actual question is if Andrei/Walter are interested at all in > >this. Because they didn't show any interest so far. D will > >probably be doomed to compile time bug-typing I mean duck-typing > >forever. > > There's an embarrassment of riches when it comes to finding stuff to > work on for D2. I think we need to resign ourselves to the idea that > we need to focus only on one subset of the stream of good ideas that > are being proposed. I completely agree and understand. I wish I had the time to make patches myself for the things I propose. But it's very different if something is not implemented because it sucks or just because the lack of men power :) If some good feature has Walter's blessing, maybe other person can implement it. Nobody wants to implement something if it doesn't have Walter's blessing, because we all know he's very tough to convince, and nobody wants to work on something it won't get accepted. > FWIW I was keen on structs interacting in interesting ways with > interfaces (and submitted a number of enhancements in that > directions) but then realized there are a number of problems that > structs/interfaces cannot solve. I believe that a better path to > pursue in checking interface conformance is via reflection. But that's very laborious, to be honest, I saw some points in std.range that would be hard to cover with static interfaces, but for those things you have all the flexibility you're already using. But static interfaces could cover a wide range of applications, making static duck-typing very easy to use. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Breathe, breathe in the air. Don't be afraid to care. Leave but don't leave me. Look around and choose your own ground.
Re: static interface
On Mon, Nov 16, 2009 at 9:25 AM, Leandro Lucarella wrote: > Why not? ;) > > I know you might want to hit me for bringing just another feature request > inspired in Google's Go, but please do read it without preconceptions, > because I think the features I'm suggesting are mostly already in D, but > in a less convenient way. I, for one, think these are great things to talk about. Even if it's decided that it's a bad idea for D to get such a feature, then as many people as possible should know that reason so we can talk intelligently about why D does things the way it does. Because if we're asking ourselves why D doesn't have X, you can bet there are others who will wonder the same when they see D. --bb
Re: How about Go's... error on unused imports?
"Walter Bright" wrote in message news:hdr7mp$1ei...@digitalmars.com... > Leandro Lucarella wrote: >> Walter Bright, el 12 de noviembre a las 19:35 me escribiste: >>> Andrei Alexandrescu wrote: I think this is an environment issue. I like Eclipse's approach. Java unnecessary imports are underlined with a wavy red line. >>> I agree. I would find it very annoying to have to remove unused >>> imports to get it to compiler. First off, I tend to have "all" >>> imports that import everything. >> >> That's odd, first you say you think D would be a failure if it needs an >> IDE and now you say that the only way to avoid unnecessary dependencies >> you should rely on an IDE =) > > It's not a problem that needs fixing. It's not a bug, it's a stylistic > issue. IDEs are good for that. > > >> I really think this should be a compiler feature. Make it a warning then >> (and while you are at it, make it a *real* warning, not a warning-error). >> >>> Secondly, what if I version out some code, wouldn't want to version the >>> import too. >> >> Why? > > Because I often block out and unblock out code during development. Having > to go up and dink with the imports too would be quite annoying. > > At some point, adding too much of this nagging stuff into a language will > drive people away. The is why the general consensus in the thread is that it should be an optional notice by the compiler rather than an error. So you don't want to have to remove unused imports to get something to compile? Great. I fully agree. So how about having it as an optional diagnostic (as almost everyone on this thread has suggested)? It's pretty hard to imagine that causing anyone any trouble.
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. True, but the case label inside the if statement is obfuscation too. I bet many C/C++ programmers don't even know that this syntax is allowed... But we need to keep it for duff's device, I guess.
Re: Making alloca more safe
On Mon, Nov 16, 2009 at 9:48 PM, Walter Bright wrote: > bearophile wrote: >> >> Walter Bright: >>> >>> I just wished to point out that it was not a *safety* issue.< >> >> A safe system is not a program that switches itself off as soon as >> there's a small problem. > > Computers cannot know whether a problem is "small" or not. > >> One Ariane missile has self-destroyed (and destroyed an extremely >> important scientific satellite it was carrying whose mission I miss >> still) because of this silly behaviour united with the inflexibility >> of the Ada language. >> >> A reliable system is a systems that keeps working correctly despite >> all. If this is not possible, in real life you usually want a "good >> enough" behaviour. For example, for your TAC medical machine, in >> Africa if the machine switches itself off at the minimal problem they >> force the machine to start again, because they don't have money for a >> 100% perfect fix. So for them it's better a machine that shows a slow >> and graceful degradation. That's a reliable system, something that >> looks more like your liver, that doesn't totally switch off as soon >> it has a small problem (killing you quickly). > > This is how you make reliable systems: > You sure got all the answers...
Re: D: at Borders soon?
"AJ" wrote in message news:hdr79b$1cm...@digitalmars.com... > Tim Matthews wrote: >> AJ wrote: >>> Is D about to go commercial? >> >> D is not intended as a scam for someones profit > > Oh? Is it the current direction. Oh, yeah, bill gates is stupid (I think > so). > That came straight out of left-field. > I hate being smart. Great, sounds like you don't have much to worry about.
Re: Ansi vs Unicode API
On Mon, 16 Nov 2009 16:07:56 -0500, Walter Bright 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 . 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
Re: Making alloca more safe
Yigal Chripun wrote:
Andrei Alexandrescu wrote:
Denis Koroskin wrote:
On Mon, 16 Nov 2009 19:27:41 +0300, Andrei Alexandrescu
wrote:
bearophile wrote:
Walter Bright:
A person using alloca is expecting stack allocation, and that it
goes away after the function exits. Switching arbitrarily to the
gc will not be detected and may hide a programming error (asking
for a gigantic piece of memory is not anticipated for alloca, and
could be caused by an overflow or logic error in calculating its
size).
There's another solution, that I'd like to see more often used in
Phobos: you can add another function to Phobos, let's call it
salloca (safe alloca) that does what Denis Koroskin asks for (it's
a very simple function).
Can't be written. Try it.
Andrei
It's tricky. It can't be written *without a compiler support*,
because it is considered special for a compiler (it always inlines
the call to it). It could be written otherwise.
I was thinking about proposing either an inline keyword in a language
(one that would enforce function inlining, rather than suggesting it
to compiler), or allways inline all the functions that make use of
alloca. Without either of them, it is impossible to create wrappers
around alloca (for example, one that create arrays on stack
type-safely and without casts):
T[] array_alloca(T)(size_t size) { ... }
or one that would return GC-allocated memory when stack allocation
fails:
void* salloca(size_t size) {
void* ptr = alloca(size);
if (ptr is null) return (new void[size]).ptr;
return ptr;
}
The problem of salloca is that alloca's memory gets released when
salloca returns.
Andrei
template salloca(alias ptr, alias size) { // horrible name, btw
ptr = alloca(size);
if (ptr is null) ptr = (new void[size]).ptr;
}
// use:
void foo() {
int size = 50;
void* ptr;
mixin salloca!(ptr, size);
//...
}
wouldn't that work?
mixin? Interesting. Probably it works.
Andrei
Re: static interface
Jesse Phillips, el 16 de noviembre a las 13:19 me escribiste: > Is there a reason not to have all interfaces compile time checked? It > would still be allowable to state a class implements an interface and > have the compiler check it. > > The reason I say this is it would remove the complexity of having the > two types of interfaces. And if you wanted to be able to check for the > interface at run-time the same interface can be used. 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). -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Si pudiera acercarme un poco más, hacia vos Te diría que me tiemblan los dos pies, cuando me mirás Si supieras todo lo que me costó, llegar Hoy sabrías que me cuesta respirar, cuando me mirás
Re: About switch case statements...
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. The optimizer/code generator has a lot of awful #if's in them, generally as a result of it being hackishly ported to other platforms. I'm not going to stand up and say the optimizer/code gen is a fine example of elegant software (it isn't), just that it *works* and is remarkably free of bugs.
Re: Making alloca more safe
On Mon, 16 Nov 2009 12:48:51 -0800, Walter Bright wrote: > bearophile wrote: >> Walter Bright: >>> I just wished to point out that it was not a *safety* issue.< >> A safe system is not a program that switches itself off as soon as >> there's a small problem. > > Computers cannot know whether a problem is "small" or not. But designers who make the system can. > Pretending a program hasn't failed when it has, and just "soldiering > on", is completely unacceptable behavior in a system that must be reliable. ... > 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. What is the 'scope' of "system"? Is that if any component in a system fails, then all other components are also in an unknown, and therefore potentially unsafe, state too? For example, can one describe this scenario below as a single system or multiple systems... "A software failure causes the cabin lights to be permanently turned on, so should the 'system' also assume that the toilets must no longer be flushed?" Is the "system" the entire aircraft, i.e. all its components, or is there a set of systems involved here? In the "set of systems" concept, is it possible that a failure of one system can have no impact on another system in the set, or must it be assumed that every system is reliant on all other systems in the same set? -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: Ansi vs Unicode API
Walter Bright wrote: Steven Schveighoffer wrote: On Mon, 16 Nov 2009 15:05:48 -0500, Walter Bright wrote: Steven Schveighoffer wrote: On Mon, 16 Nov 2009 14:18:57 -0500, Walter Bright wrote: Microsoft doesn't break support for older Windows when it comes out with newer ones. Supporting the full range of Windows is essentially trivial. For the compiler, yes. For library code, not so much. If you want to use newer features of the MS libraries, you must abandon support older Windows. True, but that's an app issue, not a dev tools issue. If Phobos depends on functionality not supported in Windows 98, then dmd is pretty useless on win98 unless you provide a compatible standard library. Most normal users consider the standard library to be an essential part of the compiler. Phobos doesn't currently have any compatibility problems with Win95. If a new feature of Phobos did have such an issue, I would expect to document it for that feature. Wouldn't it have with static data? I know I introduced at least one static variable in a Phobos function. Andrei
Re: static interface
grauzone wrote: Andrei Alexandrescu wrote: grauzone wrote: Andrei Alexandrescu wrote: grauzone wrote: Leandro Lucarella wrote: Why not? ;) The actual question is if Andrei/Walter are interested at all in this. Because they didn't show any interest so far. D will probably be doomed to compile time bug-typing I mean duck-typing forever. There's an embarrassment of riches when it comes to finding stuff to work on for D2. I think we need to resign ourselves to the idea that we need to focus only on one subset of the stream of good ideas that are being proposed. That's understandable of course. FWIW I was keen on structs interacting in interesting ways with interfaces (and submitted a number of enhancements in that directions) but then realized there are a number of problems that structs/interfaces cannot solve. I believe that a better path to pursue in checking interface conformance is via reflection. That's a possible solution (and an easy way out to get rid of language design problems), but I'm sure it's not the best solution. (It also should be a little bit extended to give the user better error messages.) I hope cleaner solutions will be considered later, possibly after D2 is done. Which are the problems you mentioned? I knew this was going to be asked. One issue I remember was that it's difficult to talk about "a struct must define a type with certain properties". You will say "but you can express that type as another interface" but that solves the problem by increasing the size of the feature. It gets even more complicated when you want to say "defines a type with these or these other properties, depending on the properties of this type parameter." I think that all can be solved through something that is very similar to C++ concepts, and I would want to avoid going that route. In other words, a general solution inside the language would be too complex (because it had to support all sorts of type interfaces), so you'll just leave it to the user, who will implement the same thing with is() and friends? I don't think that's a fair characterization. With reflection you can implement such capability in a library. Sometimes a motivated and well-intended feature could grow into a monster of generalization. This is what happened to C++ concepts and what could have happened to typedef if we hadn't clipped it. Andrei
Re: D array expansion and non-deterministic re-allocation
"Walter Bright" wrote in message news:hdr6mm$1bf...@digitalmars.com... > Rainer Deyke wrote: >> Walter Bright wrote: >>> It's deterministic in the sense that if you run the program again with >>> the same inputs, you will get the same result. This is a highly useful >>> attribute for testing and debugging. >> On the same platform, with the same compiler, compiler settings, and >> standard library implementation. That makes it harder to test, not >> easier. You now have to test with multiple compilers. > > That is still determinate. Indeterminate means you get different results > if your run it again on the same machine. > Even if it is technically determinate if you run it on the same machine with the same inputs, that still does nothing to address Bartosz's claim that it's a potential security hole - Apps don't always get run on the same machine with the same inputs.
Re: Making alloca more safe
Andrei Alexandrescu wrote:
Denis Koroskin wrote:
On Mon, 16 Nov 2009 19:27:41 +0300, Andrei Alexandrescu
wrote:
bearophile wrote:
Walter Bright:
A person using alloca is expecting stack allocation, and that it
goes away after the function exits. Switching arbitrarily to the gc
will not be detected and may hide a programming error (asking for a
gigantic piece of memory is not anticipated for alloca, and could
be caused by an overflow or logic error in calculating its size).
There's another solution, that I'd like to see more often used in
Phobos: you can add another function to Phobos, let's call it
salloca (safe alloca) that does what Denis Koroskin asks for (it's a
very simple function).
Can't be written. Try it.
Andrei
It's tricky. It can't be written *without a compiler support*, because
it is considered special for a compiler (it always inlines the call to
it). It could be written otherwise.
I was thinking about proposing either an inline keyword in a language
(one that would enforce function inlining, rather than suggesting it
to compiler), or allways inline all the functions that make use of
alloca. Without either of them, it is impossible to create wrappers
around alloca (for example, one that create arrays on stack
type-safely and without casts):
T[] array_alloca(T)(size_t size) { ... }
or one that would return GC-allocated memory when stack allocation fails:
void* salloca(size_t size) {
void* ptr = alloca(size);
if (ptr is null) return (new void[size]).ptr;
return ptr;
}
The problem of salloca is that alloca's memory gets released when
salloca returns.
Andrei
template salloca(alias ptr, alias size) { // horrible name, btw
ptr = alloca(size);
if (ptr is null) ptr = (new void[size]).ptr;
}
// use:
void foo() {
int size = 50;
void* ptr;
mixin salloca!(ptr, size);
//...
}
wouldn't that work?
Re: Ansi vs Unicode API
Walter Bright wrote: Andrei Alexandrescu wrote: Walter Bright wrote: Andrei Alexandrescu wrote: Walter Bright wrote: Trass3r wrote: Yeah, but the whole point of creating D has been to get rid of any kind of legacy that unnecessarily complicates stuff. The Win 9x support in Phobos already exists, doesn't hurt anything, and there's simply no reason to gratuitously remove it. How about TLS? I understand Win95 doesn't have it. My copy of "Advanced Windows" by Richter says it does have it. I recall you told me there is a problem with the way it works that causes dmd trouble. Do you mean: http://d.puremagic.com/issues/show_bug.cgi?id=3342 I would guess so. Andrei
Re: Ansi vs Unicode API
Steven Schveighoffer wrote: On Mon, 16 Nov 2009 15:05:48 -0500, Walter Bright wrote: Steven Schveighoffer wrote: On Mon, 16 Nov 2009 14:18:57 -0500, Walter Bright wrote: Microsoft doesn't break support for older Windows when it comes out with newer ones. Supporting the full range of Windows is essentially trivial. For the compiler, yes. For library code, not so much. If you want to use newer features of the MS libraries, you must abandon support older Windows. True, but that's an app issue, not a dev tools issue. If Phobos depends on functionality not supported in Windows 98, then dmd is pretty useless on win98 unless you provide a compatible standard library. Most normal users consider the standard library to be an essential part of the compiler. Phobos doesn't currently have any compatibility problems with Win95. If a new feature of Phobos did have such an issue, I would expect to document it for that feature. I was just arguing your point about how Windows always provides backwards compatibility. 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 . Even the DOS programs still work.
Re: static interface
Andrei Alexandrescu wrote: grauzone wrote: Andrei Alexandrescu wrote: grauzone wrote: Leandro Lucarella wrote: Why not? ;) The actual question is if Andrei/Walter are interested at all in this. Because they didn't show any interest so far. D will probably be doomed to compile time bug-typing I mean duck-typing forever. There's an embarrassment of riches when it comes to finding stuff to work on for D2. I think we need to resign ourselves to the idea that we need to focus only on one subset of the stream of good ideas that are being proposed. That's understandable of course. FWIW I was keen on structs interacting in interesting ways with interfaces (and submitted a number of enhancements in that directions) but then realized there are a number of problems that structs/interfaces cannot solve. I believe that a better path to pursue in checking interface conformance is via reflection. That's a possible solution (and an easy way out to get rid of language design problems), but I'm sure it's not the best solution. (It also should be a little bit extended to give the user better error messages.) I hope cleaner solutions will be considered later, possibly after D2 is done. Which are the problems you mentioned? I knew this was going to be asked. One issue I remember was that it's difficult to talk about "a struct must define a type with certain properties". You will say "but you can express that type as another interface" but that solves the problem by increasing the size of the feature. It gets even more complicated when you want to say "defines a type with these or these other properties, depending on the properties of this type parameter." I think that all can be solved through something that is very similar to C++ concepts, and I would want to avoid going that route. In other words, a general solution inside the language would be too complex (because it had to support all sorts of type interfaces), so you'll just leave it to the user, who will implement the same thing with is() and friends? Andrei
Re: struct mixins
On Mon, Nov 16, 2009 at 11:32 AM, div0 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Leandro Lucarella wrote:
>> struct inheritance never make it into D, for a good reason: structs are
>> not supposed to be polymorphic and inheritance is very tied to
>> polymorphism. But struct inheritance is sometimes very useful for
>> "composition", avoid an extra member when accessing to the composed type
>> members.
>>
>> Example:
>>
>> struct A {
>> int x;
>> int y;
>> }
>>
>> struct B {
>> A a;
>> int z;
>> }
>>
>> B b;
>> b.a.x = 5;
>>
>> A way to "fix" this is using template mixins:
>>
>> template Common() {
>> int x;
>> int y;
>> }
>>
>> struct A {
>> mixin Common;
>> }
>>
>> struct B {
>> mixin Common;
>> int z;
>> }
>>
>> B b;
>> b.x = 5;
>>
>> But one can think this is even worse than the previous approach :)
>>
>> What if one could use a struct directly with mixin?
>>
>> struct A {
>> int x;
>> int y;
>> }
>>
>> struct B {
>> mixin A;
>> int z;
>> }
>>
>> B b;
>> b.x = 5;
>>
>>
>> I think this is nice, looks good, is backwards compatible, it might be
>> easy to implement (not sure about that though) and can be even extended to
>> classes (not sure about the usefulness of that either).
>>
>> The only problem are name collisions, but that can already happen with
>> template mixins, right? Anyway, collisions can yield a compile error, or
>> they might be accepted, requiring the full qualified name to access the
>> attribute, like with classes and inheritance (you can't do a mixin of the
>> same struct twice). Say A is updated in the future:
>>
>> struct A {
>> int x;
>> int y;
>> int z;
>> }
>>
>> b.z = 1; // changes B.z
>> // to modify B.A.z:
>> b.A.z = 1;
>>
>>
>> I think collisions should be very rare anyways in structs.
>>
>> PS: For those who wonder, yes, this is inspired in the "embedding" feature
>> of Google's Go, which is basically a mixin, but without adding
>> template to the mix, it's just this, struct mixins.
>>
>>
>
> 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
Re: Ansi vs Unicode API
Andrei Alexandrescu wrote: Walter Bright wrote: Andrei Alexandrescu wrote: Walter Bright wrote: Trass3r wrote: Yeah, but the whole point of creating D has been to get rid of any kind of legacy that unnecessarily complicates stuff. The Win 9x support in Phobos already exists, doesn't hurt anything, and there's simply no reason to gratuitously remove it. How about TLS? I understand Win95 doesn't have it. My copy of "Advanced Windows" by Richter says it does have it. I recall you told me there is a problem with the way it works that causes dmd trouble. Do you mean: http://d.puremagic.com/issues/show_bug.cgi?id=3342
Re: Making alloca more safe
On Mon, Nov 16, 2009 at 03:19:06PM -0500, bearophile wrote: > One Ariane missile has self-destroyed (and destroyed an extremely important > scientific satellite it was carrying whose mission I miss still) because of > this silly behaviour united with the inflexibility of the Ada language. Would you have preferred it to just randomly do its own thing and potentially end up landing on people? Blowing it up over the ocean or the launch site is something they would be prepared for anyway, so it is relatively safe to people, which is what ultimately matters. Even expensive, important pieces of equipment can always be replaced. > A program that stops working in a random moment because of a null is not safe. What would you have it do? Carry on in the error state, doing Lord knows what? That's clearly unsafe. Terminating it is a completely predictable situation - one you can design the safe system as a whole around. The rocket scientists know their rocket might blow up at launch, so they build the launch pad out far enough from people and schedule lift off on a day with favourable weather, so if it does explode, the odds of someone getting hurt are low. Hospitals know their medical machines might screw up, so they keep a nurse on duty at all times who can handle the situation - restart the failed machine, or bring in a replacement before it kills someone. Similarly, if your program simply must not fail, null pointer problems don't preclude this. You can predict the eventuality of termination, and set up an external process to restart the dead program: while [ true ] ; do ./buggy-program ; done It might not be convenient all the time, but it is safe. Certainly safer than the alternative of carrying on in an unknown state. > A safer program is a program that avoids null pointer exception because the > type system has formally verified the program has no nulls. I wouldn't say safer, though I will concede that it is easier to debug. -- Adam D. Ruppe http://arsdnet.net
Re: Making alloca more safe
Walter Bright wrote: dsimcha wrote: In a way you're right. However, there is no universal answer for what to do about a null pointer except die **with a good error message explaining what went wrong**. This is the part that's missing. Right now you get an access violation. I'd like an assert failure with a line number and a "Null pointer dereference" error message when I'm not in release mode. You do get just that if you run the program under a debugger. There was a patch for Phobos a while back which would use the debug data to print a stack trace on such an exception without needing a debugger. It has languished because nobody has spent the time to verify that it is correctly done and that it won't negatively impact anything else. I can forward it to you if you like and want to take a look at it. It's in Tango and it works. Both on Linux and Windows. (Needs the Tango svn version.)
Re: Making alloca more safe
dsimcha wrote: In a way you're right. However, there is no universal answer for what to do about a null pointer except die **with a good error message explaining what went wrong**. This is the part that's missing. Right now you get an access violation. I'd like an assert failure with a line number and a "Null pointer dereference" error message when I'm not in release mode. You do get just that if you run the program under a debugger. There was a patch for Phobos a while back which would use the debug data to print a stack trace on such an exception without needing a debugger. It has languished because nobody has spent the time to verify that it is correctly done and that it won't negatively impact anything else. I can forward it to you if you like and want to take a look at it.
Re: D: at Borders soon?
AJ Wrote: > I don't believe you. > > > Don wrote: > > AJ wrote: > >> Is D about to go commercial? I mean, in the form of a book or a > >> series of books? Is the seeming disarray of the language, the ng, > >> the "community", the inventor because the goal is to capitalize on > >> book sales? I'm a prick, of course, but I would like to know. > >> > >> I was being facetious above. (But if the shoe fits, wear it!). > >> Walter, how much money do you have? Nevermind that. Are you rich > >> though? I am poor. Someone said D bought you a Ferrari. > > > > That's completely false. Nobody is making any money from D. AJ, I have no intention of offending you or anyone else, but something needs to be made clear. A more productive thing for you to do is contribute to some aspect of D or its available libraries and make it succeed such that you can make money off of it yourself via resume enhancement and adding to your portfolio. Demanding a handout is, let's just say, not very effective. I saw a few of your other posts, and I would posit that you are an intelligent person who can make a positive impact by writing some code or otherwise helping out. It doesn't matter in the slightest whether you believe Don or not. Walking on to some NG and essentially calling people liars tends to just reflect poorly on you, but you already knew that. I want to assist where I can whether or not Walter, Andrei, Don, or anyone else is or isn't making money off of D. I am free to use it, so what they do with it is none of my concern. I don't want anyone to "share" any money with me, because I can work and earn my own keep. Making money off of your own hard work and (gasp!) keeping it for some time period is the opposite of a sin. That's called a 'job.' And Walter is doing a great job, as far as I've seen. -Mike
Re: Making alloca more safe
bearophile wrote: Walter Bright: I just wished to point out that it was not a *safety* issue.< A safe system is not a program that switches itself off as soon as there's a small problem. Computers cannot know whether a problem is "small" or not. One Ariane missile has self-destroyed (and destroyed an extremely important scientific satellite it was carrying whose mission I miss still) because of this silly behaviour united with the inflexibility of the Ada language. A reliable system is a systems that keeps working correctly despite all. If this is not possible, in real life you usually want a "good enough" behaviour. For example, for your TAC medical machine, in Africa if the machine switches itself off at the minimal problem they force the machine to start again, because they don't have money for a 100% perfect fix. So for them it's better a machine that shows a slow and graceful degradation. That's a reliable system, something that looks more like your liver, that doesn't totally switch off as soon it has a small problem (killing you quickly). This is how you make reliable systems: http://dobbscodetalk.com/index.php?option=com_myblog&show=Safe-Systems-from-Unreliable-Parts.html&Itemid=29 http://dobbscodetalk.com/index.php?option=com_myblog&show=Designing-Safe-Software-Systems-Part-2.html&Itemid=29 Pretending a program hasn't failed when it has, and just "soldiering on", is completely unacceptable behavior in a system that must be reliable. The Ariane 5 had a backup system which was engaged, but the backup system had the same software in it, so failed in the same way. That is not how you make reliable systems. A program that stops working in a random moment because of a null is not safe. (And even if you accept this, in safer languages like C#/Java there are null exceptions that show a stack trace. The type system is smart enough to remove most of those tests to improve performance). A safer program is a program that avoids null pointer exception because the type system has formally verified the program has no nulls. You're using two different definitions of the word "safe". Program safety is about not corrupting memory. System safety (i.e. reliability) is a completely different thing. 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. 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.
Re: static interface
grauzone wrote: Andrei Alexandrescu wrote: grauzone wrote: Leandro Lucarella wrote: Why not? ;) The actual question is if Andrei/Walter are interested at all in this. Because they didn't show any interest so far. D will probably be doomed to compile time bug-typing I mean duck-typing forever. There's an embarrassment of riches when it comes to finding stuff to work on for D2. I think we need to resign ourselves to the idea that we need to focus only on one subset of the stream of good ideas that are being proposed. That's understandable of course. FWIW I was keen on structs interacting in interesting ways with interfaces (and submitted a number of enhancements in that directions) but then realized there are a number of problems that structs/interfaces cannot solve. I believe that a better path to pursue in checking interface conformance is via reflection. That's a possible solution (and an easy way out to get rid of language design problems), but I'm sure it's not the best solution. (It also should be a little bit extended to give the user better error messages.) I hope cleaner solutions will be considered later, possibly after D2 is done. Which are the problems you mentioned? I knew this was going to be asked. One issue I remember was that it's difficult to talk about "a struct must define a type with certain properties". You will say "but you can express that type as another interface" but that solves the problem by increasing the size of the feature. It gets even more complicated when you want to say "defines a type with these or these other properties, depending on the properties of this type parameter." I think that all can be solved through something that is very similar to C++ concepts, and I would want to avoid going that route. Andrei
Re: Making alloca more safe
bearophile wrote: Walter Bright: I don't want to get into another lng thread about should pointers be nullable or not, It was a good thread with good ideas. I just wished to point out that it was not a *safety* issue.< A safe system is not a program that switches itself off as soon as there's a small problem. One Ariane missile has self-destroyed (and destroyed an extremely important scientific satellite it was carrying whose mission I miss still) because of this silly behaviour united with the inflexibility of the Ada language. A reliable system is a systems that keeps working correctly despite all. If this is not possible, in real life you usually want a "good enough" behaviour. For example, for your TAC medical machine, in Africa if the machine switches itself off at the minimal problem they force the machine to start again, because they don't have money for a 100% perfect fix. So for them it's better a machine that shows a slow and graceful degradation. That's a reliable system, something that looks more like your liver, that doesn't totally switch off as soon it has a small problem (killing you quickly). A program that stops working in a random moment because of a null is not safe. (And even if you accept this, in safer languages like C#/Java there are null exceptions that show a stack trace. The type system is smart enough to remove most of those tests to improve performance). A safer program is a program that avoids null pointer exception because the type system has formally verified the program has no nulls. Bye, bearophile I think it all has to do with definitions. If you define safety as a yes/no property, then there can be no discussion about "safer". The classic safety definition involves progress and preservation. If those are satisfied for all programs, the language is safe. All languages in actual use cannot satisfy progress for all programs, which makes the definition too restrictive. So people use more relaxed definitions, e.g. allow for stuck states (e.g. use of a null pointer is a stuck state) or work in terms of trapped vs. untrapped errors. D's definition of safety is "no undefined behavior" which is as far as I can understand a tight superset of "no untrapped errors". If we go by that definition we can't talk about safer or less safe. You either have UB or don't. That being said, I like non-null references. The problem is that as soon as someone tries to enumerate safety among the desirable behaviors of non-null references, Walter's regard for the argument completely shuts down, taking down with it all good arguments too. Andrei
Re: About switch case statements...
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. (2) it's an extremely common writing style in human languages, thus aids readability. (3) case A: case B: case C: is ambiguous. It looks like the coder put in place markers for intended code but forgot the code. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Re: Making alloca more safe
== Quote from bearophile (bearophileh...@lycos.com)'s article > Walter Bright: > > I don't want to get into another lng thread about should pointers be > > nullable or not, > It was a good thread with good ideas. > >I just wished to point out that it was not a *safety* issue.< > A safe system is not a program that switches itself off as soon as there's a small problem. > One Ariane missile has self-destroyed (and destroyed an extremely important scientific satellite it was carrying whose mission I miss still) because of this silly behaviour united with the inflexibility of the Ada language. > A reliable system is a systems that keeps working correctly despite all. If > this is not possible, in real life you usually want a "good enough" behaviour. For example, for your TAC medical machine, in Africa if the machine switches itself off at the minimal problem they force the machine to start again, because they don't have money for a 100% perfect fix. So for them it's better a machine that shows a slow and graceful degradation. That's a reliable system, something that looks more like your liver, that doesn't totally switch off as soon it has a small problem (killing you quickly). > A program that stops working in a random moment because of a null is not safe. (And even if you accept this, in safer languages like C#/Java there are null exceptions that show a stack trace. The type system is smart enough to remove most of those tests to improve performance). A safer program is a program that avoids null pointer exception because the type system has formally verified the program has no nulls. > Bye, > bearophile In a way you're right. However, there is no universal answer for what to do about a null pointer except die **with a good error message explaining what went wrong**. This is the part that's missing. Right now you get an access violation. I'd like an assert failure with a line number and a "Null pointer dereference" error message when I'm not in release mode.
Re: static interface
Andrei Alexandrescu wrote: grauzone wrote: Leandro Lucarella wrote: Why not? ;) The actual question is if Andrei/Walter are interested at all in this. Because they didn't show any interest so far. D will probably be doomed to compile time bug-typing I mean duck-typing forever. There's an embarrassment of riches when it comes to finding stuff to work on for D2. I think we need to resign ourselves to the idea that we need to focus only on one subset of the stream of good ideas that are being proposed. That's understandable of course. FWIW I was keen on structs interacting in interesting ways with interfaces (and submitted a number of enhancements in that directions) but then realized there are a number of problems that structs/interfaces cannot solve. I believe that a better path to pursue in checking interface conformance is via reflection. That's a possible solution (and an easy way out to get rid of language design problems), but I'm sure it's not the best solution. (It also should be a little bit extended to give the user better error messages.) I hope cleaner solutions will be considered later, possibly after D2 is done. Which are the problems you mentioned? Andrei
Re: Ansi vs Unicode API
On Mon, 16 Nov 2009 15:05:48 -0500, Walter Bright wrote: Steven Schveighoffer wrote: On Mon, 16 Nov 2009 14:18:57 -0500, Walter Bright wrote: Microsoft doesn't break support for older Windows when it comes out with newer ones. Supporting the full range of Windows is essentially trivial. For the compiler, yes. For library code, not so much. If you want to use newer features of the MS libraries, you must abandon support older Windows. True, but that's an app issue, not a dev tools issue. If Phobos depends on functionality not supported in Windows 98, then dmd is pretty useless on win98 unless you provide a compatible standard library. Most normal users consider the standard library to be an essential part of the compiler. One example: Tango's Process class tries to avoid popping up a console window when running a script, but it uses a flag to CreateProcess that is not supported on Windows 98 or earlier. The decision was made to just simply not support Windows 98 or earlier because it wasn't worth throwing out that feature simply to support users of Windows 98 (who frankly, should retire their likely now-paperweights). This is probably a milder case which causes no harm on a win98 box. However, calling a new function would make the lib not compile or fail to run. I don't see any problem with not going to extra effort to support Win9x. I just see a problem with gratuitously breaking it. If its for the sake of functionality (i.e. you can't get the functionality without it) then I think gratuitous breaking is warranted. However, I don't care too much about Unicode, I work mostly in English and pretty much only in ANSI-compatible utf8. From your description, it sounds like this is not one of those cases (i.e. you *can* get the functionality without breaking compatibility). I was just arguing your point about how Windows always provides backwards compatibility. -Steve
Re: About switch case statements...
On Mon, 16 Nov 2009 15:01:47 -0500, Andrei Alexandrescu wrote: Steven Schveighoffer wrote: On Mon, 16 Nov 2009 03:27:22 -0500, Don wrote: Requiring 'goto' to implement fall-through would run into the prejudice against 'goto'. It's necessary to persuade managers that "goto case XXX;" isn't a bad, evil goto that eats babies. I have no idea if that's difficult or not. Otherwise, I think it's a superb solution. (providing that empty fall-through case statements remain valid; disallowing them would be really annoying). It hasn't hurt C# at all... http://msdn.microsoft.com/en-us/library/06tc147t(VS.80).aspx I haven't had any issues with it. This reminds me of the != null problem. Now if only Walter made as many mistakes with switch case fallthrough as he did with != null :) Walter, at some point, you should heed the complaints of the masses even if it doesn't affect you. It's like a politician who lives in a nice neighborhood ignoring the requests of his constituents for more police protection in higher crime areas because he doesn't live there. Except it's worse, because we can't vote you out :) Also keep in mind that this does *not* change the power of switch at all, since goto already covers fallthrough. One thing I learned from the != null to !is null change is that I stopped writing the offending code when I get immediate feedback. It just gets ingrained in my brain better. So having to write goto next_case; all the time is going to be much less of a chore than you think, because you'll just learn to avoid that mistake in the first place. My thoughts exactly. But that being said, if a guy can't design his own language to cater for what he thinks he frequently does (massive, overwhelming, and exhausting evidence to the contrary notwithstanding), then where is freedom in this world? You are totally free to make a language that nobody uses :) -Steve
Re: static interface
grauzone wrote: Leandro Lucarella wrote: Why not? ;) The actual question is if Andrei/Walter are interested at all in this. Because they didn't show any interest so far. D will probably be doomed to compile time bug-typing I mean duck-typing forever. There's an embarrassment of riches when it comes to finding stuff to work on for D2. I think we need to resign ourselves to the idea that we need to focus only on one subset of the stream of good ideas that are being proposed. FWIW I was keen on structs interacting in interesting ways with interfaces (and submitted a number of enhancements in that directions) but then realized there are a number of problems that structs/interfaces cannot solve. I believe that a better path to pursue in checking interface conformance is via reflection. Andrei
Re: Making alloca more safe
Walter Bright: > I don't want to get into another lng thread about should pointers be > nullable or not, It was a good thread with good ideas. >I just wished to point out that it was not a *safety* issue.< A safe system is not a program that switches itself off as soon as there's a small problem. One Ariane missile has self-destroyed (and destroyed an extremely important scientific satellite it was carrying whose mission I miss still) because of this silly behaviour united with the inflexibility of the Ada language. A reliable system is a systems that keeps working correctly despite all. If this is not possible, in real life you usually want a "good enough" behaviour. For example, for your TAC medical machine, in Africa if the machine switches itself off at the minimal problem they force the machine to start again, because they don't have money for a 100% perfect fix. So for them it's better a machine that shows a slow and graceful degradation. That's a reliable system, something that looks more like your liver, that doesn't totally switch off as soon it has a small problem (killing you quickly). A program that stops working in a random moment because of a null is not safe. (And even if you accept this, in safer languages like C#/Java there are null exceptions that show a stack trace. The type system is smart enough to remove most of those tests to improve performance). A safer program is a program that avoids null pointer exception because the type system has formally verified the program has no nulls. Bye, bearophile
