Nick Sabalausky wrote:
As for whether or not this effect can be reasonably accomplished with
structs: I have no idea, I haven't really looked into it.
I use a tagged variant for the token struct.
This doesn't make any difference if one is parsing small pieces of code. But
when you're trying t
bearophile wrote:
Walter:
Java made a related mistake by failing to acknowledge that value types have
any useful purpose at all (unless they are built-in).
Java was designed to be simple! Simple means to have a more uniform
semantics.
So was Pascal. See the thread about how useless it was a
Rainer Deyke wrote:
On 10/26/2010 20:16, Walter Bright wrote:
Rainer Deyke wrote:
On the other hand, if the object itself calls it own public member
functions, then no invariants should be checked. Not being able to call
public member functions while the object is temporarily in an invalid
sta
On 10/26/2010 09:26 PM, Walter Bright wrote:
That's a good sentiment, but it doesn't work that way in practice.
Warnings always become de-facto requirements. They aren't the solution
to a disagreement about how the language should work.
My point was that your claim to be trying to put static an
"Walter Bright" wrote in message
news:ia8321$vu...@digitalmars.com...
> Nick Sabalausky wrote:
>> "Walter Bright" wrote in message
>> news:i9qd8q$1ls...@digitalmars.com...
>>> 4. the tokens should be a value type, not a reference type
>>
>> I'm curious, is your reason for this purely to avoid a
Walter:
> Java made a related mistake by failing to acknowledge that
> value types have any useful purpose at all (unless they are built-in).
Java was designed to be simple! Simple means to have a more uniform semantics.
Removing value types was a good idea if you want to simplify a language (a
On 10/26/2010 20:16, Walter Bright wrote:
> Rainer Deyke wrote:
>> On the other hand, if the object itself calls it own public member
>> functions, then no invariants should be checked. Not being able to call
>> public member functions while the object is temporarily in an invalid
>> state is too
Nick Sabalausky wrote:
"Walter Bright" wrote in message
news:i9qd8q$1ls...@digitalmars.com...
4. the tokens should be a value type, not a reference type
I'm curious, is your reason for this purely to avoid allocations during
lexing, or are there other reasons too?
It's one big giant reason
Ellery Newcomer wrote:
Question: would it be feasible to make D use some sort of bignum type as
the default index type for arrays, etc, but make it possible for the
programmer to use uint or ulong or whatever for e.g. places where
performance is an issue?
I suspect that's a big jump in comple
Rainer Deyke wrote:
On the other hand, if the object itself calls it own public member
functions, then no invariants should be checked. Not being able to call
public member functions while the object is temporarily in an invalid
state is too strict. This is a problem that I actually ran into wh
Short story: long time ago, lost code, think it's already in bugzilla (259?)
On 10/26/2010 08:25 PM, bearophile wrote:
Ellery Newcomer:
I went to the trouble of modifying dmd to warn on unsigned/signed
comparison. It found me some bugs which probably would not have been
noticed otherwise. Did
Jonathan M Davis wrote:
In the general case, it would overly complicate things to try and make an
invariant not really be an invariant. If you really wanted to do that, you could
use class variables which kept the state and made it so that the asserts in the
invariant weren't run after a partic
On 10/26/2010 18:00, bearophile wrote:
> All this looks bug-prone, and surely hairy, but it looks potentially
> useful. Is it a good idea to design a class that uses such temporary
> suspension of the invariant?
I think invariants should be checked whenever a public member function
is called from
"Walter Bright" wrote in message
news:i9qd8q$1ls...@digitalmars.com...
>
> 4. the tokens should be a value type, not a reference type
I'm curious, is your reason for this purely to avoid allocations during
lexing, or are there other reasons too?
If it's mainly to avoid allocations during lexin
On 10/26/2010 07:25 PM, Walter Bright wrote:
An invariant that is not invariant is a meaningless attribute. It's like
"logical constness" where classes claim to be const but aren't.
an invariant which isn't used because it is too strict isn't much better.
Example:
class with some sort of sta
Ellery Newcomer:
> I went to the trouble of modifying dmd to warn on unsigned/signed
> comparison. It found me some bugs which probably would not have been
> noticed otherwise. Did it produce false positives? Yes. Did that make me
> wish I hadn't done it? Hell no.
Please, put this patch in a B
On 10/26/2010 04:21 PM, Walter Bright wrote:
7. Certainly the idea of non-null types has a lot of adherents, D
doesn't have that.
8. The only successful solution to this I've seen is Java's simply not
having unsigned types. Analysis tools just produce false positives.
or python's variation: n
On Tuesday, October 26, 2010 17:25:20 Walter Bright wrote:
> bearophile wrote:
> > All this looks bug-prone, and surely hairy, but it looks potentially
> > useful. Is it a good idea to design a class that uses such temporary
> > suspension of the invariant?
>
> An invariant that is not invariant i
The weak purity is big. With DMD 2.050 many Phobos functions will be able to
support the pure attribute.
This is just a little example, swap:
http://d.puremagic.com/issues/show_bug.cgi?id=5121
A more complex example, sort, with the problems I've found (using 2.050alpha):
http://d.puremagic.com/i
bearophile wrote:
All this looks bug-prone, and surely hairy, but it looks potentially useful.
Is it a good idea to design a class that uses such temporary suspension of
the invariant?
An invariant that is not invariant is a meaningless attribute. It's like
"logical constness" where classes cl
I have not asked this in the D.learn newsgroup because I think it may be a bit
interesting for other general people too.
In D contract programming the invariant is not called before/after private
methods. I think that in some cases you may want to disable the invariant even
in some public metho
On 10/26/10 17:29 CDT, osa wrote:
On 10/26/2010 05:09 PM, Andrei Alexandrescu wrote:
Thanks. Defining opAssign for Bar will allow you to use the syntax bar =
null and have it nullify the reference.
I feel stupid, but I do not see how to nullify the Bar reference inside
of opAssign. Again, my p
On 10/26/2010 05:09 PM, Andrei Alexandrescu wrote:
Thanks. Defining opAssign for Bar will allow you to use the syntax bar =
null and have it nullify the reference.
I feel stupid, but I do not see how to nullify the Bar reference inside
of opAssign. Again, my problem is that I have
Bar
On 10/26/10 16:58 CDT, osa wrote:
On 10/26/2010 04:46 PM, Andrei Alexandrescu wrote:
In this particular case the decision goes both ways, and both have
something going for them. You may want to submit a bug report at least
to prompt us to change the documentation to clarify the behavior.
A worka
On 10/26/2010 04:46 PM, Andrei Alexandrescu wrote:
In this particular case the decision goes both ways, and both have
something going for them. You may want to submit a bug report at least
to prompt us to change the documentation to clarify the behavior.
A workaround is to define opAssign(Bar).
On 10/26/10 11:35 CDT, osa wrote:
Every time I'm trying to use alias this (which looks like a nice
feature, on paper), I end up with problems. This is the most recent one
(dmd v2.049):
--
struct Foo {}
class Bar {
Foo foo_;
alias foo_ this;
}
void main() {
auto a = new Bar;
auto b = a;
a = n
bearophile wrote:
From my experience I've seen that lint tools are very useful to quickly find
many bugs, on the other hand most of my friends don't use them. This is a
problem I've felt for some time. Recently I have found an interesting paper
that expresses my feelings better:
"Condate: A Prot
Andrei:
> Rory McGuire:
> > To get some basic runtime reflection one could use dmd's json dump.
> >
> > and then use import("filename.json") to get the json into the
> > executable. Then make a class which makes it more usable as a
> > reflection system.
> >
> > You can try it out by compiling thi
Jérôme M. Berger wrote:
Walter Bright wrote:
Jérôme M. Berger wrote:
Walter Bright wrote:
bearophile wrote:
"acts very badly" kinda means the same thing :-)
DMD acts very badly regarding that specific situation,
As I said, the two error messages it gives are right on target.
"Assertion
On 10/26/10 10:29 CDT, Rory McGuire wrote:
To get some basic runtime reflection one could use dmd's json dump.
and then use import("filename.json") to get the json into the
executable. Then make a class which makes it more usable as a
reflection system.
You can try it out by compiling this code
On 10/26/2010 03:22 PM, "Jérôme M. Berger" wrote:
I'm not sure that the problem is on the line where the error is
reported. My guess would be that the issue is with the "auto a = new
Bar" line: I would bet that this gets interpreted as "Foo a = new
Bar" instead of what we expect ("Bar a =
"dennis luehring" wrote in message
news:ia6s3b$1q9...@digitalmars.com...
> Am 26.10.2010 16:48, schrieb dennis luehring:
>> Am 26.10.2010 15:55, schrieb Leandro Lucarella:
>>
>> yupp - Spirit feels right on the integration-side, but becomes more and
>> more evil when stuff gets bigger
Goldie (an
Walter Bright wrote:
> Jérôme M. Berger wrote:
>> Walter Bright wrote:
>>> bearophile wrote:
> "acts very badly" kinda means the same thing :-)
DMD acts very badly regarding that specific situation,
>>> As I said, the two error messages it gives are right on target.
>>
>> "AssertionFai
Jonathan M Davis wrote:
> On Tuesday, October 26, 2010 09:35:21 osa wrote:
>> Every time I'm trying to use alias this (which looks like a nice
>> feature, on paper), I end up with problems. This is the most recent one
>> (dmd v2.049):
>> --
>> struct Foo {}
>> class Bar {
>> Foo foo_;
>>
Adam D. Ruppe:
> I've used D2 for a large web application for 7 months now without having to
> change
> any more than a handful of lines of code due to language/lib changes.
Using D2 for an accounting program is currently too much dangerous still. D1
may be used for that purpose, maybe.
Bye,
b
Jérôme M. Berger wrote:
Walter Bright wrote:
bearophile wrote:
"acts very badly" kinda means the same thing :-)
DMD acts very badly regarding that specific situation,
As I said, the two error messages it gives are right on target.
"AssertionFailure: 'tn->mod == MODimmutable' on line
I've used D2 for a large web application for 7 months now without having to
change
any more than a handful of lines of code due to language/lib changes.
The most intrusive change has probably been std.contracts being renamed!
If you are just using this newsgroup, or one attempt at one of the fa
Jonathan M Davis Wrote:
> On Tuesday, October 26, 2010 03:15:18 tuanhoanganh wrote:
> > I am newbie of D language.
> > I know D is new language. Is D v1.064 stable to write accounting
> > application ( because ddbi is only support this D version).?
> > Is there commercial write in D.
> >
> > Tha
Jacob Carlborg wrote:
> That is what the whole thread is about, giving better and more accurate
> error messages. A great example, as bearophile shows, is the missing
> semicolon error which Clang points to the "right" line wheres DMD, GCC
> points to the start of the next statement. As Walter poin
Walter Bright wrote:
> bearophile wrote:
>>> "acts very badly" kinda means the same thing :-)
>>
>> DMD acts very badly regarding that specific situation,
>
> As I said, the two error messages it gives are right on target.
"AssertionFailure: 'tn->mod == MODimmutable' on line 879 in file
'
On Tuesday, October 26, 2010 09:35:21 osa wrote:
> Every time I'm trying to use alias this (which looks like a nice
> feature, on paper), I end up with problems. This is the most recent one
> (dmd v2.049):
> --
> struct Foo {}
> class Bar {
> Foo foo_;
> alias foo_ this;
> }
>
> void
On Tuesday, October 26, 2010 03:15:18 tuanhoanganh wrote:
> I am newbie of D language.
> I know D is new language. Is D v1.064 stable to write accounting
> application ( because ddbi is only support this D version).?
> Is there commercial write in D.
>
> Thanks in advance
> Sorry for my English.
Sean Kelly Wrote:
> Don Wrote:
> >
> > Wait a minute. x86 has no read-modify-write instructions for x87, or for
> > SSE. So I don't think it's possible to implement atomic floating-point
> > ops, apart from assignment.
> > (Of course, you can fake it with a mass of casts and a CAS, but that
>
On Tue, 2010-10-26 at 08:23 +0200, Gour wrote:
> On Mon, 25 Oct 2010 07:30:16 +0100
> >> "Russel" == Russel Winder wrote:
>
> Russel> Is the intention that D should be the language of choice for
> Russel> implementing applications on MeeGo? If not maybe it should?
>
> For MeeGo we need fully
Every time I'm trying to use alias this (which looks like a nice
feature, on paper), I end up with problems. This is the most recent one
(dmd v2.049):
--
struct Foo {}
class Bar {
Foo foo_;
alias foo_ this;
}
void main() {
auto a = new Bar;
auto b = a;
a = null; // fails
On 04/10/2010 10:07, Don wrote:
A great example of how C syntax is hurting us.
---
I found this bit of code in std.container, inside BinaryHeap:
size_t insert(ElementType!Store value)
{
static if (is(_store.insertBack(value)))
{
...
}
else ...
What does the static if do? It's *intended* to chec
On 05/10/2010 10:50, Walter Bright wrote:
Lars T. Kyllingstad wrote:
http://dsource.org/projects/dmd/changeset/703
:)
Don, as usual, made a compelling case.
Programs going down in flames is always a compelling argument... ^_^'
--
Bruno Medeiros - Software Engineer
On 26-ott-10, at 05:13, Sean Kelly wrote:
Don Wrote:
Wait a minute. x86 has no read-modify-write instructions for x87,
or for
SSE. So I don't think it's possible to implement atomic floating-
point
ops, apart from assignment.
(Of course, you can fake it with a mass of casts and a CAS, but
To get some basic runtime reflection one could use dmd's json dump.
and then use import("filename.json") to get the json into the
executable. Then make a class which makes it more usable as a
reflection system.
You can try it out by compiling this code twice, first time with a
dummy jsontest.js
Am 26.10.2010 16:48, schrieb dennis luehring:
Am 26.10.2010 15:55, schrieb Leandro Lucarella:
bearophile, el 26 de octubre a las 06:20 me escribiste:
Nick Sabalausky:
> I've taken a deeper look at Spirit's docs:
I have not used Spirit, but from what I have read, it doesn't scale
(t
On 05/10/2010 08:27, Jacob Carlborg wrote:
If you have two classes in one file in Java you can access private
methods from the other class.
Only if one class is nested in the other.
--
Bruno Medeiros - Software Engineer
Am 26.10.2010 15:55, schrieb Leandro Lucarella:
bearophile, el 26 de octubre a las 06:20 me escribiste:
Nick Sabalausky:
> I've taken a deeper look at Spirit's docs:
I have not used Spirit, but from what I have read, it doesn't scale
(the compilation becomes too much slower when the syste
On 10/26/10 9:07 CDT, Leandro Lucarella wrote:
Dmitry Olshansky, el 26 de octubre a las 12:54 me escribiste:
On 26.10.2010 7:42, Walter Bright wrote:
Rainer Deyke wrote:
On 10/25/2010 19:01, Walter Bright wrote:
Yes, we discussed it before. The Digital Mars C/C++ compiler does this,
and NOBOD
Dmitry Olshansky, el 26 de octubre a las 12:54 me escribiste:
> On 26.10.2010 7:42, Walter Bright wrote:
> >Rainer Deyke wrote:
> >>On 10/25/2010 19:01, Walter Bright wrote:
> >>>Yes, we discussed it before. The Digital Mars C/C++ compiler does this,
> >>>and NOBODY CARES.
> >>>Not one person in 25
bearophile, el 26 de octubre a las 06:20 me escribiste:
> Nick Sabalausky:
>
> > I've taken a deeper look at Spirit's docs:
>
> I have not used Spirit, but from what I have read, it doesn't scale
> (the compilation becomes too much slower when the system you have
> built becomes bigger).
I can c
bearophile schrieb:
Walter:
Only because clang made a marketing issue out of it. Nobody coming from dmc++
noticed.
I used to point out this feature in dmc++ to users. Nobody cared, I'd just get
blank looks. Why would I drop it if people wanted it?
Maybe it's all just marketing. But sometimes
On Tue, 19 Oct 2010 21:53:56 +0200, Jacob Carlborg wrote:
> On 2010-10-19 21:37, Andrei Alexandrescu wrote:
>> More detail about the design please? I browsed through the code and the
>> main issue seems to be heavy reliance on granular delegates to do
>> pretty much anything. Would fixing that imp
>From my experience I've seen that lint tools are very useful to quickly find
>many bugs, on the other hand most of my friends don't use them. This is a
>problem I've felt for some time. Recently I have found an interesting paper
>that expresses my feelings better:
"Condate: A Proto-language at
Walter Bright wrote:
> bearophile wrote:
>>> "acts very badly" kinda means the same thing :-)
>>
>> DMD acts very badly regarding that specific situation,
>
> As I said, the two error messages it gives are right on target.
They are and technically more so than what clang claims. The difference
I am newbie of D language.
I know D is new language. Is D v1.064 stable to write accounting application
( because ddbi is only support this D version).?
Is there commercial write in D.
Thanks in advance
Sorry for my English.
Tuan Hoang Anh.
Walter:
> Only because clang made a marketing issue out of it. Nobody coming from dmc++
> noticed.
>
> I used to point out this feature in dmc++ to users. Nobody cared, I'd just get
> blank looks. Why would I drop it if people wanted it?
Maybe it's all just marketing. But sometimes marketing is
Nick Sabalausky:
> I've taken a deeper look at Spirit's docs:
I have not used Spirit, but from what I have read, it doesn't scale (the
compilation becomes too much slower when the system you have built becomes
bigger).
Bye,
bearophile
On 26.10.2010 7:42, Walter Bright wrote:
Rainer Deyke wrote:
On 10/25/2010 19:01, Walter Bright wrote:
Yes, we discussed it before. The Digital Mars C/C++ compiler does this,
and NOBODY CARES.
Not one person in 25 years has ever even commented on it. Nobody
commented on its lack in dmd.
I thi
"Walter Bright" wrote in message
news:ia5j41$2bn...@digitalmars.com...
>
> To specifically answer your question, yes, in the lexers I make, you know
> you're parsing a string, so you process it as you parse it.
>
>...
>
> I don't know. I'd have to study the issue for a while. I suggest taking a
"bearophile" wrote in message
news:ia6a0h$ns...@digitalmars.com...
> Nick Sabalausky:
>
>> I've taken a deeper look at Spirit's docs:
>
> I have not used Spirit, but from what I have read, it doesn't scale (the
> compilation becomes too much slower when the system you have built becomes
> bigge
"Michel Fortin" wrote in message
news:ia5e1v$22j...@digitalmars.com...
> On 2010-10-25 21:57:54 -0400, Walter Bright
> said:
>
>> bearophile wrote:
>>> Walter:
>>>
It's the very next token. There's nothing wrong with the message.
>>>
>>> In that case I prefer the error message to refer to
On 2010-10-26 04:44, Nick Sabalausky wrote:
"Walter Bright" wrote in message
news:ia59si$1r0...@digitalmars.com...
Consider a string literal, say "abc\"def". With Goldie's method, I infer
this string has to be scanned twice. Once to find its limits, and the
second to convert it to the actual s
On 2010-10-26 04:25, Andrei Alexandrescu wrote:
On 10/25/10 21:12 CDT, Michel Fortin wrote:
On 2010-10-25 21:01:49 -0400, Walter Bright
said:
bearophile wrote:
Another diagnostic feature is to not just use the caret (we have
discussed about it time ago) but it also underlines the wrong part:
68 matches
Mail list logo
