Andrei Alexandrescu wrote:
Benji Smith wrote:
Andrei Alexandrescu wrote:
Anyhow... it would be a bummer if the negative atmosphere as of late
in the group would cause people like you just lose interest. I can't
understand what's going on.
I think it would help if you weren't so
Andrei Alexandrescu wrote:
Anyhow... it would be a bummer if the negative atmosphere as of late in
the group would cause people like you just lose interest. I can't
understand what's going on.
I think it would help if you weren't so condescending to people all the
time. People don't like
Andrei Alexandrescu Wrote:
Anyhow... it would be a bummer if the negative atmosphere as of late in
the group would cause people like you just lose interest. I can't
understand what's going on. It starts looking like a disfunctional
relationship: the more Walter and others do, the less
Benji Smith wrote:
Andrei Alexandrescu wrote:
Anyhow... it would be a bummer if the negative atmosphere as of late
in the group would cause people like you just lose interest. I can't
understand what's going on.
I think it would help if you weren't so condescending to people all the
time.
Yigal Chripun wrote:
Let's compare:
Bartosz took upon himself the task of designing concurrency for D. For that he put forth a lot of effort to explain the design and the rational behind it, he also encouraged discussion of the subject in the NG and answered questions.
You've re-implemented
Andrei Alexandrescu wrote:
By the way, it seems that Walter hasn't regenerated the documentation
when releasing 2.031, for example search this page for enum
http://www.dsource.org/projects/phobos/browser/trunk/phobos/std/conv.d
vs. this page:
BCS wrote:
I think this strand of the thread (and what I was talking about) was not
about octal but about complexity in the lexical design. That bugzilla
issue was brought up as an issue and IS the first point that comes to my
mind in that direction. disallowing leading or trailing decimal
Rainer Deyke wrote:
Andrei Alexandrescu wrote:
Derek Parnell wrote:
I would not complain if trailing dot and leading dot were disallowed.
I think the question that should be asked is: would anyone complain if
they were kept? We have bigger rocks to move than that one.
It seems rather
Derek Parnell wrote:
So ...
... just in case you look over your shoulder:
Octal literals are so common that we need compiler/language support.
We don't need, we have it.
Character ranges are so rare that we do not need compiler/language support.
This is just immature. It's not that
Hello Walter,
BCS wrote:
What would you sell it outright for? As in I would own it and have
every right I would have if I was the original author.
As a non-exclusive license, probably $500.
Not a license, *own*. As in I *own* my hat. (ignoring the question of would
you still own your
BCS wrote:
BCS wrote:
What would you sell it outright for? As in I would own it and have
every right I would have if I was the original author.
As a non-exclusive license, probably $500.
Not a license, *own*. As in I *own* my hat. (ignoring the question of
would you still own your copy)
Walter Bright wrote:
BCS wrote:
Hello Walter,
Jarrett Billingsley wrote:
Totally agree. They're cruft that just complicate lexical analysis.
Not a significant issue, as the code to lex it is done, works, and is
readily available.
But that assumes that just using the lexer is
Walter Bright wrote:
Jarrett Billingsley wrote:
On Tue, Jul 7, 2009 at 11:20 PM, Walter
Translating C code to D.
I don't see this as a reasonable justification. Octal isn't used that
much in C either, and D is already so far from C that you need an
automated tool to do it, so you might as
Walter Bright wrote:
Back in the 80's, there was some n.g. discussion about what xy meant
and how it was lexed and parsed. The best answer was:
Here a plus, there a plus, everywhere a plus plus.
What I'd really like to see is a lexer that parses operators by rules
rather than lists. If
Walter Bright:
Not a significant issue, as the code to lex it is done, works, and is
readily available.
It's not an issue for the compiler, but a modern programming language has to be
designed for programmers, to be as little bug-prone as possible. Literals as .5
and 5. are not correct in my
Andrei Alexandrescu:
I can't understand what's going on. It starts looking like a disfunctional
relationship: the more Walter and others do, the less content people on the
group are. I don't care much for being pat on the back, but it's extremely
disheartening to see that the more we do the
Don wrote:
Make a leading 0 illegal,
I'm not sure what benefit that accomplishes.
and either:
(1) change the octal syntax into 0c77733,
or(better) (2) provide an octal conversion function in the standard
library.
Because of CTFE, so we can actually do (2) very nicely. I don't see any
bearophile wrote:
Walter Bright:
Not a significant issue, as the code to lex it is done, works, and is
readily available.
It's not an issue for the compiler, but a modern programming language has to be
designed for programmers, to be as little bug-prone as possible. Literals as .5
and 5.
Compatibility with C is paramount, except when it's not.
You didn't understand. Compatibility with C is important in the sense
that we want to have a clean-cut answer to a function rsa_encrypt()
taken from C and pasted into D: either it compiles and runs with the
same result, or it doesn't
Jarrett Billingsley, el 7 de julio a las 22:28 me escribiste:
On Tue, Jul 7, 2009 at 8:08 PM, bearophilebearophileh...@lycos.com wrote:
Nick Sabalausky:
why in the world is anyone defending the continued existance of 5.
and .5?
I'm for disallowing them; 5.0 ad 0.5 are better.
Anyone
Jarrett Billingsley, el 7 de julio a las 23:40 me escribiste:
On Tue, Jul 7, 2009 at 11:20 PM, Walter
Brightnewshou...@digitalmars.com wrote:
Jarrett Billingsley wrote:
Totally agree. They're cruft that just complicate lexical analysis.
Not a significant issue, as the code to lex it
grauzone wrote:
Compatibility with C is paramount, except when it's not.
You didn't understand. Compatibility with C is important in the sense
that we want to have a clean-cut answer to a function rsa_encrypt()
taken from C and pasted into D: either it compiles and runs with the
same result,
*cough* pot *cough* kettle *cough* black... :o)
Are you alright?
Don wrote:
Walter Bright wrote:
Don wrote:
Make a leading 0 illegal,
I'm not sure what benefit that accomplishes.
It catches occasional mistakes such as:
int [] foo = [
001
010
100
];
which are admittedly very rare, though it actually happened to me
earlier this year. It's quite
Leandro Lucarella wrote:
That's not a good enough reason. Having *one* front-end
(lexer/parser/semantic analizer) is not good enough. D was supposed to
make this easy to encourage different implementations. If the D specs are
twisted and making a new lexer is... confusing, I think that's a
Walter Bright wrote:
Don wrote:
It catches occasional mistakes such as:
int [] foo = [
001
010
100
];
I see your point, but I'd like to add that it is rare enough that it has
never happened to me in 30 years.
It has happened to me once or twice. I have never intentionally used an
Hello Walter,
BCS wrote:
BCS wrote:
What would you sell it outright for? As in I would own it and have
every right I would have if I was the original author.
As a non-exclusive license, probably $500.
Not a license, *own*. As in I *own* my hat. (ignoring the question of
would you still
BCS wrote:
I don't see where the gotcha is. It's not trivial, but it's
specifiable, and the code implementing it is there and is correct.
well for one thing the spec is wrong:
http://d.puremagic.com/issues/show_bug.cgi?id=1466
That issue has nothing to do with octal literals, and removing
Hello Walter,
BCS wrote:
I don't see where the gotcha is. It's not trivial, but it's
specifiable, and the code implementing it is there and is correct.
well for one thing the spec is wrong:
http://d.puremagic.com/issues/show_bug.cgi?id=1466
That issue has nothing to do with octal
bearophile wrote:
C) adding unbounded integral literals for multi-precisions integral
numbers (to be used by bigintegers implemented in the std lib or
other D code). (This is to teach D another bit of fishing, using
Andrei metaphor).
No, it's exactly the opposite - putting on the table a
On Tue, 07 Jul 2009 20:08:55 -0400, bearophile wrote:
Nick Sabalausky:
why in the world is anyone defending the continued existance of 5. and
.5?
I'm for disallowing them; 5.0 ad 0.5 are better.
Anyone else pro/against this idea?
I would not complain if trailing dot and leading dot were
Derek Parnell wrote:
On Tue, 07 Jul 2009 20:08:55 -0400, bearophile wrote:
Nick Sabalausky:
why in the world is anyone defending the continued existance of 5. and .5?
I'm for disallowing them; 5.0 ad 0.5 are better.
Anyone else pro/against this idea?
I would not complain if trailing dot
bearophile wrote:
Andrei Alexandrescu:
No, it's exactly the opposite - putting on the table a rotten fish.
If it's so smelly all people will avoid it quickly, so no harm done :-)
Big integer literals can be accommodated as compile-time strings.
Do you mean like this?
BigInt a =
Andrei Alexandrescu:
Anyway, I think this feature is thoroughly useless. An adage says that
the only numeric literals in a program should be 0, 1, and -1. How many
big integer literals can you think of right now?
OK, let's forget big integer literals for now :-)
I agree that there are
Andrei Alexandrescu:
I think the question that should be asked is: would anyone complain if
they were kept? We have bigger rocks to move than that one.
D has small differences, like disallowing 156l (only 156L is allowed). Such
small details build up improving the language.
For example I have
On Tue, Jul 7, 2009 at 8:08 PM, bearophilebearophileh...@lycos.com wrote:
Nick Sabalausky:
why in the world is anyone defending the continued existance of 5. and
.5?
I'm for disallowing them; 5.0 ad 0.5 are better.
Anyone else pro/against this idea?
Totally agree. They're cruft that just
Andrei Alexandrescu wrote:
Anyway, I think this feature is thoroughly useless. An adage says that
the only numeric literals in a program should be 0, 1, and -1. How many
big integer literals can you think of right now?
The deficit?
Jarrett Billingsley wrote:
Totally agree. They're cruft that just complicate lexical analysis.
Not a significant issue, as the code to lex it is done, works, and is
readily available.
Or just drop octal altogether. Outside of chmod, when is there any
legitimate need for it these days?
On Tue, Jul 7, 2009 at 11:20 PM, Walter
Brightnewshou...@digitalmars.com wrote:
Jarrett Billingsley wrote:
Totally agree. They're cruft that just complicate lexical analysis.
Not a significant issue, as the code to lex it is done, works, and is
readily available.
I'm not going to argue
Jarrett Billingsley wrote:
On Tue, Jul 7, 2009 at 11:20 PM, Walter
Translating C code to D.
I don't see this as a reasonable justification. Octal isn't used that
much in C either, and D is already so far from C that you need an
automated tool to do it, so you might as well just have the tool
Hello Andrei,
Anyway, I think this feature is thoroughly useless. An adage says that
the only numeric literals in a program should be 0, 1, and -1. How
many big integer literals can you think of right now?
The Avogadro constant is slightly less than 2^79. (~2^78.99)
Hello Andrei,
Derek Parnell wrote:
On Tue, 07 Jul 2009 20:08:55 -0400, bearophile wrote:
Nick Sabalausky:
why in the world is anyone defending the continued existance of
5. and .5?
I'm for disallowing them; 5.0 ad 0.5 are better.
Anyone else pro/against this idea?
I would not complain
On Tue, 07 Jul 2009 20:20:18 -0500, Andrei Alexandrescu wrote:
Derek Parnell wrote:
On Tue, 07 Jul 2009 20:08:55 -0400, bearophile wrote:
Nick Sabalausky:
why in the world is anyone defending the continued existance of 5.
and .5?
I'm for disallowing them; 5.0 ad 0.5 are better. Anyone
BCS wrote:
Hello Walter,
Jarrett Billingsley wrote:
Totally agree. They're cruft that just complicate lexical analysis.
Not a significant issue, as the code to lex it is done, works, and is
readily available.
But that assumes that just using the lexer is acceptable. What if
someone
BCS wrote:
Hello Andrei,
Derek Parnell wrote:
On Tue, 07 Jul 2009 20:08:55 -0400, bearophile wrote:
Nick Sabalausky:
why in the world is anyone defending the continued existance of
5. and .5?
I'm for disallowing them; 5.0 ad 0.5 are better.
Anyone else pro/against this idea?
I would
On Tue, 07 Jul 2009 20:20:28 -0700, Walter Bright wrote:
Or just drop octal altogether. Outside of chmod, when is there any
legitimate need for it these days?
Translating C code to D.
On Tue, 07 Jul 2009 20:29:40 -0700, Walter Bright wrote:
Sometimes I run across someone else's code that
Andrei Alexandrescu wrote:
Derek Parnell wrote:
I would not complain if trailing dot and leading dot were disallowed.
I think the question that should be asked is: would anyone complain if
they were kept? We have bigger rocks to move than that one.
It seems rather disingenuous to complain
Hello Walter,
BCS wrote:
Hello Walter,
Jarrett Billingsley wrote:
Totally agree. They're cruft that just complicate lexical
analysis.
Not a significant issue, as the code to lex it is done, works, and
is readily available.
But that assumes that just using the lexer is acceptable.
BCS wrote:
What would you sell it outright for? As in I would own it and have every
right I would have if I was the original author.
As a non-exclusive license, probably $500. If you can develop it for
less than that, then it wasn't really that hard g. For less than $500,
it isn't even worth
Rainer Deyke wrote:
Never mind if any of these
token sequences are syntactically valid, this is a mess at the lexical
level. If '0.wyda' is interpreted as the token sequence '0. ... .
wyda', then you have bigger things to worry about than whether or not
that token sequence is ever
Derek Parnell wrote:
So ...
Octal literals are so common that we need compiler/language support.
Character ranges are so rare that we do not need compiler/language support.
Compatibility with C is paramount, except when it's not.
Technical merit trumps human interface.
If you're looking for
51 matches
Mail list logo
