Re: parallelFuture
== Quote from dsimcha (dsim...@yahoo.com)'s article
I've created an alpha release of parallelFuture, a high-level parallelization
library for D2. Right now, it has a task pool, futures, parallel foreach, and
parallel map.
Here's the (IMHO) coolest example:
auto pool = new ThreadPool();
// Assuming we have a function isPrime(), print all
// prime numbers from 0 to uint.max, testing for primeness
// in parallel.
auto myRange = iota(0, uint.max);
foreach(num; pool.parallel(myRange)) {
if(isPrime(num)) {
synchronized writeln(num);
}
}
The interface is there and it seems to work, although it has not been
extensively stress tested yet. Some of the implementation details could
admittedly use some cleaning up, and I would appreciate help from some
threading gurus on improving my queue (right now it's a naive synchronized
singly-linked list) and getting condition mutexes to work properly. (Right
now, I'm using atomic polling followed by sleeping for 1 millisecond in a lot
of places. It's a kludge, but it seems to work reasonably well in practice.)
The code is at:
http://dsource.org/projects/scrapple/browser/trunk/parallelFuture/parallelFuture.d
The docs are at:
http://cis.jhu.edu/~dsimcha/parallelFuture.html
Very good!
Re: parallelFuture
dsimcha wrote:
I've created an alpha release of parallelFuture, a high-level parallelization
library for D2. Right now, it has a task pool, futures, parallel foreach, and
parallel map.
Here's the (IMHO) coolest example:
auto pool = new ThreadPool();
// Assuming we have a function isPrime(), print all
// prime numbers from 0 to uint.max, testing for primeness
// in parallel.
auto myRange = iota(0, uint.max);
foreach(num; pool.parallel(myRange)) {
if(isPrime(num)) {
synchronized writeln(num);
}
}
The interface is there and it seems to work, although it has not been
extensively stress tested yet. Some of the implementation details could
admittedly use some cleaning up, and I would appreciate help from some
threading gurus on improving my queue (right now it's a naive synchronized
singly-linked list) and getting condition mutexes to work properly. (Right
now, I'm using atomic polling followed by sleeping for 1 millisecond in a lot
of places. It's a kludge, but it seems to work reasonably well in practice.)
The code is at:
http://dsource.org/projects/scrapple/browser/trunk/parallelFuture/parallelFuture.d
The docs are at:
http://cis.jhu.edu/~dsimcha/parallelFuture.html
Very nice! Parallelisation for us ordinary folks. :) I tried your
isPrime example, which was very cool. I can't wait to try the library in
a real application.
I often have a situation where I have a set of grid points, and I do
(mostly) separate calculations on each grid point. Your library should
allow me to do calculations on several grid points in parallel, with
minimal changes to my code.
Is there some particular reason why you have capitalised the F in the
file name, but not in the module name?
-Lars
Re: parallelFuture
== Quote from Lars T. Kyllingstad (pub...@kyllingen.nospamnet)'s article Is there some particular reason why you have capitalised the F in the file name, but not in the module name? -Lars This is called the effects of being in hack mode late at night. I guess the convention is all lower case.
Re: parallelFuture
== Quote from Tim Matthews (tim.matthe...@gmail.com)'s article
dsimcha wrote:
I've created an alpha release of parallelFuture, a high-level
parallelization
library for D2. Right now, it has a task pool, futures, parallel foreach,
and
parallel map.
Here's the (IMHO) coolest example:
auto pool = new ThreadPool();
// Assuming we have a function isPrime(), print all
// prime numbers from 0 to uint.max, testing for primeness
// in parallel.
auto myRange = iota(0, uint.max);
foreach(num; pool.parallel(myRange)) {
if(isPrime(num)) {
synchronized writeln(num);
}
}
The interface is there and it seems to work, although it has not been
extensively stress tested yet. Some of the implementation details could
admittedly use some cleaning up, and I would appreciate help from some
threading gurus on improving my queue (right now it's a naive synchronized
singly-linked list) and getting condition mutexes to work properly. (Right
now, I'm using atomic polling followed by sleeping for 1 millisecond in a
lot
of places. It's a kludge, but it seems to work reasonably well in
practice.)
The code is at:
http://dsource.org/projects/scrapple/browser/trunk/parallelFuture/parallelFuture.d
The docs are at:
http://cis.jhu.edu/~dsimcha/parallelFuture.html
Nice. About the tasks:
In .Net a worker thread is created for each cpu core. Each worker thread
has its own local queue of tasks which it initially retrieves from the
global queue but if the tasks creates new tasks it adds to its local
queue directly for less contention. When it finishes completing a task
it takes the next from the back of its local queue to take advantage of
cache (like a stack). The tasks at the front of the queue can be stolen
from another worker thread if its local queue and the global queue are
both empty to maximize cpu usage.
Also the task's wait for complete is only considered complete if all of
the tasks it created too are complete (kinda like recursion).
What is the implementation or plans like for this.
For now, parallelFuture was designed with a single producer, multiple worker
model. Absolutely no attempt was made to allow for tasks running in the task
pool
to themselves submit jobs to the same task pool, because it would have made
things
more complicated and I couldn't think of any use cases. I designed the lib with
the types of use cases I encounter in my work in mind. (mathy, pure throughput
oriented computing on large, embarrassingly parallel problems.) If someone
comes
up with a compelling use case, though, I'd certainly consider adding such
abilities provided they don't interfere with performance or API simplicity for
the
more common cases.
To make this discussion simple, let's define F1 as a future/task submitted by
the
main producer thread, and F2 as a task/future submitted by F1. The queue is
(for
now) strictly FIFO, except that if you have a pointer to the Task/Future object
you can steal a job. When F1 submits F2 to the queue, F2 goes to the back of
the
queue like anything else. This means when F1 waits on F2, it is possible to
have
a cyclical dependency (F1 waiting on F2, F2 waiting for a worker thread
populated
by F1). This is mitigated by work stealing (F1 may just steal F2 and do it in
its
own thread).
In parallel map and foreach, I should probably document this, but for now it's
undefined behavior for the mapping function or parallel foreach loop body to
submit jobs to the task pool and wait on them, and in practice will likely
result
in deadlocks.
Re: parallelFuture
== Quote from Charles Hixson (charleshi...@earthlink.net)'s article
dsimcha wrote:
I've created an alpha release of parallelFuture, a high-level
parallelization
library for D2. Right now, it has a task pool, futures, parallel foreach,
and
parallel map.
Here's the (IMHO) coolest example:
auto pool = new ThreadPool();
// Assuming we have a function isPrime(), print all
// prime numbers from 0 to uint.max, testing for primeness
// in parallel.
auto myRange = iota(0, uint.max);
foreach(num; pool.parallel(myRange)) {
if(isPrime(num)) {
synchronized writeln(num);
}
}
The interface is there and it seems to work, although it has not been
extensively stress tested yet. Some of the implementation details could
admittedly use some cleaning up, and I would appreciate help from some
threading gurus on improving my queue (right now it's a naive synchronized
singly-linked list) and getting condition mutexes to work properly. (Right
now, I'm using atomic polling followed by sleeping for 1 millisecond in a
lot
of places. It's a kludge, but it seems to work reasonably well in
practice.)
The code is at:
http://dsource.org/projects/scrapple/browser/trunk/parallelFuture/parallelFuture.d
The docs are at:
http://cis.jhu.edu/~dsimcha/parallelFuture.html
If you can easily do it, it would be nice to be able to have the threads
able to communicate with each other. Something along the lines of both
broadcast messages and 1:1 exchanges. A very rough sketch of a possible
use:
Task[] tasks = Task.who_is_waiting;
foreach (auto task; tasks)
{ if (task.process(something) )
{ task.markDone(true); }
}
I see something as being an Object that would need to implement an
interface to carry some identifying information, so when a task received
it it could determine what to do with it (with reject processing being
an option). I think the rest is pretty clear.
OTOH, this comment was just to demonstrate the kind of communication
between tasks that I'm talking about. Static methods for broadcast
communication and instance methods for 1:1 communication. With
safeties, so when a task completes before it gets your message, you
aren't left talking to a null pointer. Cleanup would need to be managed
by the original thread that created the tasks. It would need to be able
to send a broadcast now closing task xxx signal to all threads.
Threads maintaining a list of tasks would need to scan through them and
remove any references to that task.
Maybe this is getting to complicated, but it would certainly be useful.
In the past interthread communication is the main problem that's kept
me from using them.
I'll think about this and see if I can work something like this in, but I need
real-world use cases. I do bioinformatics work, which basically means
large-scale
data mining, embarrassingly parallel problems and very CPU-bound work. The use
cases I had in mind were mostly the use every core I have to do something
embarrassingly parallel kind. The goal was to make these use cases as dead
simple as possible.
Whatever use cases you have in mind, I'm apparently not familiar with them. If
I'm to improve this lib to handle use cases other than the pure
throughput-oriented parallelization of embarrassingly parallel tasks that I had
in
mind, I need to understand use cases from other fields.
Re: parallelFuture
dsimcha wrote: For now, parallelFuture was designed with a single producer, multiple worker model. Absolutely no attempt was made to allow for tasks running in the task pool to themselves submit jobs to the same task pool, because it would have made things more complicated and I couldn't think of any use cases. like recursion a function is gona need to call another function, a thread needs to be able to spawn threads and task should be able to create new tasks. Making newly spawned tasks stay on the same thread is good optimization. This shouldn't need a specific use case. I designed the lib with the types of use cases I encounter in my work in mind. (mathy, pure throughput oriented computing on large, embarrassingly parallel problems.) If someone comes up with a compelling use case, though, I'd certainly consider adding such abilities provided they don't interfere with performance or API simplicity for the more common cases. To make this discussion simple, let's define F1 as a future/task submitted by the main producer thread, and F2 as a task/future submitted by F1. The queue is (for now) strictly FIFO, except that if you have a pointer to the Task/Future object you can steal a job. When F1 submits F2 to the queue, F2 goes to the back of the queue like anything else. This means when F1 waits on F2, it is possible to have a cyclical dependency (F1 waiting on F2, F2 waiting for a worker thread populated by F1). This is mitigated by work stealing (F1 may just steal F2 and do it in its own thread). I don't like that ^ idea of simple discussion with the many F1 and F2 all over the place. I hope this video can help visualize some ideas: http://channel9.msdn.com/pdc2008/TL26/ In parallel map and foreach, I should probably document this, but for now it's undefined behavior for the mapping function or parallel foreach loop body to submit jobs to the task pool and wait on them, and in practice will likely result in deadlocks. You want to document that as undefined behavior? It can be made to work.
Re: parallelFuture
== Quote from Tim Matthews (tim.matthe...@gmail.com)'s article dsimcha wrote: For now, parallelFuture was designed with a single producer, multiple worker model. Absolutely no attempt was made to allow for tasks running in the task pool to themselves submit jobs to the same task pool, because it would have made things more complicated and I couldn't think of any use cases. like recursion a function is gona need to call another function, a thread needs to be able to spawn threads and task should be able to create new tasks. Making newly spawned tasks stay on the same thread is good optimization. This shouldn't need a specific use case. I designed the lib with the types of use cases I encounter in my work in mind. (mathy, pure throughput oriented computing on large, embarrassingly parallel problems.) If someone comes up with a compelling use case, though, I'd certainly consider adding such abilities provided they don't interfere with performance or API simplicity for the more common cases. To make this discussion simple, let's define F1 as a future/task submitted by the main producer thread, and F2 as a task/future submitted by F1. The queue is (for now) strictly FIFO, except that if you have a pointer to the Task/Future object you can steal a job. When F1 submits F2 to the queue, F2 goes to the back of the queue like anything else. This means when F1 waits on F2, it is possible to have a cyclical dependency (F1 waiting on F2, F2 waiting for a worker thread populated by F1). This is mitigated by work stealing (F1 may just steal F2 and do it in its own thread). I don't like that ^ idea of simple discussion with the many F1 and F2 all over the place. I hope this video can help visualize some ideas: http://channel9.msdn.com/pdc2008/TL26/ In parallel map and foreach, I should probably document this, but for now it's undefined behavior for the mapping function or parallel foreach loop body to submit jobs to the task pool and wait on them, and in practice will likely result in deadlocks. You want to document that as undefined behavior? It can be made to work. Ok, I thought of my use case and an easy fix. It will probably be fixed soon.
Re: Semicolons: mostly unnecessary?
KennyTM~ kenn...@gmail.com wrote in message news:hbopns$125...@digitalmars.com... On Oct 22, 09 12:29, AJ wrote: Adam D. Ruppedestructiona...@gmail.com wrote in message news:mailman.228.1256181155.20261.digitalmar...@puremagic.com... On Wed, Oct 21, 2009 at 09:25:34PM -0500, AJ wrote: That's not D source code. Why do you keep trying to use English text as an example? The logic behind all the arguments you make, That would be all fine and dandy, but I'm not arguing about anything. (So you must be arguing? About what?). except for one, should apply equally well to English as it does to D. That's silly. There is no need to use the text of Shakespeare's tragedies to allude to source code. There is no need and it is entirely inappropriate to expand the context of the issue to other realms. The context is (currently): semicolons as statement terminators for single-statement lines. Cons: 1. Makes source code less comprehensible. Based on what? Because you say so? It's more to digest when it's not necessary. It's easier to identify something when it's in less intricate (read, plain) surroundings. snipped inappropriate context reference 2. Is redundant with the newline designator. snipped inappropriate context reference is obviously false, If I put it on the list, it wasn't obvious at all, even if it is incorrect (though I think it is correct). unless you specifically require a line continuation character: a = b + c Without semicolon requirement: a=b+ // this is an error c // this is OK With semicolon requirement: a=b+; // this is an error c; // this is OK What's the diff? A newline and a semicolon are not redundant unless you specifically define a statement as being one and only one line. A semicolon is redundate with newline for single-statement lines. Oh, you say that a lot of constructs are inherently single statements but written on multiple lines? Well, that may be just the kind of examination I was looking for (ironic that _I_ had to bring it up, huh): if(true) dothis() That situation has to be evaluated: is parsing at the construct level too much effort or is it desireable? (ParseIfStatement()). Statement-level parsing better/worse than line-level parsing? Back to the magic of above though. What if you rewrote it: a = b +c Without semicolon requirement: a=b // OK +c // error With semicolon requirement: a=b; // OK +c; // error What's the diff? a=b +c(d) // no error Why not? Whether c is declared as a variable or a function, it still looks wrong to me. A statement can't begin with a +. 3. Is more typing. snipped inappropriate context reference how long does it take to type a semicolon anyway? Typing unnecessary semicolons (if they are unnecessary) is dumb.
Re: No header files?
AJ wrote:
Steven Schveighoffer schvei...@yahoo.com wrote in message
news:op.u16mw4o6eav...@localhost.localdomain...
On Wed, 21 Oct 2009 23:10:38 -0400, AJ a...@nospam.net wrote:
Steven Schveighoffer schvei...@yahoo.com wrote in message
news:op.u16j03t2eav...@localhost.localdomain...
On Wed, 21 Oct 2009 19:31:02 -0400, AJ a...@nospam.net wrote:
Steven Schveighoffer schvei...@yahoo.com wrote in message
news:op.u15929x0eav...@localhost.localdomain...
What happens (and being a long-time C++ developer, I've had my fair
share
of experience with it) is that the interface gets out of sync with
the
implementation, so weird shit happens.
I even think d's editable interface files are suspect. They can be
out
of sync with the object files, and then you have the same problem.
The
best model by far is Java and C# where the object files *are* the
interface files. Then you only have to worry about documentation
being
out of sync. But at least your programs don't crash randomly for no
reason because the docs are invalid.
What I would suggest is creating stub functions via {} and then when
you
go back to fill in the interface, fill in the {} area. You get the
same
effect.
You lose the ability to use, say a class declaration, as the
specification
(at least without a sophisitcated, code-folding/code-formatting IDE).
What do you use, Notepad? Even vi does this now.
Oh, can you print that out for me so I can look it over on the train ride
into work?
Sure. But I just prefer to use my laptop when traveling.
That doesn't quite help me any though, now does it? Another non-reason why
header files are obsolete?
And you know that code folding of an implementation file cannot encompass
the elements of hand-written header file.
You mean format styles?
Not nearly just that. For all the richness of everything contained therein:
the blueprint (only), the brief documentation, the style, other things
surely. Do I want to weed out the high level view or documentation from what
is in the implementation file? No way! Documentation in the implementation
file would be something like: I used algorithm X instead of algorithm Y to
implement this function because.. whereas documentation in a header file
would be something like: Class Z was developed to fullfill the following
needs: ... and can be used where
In any case, I seldom refer to the source file when I can just look at
the
docs generated from the comments. If you aren't commenting your API,
then
I'm not using your lib, so don't even suggest that header files *without
comments* are better than auto-generated docs.
I never suggested that header files not have comments. But I was saying
that
I use header files as the answer book in using code (aka,
documentation)
and also that header files can eliminate the need for auxiliary
documentation.
With source and headers, you have 2 pieces. With source and docs, you
have 2 pieces. Why would documentation be considered any more auxiliary
than header files?
Documentation is not the only value of header files. The constructs
themselves are self-documenting. I don't want to read about something being
a class, I want to see the class! Afterall, I'll be working with that in the
code. Not some description of it in some paragraph. And if that auxiliary
documentation has the class declaration, then what you ask? Well then it's
basically a header file! (But without the value of being a high level design
tool).
And a generated doc is just a different view of the same data, so it's
more likely to be correct.
OK, enough of this now. I use header files for the reasons I mentioned. I've
heard nothing to justify jettisoning them or even consider such.
Good thing for me that the IDEs open header files with a few
clicks on the #include myhdr.h line huh. A header file is the real
thing,
while auxiliary documentation describes the real thing. Software isn't
built
with documentation. It's built with source code. Blueprints, not a
brochure.
I look at headers and source as 2 blueprints,
Then you don't understand the concept of blueprint.
of which one or both might not be correct, so there is more chance for
error. More places to maintain the exact same thing means more overhead,
more
And suggesting auto-generated docs are any different than a header file is
completely false.
If there weren't header files, I would still write, say class, declarations
and follow them with the out-of-line implementations. It gives me immediate
grasp of what I am working with (would be a tad better without unnecessary
semicolons all over the place too). Zero comments in a generated header, but
a bigger issue for me is that not using header files means not developing in
my chosen, well-thought-out way.
The exact function signatures are copied from the actual source, how is
that a brochure?
I was comparing header files with auxiliary documentation. Not generated
headers.
Header
Re: No header files?
Nick Sabalausky a...@a.a wrote in message
news:hbontv$uq...@digitalmars.com...
AJ a...@nospam.net wrote in message news:hbof8k$ed...@digitalmars.com...
Adam D. Ruppe destructiona...@gmail.com wrote in message
news:mailman.226.1256173717.20261.digitalmar...@puremagic.com...
On Wed, Oct 21, 2009 at 08:05:46PM -0500, AJ wrote:
Well of course header files will have comments. The thing is though,
tomes
of documentation are not necessary you have header files. And what are
the
chances that the documentation will be in synch with the code if the
documentation is external? Much better chance of that if the header
file IS
the documentation and the code is crafted such that it needs very
little
doc.
That's what ddoc is all about.
http://www.digitalmars.com/d/2.0/ddoc.html
Even that is over-kill when formal documentation is not required. one
size fits all hardly ever does (never?). Sure, if you're Microsoft, you
need to formally document in great detail the API. But most development
does not require the large-scale solutions. A lot of times (I'd say the
common case) does not require external formal documentation. While these
kinds of things may be nice in certain situations, they don't wipe out
everything else once they are created. My way of thinking is such that
eliminates the need for yet another programming task while your's seems
to be to take that task for granted and automate it. That's fine, there's
no one correct answer other than do it the way you like to. I won't be
ditching header files.
/// Some little documentation
int someFunction(int a, int b) { implementation }
All in one file.
If you want to manually write a separate redundant file with just
declarations before writing the implementation, no one's stopping you.
You sound angry that your feature is not a fit for my development process.
jump in and start coding algorithms is not an acceptable development
method in my book.
Re: int always 32 bits on all platforms?
Sean Kelly s...@invisibleduck.org wrote in message news:hbo3bv$2q2...@digitalmars.com... AJ Wrote: How can/does D guarantee that int will always be 32 bits on all platforms? Does this mean that D won't work on some platforms? Why is integer width so ambiguous in C/C++? (I am using platform as equivalent to CPU+OS+compiler). int can be any width D wants it to be and everything works great so long as you're only calling D functions. The conflict comes when calling C functions, and there's nothing in the language for addressing this. Instead, it's a library issue. For example, Druntime's core.stdc.config defines c_long and c_ulong types for interfacing with C, since these types change width across 32 and 64-bit platforms. There's been no attempt to deal with odd-sized int or other types though. That just isn't an issue on common platforms. I had struct layout/size/alignment/member-alignment concerns.
Re: int always 32 bits on all platforms?
AJ wrote:
Nick Sabalausky a...@a.a wrote in message
news:hbonbp$to...@digitalmars.com...
AJ a...@nospam.net wrote in message news:hboaeu$5s...@digitalmars.com...
BCS n...@anon.com wrote in message
news:a6268ffbb0a8cc20817fe1f...@news.digitalmars.com...
Hello aJ,
I would think so. Anyway, what I find compelling about guaranteed
widths is the potential to eliminate alignment and padding issues
(that is, be able to control it with confidence across platforms as
one already can on a single platform via compiler pragmas or cmdline
switches).
Ah! I thought you were taking issue with something. D has that and gets
most of the porting stuff to work.
It does? Get this to work on all platforms:
struct ABC
{
byte a;
int b; // may be improperly aligned on some platforms
int64 c; // same issue
};
// Guarantee packed on all platforms
align() struct ABC
{
byte a;
int b; // may be improperly aligned on some platforms
int64 c; // same issue
};
Well I can do the same thing with pragma or compiler switch in C++. It
doesn't mean that thing will work if 32-bit ints have to be aligned on
32-bit boundaries. While nice to have one syntax to do that, it doesn't fix
the problem (which I haven't expressed correctly probably). What good is a
packed structure that has misaligned data members for the platform?
struct ABC {
version (RequireAlign4) align(4)
byte a;
int b;
int64 c;
}
Re: Revamped concurrency API (Don can you contact Bartosz ?)
Leandro Lucarella wrote: Don, el 21 de octubre a las 09:46 me escribiste: All my public email addresses are fake. Bugzilla is just spam bait. It clearly comes from a more innocent age. I once made the mistake of submitting a bug to gcc. Although the GCC Bugzilla hides the email in the submitter field, the idiots include the real email address in the 100% useless 'X-Ref' line. Two weeks later, my email address was dead. I've never made that mistake again. I am contactable through my dsource account. You don't even use a real account for personal e-mails! That's odd. I couldn't reply your private e-mail about changing the title of the bugzilla report because the From address were fake. Yes, I too use fake personal email accounts, as I do not want my gmail accounts hammered with spam. I could add -nospam to the name, but I am unsure how good the spammers are these days to get around this. Any suggestions/comments, anyone ? Nick B
Re: Semicolons: mostly unnecessary?
AJ wrote: Why not eliminate the requirement for semicolon statement terminators (unless there are multiple statements per line)? Less typing is more! Please don't post crazy stuff like this. This proposal would break every line of D code ever written. YOU ARE WASTING YOUR TIME (and everyone elses).
Re: No header files?
On 22/10/2009 02:01, Walter Bright wrote: Yigal Chripun wrote: the only valid IMO use case for header files is for linking libs - the compiler can handle just find binary formats for that. I was originally going to go with a binary format for that - but it turned out to be pointless. dmd is so fast at parsing, there simply was no advantage to replacing the text file parser with a binary file parser. If you consider the .di file as a binary format, I think you'll find it fulfills all the purposes of it, as well as being human readable without needing a pretty-printer. Let me re-phrase myself, since I think you misunderstood: c headers are used for hiding implementation *and* documentation. the latter is accomplished much better by tools such as ddoc, javadoc, etc. This leaves us with the former, which doesn't require the format to be human readable, it doesn't mean you must make it not-readable. the benefits of using the llvm byte-code format are as following: 1) platform neutral 2) has efficient representation for in-memory and an equivalent for on-disk. 3) like with C# and Java, the file *is* the interface, no need to maintain a separate interface file. 4) already implemented with all the required tooling by the LLVM project
Re: No header files?
Yigal Chripun wrote: On 22/10/2009 02:01, Walter Bright wrote: Yigal Chripun wrote: the only valid IMO use case for header files is for linking libs - the compiler can handle just find binary formats for that. I was originally going to go with a binary format for that - but it turned out to be pointless. dmd is so fast at parsing, there simply was no advantage to replacing the text file parser with a binary file parser. If you consider the .di file as a binary format, I think you'll find it fulfills all the purposes of it, as well as being human readable without needing a pretty-printer. Let me re-phrase myself, since I think you misunderstood: c headers are used for hiding implementation *and* documentation. the latter is accomplished much better by tools such as ddoc, javadoc, etc. This leaves us with the former, which doesn't require the format to be human readable, it doesn't mean you must make it not-readable. the benefits of using the llvm byte-code format are as following: 1) platform neutral Check. 2) has efficient representation for in-memory and an equivalent for on-disk. Check. 3) like with C# and Java, the file *is* the interface, no need to maintain a separate interface file. Check. (D doesn't need bytecode files in addition to .obj files, so LLVM isn't saving on any files compared with D.) 4) already implemented with all the required tooling by the LLVM project Check. I'm not really understanding what's wrong with .di files. Further advantages of .di files: 1. Neither .di files nor .obj files are needed for other files to successfully import and reference library code 2. .di files are human readable without any need to learn anything other than D 3. No new file formats to design, document, debug and maintain 4. No extra code needed to implement a .di file reader in the compiler
Re: No header files?
Steven Schveighoffer wrote: On Wed, 21 Oct 2009 19:21:32 -0400, Walter Bright newshou...@digitalmars.com wrote: Yigal Chripun wrote: The C/C++ way of headers + lib has problems which D inherited as part of the same (broken) design. Hardly, as: 1. you don't need to use header files in D at all 2. you can automatically generate .di files, guaranteeing they are not out of sync That second one is not true if you are doing incremental building (ever use a build tool that occasionally screws up and doesn't rebuild something?). At least it is possible to automate. You cannot automate C/C++ header files, so they are inherently unreliable. In addition, the only *true* reason to use .di files is to hide implementation It's also to speed up compilation. -- which the auto generator does *not* do. So you are back to hand editing and back to sync problems. If you need to hide implementation, I suggest instead redesigning your interface to use interface types, or use the pimpl idiom. IMO .di files are as horrible as header files in C and I avoid them like the plague. I'd hate to have to use them, but so far, I haven't had any public release of proprietary code, so no need for them yet. I agree they aren't necessary most of the time, I don't agree they are even as close to being as horrible as C headers, unless you are hand-editting them. If you are doing the latter, I suggest something may have gone wrong with the design of your interface.
Re: Semicolons: mostly unnecessary?
Adam D. Ruppe wrote: Ifthepointisntplainobviousfromtheabovefewersymbolsmostcertainly doesNOTmeanalanguageisnecessarilyeasiertoparseSymbolsgiveus aparsinganchorperiodsinasentencearentstrictlynecessarywecould putoneperlineorjustfigureoutwheretheybelongbyparsingthecontext Butthatsfairlyobviouslymuchharderthanusingperiodstofollowwhere youareSemicolonsarethesamething (Fixed that for you!)
Re: Array, AA Implementations
Andrei Alexandrescu wrote: Bill Baxter wrote: On Wed, Oct 21, 2009 at 6:35 PM, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: 3. Remove some element from the container and give it to me E removeAny(); 4. Add an element to the container is possible bool add(E); I think any container must support these primitives in O(1), and I find it difficult to think of a significant category of containers that can't support them (but then there may as well be, so please join me in thinking of that). A lot of stuff can be done with only these few methods. I think balanced trees generally take O(lg N) to add and remove elements. Good point, thanks. Logarithmic of better. Andrei Can it be amortized O(lg N) ?
Re: No header files?
AJ wrote: Walter Bright newshou...@digitalmars.com wrote in message news:hbo7fa$316...@digitalmars.com... AJ wrote: You lose the ability to use, say a class declaration, as the specification (at least without a sophisitcated, code-folding/code-formatting IDE). Just change class to interface and you're good to go. Seems apples and oranges to me. class declaration can have data members while interface can't. It's usually considered good style to keep your data members hidden from users. Interfaces do that nicely. I mean, my concept of it. I don't know what definitions D has of those things. In C++, I use interfaces where appropriate (say, where usage outside of a given library/subsystem is anticipated/desired), but for most purposes (say, within a given library/subsystem), I want a full class declaration (with data members etc). When I think interface, I think pure abstract base class and is something strictly behavioral. When thinking class or struct, I think first of the data members, something more nominal (noun-ish). If you're exposing data members to all the users, then you might as well expose the function bodies, too, because the benefits of hiding the implementation are already mostly gone.
Re: Semicolons: mostly unnecessary?
bearophile Wrote: Even worse, someone may even implement such alternative D syntax, and the sky will fall on your head: http://delight.sourceforge.net/ import dlt io Printer class Main void main Printer stdout stdout write Hello World!\n lolol
Re: Semicolons: mostly unnecessary?
Semicolons As Implicit Programming Language Statement Terminators (An Analysis in Process) Pros: 1. Makes parsing of certain (they need to be listed) constructs easier (how much?) (?). 2. Adds redundancy which helps diagnose and isolate (facilitates reporting of ) the following common programming/syntax errors: A. B. 3. One well-defined statement terminator. 4. No need to think: just assume what C/C++ uses is best, without question. 5. Does not require long statement line-continuation character (for instance, if statements with lots of clauses, and function calls/definitions with lots of arguments). 6. Prevents subtle bugs. 7. Facilitates languages that don't have header files. 8. Makes lexical analysis less syntactic. 9. Acts as a forward jump point for parser restart on error. 10. Makes select source code more comprehensible. 11. Cons: 1. Makes most source code less comprehensible. 2. Is redundant with the newline designator. 3. Is more typing. 4. Introduces tedium in development of implementations from header files. 5. Makes Andrei vomit. 6. Missing semicolons are the #1 bugaboo of all C programmers. 7. Imposes a requirement on the common case to handle the exceptional case. 8. Is a crutch for parser developers/stifles parser technology. 9. Imposes parser's role onto every developer. 10. Allows one to write hard-to-see do nothings like: for(;;); 11. Introduces subtle bugs. 12. Allows ignorant jettisoning of header file concept. 13. Discussion/Analysis On Pro5, if statements with lots of clauses: Parser should parse if statement as soon as it sees if rather than parse general statement. Aren't things like if ubiquitous enough to accept them as lexical rather than syntactical/semantical? On Pro5, Function calls/definitions with lots of arguments: same comment as on if statements with lots of clauses. On Pro8: Isn't that just a rewording of Con8? (5/8/08)
Re: Semicolons: mostly unnecessary?
Walter Bright newshou...@digitalmars.com wrote in message news:hbp2lc$1m2...@digitalmars.com... Adam D. Ruppe wrote: Ifthepointisntplainobviousfromtheabovefewersymbolsmostcertainly doesNOTmeanalanguageisnecessarilyeasiertoparseSymbolsgiveus aparsinganchorperiodsinasentencearentstrictlynecessarywecould putoneperlineorjustfigureoutwheretheybelongbyparsingthecontext Butthatsfairlyobviouslymuchharderthanusingperiodstofollowwhere youareSemicolonsarethesamething (Fixed that for you!) Ah, going from well-defined specific context to other, irrelevant context. Who do you think you are fooling?
Re: Semicolons: mostly unnecessary?
Don Wrote:
Please don't post crazy stuff like this. This proposal would break every
line of D code ever written.
If semicolons become optional, the old code that uses them will keep working,
because adding an extra semicolon isn't an error.
Broken lines like:
foo(x,
y);
a = [1, 2,
3];
c = [1:2,
3:4];
d = {0,
1};
too will keep working because the things inside parentheses [] () (and {} when
it's a static struct initializer) don't need an explicit line continuation sign.
Some lines will need editing because they will need the line continuation
syntax. I think this may be acceptable.
Bye,
bearophile
Re: Semicolons: mostly unnecessary?
Walter Bright: Adam D. Ruppe wrote: Ifthepointisntplainobviousfromtheabovefewersymbolsmostcertainly doesNOTmeanalanguageisnecessarilyeasiertoparseSymbolsgiveus aparsinganchorperiodsinasentencearentstrictlynecessarywecould putoneperlineorjustfigureoutwheretheybelongbyparsingthecontext Butthatsfairlyobviouslymuchharderthanusingperiodstofollowwhere youareSemicolonsarethesamething (Fixed that for you!) Having no spaces is not comparable to having no semicolons, because newlines are kept. Better to have a little more complex parser than putting the burden of adding the correct semicolons on the programmers. Bye, bearophile
Re: Semicolons: mostly unnecessary?
Don nos...@nospam.com wrote in message news:hbp00i$1d8...@digitalmars.com... AJ wrote: Why not eliminate the requirement for semicolon statement terminators (unless there are multiple statements per line)? Less typing is more! Please don't post crazy stuff like this. This proposal It's not a proposal, it's a question. It's becoming more well-formed as the thread evolves. would break every line of D code ever written. I don't care about that. I just want to know the right way to do it. When I figure that out (and I will), I'll either give D designers one point or take one point away (did he/they get it right or get it wrong?). YOU ARE WASTING YOUR TIME (and everyone elses). Accumulating knowledge is never a waste of time. If you personally are not interested in the topic, why bother reading the thread? Isn't reading threads on topics you are not interested in and cannot add value to a waste of your time?
Re: No header files?
Nick Sabalausky a...@a.a wrote in message news:hboum3$1bh...@digitalmars.com... AJ a...@nospam.net wrote in message news:hbosh1$17l...@digitalmars.com... Nick Sabalausky a...@a.a wrote in message news:hbontv$uq...@digitalmars.com... If you want to manually write a separate redundant file with just declarations before writing the implementation, no one's stopping you. You sound angry that your feature is not a fit for my development process. jump in and start coding algorithms is not an acceptable development method in my book. Don't put words in my mouth. I wasn't. I was telling you what I parsed your verbage into (and I'm correct 99% of the time) and gave you back some of your own medicine.
Re: No header files?
Walter Bright newshou...@digitalmars.com wrote in message news:hbp309$1nb...@digitalmars.com... AJ wrote: Walter Bright newshou...@digitalmars.com wrote in message news:hbo7fa$316...@digitalmars.com... AJ wrote: You lose the ability to use, say a class declaration, as the specification (at least without a sophisitcated, code-folding/code-formatting IDE). Just change class to interface and you're good to go. Seems apples and oranges to me. class declaration can have data members while interface can't. It's usually considered good style to keep your data members hidden from users. That's an incomplete thought. You are assuming a certain scenario perhaps. It would be seemingly (for lack of any agreement on the definition of users and the context) an extreme position to take otherwise. And no, I don't want to entertain or tangent to OO 101 dialog/discussion/debate either thank you. Interfaces do that nicely. I mean, my concept of it. I don't know what definitions D has of those things. In C++, I use interfaces where appropriate (say, where usage outside of a given library/subsystem is anticipated/desired), but for most purposes (say, within a given library/subsystem), I want a full class declaration (with data members etc). When I think interface, I think pure abstract base class and is something strictly behavioral. When thinking class or struct, I think first of the data members, something more nominal (noun-ish). If you're exposing data members to all the users, then you might as well expose the function bodies, too, because the benefits of hiding the implementation are already mostly gone. There's no sense in discussing it in such a general or dogmatic way.
Re: No header files?
Yigal Chripun yigal...@gmail.com wrote in message news:hbp0hh$1i2...@digitalmars.com... the benefits of using the llvm byte-code format are as following: 1) platform neutral Ha! I consider it another platform! 2) has efficient representation for in-memory and an equivalent for on-disk. 3) like with C# and Java, the file *is* the interface, no need to maintain a separate interface file. 4) already implemented with all the required tooling by the LLVM project
Re: Semicolons: mostly unnecessary?
I say we should get rid of vowels - it worked for the ancient egyptians :-) Next thing you know someone will propose eliminating braces and just using whitespace to denote blocks. It's utter madness. Or get rid of all the visible chars and use Whitespace... http://compsoc.dur.ac.uk/whitespace/ -=mike=-
Re: No header files?
Walter Bright newshou...@digitalmars.com wrote in message news:hbp2a5$1m2...@digitalmars.com... Steven Schveighoffer wrote: On Wed, 21 Oct 2009 19:21:32 -0400, Walter Bright newshou...@digitalmars.com wrote: Yigal Chripun wrote: The C/C++ way of headers + lib has problems which D inherited as part of the same (broken) design. Hardly, as: 1. you don't need to use header files in D at all 2. you can automatically generate .di files, guaranteeing they are not out of sync That second one is not true if you are doing incremental building (ever use a build tool that occasionally screws up and doesn't rebuild something?). At least it is possible to automate. You cannot automate C/C++ header files, so they are inherently unreliable. In addition, the only *true* reason to use .di files is to hide implementation It's also to speed up compilation. -- which the auto generator does *not* do. So you are back to hand editing and back to sync problems. If you need to hide implementation, I suggest instead redesigning your interface to use interface types, or use the pimpl idiom. And jettison close to the metal in one fell swoop? IMO .di files are as horrible as header files in C and I avoid them like the plague. I'd hate to have to use them, but so far, I haven't had any public release of proprietary code, so no need for them yet. I agree they aren't necessary most of the time, I don't agree they are even as close to being as horrible as C headers, unless you are hand-editting them. If you are doing the latter, I suggest something may have gone wrong with the design of your interface. That's a very, very paradigmical view/statement.
Re: int always 32 bits on all platforms?
Chris Nicholson-Sauls ibisbase...@gmail.com wrote in message
news:hbou95$1al...@digitalmars.com...
AJ wrote:
Nick Sabalausky a...@a.a wrote in message
news:hbonbp$to...@digitalmars.com...
AJ a...@nospam.net wrote in message
news:hboaeu$5s...@digitalmars.com...
BCS n...@anon.com wrote in message
news:a6268ffbb0a8cc20817fe1f...@news.digitalmars.com...
Hello aJ,
I would think so. Anyway, what I find compelling about guaranteed
widths is the potential to eliminate alignment and padding issues
(that is, be able to control it with confidence across platforms as
one already can on a single platform via compiler pragmas or cmdline
switches).
Ah! I thought you were taking issue with something. D has that and
gets most of the porting stuff to work.
It does? Get this to work on all platforms:
struct ABC
{
byte a;
int b; // may be improperly aligned on some platforms
int64 c; // same issue
};
// Guarantee packed on all platforms
align() struct ABC
{
byte a;
int b; // may be improperly aligned on some platforms
int64 c; // same issue
};
Well I can do the same thing with pragma or compiler switch in C++. It
doesn't mean that thing will work if 32-bit ints have to be aligned on
32-bit boundaries. While nice to have one syntax to do that, it doesn't
fix the problem (which I haven't expressed correctly probably). What
good is a packed structure that has misaligned data members for the
platform?
struct ABC {
version (RequireAlign4) align(4)
byte a;
int b;
int64 c;
}
Please 'splain the above.
Re: int always 32 bits on all platforms?
Nick Sabalausky a...@a.a wrote in message
news:hboui3$1bb...@digitalmars.com...
AJ a...@nospam.net wrote in message
news:hbor97$155...@digitalmars.com...
Nick Sabalausky a...@a.a wrote in message
news:hbonj3$u3...@digitalmars.com...
AJ a...@nospam.net wrote in message
news:hboa9p$5m...@digitalmars.com...
How do you make ABC below work on a platform that requires 32-bit
integers to be aligned on 32-bit boundaries while keeping the layount
and size of ABC the same as on a platform that has no such alignment
requirement?
struct ABC
{
byte a;
int b; // may be improperly aligned on some platforms
int64 c; // same issue
};
It can be done by using bitmasks and bit shifting on every access.
I had a feeling I was delving into dangerous territory (read, way too
low level for me, but I wonder what the possibilities are). I have a
feeling that I may be wanting hardware standardization because it can't
be solved at the language level (?).
I don't understand how using bitmasks and bit shifting on every access
would work
Normally, the compiler would turn this:
myabc1.b = myabc2.b + 1;
Into something like this:
- move value at memory address x (myabc2.b) into cpu register
- add 1
- move value in cpu register into memory address x (myabc1.b)
If the compiler knows that myabc1.b and myabc2.b are not aligned in a way
that the cpu can directly access, then what it would turn it into is
something like:
- move the values at the two memory addresses that myabc2.b straddles into
cpu registers
- use bit manipulation tricks to throw away myabc2.a and myabc2.c and
compine the two parts of myabc2.b
- add 1
- use bit manipulation tricks to split the value in the cpu register back
into two parts, and mix in myabc1.a and myabc1.c
- move the restulting values into the memory addresses that myabc1.b
straddles
OK, thanks.
the plausibility of it
It should always possible. Although references to the struct's members
would probably be very tricky and require a lot of extra fancy work.
I should have used 'practicality' instead of 'plausibility'. So maybe not so
practical (unless the concept is a real boon). (No, I don't know what a
boon is either ;) ).
and the cost (in execution time) of doing so.
Depends completely on the cpu, of course. In general though, it's quite a
bit slower (a single fetch or store turns into at least two fetches/stores
plus some bitmasking and shifting, maybe uses up extra registers, and
would make less of the code fit in cache). But that's the price you pay
for using packed structs like that on such a CPU. Or you could just use
align(4) to guarantee 32-bit alignment on all fields for all cpus.
Yes, surely that is the way to go. Or... craft structs to align nicely in
the first place and make the decision on which CPUs you want one set of code
to run on:
struct ABC
{
byte a;
byte pad1;
byte pad2;
byte pad3;
int b; // may be improperly aligned on some platforms
int64 c; // same issue
}
Re: int always 32 bits on all platforms?
On Oct 22, 09 17:31, AJ wrote:
Nick Sabalauskya...@a.a wrote in message
news:hboui3$1bb...@digitalmars.com...
AJa...@nospam.net wrote in message
news:hbor97$155...@digitalmars.com...
Nick Sabalauskya...@a.a wrote in message
news:hbonj3$u3...@digitalmars.com...
AJa...@nospam.net wrote in message
news:hboa9p$5m...@digitalmars.com...
How do you make ABC below work on a platform that requires 32-bit
integers to be aligned on 32-bit boundaries while keeping the layount
and size of ABC the same as on a platform that has no such alignment
requirement?
struct ABC
{
byte a;
int b; // may be improperly aligned on some platforms
int64 c; // same issue
};
It can be done by using bitmasks and bit shifting on every access.
I had a feeling I was delving into dangerous territory (read, way too
low level for me, but I wonder what the possibilities are). I have a
feeling that I may be wanting hardware standardization because it can't
be solved at the language level (?).
I don't understand how using bitmasks and bit shifting on every access
would work
Normally, the compiler would turn this:
myabc1.b = myabc2.b + 1;
Into something like this:
- move value at memory address x (myabc2.b) into cpu register
- add 1
- move value in cpu register into memory address x (myabc1.b)
If the compiler knows that myabc1.b and myabc2.b are not aligned in a way
that the cpu can directly access, then what it would turn it into is
something like:
- move the values at the two memory addresses that myabc2.b straddles into
cpu registers
- use bit manipulation tricks to throw away myabc2.a and myabc2.c and
compine the two parts of myabc2.b
- add 1
- use bit manipulation tricks to split the value in the cpu register back
into two parts, and mix in myabc1.a and myabc1.c
- move the restulting values into the memory addresses that myabc1.b
straddles
OK, thanks.
the plausibility of it
It should always possible. Although references to the struct's members
would probably be very tricky and require a lot of extra fancy work.
I should have used 'practicality' instead of 'plausibility'. So maybe not so
practical (unless the concept is a real boon). (No, I don't know what a
boon is either ;) ).
and the cost (in execution time) of doing so.
Depends completely on the cpu, of course. In general though, it's quite a
bit slower (a single fetch or store turns into at least two fetches/stores
plus some bitmasking and shifting, maybe uses up extra registers, and
would make less of the code fit in cache). But that's the price you pay
for using packed structs like that on such a CPU. Or you could just use
align(4) to guarantee 32-bit alignment on all fields for all cpus.
Yes, surely that is the way to go. Or... craft structs to align nicely in
the first place and make the decision on which CPUs you want one set of code
to run on:
struct ABC
{
byte a;
byte pad1;
byte pad2;
byte pad3;
int b; // may be improperly aligned on some platforms
int64 c; // same issue
}
If data offset is really that important, you should use a bitfield.
Re: Array, AA Implementations
Don wrote: Andrei Alexandrescu wrote: Bill Baxter wrote: On Wed, Oct 21, 2009 at 6:35 PM, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: 3. Remove some element from the container and give it to me E removeAny(); 4. Add an element to the container is possible bool add(E); I think any container must support these primitives in O(1), and I find it difficult to think of a significant category of containers that can't support them (but then there may as well be, so please join me in thinking of that). A lot of stuff can be done with only these few methods. I think balanced trees generally take O(lg N) to add and remove elements. Good point, thanks. Logarithmic of better. Andrei Can it be amortized O(lg N) ? Amortized logarithmic is equivalent to logarithmic.
Re: No header files?
Walter Bright Wrote: Yigal Chripun wrote: On 22/10/2009 02:01, Walter Bright wrote: Yigal Chripun wrote: the only valid IMO use case for header files is for linking libs - the compiler can handle just find binary formats for that. I was originally going to go with a binary format for that - but it turned out to be pointless. dmd is so fast at parsing, there simply was no advantage to replacing the text file parser with a binary file parser. If you consider the .di file as a binary format, I think you'll find it fulfills all the purposes of it, as well as being human readable without needing a pretty-printer. Let me re-phrase myself, since I think you misunderstood: c headers are used for hiding implementation *and* documentation. the latter is accomplished much better by tools such as ddoc, javadoc, etc. This leaves us with the former, which doesn't require the format to be human readable, it doesn't mean you must make it not-readable. the benefits of using the llvm byte-code format are as following: 1) platform neutral Check. 2) has efficient representation for in-memory and an equivalent for on-disk. Check. 3) like with C# and Java, the file *is* the interface, no need to maintain a separate interface file. Check. (D doesn't need bytecode files in addition to .obj files, so LLVM isn't saving on any files compared with D.) 4) already implemented with all the required tooling by the LLVM project Check. I'm not really understanding what's wrong with .di files. Further advantages of .di files: 1. Neither .di files nor .obj files are needed for other files to successfully import and reference library code 2. .di files are human readable without any need to learn anything other than D 3. No new file formats to design, document, debug and maintain 4. No extra code needed to implement a .di file reader in the compiler I think you misunderstood. the idea is *not* to replace .di header files with llvm bit-code files. the idea is to replace d object files lib files with a llvm bit-code equivalents which does not need additional header files. let's go over the list one more time: 1) i can't use obj files from different OSes or even different compilers on the same OS - so definitly *not* platform neutral 2) you need to parse a header file in addition to linking functions from the lib file, how is that better than having one file without needing to do any parsing of headers at all? 3) like Steve said, there is only one file so you don't get syncing problems between the header and the object file. the bit-code object file already contains all the required metadata and doesn't depend on a separate header file. 4)LLVM is already implemented and has all the required tools for its format. ldc for example can take advantage of this easily.
Re: Semicolons: mostly unnecessary?
Mike James f...@bar.com wrote in message news:hbp7le$220...@digitalmars.com... I say we should get rid of vowels - it worked for the ancient egyptians :-) Next thing you know someone will propose eliminating braces and just using whitespace to denote blocks. It's utter madness. Or get rid of all the visible chars and use Whitespace... http://compsoc.dur.ac.uk/whitespace/ Until editors/IDEs become Whitespace-aware, I wouldn't recommend using Whitespace: one click on Save in an editor that converts tabs into spaces and your code is gone. (I was so mad when that happened enough times that I went back to C++).
Re: Semicolons: mostly unnecessary?
On Oct 22, 09 13:57, AJ wrote:
KennyTM~kenn...@gmail.com wrote in message
news:hbopns$125...@digitalmars.com...
On Oct 22, 09 12:29, AJ wrote:
Adam D. Ruppedestructiona...@gmail.com wrote in message
news:mailman.228.1256181155.20261.digitalmar...@puremagic.com...
On Wed, Oct 21, 2009 at 09:25:34PM -0500, AJ wrote:
That's not D source code. Why do you keep trying to use English text as
an
example?
The logic behind all the arguments you make,
That would be all fine and dandy, but I'm not arguing about anything.
(So
you must be arguing? About what?).
except for one, should apply
equally well to English as it does to D.
That's silly. There is no need to use the text of Shakespeare's tragedies
to
allude to source code. There is no need and it is entirely inappropriate
to
expand the context of the issue to other realms. The context is
(currently):
semicolons as statement terminators for single-statement lines.
Cons:
1. Makes source code less comprehensible.
Based on what? Because you say so?
It's more to digest when it's not necessary. It's easier to identify
something when it's in less intricate (read, plain) surroundings.
snipped inappropriate context reference
2. Is redundant with the newline designator.
snipped inappropriate context reference
is obviously false,
If I put it on the list, it wasn't obvious at all, even if it is
incorrect
(though I think it is correct).
unless
you specifically require a line continuation character:
a = b +
c
Without semicolon requirement:
a=b+ // this is an error
c // this is OK
With semicolon requirement:
a=b+; // this is an error
c; // this is OK
What's the diff?
A newline and a semicolon are not redundant unless you specifically
define
a statement as being one and only one line.
A semicolon is redundate with newline for single-statement lines. Oh, you
say that a lot of constructs are inherently single statements but written
on
multiple lines? Well, that may be just the kind of examination I was
looking
for (ironic that _I_ had to bring it up, huh):
if(true)
dothis()
That situation has to be evaluated: is parsing at the construct level too
much effort or is it desireable? (ParseIfStatement()). Statement-level
parsing better/worse than line-level parsing?
Back to the magic of above though. What if you rewrote it:
a = b
+c
Without semicolon requirement:
a=b // OK
+c // error
With semicolon requirement:
a=b; // OK
+c; // error
What's the diff?
a=b
+c(d) // no error
Why not?
Good question. Because the compiler accepts a=b;+c(d);.
Whether c is declared as a variable or a function, it still looks
wrong to me. A statement can't begin with a +.
OK.
struct S { int a }
int a
void main () {
S s
auto t = s
.a = 1 // ambiguity: Note that .sth means global scope.
}
3. Is more typing.
snipped inappropriate context reference
how long does it take to type a semicolon anyway?
Typing unnecessary semicolons (if they are unnecessary) is dumb.
Re: No header files?
AJ a...@nospam.net wrote in message news:hbp6ka$1uv...@digitalmars.com... Nick Sabalausky a...@a.a wrote in message news:hboum3$1bh...@digitalmars.com... AJ a...@nospam.net wrote in message news:hbosh1$17l...@digitalmars.com... Nick Sabalausky a...@a.a wrote in message news:hbontv$uq...@digitalmars.com... If you want to manually write a separate redundant file with just declarations before writing the implementation, no one's stopping you. You sound angry that your feature is not a fit for my development process. jump in and start coding algorithms is not an acceptable development method in my book. Don't put words in my mouth. I wasn't. I was telling you what I parsed your verbage into (and I'm correct 99% of the time) and gave you back some of your own medicine. superdan, is that you?
Re: int always 32 bits on all platforms?
KennyTM~ kenn...@gmail.com wrote in message
news:hbp924$24h...@digitalmars.com...
On Oct 22, 09 17:31, AJ wrote:
Nick Sabalauskya...@a.a wrote in message
news:hboui3$1bb...@digitalmars.com...
AJa...@nospam.net wrote in message
news:hbor97$155...@digitalmars.com...
Nick Sabalauskya...@a.a wrote in message
news:hbonj3$u3...@digitalmars.com...
AJa...@nospam.net wrote in message
news:hboa9p$5m...@digitalmars.com...
How do you make ABC below work on a platform that requires 32-bit
integers to be aligned on 32-bit boundaries while keeping the layount
and size of ABC the same as on a platform that has no such alignment
requirement?
struct ABC
{
byte a;
int b; // may be improperly aligned on some platforms
int64 c; // same issue
};
It can be done by using bitmasks and bit shifting on every access.
I had a feeling I was delving into dangerous territory (read, way too
low level for me, but I wonder what the possibilities are). I have a
feeling that I may be wanting hardware standardization because it can't
be solved at the language level (?).
I don't understand how using bitmasks and bit shifting on every access
would work
Normally, the compiler would turn this:
myabc1.b = myabc2.b + 1;
Into something like this:
- move value at memory address x (myabc2.b) into cpu register
- add 1
- move value in cpu register into memory address x (myabc1.b)
If the compiler knows that myabc1.b and myabc2.b are not aligned in a
way
that the cpu can directly access, then what it would turn it into is
something like:
- move the values at the two memory addresses that myabc2.b straddles
into
cpu registers
- use bit manipulation tricks to throw away myabc2.a and myabc2.c and
compine the two parts of myabc2.b
- add 1
- use bit manipulation tricks to split the value in the cpu register
back
into two parts, and mix in myabc1.a and myabc1.c
- move the restulting values into the memory addresses that myabc1.b
straddles
OK, thanks.
the plausibility of it
It should always possible. Although references to the struct's members
would probably be very tricky and require a lot of extra fancy work.
I should have used 'practicality' instead of 'plausibility'. So maybe not
so
practical (unless the concept is a real boon). (No, I don't know what a
boon is either ;) ).
and the cost (in execution time) of doing so.
Depends completely on the cpu, of course. In general though, it's quite
a
bit slower (a single fetch or store turns into at least two
fetches/stores
plus some bitmasking and shifting, maybe uses up extra registers, and
would make less of the code fit in cache). But that's the price you pay
for using packed structs like that on such a CPU. Or you could just use
align(4) to guarantee 32-bit alignment on all fields for all cpus.
Yes, surely that is the way to go. Or... craft structs to align nicely in
the first place and make the decision on which CPUs you want one set of
code
to run on:
struct ABC
{
byte a;
byte pad1;
byte pad2;
byte pad3;
int b; // may be improperly aligned on some platforms
int64 c; // same issue
}
If data offset is really that important, you should use a bitfield.
?
Re: No header files?
On Thu, Oct 22, 2009 at 11:50 AM, Yigal Chripun yigal...@gmail.com wrote: I think you misunderstood. the idea is *not* to replace .di header files with llvm bit-code files. the idea is to replace d object files lib files with a llvm bit-code equivalents which does not need additional header files. let's go over the list one more time: 1) i can't use obj files from different OSes or even different compilers on the same OS - so definitly *not* platform neutral 2) you need to parse a header file in addition to linking functions from the lib file, how is that better than having one file without needing to do any parsing of headers at all? 3) like Steve said, there is only one file so you don't get syncing problems between the header and the object file. the bit-code object file already contains all the required metadata and doesn't depend on a separate header file. 4)LLVM is already implemented and has all the required tools for its format. ldc for example can take advantage of this easily. This locks D to the LLVM backend, things like that is never a good idea. Also, LLVM bitcode files produced both by LDC and Clang/llvm-gcc are platform specific. Sure you can process them on any platform, but the source code they were compiled from was platform specific, and so is the resulting bitcode. Using LLVM bitcode as a replacement format for native OMF/COFF/ELF objects, does not give us platform neutrality. -Tomas
Re: Semicolons: mostly unnecessary?
AJ wrote: Mike James f...@bar.com wrote in message news:hbp7le$220...@digitalmars.com... I say we should get rid of vowels - it worked for the ancient egyptians :-) Next thing you know someone will propose eliminating braces and just using whitespace to denote blocks. It's utter madness. Or get rid of all the visible chars and use Whitespace... http://compsoc.dur.ac.uk/whitespace/ Until editors/IDEs become Whitespace-aware, I wouldn't recommend using Whitespace: one click on Save in an editor that converts tabs into spaces and your code is gone. (I was so mad when that happened enough times that I went back to C++). You should try WhitespaceIDE: http://sourceforge.net/projects/whitespaceide/
Re: Semicolons: mostly unnecessary?
KennyTM~ kenn...@gmail.com wrote in message
news:hbpa89$27s...@digitalmars.com...
On Oct 22, 09 13:57, AJ wrote:
KennyTM~kenn...@gmail.com wrote in message
news:hbopns$125...@digitalmars.com...
On Oct 22, 09 12:29, AJ wrote:
Adam D. Ruppedestructiona...@gmail.com wrote in message
news:mailman.228.1256181155.20261.digitalmar...@puremagic.com...
On Wed, Oct 21, 2009 at 09:25:34PM -0500, AJ wrote:
That's not D source code. Why do you keep trying to use English text
as
an
example?
The logic behind all the arguments you make,
That would be all fine and dandy, but I'm not arguing about anything.
(So
you must be arguing? About what?).
except for one, should apply
equally well to English as it does to D.
That's silly. There is no need to use the text of Shakespeare's
tragedies
to
allude to source code. There is no need and it is entirely
inappropriate
to
expand the context of the issue to other realms. The context is
(currently):
semicolons as statement terminators for single-statement lines.
Cons:
1. Makes source code less comprehensible.
Based on what? Because you say so?
It's more to digest when it's not necessary. It's easier to identify
something when it's in less intricate (read, plain) surroundings.
snipped inappropriate context reference
2. Is redundant with the newline designator.
snipped inappropriate context reference
is obviously false,
If I put it on the list, it wasn't obvious at all, even if it is
incorrect
(though I think it is correct).
unless
you specifically require a line continuation character:
a = b +
c
Without semicolon requirement:
a=b+ // this is an error
c // this is OK
With semicolon requirement:
a=b+; // this is an error
c; // this is OK
What's the diff?
A newline and a semicolon are not redundant unless you specifically
define
a statement as being one and only one line.
A semicolon is redundate with newline for single-statement lines. Oh,
you
say that a lot of constructs are inherently single statements but
written
on
multiple lines? Well, that may be just the kind of examination I was
looking
for (ironic that _I_ had to bring it up, huh):
if(true)
dothis()
That situation has to be evaluated: is parsing at the construct level
too
much effort or is it desireable? (ParseIfStatement()). Statement-level
parsing better/worse than line-level parsing?
Back to the magic of above though. What if you rewrote it:
a = b
+c
Without semicolon requirement:
a=b // OK
+c // error
With semicolon requirement:
a=b; // OK
+c; // error
What's the diff?
a=b
+c(d) // no error
Why not?
Good question. Because the compiler accepts a=b;+c(d);.
I don't think it should.
Whether c is declared as a variable or a function, it still looks
wrong to me. A statement can't begin with a +.
OK.
struct S { int a }
int a
void main () {
S s
auto t = s
.a = 1 // ambiguity: Note that .sth means global scope.
}
That's not ambiguous, it's erroneous. The passage means:
auto t = s // fine
.a = 1 // can't have .a without something on the left of the dot
// or else remove the dot
Small performance problem
In D there are several things to implement and fix that have a priority higher
than tuning the performance of the DMD back-end (a work may be wasted time
anyway). But arrays are common, so the following may interest anyway.
On LDC this synthetic benchmark shows the same run time with both values of the
use_dynamic_array constant, while on DMD the version that uses dynamic arrays
is something like 70% faster (on both D1 compiler and last D2 compiler):
version (Tango)
import tango.stdc.stdio: printf;
else
version (D_Version2)
import std.c.stdio: printf;
const bool use_dynamic_array = true; // change this
void main() {
const int n = 100_000;
const int nloop = 6_000;
int[] aux1 = new int[n];
int[] aux2 = new int[n];
static if (use_dynamic_array) {
alias aux1 a1;
alias aux2 a2;
} else {
int* a1 = aux1.ptr;
int* a2 = aux2.ptr;
}
for (int i; i nloop; i++) {
for (int j; j n; j++)
a1[j] += a2[j];
for (int j; j n; j++)
a2[j] += a1[j];
}
printf(%d\n, a1[10]);
}
Asm of the inner loop with dynamic arrays (DMD):
L59:mov ECX,[EBX*4][ESI]
add [EBX*4][EDX],ECX
inc EBX
cmp EBX,0186A0h
jb L59
Asm of the inner loop with pointers (DMD):
L47:mov ESI,01Ch[ESP]
mov EAX,014h[ESP]
mov EDI,[EBX*4][ESI]
add [EBX*4][EAX],EDI
inc EBX
cmp EBX,0186A0h
jb L47
Bye,
bearophile
Re: Semicolons: mostly unnecessary?
Ary Borenszweig a...@esperanto.org.ar wrote in message news:hbpau3$297...@digitalmars.com... AJ wrote: Mike James f...@bar.com wrote in message news:hbp7le$220...@digitalmars.com... I say we should get rid of vowels - it worked for the ancient egyptians :-) Next thing you know someone will propose eliminating braces and just using whitespace to denote blocks. It's utter madness. Or get rid of all the visible chars and use Whitespace... http://compsoc.dur.ac.uk/whitespace/ Until editors/IDEs become Whitespace-aware, I wouldn't recommend using Whitespace: one click on Save in an editor that converts tabs into spaces and your code is gone. (I was so mad when that happened enough times that I went back to C++). You should try WhitespaceIDE: http://sourceforge.net/projects/whitespaceide/ I'm not nearly about to recreate all that lost code that I've since redeveloped in C++!! (The very clean syntax is alluring though).
Re: Semicolons: mostly unnecessary?
bearophile bearophileh...@lycos.com wrote in message news:hbp5qa$1te...@digitalmars.com... Walter Bright: Adam D. Ruppe wrote: Ifthepointisntplainobviousfromtheabovefewersymbolsmostcertainly doesNOTmeanalanguageisnecessarilyeasiertoparseSymbolsgiveus aparsinganchorperiodsinasentencearentstrictlynecessarywecould putoneperlineorjustfigureoutwheretheybelongbyparsingthecontext Butthatsfairlyobviouslymuchharderthanusingperiodstofollowwhere youareSemicolonsarethesamething (Fixed that for you!) Having no spaces is not comparable to having no semicolons, because newlines are kept. Better to have a little more complex parser than putting the burden of adding the correct semicolons on the programmers. I'm already kicking myself for trying to jump into the middle of yet another semicolon debate, but...burden of semicolons? Isn't that a bit overstated? I suppose it depends on the person, but I find it to be every bit as automatic as reaching for the Shift key when I write camelcase, or hitting enter for a new line, or going for control when I want to arrow around a word-at-a-time. And those are hardly burdens (and sure, technically a semicolon plus newline is more than *just* newline, but only negligibly so). Line-continuation operators, on the other hand, or complex rules for when a semicolon is or isn't required (along with the resulting inconsistency of some things having semicolons and other things not), do tend to noticeably get in my way.
Re: No header files?
Nick Sabalausky a...@a.a wrote in message news:hbpa7q$27r...@digitalmars.com... AJ a...@nospam.net wrote in message news:hbp6ka$1uv...@digitalmars.com... Nick Sabalausky a...@a.a wrote in message news:hboum3$1bh...@digitalmars.com... AJ a...@nospam.net wrote in message news:hbosh1$17l...@digitalmars.com... Nick Sabalausky a...@a.a wrote in message news:hbontv$uq...@digitalmars.com... If you want to manually write a separate redundant file with just declarations before writing the implementation, no one's stopping you. You sound angry that your feature is not a fit for my development process. jump in and start coding algorithms is not an acceptable development method in my book. Don't put words in my mouth. I wasn't. I was telling you what I parsed your verbage into (and I'm correct 99% of the time) and gave you back some of your own medicine. superdan, is that you? No. And tomorrow (later today after I get done sleeping), I'm going to do more coding and less newsgrouping! Goodnight.
Re: Semicolons: mostly unnecessary?
AJ a...@nospam.net wrote in message news:hbpb1b$29u...@digitalmars.com...
KennyTM~ kenn...@gmail.com wrote in message
news:hbpa89$27s...@digitalmars.com...
OK.
struct S { int a }
int a
void main () {
S s
auto t = s
.a = 1 // ambiguity: Note that .sth means global scope.
}
That's not ambiguous, it's erroneous. The passage means:
auto t = s // fine
.a = 1 // can't have .a without something on the left of the dot
// or else remove the dot
Wrong. Read the D docs.
Re: int always 32 bits on all platforms?
AJ a...@nospam.net wrote in message news:hbp85j$238...@digitalmars.com...
Chris Nicholson-Sauls ibisbase...@gmail.com wrote in message
news:hbou95$1al...@digitalmars.com...
AJ wrote:
Nick Sabalausky a...@a.a wrote in message
news:hbonbp$to...@digitalmars.com...
AJ a...@nospam.net wrote in message
news:hboaeu$5s...@digitalmars.com...
BCS n...@anon.com wrote in message
news:a6268ffbb0a8cc20817fe1f...@news.digitalmars.com...
Hello aJ,
I would think so. Anyway, what I find compelling about guaranteed
widths is the potential to eliminate alignment and padding issues
(that is, be able to control it with confidence across platforms as
one already can on a single platform via compiler pragmas or cmdline
switches).
Ah! I thought you were taking issue with something. D has that and
gets most of the porting stuff to work.
It does? Get this to work on all platforms:
struct ABC
{
byte a;
int b; // may be improperly aligned on some platforms
int64 c; // same issue
};
// Guarantee packed on all platforms
align() struct ABC
{
byte a;
int b; // may be improperly aligned on some platforms
int64 c; // same issue
};
Well I can do the same thing with pragma or compiler switch in C++. It
doesn't mean that thing will work if 32-bit ints have to be aligned on
32-bit boundaries. While nice to have one syntax to do that, it doesn't
fix the problem (which I haven't expressed correctly probably). What
good is a packed structure that has misaligned data members for the
platform?
struct ABC {
version (RequireAlign4) align(4)
byte a;
int b;
int64 c;
}
Please 'splain the above.
http://www.digitalmars.com/d/1.0/attribute.html#align
http://www.digitalmars.com/d/1.0/version.html#version
http://dictionary.reference.com/browse/explain?r=75
Re: Targeting C
bearophile wrote:
Tim Matthews:
OOC. I quite like how this one myself personally. http://ooc-lang.org/about
Type of arguments can be stated once:
Vector3f: class {
x, y, z : Float
init: func(x, y, z : Float) {
this x = x // 'this' is called 'self' in some other languages
this y = y
this z = z
}
}
It doesn't need the is() when you test for type equality:
print: func T (arg: T) {
if(T == Int) {
printf(%d\n, arg as Int) // 'as' allow casting
} else if(T == String) {
printf(%s\n, arg as String)
}
}
Uses a syntax better than the D foreach:
list := ArrayListInt new()
for(i in 0..10) list add(i) // oh yeah no needs for brackets
for(i in list) printf(%d\n)
And I have omitted some other handy features.
There's something to learn for D too :-)
Bye,
bearophile
Personally, I like this:
foreach (i; 0..10) list ~= i;
more. :)
Re: Semicolons: mostly unnecessary?
AJ wrote:
KennyTM~ kenn...@gmail.com wrote in message
news:hbpa89$27s...@digitalmars.com...
On Oct 22, 09 13:57, AJ wrote:
KennyTM~kenn...@gmail.com wrote in message
news:hbopns$125...@digitalmars.com...
On Oct 22, 09 12:29, AJ wrote:
Adam D. Ruppedestructiona...@gmail.com wrote in message
news:mailman.228.1256181155.20261.digitalmar...@puremagic.com...
On Wed, Oct 21, 2009 at 09:25:34PM -0500, AJ wrote:
That's not D source code. Why do you keep trying to use English text
as
an
example?
The logic behind all the arguments you make,
That would be all fine and dandy, but I'm not arguing about anything.
(So
you must be arguing? About what?).
except for one, should apply
equally well to English as it does to D.
That's silly. There is no need to use the text of Shakespeare's
tragedies
to
allude to source code. There is no need and it is entirely
inappropriate
to
expand the context of the issue to other realms. The context is
(currently):
semicolons as statement terminators for single-statement lines.
Cons:
1. Makes source code less comprehensible.
Based on what? Because you say so?
It's more to digest when it's not necessary. It's easier to identify
something when it's in less intricate (read, plain) surroundings.
snipped inappropriate context reference
2. Is redundant with the newline designator.
snipped inappropriate context reference
is obviously false,
If I put it on the list, it wasn't obvious at all, even if it is
incorrect
(though I think it is correct).
unless
you specifically require a line continuation character:
a = b +
c
Without semicolon requirement:
a=b+ // this is an error
c // this is OK
With semicolon requirement:
a=b+; // this is an error
c; // this is OK
What's the diff?
A newline and a semicolon are not redundant unless you specifically
define
a statement as being one and only one line.
A semicolon is redundate with newline for single-statement lines. Oh,
you
say that a lot of constructs are inherently single statements but
written
on
multiple lines? Well, that may be just the kind of examination I was
looking
for (ironic that _I_ had to bring it up, huh):
if(true)
dothis()
That situation has to be evaluated: is parsing at the construct level
too
much effort or is it desireable? (ParseIfStatement()). Statement-level
parsing better/worse than line-level parsing?
Back to the magic of above though. What if you rewrote it:
a = b
+c
Without semicolon requirement:
a=b // OK
+c // error
With semicolon requirement:
a=b; // OK
+c; // error
What's the diff?
a=b
+c(d) // no error
Why not?
Good question. Because the compiler accepts a=b;+c(d);.
I don't think it should.
Whether c is declared as a variable or a function, it still looks
wrong to me. A statement can't begin with a +.
OK.
struct S { int a }
int a
void main () {
S s
auto t = s
.a = 1 // ambiguity: Note that .sth means global scope.
}
That's not ambiguous, it's erroneous. The passage means:
auto t = s // fine
.a = 1 // can't have .a without something on the left of the dot
// or else remove the dot
In D you use the dot like that to access globals, cf. the comment in
KennyTM~s example.
-Lars
Re: Targeting C
Pelle Månsson: Personally, I like this: foreach (i; 0..10) list ~= i; more. :) While I like this more: for (i in 0 .. 10) list ~= i; Bye, bearophile
Re: Semicolons: mostly unnecessary?
Nick Sabalausky: I'm already kicking myself for trying to jump into the middle of yet another semicolon debate, but...burden of semicolons? Isn't that a bit overstated? I suppose it depends on the person, but I find it to be every bit as automatic as reaching for the Shift key when I write camelcase, or hitting enter for a new line, or going for control when I want to arrow around a word-at-a-time. And those are hardly burdens (and sure, technically a semicolon plus newline is more than *just* newline, but only negligibly so). Yes, you are right, adding the semicolon doesn't take a lot of time, but when you miss it, the program doesn't compile, and you have to find where you have missed it, sometimes this requires some time. And I've seen plenty of newbie programmers that think the computer is idiot and fussy for asking them to put such useless semicolons. I guess this is not a strong argument because newbie programmers will probably not want to start with D as first language :-) Bye, bearophile
Re: Semicolons: mostly unnecessary?
KennyTM~ wrote:
On Oct 22, 09 13:57, AJ wrote:
KennyTM~kenn...@gmail.com wrote in message
news:hbopns$125...@digitalmars.com...
On Oct 22, 09 12:29, AJ wrote:
Adam D. Ruppedestructiona...@gmail.com wrote in message
news:mailman.228.1256181155.20261.digitalmar...@puremagic.com...
On Wed, Oct 21, 2009 at 09:25:34PM -0500, AJ wrote:
That's not D source code. Why do you keep trying to use English
text as
an
example?
The logic behind all the arguments you make,
That would be all fine and dandy, but I'm not arguing about anything.
(So
you must be arguing? About what?).
except for one, should apply
equally well to English as it does to D.
That's silly. There is no need to use the text of Shakespeare's
tragedies
to
allude to source code. There is no need and it is entirely
inappropriate
to
expand the context of the issue to other realms. The context is
(currently):
semicolons as statement terminators for single-statement lines.
Cons:
1. Makes source code less comprehensible.
Based on what? Because you say so?
It's more to digest when it's not necessary. It's easier to identify
something when it's in less intricate (read, plain) surroundings.
snipped inappropriate context reference
2. Is redundant with the newline designator.
snipped inappropriate context reference
is obviously false,
If I put it on the list, it wasn't obvious at all, even if it is
incorrect
(though I think it is correct).
unless
you specifically require a line continuation character:
a = b +
c
Without semicolon requirement:
a=b+ // this is an error
c // this is OK
With semicolon requirement:
a=b+; // this is an error
c; // this is OK
What's the diff?
A newline and a semicolon are not redundant unless you specifically
define
a statement as being one and only one line.
A semicolon is redundate with newline for single-statement lines.
Oh, you
say that a lot of constructs are inherently single statements but
written
on
multiple lines? Well, that may be just the kind of examination I was
looking
for (ironic that _I_ had to bring it up, huh):
if(true)
dothis()
That situation has to be evaluated: is parsing at the construct
level too
much effort or is it desireable? (ParseIfStatement()). Statement-level
parsing better/worse than line-level parsing?
Back to the magic of above though. What if you rewrote it:
a = b
+c
Without semicolon requirement:
a=b // OK
+c // error
With semicolon requirement:
a=b; // OK
+c; // error
What's the diff?
a=b
+c(d) // no error
Why not?
Good question. Because the compiler accepts a=b;+c(d);.
Whether c is declared as a variable or a function, it still looks
wrong to me. A statement can't begin with a +.
OK.
struct S { int a }
int a
void main () {
S s
auto t = s
.a = 1 // ambiguity: Note that .sth means global scope.
}
That clearly means the global int a is set to one, and the local t has
type S.
Re: Semicolons: mostly unnecessary?
AJ Wrote: Cons: 1. Makes most source code less comprehensible. That depends on what parser you have. If you're a basic addict, why you bother about C family language? 2. Is redundant with the newline designator. Statements don't end at newline. 3. Is more typing. Code reuse saves typing. 5. Makes Andrei vomit. Yeah, that's a problem. 6. Missing semicolons are the #1 bugaboo of all C programmers. Programmers have parsers too. 7. Imposes a requirement on the common case to handle the exceptional case. Does the sole existence of C family languages drive you mad so you want to kill'em with fire? 9. Imposes parser's role onto every developer. You can't work in a different way. 10. Allows one to write hard-to-see do nothings like: for(;;); a=b b=a a=b b=a b=b a=a 12. Allows ignorant jettisoning of header file concept. what's with header files?
Re: Semicolons: mostly unnecessary?
AJ wrote: Ary Borenszweig a...@esperanto.org.ar wrote in message news:hbpau3$297...@digitalmars.com... AJ wrote: Mike James f...@bar.com wrote in message news:hbp7le$220...@digitalmars.com... I say we should get rid of vowels - it worked for the ancient egyptians :-) Next thing you know someone will propose eliminating braces and just using whitespace to denote blocks. It's utter madness. Or get rid of all the visible chars and use Whitespace... http://compsoc.dur.ac.uk/whitespace/ Until editors/IDEs become Whitespace-aware, I wouldn't recommend using Whitespace: one click on Save in an editor that converts tabs into spaces and your code is gone. (I was so mad when that happened enough times that I went back to C++). You should try WhitespaceIDE: http://sourceforge.net/projects/whitespaceide/ I'm not nearly about to recreate all that lost code that I've since redeveloped in C++!! (The very clean syntax is alluring though). You might find of utility this piece of code to recover your lost work:
Re: Semicolons: mostly unnecessary?
AJ wrote:
Cons:
10. Allows one to write hard-to-see do nothings like: for(;;);
That's not allowed in D, for that exact reason. You have to write
for (;;) { }
for a do-nothing loop.
-Lars
Re: No header files?
AJ wrote: Nick Sabalausky a...@a.a wrote in message news:hboum3$1bh...@digitalmars.com... AJ a...@nospam.net wrote in message news:hbosh1$17l...@digitalmars.com... Nick Sabalausky a...@a.a wrote in message news:hbontv$uq...@digitalmars.com... If you want to manually write a separate redundant file with just declarations before writing the implementation, no one's stopping you. You sound angry that your feature is not a fit for my development process. jump in and start coding algorithms is not an acceptable development method in my book. Don't put words in my mouth. I wasn't. I was telling you what I parsed your verbage into (and I'm correct 99% of the time) and gave you back some of your own medicine. As an independent observer: your parser is broken.
Re: No header files?
On Thu, 22 Oct 2009 06:16:50 -0400, AJ a...@nospam.net wrote: No. And tomorrow (later today after I get done sleeping), I'm going to do more coding and less newsgrouping! Goodnight. Oh thank god. (Yes, keep replying, I'm going to see how long I can keep you away from critical header development) -Steve
Re: Semicolons: mostly unnecessary?
Op Thu, 22 Oct 2009 07:44:44 +0200 schreef AJ a...@nospam.net: Also, referring to your second struct example above, D never has semicolons directly after a closing curly-brace. Isn't that ironic! Kinda far fetched to call that ironic. The struct decleration was already ended by '}'. I don't end my sentences with ;. either.
Re: Semicolons: mostly unnecessary?
On Oct 22, 09 19:03, Pelle Månsson wrote:
KennyTM~ wrote:
On Oct 22, 09 13:57, AJ wrote:
KennyTM~kenn...@gmail.com wrote in message
news:hbopns$125...@digitalmars.com...
On Oct 22, 09 12:29, AJ wrote:
Adam D. Ruppedestructiona...@gmail.com wrote in message
news:mailman.228.1256181155.20261.digitalmar...@puremagic.com...
On Wed, Oct 21, 2009 at 09:25:34PM -0500, AJ wrote:
That's not D source code. Why do you keep trying to use English
text as
an
example?
The logic behind all the arguments you make,
That would be all fine and dandy, but I'm not arguing about
anything.
(So
you must be arguing? About what?).
except for one, should apply
equally well to English as it does to D.
That's silly. There is no need to use the text of Shakespeare's
tragedies
to
allude to source code. There is no need and it is entirely
inappropriate
to
expand the context of the issue to other realms. The context is
(currently):
semicolons as statement terminators for single-statement lines.
Cons:
1. Makes source code less comprehensible.
Based on what? Because you say so?
It's more to digest when it's not necessary. It's easier to identify
something when it's in less intricate (read, plain) surroundings.
snipped inappropriate context reference
2. Is redundant with the newline designator.
snipped inappropriate context reference
is obviously false,
If I put it on the list, it wasn't obvious at all, even if it is
incorrect
(though I think it is correct).
unless
you specifically require a line continuation character:
a = b +
c
Without semicolon requirement:
a=b+ // this is an error
c // this is OK
With semicolon requirement:
a=b+; // this is an error
c; // this is OK
What's the diff?
A newline and a semicolon are not redundant unless you specifically
define
a statement as being one and only one line.
A semicolon is redundate with newline for single-statement lines.
Oh, you
say that a lot of constructs are inherently single statements but
written
on
multiple lines? Well, that may be just the kind of examination I was
looking
for (ironic that _I_ had to bring it up, huh):
if(true)
dothis()
That situation has to be evaluated: is parsing at the construct
level too
much effort or is it desireable? (ParseIfStatement()). Statement-level
parsing better/worse than line-level parsing?
Back to the magic of above though. What if you rewrote it:
a = b
+c
Without semicolon requirement:
a=b // OK
+c // error
With semicolon requirement:
a=b; // OK
+c; // error
What's the diff?
a=b
+c(d) // no error
Why not?
Good question. Because the compiler accepts a=b;+c(d);.
Whether c is declared as a variable or a function, it still looks
wrong to me. A statement can't begin with a +.
OK.
struct S { int a }
int a
void main () {
S s
auto t = s
.a = 1 // ambiguity: Note that .sth means global scope.
}
That clearly means the global int a is set to one, and the local t has
type S.
No, s(lots of whitespace).a is a valid expression. You shouldn't insert
a statement break there.
Re: Semicolons: mostly unnecessary?
KennyTM~ wrote:
On Oct 22, 09 19:03, Pelle Månsson wrote:
KennyTM~ wrote:
On Oct 22, 09 13:57, AJ wrote:
KennyTM~kenn...@gmail.com wrote in message
news:hbopns$125...@digitalmars.com...
On Oct 22, 09 12:29, AJ wrote:
Adam D. Ruppedestructiona...@gmail.com wrote in message
news:mailman.228.1256181155.20261.digitalmar...@puremagic.com...
On Wed, Oct 21, 2009 at 09:25:34PM -0500, AJ wrote:
That's not D source code. Why do you keep trying to use English
text as
an
example?
The logic behind all the arguments you make,
That would be all fine and dandy, but I'm not arguing about
anything.
(So
you must be arguing? About what?).
except for one, should apply
equally well to English as it does to D.
That's silly. There is no need to use the text of Shakespeare's
tragedies
to
allude to source code. There is no need and it is entirely
inappropriate
to
expand the context of the issue to other realms. The context is
(currently):
semicolons as statement terminators for single-statement lines.
Cons:
1. Makes source code less comprehensible.
Based on what? Because you say so?
It's more to digest when it's not necessary. It's easier to identify
something when it's in less intricate (read, plain) surroundings.
snipped inappropriate context reference
2. Is redundant with the newline designator.
snipped inappropriate context reference
is obviously false,
If I put it on the list, it wasn't obvious at all, even if it is
incorrect
(though I think it is correct).
unless
you specifically require a line continuation character:
a = b +
c
Without semicolon requirement:
a=b+ // this is an error
c // this is OK
With semicolon requirement:
a=b+; // this is an error
c; // this is OK
What's the diff?
A newline and a semicolon are not redundant unless you specifically
define
a statement as being one and only one line.
A semicolon is redundate with newline for single-statement lines.
Oh, you
say that a lot of constructs are inherently single statements but
written
on
multiple lines? Well, that may be just the kind of examination I was
looking
for (ironic that _I_ had to bring it up, huh):
if(true)
dothis()
That situation has to be evaluated: is parsing at the construct
level too
much effort or is it desireable? (ParseIfStatement()).
Statement-level
parsing better/worse than line-level parsing?
Back to the magic of above though. What if you rewrote it:
a = b
+c
Without semicolon requirement:
a=b // OK
+c // error
With semicolon requirement:
a=b; // OK
+c; // error
What's the diff?
a=b
+c(d) // no error
Why not?
Good question. Because the compiler accepts a=b;+c(d);.
Whether c is declared as a variable or a function, it still looks
wrong to me. A statement can't begin with a +.
OK.
struct S { int a }
int a
void main () {
S s
auto t = s
.a = 1 // ambiguity: Note that .sth means global scope.
}
That clearly means the global int a is set to one, and the local t has
type S.
No, s(lots of whitespace).a is a valid expression. You shouldn't insert
a statement break there.
But without semicolons the line break becomes the new semicolon. That's
what most people here don't understand. There's no ambiguity: if you
have a line break and a semicolon would have been good in that place,
then that line break becomes the semicolon.
Re: Semicolons: mostly unnecessary?
KennyTM~ wrote:
On Oct 22, 09 19:03, Pelle Månsson wrote:
KennyTM~ wrote:
On Oct 22, 09 13:57, AJ wrote:
KennyTM~kenn...@gmail.com wrote in message
news:hbopns$125...@digitalmars.com...
On Oct 22, 09 12:29, AJ wrote:
Adam D. Ruppedestructiona...@gmail.com wrote in message
news:mailman.228.1256181155.20261.digitalmar...@puremagic.com...
On Wed, Oct 21, 2009 at 09:25:34PM -0500, AJ wrote:
That's not D source code. Why do you keep trying to use English
text as
an
example?
The logic behind all the arguments you make,
That would be all fine and dandy, but I'm not arguing about
anything.
(So
you must be arguing? About what?).
except for one, should apply
equally well to English as it does to D.
That's silly. There is no need to use the text of Shakespeare's
tragedies
to
allude to source code. There is no need and it is entirely
inappropriate
to
expand the context of the issue to other realms. The context is
(currently):
semicolons as statement terminators for single-statement lines.
Cons:
1. Makes source code less comprehensible.
Based on what? Because you say so?
It's more to digest when it's not necessary. It's easier to identify
something when it's in less intricate (read, plain) surroundings.
snipped inappropriate context reference
2. Is redundant with the newline designator.
snipped inappropriate context reference
is obviously false,
If I put it on the list, it wasn't obvious at all, even if it is
incorrect
(though I think it is correct).
unless
you specifically require a line continuation character:
a = b +
c
Without semicolon requirement:
a=b+ // this is an error
c // this is OK
With semicolon requirement:
a=b+; // this is an error
c; // this is OK
What's the diff?
A newline and a semicolon are not redundant unless you specifically
define
a statement as being one and only one line.
A semicolon is redundate with newline for single-statement lines.
Oh, you
say that a lot of constructs are inherently single statements but
written
on
multiple lines? Well, that may be just the kind of examination I was
looking
for (ironic that _I_ had to bring it up, huh):
if(true)
dothis()
That situation has to be evaluated: is parsing at the construct
level too
much effort or is it desireable? (ParseIfStatement()).
Statement-level
parsing better/worse than line-level parsing?
Back to the magic of above though. What if you rewrote it:
a = b
+c
Without semicolon requirement:
a=b // OK
+c // error
With semicolon requirement:
a=b; // OK
+c; // error
What's the diff?
a=b
+c(d) // no error
Why not?
Good question. Because the compiler accepts a=b;+c(d);.
Whether c is declared as a variable or a function, it still looks
wrong to me. A statement can't begin with a +.
OK.
struct S { int a }
int a
void main () {
S s
auto t = s
.a = 1 // ambiguity: Note that .sth means global scope.
}
That clearly means the global int a is set to one, and the local t has
type S.
No, s(lots of whitespace).a is a valid expression. You shouldn't insert
a statement break there.
Try an editor that shows you where the line breaks are.
Re: Array, AA Implementations
On Thu, 22 Oct 2009 09:07:47 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Don wrote: Andrei Alexandrescu wrote: Bill Baxter wrote: On Wed, Oct 21, 2009 at 6:35 PM, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: 3. Remove some element from the container and give it to me E removeAny(); 4. Add an element to the container is possible bool add(E); I think any container must support these primitives in O(1), and I find it difficult to think of a significant category of containers that can't support them (but then there may as well be, so please join me in thinking of that). A lot of stuff can be done with only these few methods. I think balanced trees generally take O(lg N) to add and remove elements. Good point, thanks. Logarithmic of better. Andrei Can it be amortized O(lg N) ? Don't see why not. Also, it turns out that iteration over a tree may cost O(log n) per step. Yes, but it's actually O(n) to traverse the entire tree, because you traverse 2n edges in the tree (one left and one right) twice (once to go down, and once to go back). -Steve
Re: Semicolons: mostly unnecessary?
On Oct 22, 09 21:12, Ary Borenszweig wrote:
KennyTM~ wrote:
On Oct 22, 09 19:03, Pelle Månsson wrote:
KennyTM~ wrote:
On Oct 22, 09 13:57, AJ wrote:
KennyTM~kenn...@gmail.com wrote in message
news:hbopns$125...@digitalmars.com...
On Oct 22, 09 12:29, AJ wrote:
Adam D. Ruppedestructiona...@gmail.com wrote in message
news:mailman.228.1256181155.20261.digitalmar...@puremagic.com...
On Wed, Oct 21, 2009 at 09:25:34PM -0500, AJ wrote:
That's not D source code. Why do you keep trying to use English
text as
an
example?
The logic behind all the arguments you make,
That would be all fine and dandy, but I'm not arguing about
anything.
(So
you must be arguing? About what?).
except for one, should apply
equally well to English as it does to D.
That's silly. There is no need to use the text of Shakespeare's
tragedies
to
allude to source code. There is no need and it is entirely
inappropriate
to
expand the context of the issue to other realms. The context is
(currently):
semicolons as statement terminators for single-statement lines.
Cons:
1. Makes source code less comprehensible.
Based on what? Because you say so?
It's more to digest when it's not necessary. It's easier to identify
something when it's in less intricate (read, plain) surroundings.
snipped inappropriate context reference
2. Is redundant with the newline designator.
snipped inappropriate context reference
is obviously false,
If I put it on the list, it wasn't obvious at all, even if it is
incorrect
(though I think it is correct).
unless
you specifically require a line continuation character:
a = b +
c
Without semicolon requirement:
a=b+ // this is an error
c // this is OK
With semicolon requirement:
a=b+; // this is an error
c; // this is OK
What's the diff?
A newline and a semicolon are not redundant unless you specifically
define
a statement as being one and only one line.
A semicolon is redundate with newline for single-statement lines.
Oh, you
say that a lot of constructs are inherently single statements but
written
on
multiple lines? Well, that may be just the kind of examination I was
looking
for (ironic that _I_ had to bring it up, huh):
if(true)
dothis()
That situation has to be evaluated: is parsing at the construct
level too
much effort or is it desireable? (ParseIfStatement()).
Statement-level
parsing better/worse than line-level parsing?
Back to the magic of above though. What if you rewrote it:
a = b
+c
Without semicolon requirement:
a=b // OK
+c // error
With semicolon requirement:
a=b; // OK
+c; // error
What's the diff?
a=b
+c(d) // no error
Why not?
Good question. Because the compiler accepts a=b;+c(d);.
Whether c is declared as a variable or a function, it still looks
wrong to me. A statement can't begin with a +.
OK.
struct S { int a }
int a
void main () {
S s
auto t = s
.a = 1 // ambiguity: Note that .sth means global scope.
}
That clearly means the global int a is set to one, and the local t has
type S.
No, s(lots of whitespace).a is a valid expression. You shouldn't
insert a statement break there.
But without semicolons the line break becomes the new semicolon. That's
what most people here don't understand. There's no ambiguity: if you
have a line break and a semicolon would have been good in that place,
then that line break becomes the semicolon.
So
auto t = s.
a = 1
would now become a syntax error?
Re: Semicolons: mostly unnecessary?
On Thu, Oct 22, 2009 at 12:46:50AM -0700, Walter Bright wrote: (Fixed that for you!) hehehe :) -- Adam D. Ruppe http://arsdnet.net
Re: Semicolons: mostly unnecessary?
On Oct 22, 09 21:17, Pelle Månsson wrote:
KennyTM~ wrote:
On Oct 22, 09 19:03, Pelle Månsson wrote:
KennyTM~ wrote:
On Oct 22, 09 13:57, AJ wrote:
KennyTM~kenn...@gmail.com wrote in message
news:hbopns$125...@digitalmars.com...
On Oct 22, 09 12:29, AJ wrote:
Adam D. Ruppedestructiona...@gmail.com wrote in message
news:mailman.228.1256181155.20261.digitalmar...@puremagic.com...
On Wed, Oct 21, 2009 at 09:25:34PM -0500, AJ wrote:
That's not D source code. Why do you keep trying to use English
text as
an
example?
The logic behind all the arguments you make,
That would be all fine and dandy, but I'm not arguing about
anything.
(So
you must be arguing? About what?).
except for one, should apply
equally well to English as it does to D.
That's silly. There is no need to use the text of Shakespeare's
tragedies
to
allude to source code. There is no need and it is entirely
inappropriate
to
expand the context of the issue to other realms. The context is
(currently):
semicolons as statement terminators for single-statement lines.
Cons:
1. Makes source code less comprehensible.
Based on what? Because you say so?
It's more to digest when it's not necessary. It's easier to identify
something when it's in less intricate (read, plain) surroundings.
snipped inappropriate context reference
2. Is redundant with the newline designator.
snipped inappropriate context reference
is obviously false,
If I put it on the list, it wasn't obvious at all, even if it is
incorrect
(though I think it is correct).
unless
you specifically require a line continuation character:
a = b +
c
Without semicolon requirement:
a=b+ // this is an error
c // this is OK
With semicolon requirement:
a=b+; // this is an error
c; // this is OK
What's the diff?
A newline and a semicolon are not redundant unless you specifically
define
a statement as being one and only one line.
A semicolon is redundate with newline for single-statement lines.
Oh, you
say that a lot of constructs are inherently single statements but
written
on
multiple lines? Well, that may be just the kind of examination I was
looking
for (ironic that _I_ had to bring it up, huh):
if(true)
dothis()
That situation has to be evaluated: is parsing at the construct
level too
much effort or is it desireable? (ParseIfStatement()).
Statement-level
parsing better/worse than line-level parsing?
Back to the magic of above though. What if you rewrote it:
a = b
+c
Without semicolon requirement:
a=b // OK
+c // error
With semicolon requirement:
a=b; // OK
+c; // error
What's the diff?
a=b
+c(d) // no error
Why not?
Good question. Because the compiler accepts a=b;+c(d);.
Whether c is declared as a variable or a function, it still looks
wrong to me. A statement can't begin with a +.
OK.
struct S { int a }
int a
void main () {
S s
auto t = s
.a = 1 // ambiguity: Note that .sth means global scope.
}
That clearly means the global int a is set to one, and the local t has
type S.
No, s(lots of whitespace).a is a valid expression. You shouldn't
insert a statement break there.
Try an editor that shows you where the line breaks are.
By whitespace I mean spaces (U+0020), tabs (U+0009), newlines (U+000A)
and other space characters (U+000B, U+000C, U+000D).
Re: Semicolons: mostly unnecessary?
KennyTM~ wrote:
On Oct 22, 09 21:17, Pelle Månsson wrote:
KennyTM~ wrote:
On Oct 22, 09 19:03, Pelle Månsson wrote:
KennyTM~ wrote:
On Oct 22, 09 13:57, AJ wrote:
KennyTM~kenn...@gmail.com wrote in message
news:hbopns$125...@digitalmars.com...
On Oct 22, 09 12:29, AJ wrote:
Adam D. Ruppedestructiona...@gmail.com wrote in message
news:mailman.228.1256181155.20261.digitalmar...@puremagic.com...
On Wed, Oct 21, 2009 at 09:25:34PM -0500, AJ wrote:
That's not D source code. Why do you keep trying to use English
text as
an
example?
The logic behind all the arguments you make,
That would be all fine and dandy, but I'm not arguing about
anything.
(So
you must be arguing? About what?).
except for one, should apply
equally well to English as it does to D.
That's silly. There is no need to use the text of Shakespeare's
tragedies
to
allude to source code. There is no need and it is entirely
inappropriate
to
expand the context of the issue to other realms. The context is
(currently):
semicolons as statement terminators for single-statement lines.
Cons:
1. Makes source code less comprehensible.
Based on what? Because you say so?
It's more to digest when it's not necessary. It's easier to
identify
something when it's in less intricate (read, plain) surroundings.
snipped inappropriate context reference
2. Is redundant with the newline designator.
snipped inappropriate context reference
is obviously false,
If I put it on the list, it wasn't obvious at all, even if it is
incorrect
(though I think it is correct).
unless
you specifically require a line continuation character:
a = b +
c
Without semicolon requirement:
a=b+ // this is an error
c // this is OK
With semicolon requirement:
a=b+; // this is an error
c; // this is OK
What's the diff?
A newline and a semicolon are not redundant unless you
specifically
define
a statement as being one and only one line.
A semicolon is redundate with newline for single-statement lines.
Oh, you
say that a lot of constructs are inherently single statements but
written
on
multiple lines? Well, that may be just the kind of examination I
was
looking
for (ironic that _I_ had to bring it up, huh):
if(true)
dothis()
That situation has to be evaluated: is parsing at the construct
level too
much effort or is it desireable? (ParseIfStatement()).
Statement-level
parsing better/worse than line-level parsing?
Back to the magic of above though. What if you rewrote it:
a = b
+c
Without semicolon requirement:
a=b // OK
+c // error
With semicolon requirement:
a=b; // OK
+c; // error
What's the diff?
a=b
+c(d) // no error
Why not?
Good question. Because the compiler accepts a=b;+c(d);.
Whether c is declared as a variable or a function, it still looks
wrong to me. A statement can't begin with a +.
OK.
struct S { int a }
int a
void main () {
S s
auto t = s
.a = 1 // ambiguity: Note that .sth means global scope.
}
That clearly means the global int a is set to one, and the local t has
type S.
No, s(lots of whitespace).a is a valid expression. You shouldn't
insert a statement break there.
Try an editor that shows you where the line breaks are.
By whitespace I mean spaces (U+0020), tabs (U+0009), newlines (U+000A)
and other space characters (U+000B, U+000C, U+000D).
You can obviously not have newlines as whitespace and remove semicolon.
That would, as you have demonstrated, not work. I think we all knew that.
Re: Semicolons: mostly unnecessary?
KennyTM~ wrote:
On Oct 22, 09 21:12, Ary Borenszweig wrote:
KennyTM~ wrote:
On Oct 22, 09 19:03, Pelle Månsson wrote:
KennyTM~ wrote:
On Oct 22, 09 13:57, AJ wrote:
KennyTM~kenn...@gmail.com wrote in message
news:hbopns$125...@digitalmars.com...
On Oct 22, 09 12:29, AJ wrote:
Adam D. Ruppedestructiona...@gmail.com wrote in message
news:mailman.228.1256181155.20261.digitalmar...@puremagic.com...
On Wed, Oct 21, 2009 at 09:25:34PM -0500, AJ wrote:
That's not D source code. Why do you keep trying to use English
text as
an
example?
The logic behind all the arguments you make,
That would be all fine and dandy, but I'm not arguing about
anything.
(So
you must be arguing? About what?).
except for one, should apply
equally well to English as it does to D.
That's silly. There is no need to use the text of Shakespeare's
tragedies
to
allude to source code. There is no need and it is entirely
inappropriate
to
expand the context of the issue to other realms. The context is
(currently):
semicolons as statement terminators for single-statement lines.
Cons:
1. Makes source code less comprehensible.
Based on what? Because you say so?
It's more to digest when it's not necessary. It's easier to
identify
something when it's in less intricate (read, plain) surroundings.
snipped inappropriate context reference
2. Is redundant with the newline designator.
snipped inappropriate context reference
is obviously false,
If I put it on the list, it wasn't obvious at all, even if it is
incorrect
(though I think it is correct).
unless
you specifically require a line continuation character:
a = b +
c
Without semicolon requirement:
a=b+ // this is an error
c // this is OK
With semicolon requirement:
a=b+; // this is an error
c; // this is OK
What's the diff?
A newline and a semicolon are not redundant unless you
specifically
define
a statement as being one and only one line.
A semicolon is redundate with newline for single-statement lines.
Oh, you
say that a lot of constructs are inherently single statements but
written
on
multiple lines? Well, that may be just the kind of examination I
was
looking
for (ironic that _I_ had to bring it up, huh):
if(true)
dothis()
That situation has to be evaluated: is parsing at the construct
level too
much effort or is it desireable? (ParseIfStatement()).
Statement-level
parsing better/worse than line-level parsing?
Back to the magic of above though. What if you rewrote it:
a = b
+c
Without semicolon requirement:
a=b // OK
+c // error
With semicolon requirement:
a=b; // OK
+c; // error
What's the diff?
a=b
+c(d) // no error
Why not?
Good question. Because the compiler accepts a=b;+c(d);.
Whether c is declared as a variable or a function, it still looks
wrong to me. A statement can't begin with a +.
OK.
struct S { int a }
int a
void main () {
S s
auto t = s
.a = 1 // ambiguity: Note that .sth means global scope.
}
That clearly means the global int a is set to one, and the local t has
type S.
No, s(lots of whitespace).a is a valid expression. You shouldn't
insert a statement break there.
But without semicolons the line break becomes the new semicolon. That's
what most people here don't understand. There's no ambiguity: if you
have a line break and a semicolon would have been good in that place,
then that line break becomes the semicolon.
So
auto t = s.
a = 1
would now become a syntax error?
Yes. Do you use this particular style of coding often?
Re: Revamped concurrency API (Don can you contact Bartosz ?)
Nick B, el 22 de octubre a las 19:35 me escribiste: Leandro Lucarella wrote: Don, el 21 de octubre a las 09:46 me escribiste: All my public email addresses are fake. Bugzilla is just spam bait. It clearly comes from a more innocent age. I once made the mistake of submitting a bug to gcc. Although the GCC Bugzilla hides the email in the submitter field, the idiots include the real email address in the 100% useless 'X-Ref' line. Two weeks later, my email address was dead. I've never made that mistake again. I am contactable through my dsource account. You don't even use a real account for personal e-mails! That's odd. I couldn't reply your private e-mail about changing the title of the bugzilla report because the From address were fake. Yes, I too use fake personal email accounts, as I do not want my gmail accounts hammered with spam. I could add -nospam to the name, but I am unsure how good the spammers are these days to get around this. Any suggestions/comments, anyone ? I just use my real e-mail everywhere and let the spammers eat the world's BW as they please. I just let my anti-spam (bogofilter and gmail in case of the gmail address) to take care of things... -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Que importante, entonces en estos días de globalización refregar nuestras almas, pasarle el lampazo a nuestros corazones para alcanzar un verdadero estado de babia peperianal. -- Peperino Pómoro
Re: Semicolons: mostly unnecessary?
On Oct 22, 09 21:36, Pelle Månsson wrote:
KennyTM~ wrote:
On Oct 22, 09 21:12, Ary Borenszweig wrote:
KennyTM~ wrote:
On Oct 22, 09 19:03, Pelle Månsson wrote:
KennyTM~ wrote:
On Oct 22, 09 13:57, AJ wrote:
KennyTM~kenn...@gmail.com wrote in message
news:hbopns$125...@digitalmars.com...
On Oct 22, 09 12:29, AJ wrote:
Adam D. Ruppedestructiona...@gmail.com wrote in message
news:mailman.228.1256181155.20261.digitalmar...@puremagic.com...
On Wed, Oct 21, 2009 at 09:25:34PM -0500, AJ wrote:
That's not D source code. Why do you keep trying to use English
text as
an
example?
The logic behind all the arguments you make,
That would be all fine and dandy, but I'm not arguing about
anything.
(So
you must be arguing? About what?).
except for one, should apply
equally well to English as it does to D.
That's silly. There is no need to use the text of Shakespeare's
tragedies
to
allude to source code. There is no need and it is entirely
inappropriate
to
expand the context of the issue to other realms. The context is
(currently):
semicolons as statement terminators for single-statement lines.
Cons:
1. Makes source code less comprehensible.
Based on what? Because you say so?
It's more to digest when it's not necessary. It's easier to
identify
something when it's in less intricate (read, plain) surroundings.
snipped inappropriate context reference
2. Is redundant with the newline designator.
snipped inappropriate context reference
is obviously false,
If I put it on the list, it wasn't obvious at all, even if it is
incorrect
(though I think it is correct).
unless
you specifically require a line continuation character:
a = b +
c
Without semicolon requirement:
a=b+ // this is an error
c // this is OK
With semicolon requirement:
a=b+; // this is an error
c; // this is OK
What's the diff?
A newline and a semicolon are not redundant unless you
specifically
define
a statement as being one and only one line.
A semicolon is redundate with newline for single-statement lines.
Oh, you
say that a lot of constructs are inherently single statements but
written
on
multiple lines? Well, that may be just the kind of examination
I was
looking
for (ironic that _I_ had to bring it up, huh):
if(true)
dothis()
That situation has to be evaluated: is parsing at the construct
level too
much effort or is it desireable? (ParseIfStatement()).
Statement-level
parsing better/worse than line-level parsing?
Back to the magic of above though. What if you rewrote it:
a = b
+c
Without semicolon requirement:
a=b // OK
+c // error
With semicolon requirement:
a=b; // OK
+c; // error
What's the diff?
a=b
+c(d) // no error
Why not?
Good question. Because the compiler accepts a=b;+c(d);.
Whether c is declared as a variable or a function, it still looks
wrong to me. A statement can't begin with a +.
OK.
struct S { int a }
int a
void main () {
S s
auto t = s
.a = 1 // ambiguity: Note that .sth means global scope.
}
That clearly means the global int a is set to one, and the local t has
type S.
No, s(lots of whitespace).a is a valid expression. You shouldn't
insert a statement break there.
But without semicolons the line break becomes the new semicolon. That's
what most people here don't understand. There's no ambiguity: if you
have a line break and a semicolon would have been good in that place,
then that line break becomes the semicolon.
So
auto t = s.
a = 1
would now become a syntax error?
Yes. Do you use this particular style of coding often?
auto s = No, but you've just broken ~
some other perfectly working ~
D codes.
writeln(s)
Re: Semicolons: mostly unnecessary?
On Oct 22, 09 21:35, Pelle Månsson wrote:
KennyTM~ wrote:
On Oct 22, 09 21:17, Pelle Månsson wrote:
KennyTM~ wrote:
On Oct 22, 09 19:03, Pelle Månsson wrote:
KennyTM~ wrote:
On Oct 22, 09 13:57, AJ wrote:
KennyTM~kenn...@gmail.com wrote in message
news:hbopns$125...@digitalmars.com...
On Oct 22, 09 12:29, AJ wrote:
Adam D. Ruppedestructiona...@gmail.com wrote in message
news:mailman.228.1256181155.20261.digitalmar...@puremagic.com...
On Wed, Oct 21, 2009 at 09:25:34PM -0500, AJ wrote:
That's not D source code. Why do you keep trying to use English
text as
an
example?
The logic behind all the arguments you make,
That would be all fine and dandy, but I'm not arguing about
anything.
(So
you must be arguing? About what?).
except for one, should apply
equally well to English as it does to D.
That's silly. There is no need to use the text of Shakespeare's
tragedies
to
allude to source code. There is no need and it is entirely
inappropriate
to
expand the context of the issue to other realms. The context is
(currently):
semicolons as statement terminators for single-statement lines.
Cons:
1. Makes source code less comprehensible.
Based on what? Because you say so?
It's more to digest when it's not necessary. It's easier to
identify
something when it's in less intricate (read, plain) surroundings.
snipped inappropriate context reference
2. Is redundant with the newline designator.
snipped inappropriate context reference
is obviously false,
If I put it on the list, it wasn't obvious at all, even if it is
incorrect
(though I think it is correct).
unless
you specifically require a line continuation character:
a = b +
c
Without semicolon requirement:
a=b+ // this is an error
c // this is OK
With semicolon requirement:
a=b+; // this is an error
c; // this is OK
What's the diff?
A newline and a semicolon are not redundant unless you
specifically
define
a statement as being one and only one line.
A semicolon is redundate with newline for single-statement lines.
Oh, you
say that a lot of constructs are inherently single statements but
written
on
multiple lines? Well, that may be just the kind of examination
I was
looking
for (ironic that _I_ had to bring it up, huh):
if(true)
dothis()
That situation has to be evaluated: is parsing at the construct
level too
much effort or is it desireable? (ParseIfStatement()).
Statement-level
parsing better/worse than line-level parsing?
Back to the magic of above though. What if you rewrote it:
a = b
+c
Without semicolon requirement:
a=b // OK
+c // error
With semicolon requirement:
a=b; // OK
+c; // error
What's the diff?
a=b
+c(d) // no error
Why not?
Good question. Because the compiler accepts a=b;+c(d);.
Whether c is declared as a variable or a function, it still looks
wrong to me. A statement can't begin with a +.
OK.
struct S { int a }
int a
void main () {
S s
auto t = s
.a = 1 // ambiguity: Note that .sth means global scope.
}
That clearly means the global int a is set to one, and the local t has
type S.
No, s(lots of whitespace).a is a valid expression. You shouldn't
insert a statement break there.
Try an editor that shows you where the line breaks are.
By whitespace I mean spaces (U+0020), tabs (U+0009), newlines (U+000A)
and other space characters (U+000B, U+000C, U+000D).
You can obviously not have newlines as whitespace and remove semicolon.
That would, as you have demonstrated, not work. I think we all knew that.
I meant s\n\n\n.a is a valid expression in the current D syntax. Sorry
my context is not clear enough.
Re: Revamped concurrency API (Don can you contact Bartosz ?)
On Thu, 22 Oct 2009 17:32:00 +0400, Leandro Lucarella llu...@gmail.com wrote: Nick B, el 22 de octubre a las 19:35 me escribiste: Leandro Lucarella wrote: Don, el 21 de octubre a las 09:46 me escribiste: All my public email addresses are fake. Bugzilla is just spam bait. It clearly comes from a more innocent age. I once made the mistake of submitting a bug to gcc. Although the GCC Bugzilla hides the email in the submitter field, the idiots include the real email address in the 100% useless 'X-Ref' line. Two weeks later, my email address was dead. I've never made that mistake again. I am contactable through my dsource account. You don't even use a real account for personal e-mails! That's odd. I couldn't reply your private e-mail about changing the title of the bugzilla report because the From address were fake. Yes, I too use fake personal email accounts, as I do not want my gmail accounts hammered with spam. I could add -nospam to the name, but I am unsure how good the spammers are these days to get around this. Any suggestions/comments, anyone ? I just use my real e-mail everywhere and let the spammers eat the world's BW as they please. I just let my anti-spam (bogofilter and gmail in case of the gmail address) to take care of things... So do I. And as a result I missed a very important message sent to me about a week ago (I was classified as a spam for some reason) :(
Re: Revamped concurrency API (Don can you contact Bartosz ?)
On Thu, 22 Oct 2009 09:32:00 -0400, Leandro Lucarella llu...@gmail.com wrote: Nick B, el 22 de octubre a las 19:35 me escribiste: Leandro Lucarella wrote: Don, el 21 de octubre a las 09:46 me escribiste: All my public email addresses are fake. Bugzilla is just spam bait. It clearly comes from a more innocent age. I once made the mistake of submitting a bug to gcc. Although the GCC Bugzilla hides the email in the submitter field, the idiots include the real email address in the 100% useless 'X-Ref' line. Two weeks later, my email address was dead. I've never made that mistake again. I am contactable through my dsource account. You don't even use a real account for personal e-mails! That's odd. I couldn't reply your private e-mail about changing the title of the bugzilla report because the From address were fake. Yes, I too use fake personal email accounts, as I do not want my gmail accounts hammered with spam. I could add -nospam to the name, but I am unsure how good the spammers are these days to get around this. Any suggestions/comments, anyone ? I just use my real e-mail everywhere and let the spammers eat the world's BW as they please. I just let my anti-spam (bogofilter and gmail in case of the gmail address) to take care of things... Been posting on D for over 2 years with my real address. Haven't seen much difference in my spam input (except occasionally when Andrei replies directly to me instead of the newsgroup by accident ;) ) -Steve
Re: Semicolons: mostly unnecessary?
KennyTM~ wrote:
On Oct 22, 09 21:36, Pelle Månsson wrote:
KennyTM~ wrote:
On Oct 22, 09 21:12, Ary Borenszweig wrote:
KennyTM~ wrote:
On Oct 22, 09 19:03, Pelle Månsson wrote:
KennyTM~ wrote:
On Oct 22, 09 13:57, AJ wrote:
KennyTM~kenn...@gmail.com wrote in message
news:hbopns$125...@digitalmars.com...
On Oct 22, 09 12:29, AJ wrote:
Adam D. Ruppedestructiona...@gmail.com wrote in message
news:mailman.228.1256181155.20261.digitalmar...@puremagic.com...
On Wed, Oct 21, 2009 at 09:25:34PM -0500, AJ wrote:
That's not D source code. Why do you keep trying to use English
text as
an
example?
The logic behind all the arguments you make,
That would be all fine and dandy, but I'm not arguing about
anything.
(So
you must be arguing? About what?).
except for one, should apply
equally well to English as it does to D.
That's silly. There is no need to use the text of Shakespeare's
tragedies
to
allude to source code. There is no need and it is entirely
inappropriate
to
expand the context of the issue to other realms. The context is
(currently):
semicolons as statement terminators for single-statement lines.
Cons:
1. Makes source code less comprehensible.
Based on what? Because you say so?
It's more to digest when it's not necessary. It's easier to
identify
something when it's in less intricate (read, plain) surroundings.
snipped inappropriate context reference
2. Is redundant with the newline designator.
snipped inappropriate context reference
is obviously false,
If I put it on the list, it wasn't obvious at all, even if it is
incorrect
(though I think it is correct).
unless
you specifically require a line continuation character:
a = b +
c
Without semicolon requirement:
a=b+ // this is an error
c // this is OK
With semicolon requirement:
a=b+; // this is an error
c; // this is OK
What's the diff?
A newline and a semicolon are not redundant unless you
specifically
define
a statement as being one and only one line.
A semicolon is redundate with newline for single-statement lines.
Oh, you
say that a lot of constructs are inherently single statements but
written
on
multiple lines? Well, that may be just the kind of examination
I was
looking
for (ironic that _I_ had to bring it up, huh):
if(true)
dothis()
That situation has to be evaluated: is parsing at the construct
level too
much effort or is it desireable? (ParseIfStatement()).
Statement-level
parsing better/worse than line-level parsing?
Back to the magic of above though. What if you rewrote it:
a = b
+c
Without semicolon requirement:
a=b // OK
+c // error
With semicolon requirement:
a=b; // OK
+c; // error
What's the diff?
a=b
+c(d) // no error
Why not?
Good question. Because the compiler accepts a=b;+c(d);.
Whether c is declared as a variable or a function, it still looks
wrong to me. A statement can't begin with a +.
OK.
struct S { int a }
int a
void main () {
S s
auto t = s
.a = 1 // ambiguity: Note that .sth means global scope.
}
That clearly means the global int a is set to one, and the local t
has
type S.
No, s(lots of whitespace).a is a valid expression. You shouldn't
insert a statement break there.
But without semicolons the line break becomes the new semicolon. That's
what most people here don't understand. There's no ambiguity: if you
have a line break and a semicolon would have been good in that place,
then that line break becomes the semicolon.
So
auto t = s.
a = 1
would now become a syntax error?
Yes. Do you use this particular style of coding often?
auto s = No, but you've just broken ~
some other perfectly working ~
D codes.
writeln(s)
Maybe true, but not ambigous.
Who's using structs nested in functions?
Refer to: http://www.digitalmars.com/d/2.0/struct.html and scroll down to the last section, Nested Structs. A struct defined inside a function has a hidden pointer to that function's stack frame and therefore can use function's local variables. Nested classes do a similar trick, but for those there's a bit of motivation - you could create a nested class and use it as a sort of closure by returning a base class or interface of it. With nested structs, however, you can't do much. You can pass them to a template, but I can't see some solid use cases there. My understanding is that nested structs have been implemented for completeness and consistency with nested classes. Any good example of nested struct uses? Andrei
Re: Who's using structs nested in functions?
On Thu, 22 Oct 2009 18:07:15 +0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Refer to: http://www.digitalmars.com/d/2.0/struct.html and scroll down to the last section, Nested Structs. A struct defined inside a function has a hidden pointer to that function's stack frame and therefore can use function's local variables. Nested classes do a similar trick, but for those there's a bit of motivation - you could create a nested class and use it as a sort of closure by returning a base class or interface of it. With nested structs, however, you can't do much. You can pass them to a template, but I can't see some solid use cases there. My understanding is that nested structs have been implemented for completeness and consistency with nested classes. Any good example of nested struct uses? Andrei Everything you can do with nested struct is doable with a nested class as well (marking methods as final, using scope to allocate instance on stack etc). I don't think there's anything specific to nested struct. One thing I can think of is that you are using some template that works with structs only, but then you may create a nested class and nest a static struct inside it (not that I would recommend doing so but still) :)
Re: Semicolons: mostly unnecessary?
On Oct 22, 09 21:51, Pelle Månsson wrote:
KennyTM~ wrote:
On Oct 22, 09 21:36, Pelle Månsson wrote:
KennyTM~ wrote:
On Oct 22, 09 21:12, Ary Borenszweig wrote:
KennyTM~ wrote:
On Oct 22, 09 19:03, Pelle Månsson wrote:
KennyTM~ wrote:
On Oct 22, 09 13:57, AJ wrote:
KennyTM~kenn...@gmail.com wrote in message
news:hbopns$125...@digitalmars.com...
On Oct 22, 09 12:29, AJ wrote:
Adam D. Ruppedestructiona...@gmail.com wrote in message
news:mailman.228.1256181155.20261.digitalmar...@puremagic.com...
On Wed, Oct 21, 2009 at 09:25:34PM -0500, AJ wrote:
That's not D source code. Why do you keep trying to use
English
text as
an
example?
The logic behind all the arguments you make,
That would be all fine and dandy, but I'm not arguing about
anything.
(So
you must be arguing? About what?).
except for one, should apply
equally well to English as it does to D.
That's silly. There is no need to use the text of Shakespeare's
tragedies
to
allude to source code. There is no need and it is entirely
inappropriate
to
expand the context of the issue to other realms. The context is
(currently):
semicolons as statement terminators for single-statement lines.
Cons:
1. Makes source code less comprehensible.
Based on what? Because you say so?
It's more to digest when it's not necessary. It's easier to
identify
something when it's in less intricate (read, plain)
surroundings.
snipped inappropriate context reference
2. Is redundant with the newline designator.
snipped inappropriate context reference
is obviously false,
If I put it on the list, it wasn't obvious at all, even if it is
incorrect
(though I think it is correct).
unless
you specifically require a line continuation character:
a = b +
c
Without semicolon requirement:
a=b+ // this is an error
c // this is OK
With semicolon requirement:
a=b+; // this is an error
c; // this is OK
What's the diff?
A newline and a semicolon are not redundant unless you
specifically
define
a statement as being one and only one line.
A semicolon is redundate with newline for single-statement
lines.
Oh, you
say that a lot of constructs are inherently single statements
but
written
on
multiple lines? Well, that may be just the kind of examination
I was
looking
for (ironic that _I_ had to bring it up, huh):
if(true)
dothis()
That situation has to be evaluated: is parsing at the construct
level too
much effort or is it desireable? (ParseIfStatement()).
Statement-level
parsing better/worse than line-level parsing?
Back to the magic of above though. What if you rewrote it:
a = b
+c
Without semicolon requirement:
a=b // OK
+c // error
With semicolon requirement:
a=b; // OK
+c; // error
What's the diff?
a=b
+c(d) // no error
Why not?
Good question. Because the compiler accepts a=b;+c(d);.
Whether c is declared as a variable or a function, it still looks
wrong to me. A statement can't begin with a +.
OK.
struct S { int a }
int a
void main () {
S s
auto t = s
.a = 1 // ambiguity: Note that .sth means global scope.
}
That clearly means the global int a is set to one, and the local
t has
type S.
No, s(lots of whitespace).a is a valid expression. You shouldn't
insert a statement break there.
But without semicolons the line break becomes the new semicolon.
That's
what most people here don't understand. There's no ambiguity: if you
have a line break and a semicolon would have been good in that place,
then that line break becomes the semicolon.
So
auto t = s.
a = 1
would now become a syntax error?
Yes. Do you use this particular style of coding often?
auto s = No, but you've just broken ~
some other perfectly working ~
D codes.
writeln(s)
Maybe true, but not ambigous.
Great, now how should I fix the old D syntax that concatenates over
multiple lines?
auto s = localizeStr(This won't work because )
~ localize(the unary ~ is ) // compile error for AJ
~ localize(the bitwise-not operator.) // compile error for AJ
Anyway, my point is that, if you want to eliminate the semicolon, you
have to change the D syntax and break old code. And if all you need is a
re-syntax-ized D with optional semicolon, there is already one here.
It's called Delight.
Struct Comparison
Regarding recent discussions in Bugzilla: I wonder if we could somehow define
a super-efficient struct opEquals that performs introspection and only tests
expensive members if it's necessary. For example, here is a simple case of it:
enum opEqualsMixin = q{
bool opEquals(typeof(this) rhs) {
foreach(tupleIndex, elem; this.tupleof) {
static if(isIntegral!(typeof(elem))) {
// Compare integers first. They're cheap.
if(elem != rhs.tupleof[tupleIndex]) {
return false;
}
}
foreach(tupleIndex, elem; this.tupleof) {
static if(isFloatingPoint!(typeof(elem))) {
// Compare floats. They're also cheap.
if(elem != rhs.tupleof[tupleIndex]) {
return false;
}
}
foreach(tupleIndex, elem; this.tupleof) {
static if(!isIntegral!(typeof(elem))
!isFloatingPoint!(typeof(elem))) {
// All the cheap elements were equal.
// Resort to more expensive comparisons.
if(elem != rhs.tupleof[tupleIndex]) {
return false;
}
}
return true;
}
}
Of course, we could get even fancier. We could recursively introspect struct
types and use various heuristics to calculate the optimal comparison order at
compile time. Similar stuff could be done for a generic opCmp that gives a
struct an arbitrary total ordering as long as all of its members have a total
ordering.
Re: Struct Comparison
dsimcha: Similar stuff could be done for a generic opCmp that gives a struct an arbitrary total ordering as long as all of its members have a total ordering. I have a similar structCmp in my dlibs, it's used by the Record/record (similar to the Tuple/tuple of Phobos2). It works recursively. I'd like all D structs to have such richer semantics (opCmp, opHash, opEquals, a good printing), so Tuple can be removed from the std lib. Bye, bearophile
Re: Who's using structs nested in functions?
bearophile wrote: Andrei Alexandrescu: With nested structs, however, you can't do much. You can pass them to a template, but I can't see some solid use cases there. My understanding is that nested structs have been implemented for completeness and consistency with nested classes. Any good example of nested struct uses? I have used nested static structs sometimes, when I need a struct just inside a function (like the main()) to avoid polluting the outer scope with the struct name. Do you want to remove them from D2? Bye, bearophile I've had similar uses, some win32 api routines require custom structs like BITMAPINFO, nested structs are neat to declare the struct right before its only usage. However I don't think having a closure for that struct is really needed, nested functions already perform that task very well, and I use those quite often. Jeremie
Re: Struct Comparison
dsimcha wrote:
Regarding recent discussions in Bugzilla: I wonder if we could somehow define
a super-efficient struct opEquals that performs introspection and only tests
expensive members if it's necessary. For example, here is a simple case of it:
enum opEqualsMixin = q{
bool opEquals(typeof(this) rhs) {
foreach(tupleIndex, elem; this.tupleof) {
static if(isIntegral!(typeof(elem))) {
// Compare integers first. They're cheap.
if(elem != rhs.tupleof[tupleIndex]) {
return false;
}
}
foreach(tupleIndex, elem; this.tupleof) {
static if(isFloatingPoint!(typeof(elem))) {
// Compare floats. They're also cheap.
if(elem != rhs.tupleof[tupleIndex]) {
return false;
}
}
foreach(tupleIndex, elem; this.tupleof) {
static if(!isIntegral!(typeof(elem))
!isFloatingPoint!(typeof(elem))) {
// All the cheap elements were equal.
// Resort to more expensive comparisons.
if(elem != rhs.tupleof[tupleIndex]) {
return false;
}
}
return true;
}
}
Looks cool. I think a first shot would be to make it a standalone function.
Of course, we could get even fancier. We could recursively introspect struct
types and use various heuristics to calculate the optimal comparison order at
compile time. Similar stuff could be done for a generic opCmp that gives a
struct an arbitrary total ordering as long as all of its members have a total
ordering.
This can be done if you associate a cost with each operation (e.g.
comparing numbers has cost 1, comparing strings has cost 10, comparing
using a user-defined function has cost 40 etc.) and then optimize for
smallest average cost.
Andrei
Re: Struct Comparison
dsimcha wrote: Regarding recent discussions in Bugzilla: I wonder if we could somehow define a super-efficient struct opEquals that performs introspection and only tests expensive members if it's necessary. The compiler should be doing this. It's the way to fix the Bugzilla bug. There should be no need to define opEquals() unless it does something different to an element-by-element comparison. Of course, we could get even fancier. We could recursively introspect struct types and use various heuristics to calculate the optimal comparison order at compile time. Similar stuff could be done for a generic opCmp that gives a struct an arbitrary total ordering as long as all of its members have a total ordering. Yes. This is something the compiler can't (or shouldn't) do.
Re: Struct Comparison
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article Of course, we could get even fancier. We could recursively introspect struct types and use various heuristics to calculate the optimal comparison order at compile time. Similar stuff could be done for a generic opCmp that gives a struct an arbitrary total ordering as long as all of its members have a total ordering. This can be done if you associate a cost with each operation (e.g. comparing numbers has cost 1, comparing strings has cost 10, comparing using a user-defined function has cost 40 etc.) and then optimize for smallest average cost. Andrei Right, this is what I had in mind. I take it this isn't a common, well-known optimization technique already? Walter?
What Does Haskell Have to Do with C++?
http://bartoszmilewski.wordpress.com/2009/10/21/what-does-haskell-have-to-do-with-c/ Bartosz's second part of 'Template Metaprogramming Made Easy (Huh?)', its quite a read :)
Re: Who's using structs nested in functions?
Jeremie Pelletier: However I don't think having a closure for that struct is really needed, nested functions already perform that task very well, and I use those quite often. That's why I have said static nested structs, they are like nested structs, but they don't have the extra field. Bye, bearophile
Re: What Does Haskell Have to Do with C++?
Jeremie Pelletier Wrote: http://bartoszmilewski.wordpress.com/2009/10/21/what-does-haskell-have-to-do-with-c/ Bartosz's second part of 'Template Metaprogramming Made Easy (Huh?)', its quite a read :) Jeremie, you are a champion and a scholar. Thanks for changing the topic. Justin Johansson ;-) Whoops, typo, that semi was meant to be a full breve ;-) God damm it; just can't break the habit.
Re: No header files?
Tomas Lindquist Olsen Wrote: This locks D to the LLVM backend, things like that is never a good idea. you could say the same thing about .net and Java - Java locks you to .class files and .net locks you to assemblies. there are many JVMs from different vendors for different platforms which are interoperable because of this. IIRC Mono can work with MS assemblies and also there's the interoperability between different .net languages. Also, LLVM bitcode files produced both by LDC and Clang/llvm-gcc are platform specific. Sure you can process them on any platform, but the source code they were compiled from was platform specific, and so is the resulting bitcode. Using LLVM bitcode as a replacement format for native OMF/COFF/ELF objects, does not give us platform neutrality. I don't know llvm that well but it seems that for clang/llvm-gcc the reason for this is because of the source language (c/c++) which is platform specific. Can you elaborate about this for LDC? where are the problematic parts and what can be done to make the output platform-neutral? I read that platform specific things like sizeof where hardcoded in the resulting bit-code but now they replaced it with a sizeof intrinsic so that the resulting bit-code would not depend on this. are there any other problematic cases like this still remaining? -Tomas
Re: Who's using structs nested in functions?
On 2009-10-22 16:33:01 +0200, Jeremie Pelletier jerem...@gmail.com said: bearophile wrote: Andrei Alexandrescu: With nested structs, however, you can't do much. You can pass them to a template, but I can't see some solid use cases there. My understanding is that nested structs have been implemented for completeness and consistency with nested classes. Any good example of nested struct uses? I have used nested static structs sometimes, when I need a struct just inside a function (like the main()) to avoid polluting the outer scope with the struct name. Do you want to remove them from D2? Bye, bearophile I've had similar uses, some win32 api routines require custom structs like BITMAPINFO, nested structs are neat to declare the struct right before its only usage. However I don't think having a closure for that struct is really needed, nested functions already perform that task very well, and I use those quite often. Jeremie I use structs in nested functions as context for parallel recursive loops, actually my code would be nicer if circular referring structs would be allowed in nested functions (at the moment this is not possible, even with forward references). Fawzi
Re: No header files?
On Thu, 22 Oct 2009 19:59:04 +0400, Yigal Chripun yigal...@gmail.com
wrote:
Tomas Lindquist Olsen Wrote:
This locks D to the LLVM backend, things like that is never a good idea.
you could say the same thing about .net and Java -
Java locks you to .class files and .net locks you to assemblies.
there are many JVMs from different vendors for different platforms which
are interoperable because of this. IIRC Mono can work with MS assemblies
and also there's the interoperability between different .net languages.
Also, LLVM bitcode files produced both by LDC and Clang/llvm-gcc are
platform specific. Sure you can process them on any platform, but the
source code they were compiled from was platform specific, and so is
the resulting bitcode. Using LLVM bitcode as a replacement format for
native OMF/COFF/ELF objects, does not give us platform neutrality.
I don't know llvm that well but it seems that for clang/llvm-gcc the
reason for this is because of the source language (c/c++) which is
platform specific. Can you elaborate about this for LDC? where are the
problematic parts and what can be done to make the output
platform-neutral?
I read that platform specific things like sizeof where hardcoded in the
resulting bit-code but now they replaced it with a sizeof intrinsic so
that the resulting bit-code would not depend on this. are there any
other problematic cases like this still remaining?
-Tomas
D source code:
void main()
{
version (Windows) {
writefln(Windows);
} else {
writefln(not Windows);
}
}
Using the same LLVM IR for both platforms would be a mistake in the case
above.
The only solution would be to carry version and such stuff in IR, too, and
resolve at later stages, but this is also problematic.
Re: Who's using structs nested in functions?
bearophile wrote: Andrei Alexandrescu: With nested structs, however, you can't do much. You can pass them to a template, but I can't see some solid use cases there. My understanding is that nested structs have been implemented for completeness and consistency with nested classes. Any good example of nested struct uses? I have used nested static structs sometimes, when I need a struct just inside a function (like the main()) to avoid polluting the outer scope with the struct name. Do you want to remove them from D2? Bye, bearophile I'm asking about non-static nested structs. Andrei
Re: int always 32 bits on all platforms?
Hello aJ, Well I can do the same thing with pragma or compiler switch in C++. It doesn't mean that thing will work if 32-bit ints have to be aligned on 32-bit boundaries. While nice to have one syntax to do that, it doesn't fix the problem (which I haven't expressed correctly probably). What good is a packed structure that has misaligned data members for the platform? You end up with mutually exclusive goals for different systems: align to (depending on the CPU) 8/16/32/64 bits and make it compact. You just can't have both in all cases. Generally I would expect you get one of three cases: 1) you need to ship binary struct from one system to another so you need to match a given layout from a different system (in this case avoiding misaligned data is a matter of luck), 2) you never ship the data out of the process (just skip all the align directives and let DMD align stuff correctly as, I think, it does by default) or 3) you need packed data (uses align to align on 8 bits)
Re: Who's using structs nested in functions?
Fawzi Mohamed wrote: On 2009-10-22 16:33:01 +0200, Jeremie Pelletier jerem...@gmail.com said: bearophile wrote: Andrei Alexandrescu: With nested structs, however, you can't do much. You can pass them to a template, but I can't see some solid use cases there. My understanding is that nested structs have been implemented for completeness and consistency with nested classes. Any good example of nested struct uses? I have used nested static structs sometimes, when I need a struct just inside a function (like the main()) to avoid polluting the outer scope with the struct name. Do you want to remove them from D2? Bye, bearophile I've had similar uses, some win32 api routines require custom structs like BITMAPINFO, nested structs are neat to declare the struct right before its only usage. However I don't think having a closure for that struct is really needed, nested functions already perform that task very well, and I use those quite often. Jeremie I use structs in nested functions as context for parallel recursive loops, actually my code would be nicer if circular referring structs would be allowed in nested functions (at the moment this is not possible, even with forward references). Fawzi Could you prepend static in front of their definition and still have them work? Andrei
Re: No header files?
Hello aJ, You sound angry that your feature is not a fit for my development process. I think the frustration here is that you seem to be saying that you can't do something in D that you want to do but we have yet to figure out what it is. Every thing I have seen you ask for is already possible with D as it is now (including hand writing both the header and implementation in different files with all the potential for errors and duplication of work that D tries avoid). jump in and start coding algorithms is not an acceptable development method in my book. In my experience, where you can't just start writing code, you can't just start writing headers either. I'd start on a white board or word and once stuff is designed there, I'd implement stubs with enough comment to know what they are supposed to do. In this mode, the header files would just be busy work.
Re: No header files?
Hello aJ, BCS n...@anon.com wrote in message news:a6268ffbb078cc2081280f1...@news.digitalmars.com... I will hold that the full source or webpage like documentation will do better in all cases than a header file. The first for where the details matter and the second for all other cases because it can contain anything the header can and is not bound by language constraints. We'll have to agree to disagree on that. Eliminating headers but requiring a webpage, is robbing Peter to pay Paul. Note that I'm assuming the avalability of a tool (like DMD has) to automaticly generate sutch a document. (1) is working at a higher level (designing vs. implenting) and perhaps even separating much of the design work from the implementation work (i.e., separate individuals or teams working on one or the other). (2) eliminates the need for secondary documentation (for well-designed code). I think of secondary documentation as the detailed description of how something works. Prior to consulting such, I'd want to know what something is, and something like a class declaration gives me that information immediately, without reading paragraphs of text. For example, you can describe car to me, but it would be much easier to just show me one. As said above, you can declare a class without implementing it in the current system as well as progamaticly extract what you are asking for in whatever format you want. So, it would appear, that if I am to write in D, I will be writing .di files just like I write .h files in C/C++. OK. Nope. The only time you should ever write a .di file by hand is as bindings for a non D codebase. .di files that describe something written in D should be auto generated. If you want to sketch out an interface and now and implement it later, I'd expect both to be done in a .d file (just replace the function bodies with ';') What more do you need to know usually? Some times I'd like some comments/verbiage. Well of course header files will have comments. The thing is though, tomes of documentation are not necessary you have header files. And what are the chances that the documentation will be in synch with the code if the documentation is external? Much better chance of that if the header file IS the documentation and the code is crafted such that it needs very little doc. Or even better, the code file has both the documentation source and the implementation source and you have a tool that can use that one file to generate the final documentation in a nicer format. BTW, the same argument for not having the documentation be in a different file from the header also holds for not having the interface definition be in a different file from the implementation. Some times I'd like exactly that but with better formatting. Seems like the exception rather than the common case. It depends on the coding style I guess. Certainly the STL header files are useless as any kind of documentation, that I grant you. But I'd consider that style of coding the exceptional case also. Even the best code editor I've ever seen doesn't come close to the readability that a halfway well done web page has. Try putting nice tables in your header files. Try adding clickable hyperlinks, always up to date tables of contents and indexes. A good tool will give you that and more for lest effort than it takes to keep the comment wrapping at 80 columns. The point is that if you want to start by coding that up, you can with the current system. OK, noted. If I ever write any D, that will be my preferred style. If you have a full program and you want that, you can generate it from the full program with the current system. I won't be using that feature. I have yet to see anything you have asked for that the current system can't give you. It just doesn't give it to you in exactly the same way C does. Apparently it does! No? It does what? C generally uses hand written interface and implementation files. D has either; a hand written implementation file and a auto generated interface file, only the implementation file or a hand written interface file and a non-D implementation. Doesn't look like what C does or am I totally lost on what you are looking for?
Re: Semicolons: mostly unnecessary?
KennyTM~: Please people, let's edit emails a little, so you don't carry around 30 KB of useless text :-) And if all you need is a re-syntax-ized D with optional semicolon, there is already one here. It's called Delight. In F# you have the light syntax, that you can activate with the #light annotation: http://stackoverflow.com/questions/461739/f-should-i-learn-with-or-without-light The Vala compiler accepts, with a compilation switch, the Genie code too (Genie for Vala is like Delight for D). No one is using Delight, because it's too far away, it needs an extra install, etc. If DMD will start accepting Delight code too, then some people will probably use such alternative syntax (beside syntax, Delight introduces few other things). Bye, bearophile
Re: this() not executing code on structs
dsimcha wrote: == Quote from grauzone (n...@example.net)'s article Andrei Alexandrescu wrote: I'd really like to know why scope x = new X(); is unsafe, while encouraging doing exactly the same with structs seems to be a perfectly fine idea. Allocating structs on the stack is obviously not any safer than with classes. I don't remember the exact reasons why you wanted to turn scope into a library feature, but I think I remember something about discouraging it for safety reasons; please forgive me is this is wrong. Because classes in D are always passed by pointer. (Technically references, but really they're just pointers under the hood.) Returning a scope (stack-allocated) class from a function is equivalent to escaping a pointer to a stack variable. Returning a struct is done by value, just like returning an int. But you can't return scope classes from a function. You can't pass them as ref parameters either. They're designed to be safe. On the other hand, you can pass struct pointers all the way you want around, and it's damn unsafe. I don't get this structs are safe because they are value types argument anyway, because the this pointer for structs is a pointer/reference anyway. If it's trivial to break that safety, can you really call it safety? Classes can't be value types because they are polymorphic, meaning their size isn't known at compile time. C++ tries to make them value types but really, there is no *good* way to make a polymorphic type with size not known at compile time a value type. Why do you want to add class functionality to structs to enable RAII like features, when you could just use scope classes? To me, this makes perfect sense. Classes are polymorphic, structs are value types. Except in the here be dragons world of C++, the two are mutually exclusive, which is the reason for the dichotomy in the first place. Therefore, structs should do everything they can w/o being polymorphic and classes should do everything they can w/o being value types. You then decide which one you want based on whether you need value semantics or polymorphism more. The only place in D where this logic breaks down is monitor objects on classes. Even here, while structs technically *could* be given monitors, this is inefficient because they are value types, whereas the efficiency loss from storing a few extra bytes in a reference type is minimal in most cases. Why do all objects have monitor pointers anyway? The idea, that every object can act as lock, is a really bad one. But this is off-topic... Scope is really a dangerous hack to allocate a *reference type* on the stack. It's dangerous and kludgey, but in a performance-oriented language it's a necessary evil. You could say the same about structs.
Re: this() not executing code on structs
dsimcha wrote:
== Quote from grauzone (n...@example.net)'s article
Andrei Alexandrescu wrote:
I'd really like to know why scope x = new X(); is unsafe, while
encouraging doing exactly the same with structs seems to be a perfectly
fine idea. Allocating structs on the stack is obviously not any safer
than with classes. I don't remember the exact reasons why you wanted to
turn scope into a library feature, but I think I remember something
about discouraging it for safety reasons; please forgive me is this is
wrong.
Because classes in D are always passed by pointer. (Technically references, but
really they're just pointers under the hood.) Returning a scope
(stack-allocated)
class from a function is equivalent to escaping a pointer to a stack variable.
Returning a struct is done by value, just like returning an int.
(I'm talking about scope classes as declared in scope class T { ... })
But you can't return scope classes from a function. You can't pass them
as ref parameters either. They're designed to be safe.
On the other hand, you can pass struct pointers all the way you want
around, and it's damn unsafe.
I don't get this structs are safe because they are value types
argument anyway, because the this pointer for structs is a
pointer/reference anyway. If it's trivial to break that safety, can
you really call it safety?
Classes can't be value types because they are polymorphic, meaning their size
isn't known at compile time. C++ tries to make them value types but really,
there
is no *good* way to make a polymorphic type with size not known at compile time
a
value type.
Why do you want to add class functionality to structs to enable RAII
like features, when you could just use scope classes?
To me, this makes perfect sense. Classes are polymorphic, structs are value
types. Except in the here be dragons world of C++, the two are mutually
exclusive, which is the reason for the dichotomy in the first place. Therefore,
structs should do everything they can w/o being polymorphic and classes should
do
everything they can w/o being value types. You then decide which one you want
based on whether you need value semantics or polymorphism more.
The only place in D where this logic breaks down is monitor objects on classes.
Even here, while structs technically *could* be given monitors, this is
inefficient because they are value types, whereas the efficiency loss from
storing
a few extra bytes in a reference type is minimal in most cases.
Why do all objects have monitor pointers anyway? The idea, that every
object can act as lock, is a really bad one. But this is off-topic...
Scope is really a dangerous hack to allocate a *reference type* on the stack.
It's dangerous and kludgey, but in a performance-oriented language it's a
necessary evil.
You could say the same about structs.
Re: No header files?
Hello Yigal, On 22/10/2009 00:57, BCS wrote: Hello Yigal, As you said, what is needed is a better lib format. we already have DDL NOW which already has most of what you described above. D can also take advantage of the LLVM framework. Does DDL or LLVM work to generate monolithic executable that use all of D's features and do so for both Win32 and *nux? Also, can I use notepad to view either of those file types? from http://llvm.org/docs/LangRef.html quote The LLVM code representation is designed to be used in three different forms: as an in-memory compiler IR, as an on-disk bitcode representation (suitable for fast loading by a Just-In-Time compiler), and as a human readable assembly language representation. This allows LLVM to provide a powerful intermediate representation for efficient compiler transformations and analysis, while providing a natural means to debug and visualize the transformations. The three different forms of LLVM are all equivalent. /quote So, if your library has LLVM code representation, then it's easier to get to but just as bad as reading a ASM dump from the compiler. I'm being more than a bit sarcastic there, but keep in mind that 99% of the info I'm interested in isn't in the assembly code (function names, argument names, types, comments) and/or would be better viewed as the original source. IIRC DDL wraps objects/libs with meta-data. while it will be easy to get a text representation with llvm (the equivalence that is mentioned above) why would you want to do it anyway? Automatically extracted documentation to a human format (ddoc, javadoc, etc) is much more useful and more flexible - you can get a printed manual or an interactive and easy to navigate html, you can also get all sorts of graphs and diagrams that would ease understanding of the structure of code. I'm cynical enough that I'd bet if D switches to a smarter lib format a lot of people would manage to forget the documentation. With the current system, the library must be shipped with, at a minimum, a human readable list of prototypes. the only valid IMO use case for header files is for linking libs - the compiler can handle just find binary formats for that. Truth be told I don't use .di files at all because I have yet to need to use a codebase where I didn't have full source.
Re: Semicolons: mostly unnecessary?
On Thu, Oct 22, 2009 at 9:44 AM, bearophile bearophileh...@lycos.com wrote: KennyTM~: Please people, let's edit emails a little, so you don't carry around 30 KB of useless text :-) And if all you need is a re-syntax-ized D with optional semicolon, there is already one here. It's called Delight. In F# you have the light syntax, that you can activate with the #light annotation: http://stackoverflow.com/questions/461739/f-should-i-learn-with-or-without-light Actually, the light syntax is the default in the most recent version of F# that comes with VS2010. http://msdn.microsoft.com/en-us/library/dd233199%28VS.100%29.aspx --bb
