Rory McGuire wrote:
Andrei Alexandrescu wrote:
TDPL is entering a review stage where a collection of coders from all
walks of programming life will have one month to submit feedback that
will shape the final version of the book.
The book has been blessed with feedback from people who alrea
Bill Baxter wrote:
On Tue, Dec 8, 2009 at 7:24 PM, Don wrote:
* If y == 0, x ^^ y is 1.
Need to mention what happens when x is also 0.
No. 0^^0 is 1, as well.
Is it? That's rather embarrassing for Wolfram Alpha, then (and
presumably Mathematica, too) since they have it as "indeterminate"
Andrei Alexandrescu wrote:
> TDPL is entering a review stage where a collection of coders from all
> walks of programming life will have one month to submit feedback that
> will shape the final version of the book.
>
> The book has been blessed with feedback from people who already know D
>
Problems in defining the order of evaluations in C#:
http://blogs.msdn.com/ericlippert/archive/2009/11/25/the-purpose-revealed.aspx
And eventually the named arguments too will see light in D :-)
Bye,
bearophile
"BCS" wrote in message
news:a6268ffdff18cc46f7aa8b7...@news.digitalmars.com...
> please tell me the subject is a freudian slip (or just a typo).
>
>
It's a very precise figure:
1 metric fuckton == 1,000 meteric shitloads
retard wrote:
> Thu, 10 Dec 2009 01:01:34 +0100, downs wrote:
>
>> including such gems as incorrect
>> tuple lengths, incorrect tuple slices, endless errors without line
>> numbers, spurious template instantiation errors with nonsensical
>> parameters, and at least one case where T[0] evaluated to
Thu, 10 Dec 2009 01:01:34 +0100, downs wrote:
> including such gems as incorrect
> tuple lengths, incorrect tuple slices, endless errors without line
> numbers, spurious template instantiation errors with nonsensical
> parameters, and at least one case where T[0] evaluated to T,
> necessitating th
dsimcha wrote:
> == Quote from downs (default_357-l...@yahoo.de)'s article
>> I've just committed a module to tools (tools.cpp,
> http://dsource.org/projects/scrapple/Trunk/tools/tools/cpp.d ) that should
> enable
> linking and using any C++ library with D programs without creating a C
> wrapper
BCS wrote:
> please tell me the subject is a freudian slip (or just a typo).
>
>
Considering the amount of abuse me and the compiler put each other through in
the course of writing this, including such gems as incorrect tuple lengths,
incorrect tuple slices, endless errors without line numbers,
g wrote:
> downs Wrote:
>
>> I've just committed a module to tools (tools.cpp,
>> http://dsource.org/projects/scrapple/Trunk/tools/tools/cpp.d ) that should
>> enable linking and using any C++ library with D programs without creating a
>> C wrapper for it.
>>
>> The code has been tested with a
== Quote from downs (default_357-l...@yahoo.de)'s article
> I've just committed a module to tools (tools.cpp,
http://dsource.org/projects/scrapple/Trunk/tools/tools/cpp.d ) that should
enable
linking and using any C++ library with D programs without creating a C wrapper
for it.
> The code has bee
downs Wrote:
> I've just committed a module to tools (tools.cpp,
> http://dsource.org/projects/scrapple/Trunk/tools/tools/cpp.d ) that should
> enable linking and using any C++ library with D programs without creating a C
> wrapper for it.
>
> The code has been tested with a simple multiple-in
omg
Joel C. Salomon:
> Then we may have to convince Walter not to eliminate the extra
> comparison operators.
They don't add that much to the language, while they are not easy to remember
and add complexity. So I think that even serious numeric programmers will not
miss them too much.
But I don't p
please tell me the subject is a freudian slip (or just a typo).
I've just committed a module to tools (tools.cpp,
http://dsource.org/projects/scrapple/Trunk/tools/tools/cpp.d ) that should
enable linking and using any C++ library with D programs without creating a C
wrapper for it.
The code has been tested with a simple multiple-inheritance sample:
http://
On 12/7/2009 5:37 PM, bearophile wrote:
> Lars T. Kyllingstad:
>> I searched for FORTRAN code because that's more or less equivalent to
>> searching for numerical code. And I think D's "target audience" is
>> anyone who needs a fast, close-to-the-metal programming language. This
>> definitely in
I have posted a blog about the state-of-the-art results in uniqueness. I
discuss the paper by Haller/Odersky, where they present an extension to Scala.
I would appreciate your vote on reddit:
http://www.reddit.com/r/programming/comments/acsg8/unique_objects/
TDPL is entering a review stage where a collection of coders from all
walks of programming life will have one month to submit feedback that
will shape the final version of the book.
The book has been blessed with feedback from people who already know D
or are otherwise versed enough with langu
Michal Minich wrote:
Hello Denis,
OTOH, if you want to protect yourself from (accidental) global state
mutation, you are free to declare your static function as pure:
struct X
{
static int x;
static void foo() pure
{
// x = 3; // error
}
static void bar()
{
x = 3; // okay
}
}
I was thinking
Don wrote:
> Rainer Deyke wrote:
> One that may not survive future
>> evolution of the D language, and may not respected by other
>> implementations of the D language.
>
> I think you're confusing 'pure' with 'constant expression'. They are not
> the same thing.
No.
> (I /should/ be removed.
On 12/9/2009 11:50 AM, Bill Baxter wrote:
Found this link about 0^^0:
http://mathforum.org/dr.math/faq/faq.0.to.0.power.html
I think this explains pretty well why Wolfram is justified in saying
0^^0 is indeterminate, but a PL like D is perfectly justified in
saying it's 1.
In particular the art
Andrei Alexandrescu wrote:
On a non-degenerate base, any exponent greater than 32 (for int) and 64
(for long) would generate overflow. That can be figured with one test.
In fact probably all exponents can be special-cased to use the minimal
amount of multiplications (which in the general case
KennyTM~ wrote:
On Dec 9, 09 17:25, Simen kjaeraas wrote:
On Wed, 09 Dec 2009 09:36:56 +0100, Don wrote:
CHANGES BASED ON FURTHER COMMENTS
x ^^ y is right associative, and has a precedence intermediate between
unary and postfix operators.
The type of x ^^ y is the same as
Bill Baxter wrote:
On Tue, Dec 8, 2009 at 7:24 PM, Don wrote:
* If y == 0, x ^^ y is 1.
Need to mention what happens when x is also 0.
No. 0^^0 is 1, as well.
Is it? That's rather embarrassing for Wolfram Alpha, then (and
presumably Mathematica, too) since they have it as "indeterminate"
Found this link about 0^^0:
http://mathforum.org/dr.math/faq/faq.0.to.0.power.html
I think this explains pretty well why Wolfram is justified in saying
0^^0 is indeterminate, but a PL like D is perfectly justified in
saying it's 1.
In particular the article asserts: "Consensus has recently been b
On Tue, Dec 8, 2009 at 8:07 PM, Don wrote:
> Bill Baxter wrote:
>>
>> On Tue, Dec 8, 2009 at 10:18 AM, Bill Baxter wrote:
I agree. Then at least why not make the type of the exponent unsigned?
That
gives the type system a fighting chance (via e.g. value range
propagation)
On Tue, Dec 8, 2009 at 7:24 PM, Don wrote:
>>> * If y == 0, x ^^ y is 1.
>>
>> Need to mention what happens when x is also 0.
>
> No. 0^^0 is 1, as well.
Is it? That's rather embarrassing for Wolfram Alpha, then (and
presumably Mathematica, too) since they have it as "indeterminate":
http:/
Lars T. Kyllingstad wrote:
Jeremie Pelletier wrote:
hehe45 wrote:
In c++ it is valid syntax to have trailing commas at the and of enum
definitions:
enum {a, b, c, };
This would be a useful addition to D too.
The enum class syntax from c++0x should also adopted by D, this would
allow named en
Mike Parker Wrote:
> AFAIK, zip archives can be automatically generated from a link at the
> bottom of any page in the source browser. For example, you can download
> the entire Derelict trunk on this page:
>
> http://www.dsource.org/projects/derelict/browser/trunk
Ah, thank you, missed that.
Kagamin wrote:
>
So svn access in unusable with dsource and I found no feasible method to get sources from it. Projects don't publish snapshots and trac doesn't provide them either.
AFAIK, zip archives can be automatically generated from a link at the
bottom of any page in the source browser.
Don wrote:
CHANGES BASED ON FURTHER COMMENTS
x ^^ y is right associative, and has a precedence intermediate between
unary and postfix operators.
The type of x ^^ y is the same as the type of x * y.
* If either x or y are floating-point, the result is pow(x, y).
If both x a
Don wrote:
Jason House wrote:
I think you have a bad corner case:
enum int ct = -1;
immutable rt = -1;
ct ^^ ct // Error (compile time)
This would always get rewritten.
rt ^^ ct // Error (compile time)
rt ^^ rt // Error (run time)
ct ^^ rt // Works??? (after rewrite)
No, they will all wor
Jason House wrote:
I think you have a bad corner case:
enum int ct = -1;
immutable rt = -1;
ct ^^ ct // Error (compile time)
rt ^^ ct // Error (compile time)
rt ^^ rt // Error (run time)
ct ^^ rt // Works??? (after rewrite)
No, they will all work. Both rt and ct are manifest constants.
oops, my message was supposed to be in reply to version 3 that included the
rewrite rule for -1 ^^ y
Jason House Wrote:
> I think you have a bad corner case:
>
> enum int ct = -1;
> immutable rt = -1;
>
> ct ^^ ct // Error (compile time)
> rt ^^ ct // Error (compile time)
> rt ^^ rt // Error (
I think you have a bad corner case:
enum int ct = -1;
immutable rt = -1;
ct ^^ ct // Error (compile time)
rt ^^ ct // Error (compile time)
rt ^^ rt // Error (run time)
ct ^^ rt // Works??? (after rewrite)
Don Wrote:
> Based on everyone's comments, this is what I have come up with:
>
>
KennyTM~:
> Because 3^^-1 would become 3^^4294967295
I agree, no unsigned values, please.
In D unsigned values are bug-prone, it's better to avoid them when possible,
they are useful almost only when you need a bitfield (they are useful for
arithmetic only exceptionally, when you really need a p
Denis Koroskin Wrote:
> I don't think it is dsource problem, it's rather an svn problem.
> When using TortoiseSVN, you can go to
> Start/Program/TortoiseSVN/Settings/Network/ and specify your proxy.
> Internet folks say it helps. I believe there should be similar
> configuration option for c
Rainer Deyke wrote:
Don wrote:
f() ^^ f() is not a constant expression. It won't get transformed. It
can be *interpreted* at compile time, but that'll generate an error.
That's a very fine distinction.
Yes. This is a very narrow special case. Bill Baxter and others have
argued that it is s
On Wed, 09 Dec 2009 14:57:47 +0300, Kagamin wrote:
I have well-known problem with svn client: proxy doesn't allow svn
report http requests:
svn: Server sent unexpected return value (400 Bad Request) in response
to REPORT request for '/repos/svn/!svn/vcc/default'
So svn access in unusable w
I have well-known problem with svn client: proxy doesn't allow svn report http
requests:
svn: Server sent unexpected return value (400 Bad Request) in response to
REPORT request for '/repos/svn/!svn/vcc/default'
So svn access in unusable with dsource and I found no feasible method to get
source
Justin Johansson Wrote:
> Algol-68 came out in, well, 1968. Apparently the language was
> considered 'finished' with the release of the Revision of Algol-68
> in 1974. By this time it was too late for the language to gain any
> real traction.
>
> A number of contemporary topics on this newsgro
Don wrote:
> f() ^^ f() is not a constant expression. It won't get transformed. It
> can be *interpreted* at compile time, but that'll generate an error.
That's a very fine distinction. One that may not survive future
evolution of the D language, and may not respected by other
implementations of
Hello Tomek,
Dnia 08-12-2009 o 20:09:10 Tomek Sowiński napisał(a):
I think immutable static member functions don't make sense and
rightly so. On functions immutable is about "this" and there's no
"this". Currently everything inside an immutable struct/class is
tagged with "immutable".
Hello Denis,
OTOH, if you want to protect yourself from (accidental) global state
mutation, you are free to declare your static function as pure:
struct X
{
static int x;
static void foo() pure
{
// x = 3; // error
}
static void bar()
{
x = 3; // okay
}
}
I was thinking about providing contra
Don wrote:
Rainer Deyke wrote:
Don wrote:
Rainer Deyke wrote:
Not quite. Under the proposal, -1^^-1 works (i.e. produces the correct
result) at compile time but fails at runtime.
It won't pass CTFE.
pure int f() { return -1; }
void g(int)(int);
g!(f() ^^ f())(0); // Works.
No, it doesn't
Rainer Deyke wrote:
Don wrote:
Rainer Deyke wrote:
Not quite. Under the proposal, -1^^-1 works (i.e. produces the correct
result) at compile time but fails at runtime.
It won't pass CTFE.
pure int f() { return -1; }
void g(int)(int);
g!(f() ^^ f())(0); // Works.
No, it doesn't work. It's
Algol-68 came out in, well, 1968. Apparently the language was
considered 'finished' with the release of the Revision of Algol-68
in 1974. By this time it was too late for the language to gain any
real traction.
A number of contemporary topics on this newsgroup should be tempered
with a soberi
Don wrote:
> Rainer Deyke wrote:
>> Not quite. Under the proposal, -1^^-1 works (i.e. produces the correct
>> result) at compile time but fails at runtime.
>
> It won't pass CTFE.
pure int f() { return -1; }
void g(int)(int);
g!(f() ^^ f())(0); // Works.
g!(0)(f() ^^ f()); // Runtime error?
'f(
Simen kjaeraas wrote:
On Wed, 09 Dec 2009 09:36:56 +0100, Don wrote:
CHANGES BASED ON FURTHER COMMENTS
x ^^ y is right associative, and has a precedence intermediate between
unary and postfix operators.
The type of x ^^ y is the same as the type of x * y.
* If either x
Rainer Deyke wrote:
Lars T. Kyllingstad wrote:
Rainer Deyke wrote:
I don't care if x^^y with y < 0 is 0, a runtime error, or even undefined
behavior. However, having different behavior if x is a compile-time
constant than if x is a variable is unacceptable because it silently
changes the (defi
Rainer Deyke wrote:
Lars T. Kyllingstad wrote:
Rainer Deyke wrote:
I don't care if x^^y with y < 0 is 0, a runtime error, or even undefined
behavior. However, having different behavior if x is a compile-time
constant than if x is a variable is unacceptable because it silently
changes the (defi
Rainer Deyke wrote:
Lars T. Kyllingstad wrote:
Rainer Deyke wrote:
I don't care if x^^y with y < 0 is 0, a runtime error, or even undefined
behavior. However, having different behavior if x is a compile-time
constant than if x is a variable is unacceptable because it silently
changes the (defi
KennyTM~ wrote:
On Dec 9, 09 16:36, Don wrote:
CHANGES BASED ON FURTHER COMMENTS
x ^^ y is right associative, and has a precedence intermediate between
unary and postfix operators.
The type of x ^^ y is the same as the type of x * y.
* If either x or y are floating-point, t
Lars T. Kyllingstad wrote:
> Rainer Deyke wrote:
>> I don't care if x^^y with y < 0 is 0, a runtime error, or even undefined
>> behavior. However, having different behavior if x is a compile-time
>> constant than if x is a variable is unacceptable because it silently
>> changes the (defined) behav
On Dec 9, 09 17:25, Simen kjaeraas wrote:
On Wed, 09 Dec 2009 09:36:56 +0100, Don wrote:
CHANGES BASED ON FURTHER COMMENTS
x ^^ y is right associative, and has a precedence intermediate between
unary and postfix operators.
The type of x ^^ y is the same as the type of x *
On Dec 9, 09 16:36, Don wrote:
CHANGES BASED ON FURTHER COMMENTS
x ^^ y is right associative, and has a precedence intermediate between
unary and postfix operators.
The type of x ^^ y is the same as the type of x * y.
* If either x or y are floating-point, the result is pow(
On Wed, 09 Dec 2009 09:36:56 +0100, Don wrote:
CHANGES BASED ON FURTHER COMMENTS
x ^^ y is right associative, and has a precedence intermediate between
unary and postfix operators.
The type of x ^^ y is the same as the type of x * y.
* If either x or y are floating-point
Jeremie Pelletier wrote:
hehe45 wrote:
In c++ it is valid syntax to have trailing commas at the and of enum
definitions:
enum {a, b, c, };
This would be a useful addition to D too.
The enum class syntax from c++0x should also adopted by D, this would
allow named enums which are not automatica
Don wrote:
Bill Baxter wrote:
On Tue, Dec 8, 2009 at 2:32 AM, Don wrote:
Based on everyone's comments, this is what I have come up with:
x ^^ y is right associative, and has a precedence intermediate between
multiplication and unary operators.
Is that consistent with ma
Rainer Deyke wrote:
Don wrote:
Note that by definining the 0,1, -1 cases as "rewriting" rules rather
than return values, it should be clearer that they don't apply to
variables having those values.
I don't care if x^^y with y < 0 is 0, a runtime error, or even undefined
behavior. However, hav
On Wed, 09 Dec 2009 05:28:23 +0100, Andrei Alexandrescu
wrote:
Don wrote:
Bill Baxter wrote:
On Tue, Dec 8, 2009 at 10:18 AM, Bill Baxter wrote:
I agree. Then at least why not make the type of the exponent
unsigned? That
gives the type system a fighting chance (via e.g. value range
pro
Don wrote:
> Note that by definining the 0,1, -1 cases as "rewriting" rules rather
> than return values, it should be clearer that they don't apply to
> variables having those values.
I don't care if x^^y with y < 0 is 0, a runtime error, or even undefined
behavior. However, having different beha
dfdf Wrote:
> fdfdfd
FUFUFU
CHANGES BASED ON FURTHER COMMENTS
x ^^ y is right associative, and has a precedence intermediate between
unary and postfix operators.
The type of x ^^ y is the same as the type of x * y.
* If either x or y are floating-point, the result is pow(x, y).
If both x and y are int
65 matches
Mail list logo
