Re: ICE for x[] + x[]
People are expected to search such things themselves: https://d.puremagic.com/issues/query.cgi Ok. The server was a bit sluggish when I tried. I'll be more patient next time. Thx /Per
Re: Should we deprecate comma?
On Monday, 24 March 2014 at 05:18:04 UTC, bearophile wrote: deadalnix: Andrei Alexandrescu: The change has an eye to that. Disallowing the use of the return value offers us the future possibility of redefining it. -- Andrei That is brilliant ! I'm buying. Please show few examples. I am not sure using the comma for tuples in just return situations is a good idea. It seems too much special casing. Also because returning tuples is already currently acceptable. The main problem is breaking tuples apart. I actually made a more complete explanation of what I have in mind. I should probably write a DIP one day. You can read a rough explanation of my proposal here: http://forum.dlang.org/thread/lrycaqlrtwylhbxfi...@forum.dlang.org?page=2#post-mudvqeqzbosfdirtfkhr:40forum.dlang.org
Re: Challenge: write a really really small front() for UTF8
On Monday, 24 March 2014 at 05:27:43 UTC, Michel Fortin wrote: Here's the corrected (again) version of front1: [Snip] And I'm going to suggest a variant of the above with one less branch (but three more instructions): [Snip] Everything seems to work in your corrected versions: http://dpaste.dzfl.pl/3b32535559ba Andrei's version doesn't compile on recent compiler versions due to goto skipping initialization.
Re: Walter's DConf 2014 Talks - Topics in Finance
On Sunday, 23 March 2014 at 18:15:16 UTC, Paulo Pinto wrote: At least on Java world it is not quite true. And that's why I said a language like C/C++ that allows aliasing. If you use XML parsers that return a DOM or SAX, yes quite true. But as far as I can tell, XML streaming parsers (StAX) only parse on demand. It's been a while since I used it, but the Apache SAX parser (Xerces?) converts all string input to wchar_t before passing it to the callback. And since XML input is nearly always in UTF-8, this can mean a ton of transcoding.
Re: Challenge: write a really really small front() for UTF8
On 2014-03-24 04:58:08 +, "safety0ff" said: 0b100 is missing a zero: 0b1000_ Indeed, thanks. Fixing that, I still get a range violation from "s[1+i]". That "auto indicator = (s[0] >> 5) & 0b11;" line is wrong too. s[0] needs a shift by 4, not by 5. No doubt it crashes your test program. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca
Re: Challenge: write a really really small front() for UTF8
On 2014-03-24 05:09:15 +, Andrei Alexandrescu
said:
On 3/23/14, 9:49 PM, Michel Fortin wrote:
http://goo.gl/y9EVFr
Andrei
As I said earlier, that front2 version is broken. It's missing a break.
Adding the break makes it non-interesting from an instruction count
point of view.
Also, there's still an issue in my code above (found by safetyOff): the
first "if" for ASCII should use 0b1000_, not 0b100 (missing one
zero). Here's the corrected (again) version of front1:
dchar front1(char[] s)
{
if (s[0] < 0b1000_)
return s[0]; // ASCII
// pattern indicator tailLength
// 0b1100 0b00 (0) 1
// 0b1101 0b01 (1) 1 == indicator
// 0b1110 0b10 (2) 2 == indicator
// 0b 0b11 (3) 3 == indicator
// note: undefined result for illegal 0b1xxx case
auto indicator = (s[0] >> 4) & 0b11;
auto tailLength = indicator ? indicator : 1;
dchar result = s[0] & (0b0011_ >> tailLength);
foreach (i; 0..tailLength)
result = (result << 6) | (s[1+i] & 0b0011_);
return result;
}
And I'm going to suggest a variant of the above with one less branch
(but three more instructions): look at how tailLenght is computed by
or'ing with the negative of bit 2 of indicator. I suspect it'll be
faster with non-ASCII input, unless it gets inlined less.
dchar front2(char[] s)
{
if (s[0] < 0b1000_)
return s[0]; // ASCII
// pattern indicator tailLength
// 0b1100 0b00 (0) 1
// 0b1101 0b01 (1) 1
// 0b1110 0b10 (2) 2
// 0b 0b11 (3) 3
// note: undefined result for illegal 0b1xxx case
auto indicator = ((s[0] >> 4) & 0b11);
auto tailLength = indicator | ((~indicator >> 1) & 0b1);
dchar result = s[0] & (0b0011_ >> tailLength);
foreach (i; 0..tailLength)
result = (result << 6) | (s[1+i] & 0b0011_);
return result;
}
--
Michel Fortin
michel.for...@michelf.ca
http://michelf.ca
Re: Should we deprecate comma?
deadalnix: Andrei Alexandrescu: The change has an eye to that. Disallowing the use of the return value offers us the future possibility of redefining it. -- Andrei That is brilliant ! I'm buying. Please show few examples. I am not sure using the comma for tuples in just return situations is a good idea. It seems too much special casing. Also because returning tuples is already currently acceptable. The main problem is breaking tuples apart. Bye, bearophile
Re: Challenge: write a really really small front() for UTF8
On Sunday, 23 March 2014 at 22:58:53 UTC, Andrei Alexandrescu wrote: On 3/23/14, 3:10 PM, Dmitry Olshansky wrote: 24-Mar-2014 01:34, Andrei Alexandrescu пишет: On 3/23/14, 2:29 PM, Dmitry Olshansky wrote: 24-Mar-2014 01:22, Andrei Alexandrescu пишет: Here's a baseline: http://goo.gl/91vIGc. Destroy! Assertions to check encoding?! I thought it would detect broken encoding and do a substitution at least. That implementation does zero effort to optimize checks themselves, and indeed puts them in asserts. I think there's value in having such a primitive down below. Just how much you are willing to assert? You don't even check length. Array bounds checking takes care of that. Since strings are often user input, if there is chance that bad input can cause undefined behavior, then the checks must be done unconditionally.
Re: Challenge: write a really really small front() for UTF8
On 3/23/14, 9:49 PM, Michel Fortin wrote:
dchar front(char[] s)
{
if (s[0] < 0b100)
return s[0]; // ASCII
// pattern indicator tailLength
// 0b1100 0b00 (0) 1
// 0b1101 0b01 (1) 1 == indicator
// 0b1110 0b10 (2) 2 == indicator
// 0b 0b11 (3) 3 == indicator
// note: undefined result for illegal 0b1xxx case
auto indicator = (s[0] >> 4) & 0b11;
auto tailLength = indicator ? indicator : 1;
dchar result = s[0] & (0b0011 >> tailLength);
foreach (i; 0..tailLength)
result = (result << 6) | (s[1+i] & 0b0011);
return result;
}
http://goo.gl/y9EVFr
Andrei
Re: Challenge: write a really really small front() for UTF8
On 03/23/2014 09:44 PM, Michel Fortin wrote: On 2014-03-24 04:39:08 +, "bearophile" said: Michel Fortin: I really wish D had no implicit fallthrough. Isn't your wish already granted? Maybe. I don't have a D compiler installed at the moment to check. I'm just playing with d.godbolt.org and it accepts implicit fallthrough. That compiler is very old. :) import std.compiler; pragma(msg, version_major); pragma(msg, version_minor); The output: 2u 55u Ali
Re: Challenge: write a really really small front() for UTF8
Andrei Alexandrescu: -w Probably time to move that from a warning to an error. In the short time we've used D at Facebook (forgot to add "-w" to the implicit flags) we've already have not one, but two bugs related to switch's implicit fallthrough. Lot of people in D.learn don't use warnings. What I'd like is to have (informational) warning active on default, and to disable them on request with a compiler switch. Bye, bearophile
Re: Challenge: write a really really small front() for UTF8
On Monday, 24 March 2014 at 04:37:23 UTC, Michel Fortin wrote:
dchar front(char[] s)
{
if (s[0] < 0b100)
return s[0]; // ASCII
auto indicator = (s[0] >> 5) & 0b11;
auto tailLength = indicator ? indicator : 1;
dchar result = s[0] & (0b0011 >> tailLength);
foreach (i; 0..tailLength)
result = (result << 6) | (s[1+i] & 0b0011);
return result;
}
(Disclaimer: not tested, but I did check that all the expected
code paths are present in the assembly this time.)
0b100 is missing a zero: 0b1000_
Fixing that, I still get a range violation from "s[1+i]".
- Test program -
void main()
{
foreach (ubyte b0; 0..0x80)
{
char[] s = [b0];
assert(front(s)==front2(s));
} writeln("Single byte done");
foreach (ubyte b0; 0..0x40)
foreach (ubyte b1; 0..0x20)
{
char[] s = [0xC0|b1, 0x80|b0];
assert(front(s)==front2(s));
} writeln("Double byte done");
foreach (ubyte b0; 0..0x40)
foreach (ubyte b1; 0..0x40)
foreach (ubyte b2; 0..0x10)
{
char[] s = [0xE0|b2, 0x80|b1, 0x80|b0];
assert(front(s)==front2(s));
} writeln("Triple byte done");
foreach (ubyte b0; 0..0x40)
foreach (ubyte b1; 0..0x40)
foreach (ubyte b2; 0..0x40)
foreach (ubyte b3; 0..0x08)
{
char[] s = [0xF0|b3, 0x80|b2, 0x80|b1, 0x80|b0];
assert(front(s)==front2(s));
}
}
Re: Should we deprecate comma?
On Monday, 24 March 2014 at 04:00:14 UTC, Andrei Alexandrescu wrote: On 3/23/14, 8:30 PM, bearophile wrote: How is this more limited change affecting possible future syntax usage of commas for tuples? :-) The change has an eye to that. Disallowing the use of the return value offers us the future possibility of redefining it. -- Andrei That is brilliant ! I'm buying.
Re: Should we deprecate comma?
On 2014-03-24 00:41, Andrei Alexandrescu wrote: On 3/23/14, 9:29 PM, Etienne Cimon wrote: On 2014-03-24 00:04, Andrei Alexandrescu wrote: On 3/23/14, 8:22 PM, Etienne Cimon wrote: How about allowing it only inside parenthesis? That works but breaks more valid code. -- Andrei If the comma expression operator is outlawed on the global scope, variadic template parameters could be used with commas outside the parantheses which allows such syntax: if(pMgr->ShouldRecordEvent(eSE_Weapon), pOwnerRaw) // ERROR return pMgr->RecordEvent(eSE_Weapon), pOwnerRaw; // ERROR if(e!pMgr->ShouldRecordEvent(eSE_Weapon), pOwnerRaw) // OK return e!pMgr->RecordEvent(eSE_Weapon), pOwnerRaw; // OK Would it make sense to reserve the global e identifier for expressions? With that the approach would be veering off the road. -- Andrei Well, I'll vote for the compromise, there shouldn't be issues with keeping statements in void contexts such as int i, j, k; i++, j++, k--; etc. And then I guess I'll change that part of my coding style, everyone seems to hate it so much ..
Re: Challenge: write a really really small front() for UTF8
On 3/23/14, 9:37 PM, Michel Fortin wrote:
On 2014-03-24 02:25:17 +, Andrei Alexandrescu
said:
On 3/23/14, 6:53 PM, Michel Fortin wrote:
On 2014-03-23 21:22:58 +, Andrei Alexandrescu
said:
Here's a baseline: http://goo.gl/91vIGc. Destroy!
Optimizing for smallest assembly size:
dchar front(char[] s)
{
size_t bytesize;
dchar result;
switch (s[0])
{
case 0b: .. case 0b0111:
return s[0];
case 0b1100: .. case 0b1101:
return ((s[0] & 0b0001) << 6) | (s[1] & 0b0001);
case 0b1110: .. case 0b1110:
result = s[0] & 0b;
bytesize = 3;
break;
case 0b: .. case 0b0111:
result = s[0] & 0b0111;
bytesize = 4;
default:
return dchar.init;
}
foreach (i; 1..bytesize)
result = (result << 6) | (s[i] & 0b0011);
return result;
}
Nice, thanks! I'd hope for a short path for the ASCII subset, could
you achieve that?
Unfortunately, there's a bug in the above. A missing "break" results in
a fallthrough to default case. That's why the optimizer is so good, it
just omits the four-byte branch entirely. I noticed something was wrong
by looking at the assembly. I really wish D had no implicit fallthrough.
-w
Probably time to move that from a warning to an error. In the short time
we've used D at Facebook (forgot to add "-w" to the implicit flags)
we've already have not one, but two bugs related to switch's implicit
fallthrough.
But try this instead, the result is even shorter:
dchar front(char[] s)
{
if (s[0] < 0b100)
return s[0]; // ASCII
// pattern indicator tailLength
// 0b100x 0b00 (0) 1
// 0b101x 0b01 (1) 1 == indicator
// 0b110x 0b10 (2) 2 == indicator
// 0b111x 0b11 (3) 3 == indicator
// note: undefined result for illegal 0b case
auto indicator = (s[0] >> 5) & 0b11;
auto tailLength = indicator ? indicator : 1;
dchar result = s[0] & (0b0011 >> tailLength);
foreach (i; 0..tailLength)
result = (result << 6) | (s[1+i] & 0b0011);
return result;
}
(Disclaimer: not tested, but I did check that all the expected code
paths are present in the assembly this time.)
Nicely done. I collected what we have at http://goo.gl/W9V6E7.
Andrei
Re: Challenge: write a really really small front() for UTF8
On 2014-03-24 04:37:22 +, Michel Fortin said:
But try this instead, the result is even shorter:
Oops, messed up my patterns. Here's a hopefully fixed front():
dchar front(char[] s)
{
if (s[0] < 0b100)
return s[0]; // ASCII
// pattern indicator tailLength
// 0b1100 0b00 (0) 1
// 0b1101 0b01 (1) 1 == indicator
// 0b1110 0b10 (2) 2 == indicator
// 0b 0b11 (3) 3 == indicator
// note: undefined result for illegal 0b1xxx case
auto indicator = (s[0] >> 4) & 0b11;
auto tailLength = indicator ? indicator : 1;
dchar result = s[0] & (0b0011 >> tailLength);
foreach (i; 0..tailLength)
result = (result << 6) | (s[1+i] & 0b0011);
return result;
}
--
Michel Fortin
michel.for...@michelf.ca
http://michelf.ca
Re: Challenge: write a really really small front() for UTF8
On 2014-03-24 04:39:08 +, "bearophile" said: Michel Fortin: I really wish D had no implicit fallthrough. Isn't your wish already granted? Maybe. I don't have a D compiler installed at the moment to check. I'm just playing with d.godbolt.org and it accepts implicit fallthrough. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca
Re: Should we deprecate comma?
On 3/23/14, 9:29 PM, Etienne Cimon wrote: On 2014-03-24 00:04, Andrei Alexandrescu wrote: On 3/23/14, 8:22 PM, Etienne Cimon wrote: How about allowing it only inside parenthesis? That works but breaks more valid code. -- Andrei If the comma expression operator is outlawed on the global scope, variadic template parameters could be used with commas outside the parantheses which allows such syntax: if(pMgr->ShouldRecordEvent(eSE_Weapon), pOwnerRaw) // ERROR return pMgr->RecordEvent(eSE_Weapon), pOwnerRaw; // ERROR if(e!pMgr->ShouldRecordEvent(eSE_Weapon), pOwnerRaw) // OK return e!pMgr->RecordEvent(eSE_Weapon), pOwnerRaw; // OK Would it make sense to reserve the global e identifier for expressions? With that the approach would be veering off the road. -- Andrei
Re: Challenge: write a really really small front() for UTF8
Michel Fortin: I really wish D had no implicit fallthrough. Isn't your wish already granted? Bye, bearophile
Re: Challenge: write a really really small front() for UTF8
On 2014-03-24 02:25:17 +, Andrei Alexandrescu
said:
On 3/23/14, 6:53 PM, Michel Fortin wrote:
On 2014-03-23 21:22:58 +, Andrei Alexandrescu
said:
Here's a baseline: http://goo.gl/91vIGc. Destroy!
Optimizing for smallest assembly size:
dchar front(char[] s)
{
size_t bytesize;
dchar result;
switch (s[0])
{
case 0b: .. case 0b0111:
return s[0];
case 0b1100: .. case 0b1101:
return ((s[0] & 0b0001) << 6) | (s[1] & 0b0001);
case 0b1110: .. case 0b1110:
result = s[0] & 0b;
bytesize = 3;
break;
case 0b: .. case 0b0111:
result = s[0] & 0b0111;
bytesize = 4;
default:
return dchar.init;
}
foreach (i; 1..bytesize)
result = (result << 6) | (s[i] & 0b0011);
return result;
}
Nice, thanks! I'd hope for a short path for the ASCII subset, could you
achieve that?
Unfortunately, there's a bug in the above. A missing "break" results in
a fallthrough to default case. That's why the optimizer is so good, it
just omits the four-byte branch entirely. I noticed something was wrong
by looking at the assembly. I really wish D had no implicit fallthrough.
But try this instead, the result is even shorter:
dchar front(char[] s)
{
if (s[0] < 0b100)
return s[0]; // ASCII
// pattern indicator tailLength
// 0b100x 0b00 (0) 1
// 0b101x 0b01 (1) 1 == indicator
// 0b110x 0b10 (2) 2 == indicator
// 0b111x 0b11 (3) 3 == indicator
// note: undefined result for illegal 0b case
auto indicator = (s[0] >> 5) & 0b11;
auto tailLength = indicator ? indicator : 1;
dchar result = s[0] & (0b0011 >> tailLength);
foreach (i; 0..tailLength)
result = (result << 6) | (s[1+i] & 0b0011);
return result;
}
(Disclaimer: not tested, but I did check that all the expected code
paths are present in the assembly this time.)
--
Michel Fortin
michel.for...@michelf.ca
http://michelf.ca
Re: Should we deprecate comma?
On 2014-03-24 00:04, Andrei Alexandrescu wrote: On 3/23/14, 8:22 PM, Etienne Cimon wrote: How about allowing it only inside parenthesis? That works but breaks more valid code. -- Andrei If the comma expression operator is outlawed on the global scope, variadic template parameters could be used with commas outside the parantheses which allows such syntax: if(pMgr->ShouldRecordEvent(eSE_Weapon), pOwnerRaw) // ERROR return pMgr->RecordEvent(eSE_Weapon), pOwnerRaw; // ERROR if(e!pMgr->ShouldRecordEvent(eSE_Weapon), pOwnerRaw) // OK return e!pMgr->RecordEvent(eSE_Weapon), pOwnerRaw; // OK Would it make sense to reserve the global e identifier for expressions? I'd be happy to see commas go and eventually wake up to this in a few years, also enabling what would seem like a new kind of comma operator overloading
Re: Should we deprecate comma?
Brian Schott: http://d.puremagic.com/issues/show_bug.cgi?id=953 This is off-topic in this thread. But I think just disallowing mixed C/D declarations is a step forward: http://d.puremagic.com/issues/show_bug.cgi?id=5807 I mean code like: int[] a[]; Bye, bearophile
Re: Should we deprecate comma?
On 3/23/14, 8:58 PM, Brian Schott wrote: On Sunday, 23 March 2014 at 20:56:45 UTC, Andrei Alexandrescu wrote: Discuss: https://github.com/D-Programming-Language/dmd/pull/3399 Andrei If we kill this, it should be killed properly. I fear that we'll end up with some sort of half-dead zombie syntax like C-style array declarations. http://d.puremagic.com/issues/show_bug.cgi?id=953 The comparison doesn't hold. -- Andrei
Re: Should we deprecate comma?
On 3/23/14, 8:22 PM, Etienne Cimon wrote: How about allowing it only inside parenthesis? That works but breaks more valid code. -- Andrei
Re: Should we deprecate comma?
On 3/23/14, 8:30 PM, bearophile wrote: How is this more limited change affecting possible future syntax usage of commas for tuples? :-) The change has an eye to that. Disallowing the use of the return value offers us the future possibility of redefining it. -- Andrei
Re: Challenge: write a really really small front() for UTF8
On 3/23/14, 8:36 PM, safety0ff wrote: On Sunday, 23 March 2014 at 21:23:18 UTC, Andrei Alexandrescu wrote: Here's a baseline: http://goo.gl/91vIGc. Destroy! Andrei Here's my attempt: http://goo.gl/alJ9JS I interpreted the challenge slightly differently, I went for fewer lines of code and fewer branches. I verified the output for all valid inputs. Very interesting! -- Andrei
Re: Should we deprecate comma?
On Sunday, 23 March 2014 at 20:56:45 UTC, Andrei Alexandrescu wrote: Discuss: https://github.com/D-Programming-Language/dmd/pull/3399 Andrei If we kill this, it should be killed properly. I fear that we'll end up with some sort of half-dead zombie syntax like C-style array declarations. http://d.puremagic.com/issues/show_bug.cgi?id=953
A division problem
This kind of code sometimes is wrong, because you forget to cast
x to double before the division and you lose precision (but here
the compiler knows that the result of the division will go inside
a double):
void main() {
int x = 15;
double y = x / 10;
}
The cause is that unfortunately in D the integer division uses
the same operator as the FP division. In Python there is the /
and // operators. In OcaML there are the / and /., in Delphi
there are the / and div operators, in Ada the two operands need
to be of the same type.
Seasoned C/C++/D programmers watch for the types every time they
perform a division, to avoid that trap. But less experienced
programmers introduce bugs with divisions. Can D help the
programmer reduce the frequency of similar bugs? And do we want
to?
Bye,
bearophile
Re: Challenge: write a really really small front() for UTF8
On Sunday, 23 March 2014 at 21:23:18 UTC, Andrei Alexandrescu wrote: Here's a baseline: http://goo.gl/91vIGc. Destroy! Andrei Here's my attempt: http://goo.gl/alJ9JS I interpreted the challenge slightly differently, I went for fewer lines of code and fewer branches. I verified the output for all valid inputs.
Re: Should we deprecate comma?
Andrei Alexandrescu:
Yes, can't find it now. It was something like:
foreach (e; chain(iota('a', 'я')), iota('A', 'Я')) {
...
}
Then if all or most comma-related bugs are caught with a more
limited language change, then it's an interesting thing to know.
Minimizing change impact is often positive.
How is this more limited change affecting possible future syntax
usage of commas for tuples? :-)
Bye,
bearophile
Re: Should we deprecate comma?
On Monday, 24 March 2014 at 03:09:46 UTC, Andrei Alexandrescu wrote: That was in Phobos too. Fix: Same misunderstanding all over again. Please understand that breaking code is the worst thing. (yes, I'm quoting you back from a future message, but my point is that the compromise breaks code just like the full-blown deprecation, while leaving very little value behind.) There are of course other ways, too, including defining a function that returns its last argument. Actually, that won't work. Since assert(0) returns void, it is not a valid function parameter. But it could also be rewritten as a switch statement. So if the code is broken, one way or another we'd have to change that pattern but it is doable, so not the end of the world.
Re: Should we deprecate comma?
On 2014-03-23 22:31, Andrei Alexandrescu wrote:
On 3/23/14, 7:21 PM, Kenji Hara wrote:
At least I can imagine two reasonable cases.
1. If the code is ported from C/C++, breaking it is not reasonable.
2. If the two expressions are strongly related, using comma operator is
reasonable to represent the intensity. I think rather it's an *ability*
to represent code meaning by using code style.
Kenji Hara
One concession we could make would be to disallow using the result of
the operator. That might actually catch all bugs discussed herein.
if (condition) ++i, ++j; // fine
foreach (e; exp1, exp2) {} // ERROR
if(pMgr->ShouldRecordEvent(eSE_Weapon), pOwnerRaw) // ERROR
return pMgr->RecordEvent(eSE_Weapon), pOwnerRaw; // ERROR
I think this would be a compromise worth looking into.
Andrei
How about allowing it only inside parenthesis?
e.g.
if(pMgr->ShouldRecordEvent(eSE_Weapon), pOwnerRaw) // ERROR
return pMgr->RecordEvent(eSE_Weapon), pOwnerRaw; // ERROR
if((pMgr->ShouldRecordEvent(eSE_Weapon), pOwnerRaw)) // OK
return (pMgr->RecordEvent(eSE_Weapon), pOwnerRaw); // OK
Re: Should we deprecate comma?
On Monday, 24 March 2014 at 03:10:23 UTC, Andrei Alexandrescu wrote: On 3/23/14, 7:54 PM, Asman01 wrote: if(condition) x = 2, y = 3; // fine if(condition) f(),x=3; // ERRROR What do you think? Too quirky -- Andrei True. I don't want to make a kind of C++
Re: Should we deprecate comma?
On 3/23/14, 8:12 PM, bearophile wrote:
Andrei Alexandrescu:
2. The fraction we'd disallow contains virtually all bugs that were
discussed (in addition of course to legitimate cases)
Including the actual bug found in Phobos? I can't find it now...
Yes, can't find it now. It was something like:
foreach (e; chain(iota('a', 'я')), iota('A', 'Я') {
...
}
Andrei
Re: Should we deprecate comma?
On 3/23/14, 8:12 PM, bearophile wrote:
Andrei Alexandrescu:
2. The fraction we'd disallow contains virtually all bugs that were
discussed (in addition of course to legitimate cases)
Including the actual bug found in Phobos? I can't find it now...
Yes, can't find it now. It was something like:
foreach (e; chain(iota('a', 'я')), iota('A', 'Я')) {
...
}
Andrei
Re: Should we deprecate comma?
Andrei Alexandrescu: 2. The fraction we'd disallow contains virtually all bugs that were discussed (in addition of course to legitimate cases) Including the actual bug found in Phobos? I can't find it now... Bye, bearophile
Re: Should we deprecate comma?
On 3/23/14, 8:04 PM, Adam D. Ruppe wrote:
But still, if we make this change at all, I see no reason to keep if(a)
b, c; given the extreme rarity of that case and the ease with which i
can be replaced with if(a) { b; c; }
Same misunderstanding all over again. Please understand that breaking
code is the worst thing. Arguing that the breakage is easy to fix
doesn't help that most important part.
Andrei
Re: Should we deprecate comma?
On 3/23/14, 7:54 PM, Asman01 wrote: if(condition) x = 2, y = 3; // fine if(condition) f(),x=3; // ERRROR What do you think? Too quirky -- Andrei
Re: Should we deprecate comma?
On 3/23/14, 7:50 PM, Adam D. Ruppe wrote:
int a = something == 1 ? 1
: something == 2 ? 2
: (assert(0), 0);
That was in Phobos too. Fix:
int a = something == 1 ? 1
: something == 2 ? 2
: { assert(0); return 0; }();
There are of course other ways, too, including defining a function that
returns its last argument.
Andrei
Re: Should we deprecate comma?
On 3/23/14, 7:50 PM, Adam D. Ruppe wrote: On Monday, 24 March 2014 at 02:31:46 UTC, Andrei Alexandrescu wrote: One concession we could make would be to disallow using the result of the operator. That might actually catch all bugs discussed herein. If we go that far, we might as well just kill the whole thing, since half* the reason of using an expression in the first place is to use the result. 1. I don't think that's half at all. 2. The fraction we'd disallow contains virtually all bugs that were discussed (in addition of course to legitimate cases) Andrei
Re: inlining...
Maybe we could have both declare site inlining and call site inlining. with declare site, what we mean is that this function's body is used so commonly that we make it into a function only because we don't want duplicate code, not because it should be a standalone function. with call site inlining, one can inline thirdparty functions which is not declared inline. I think the `inline` Manu suggested should not be viewed as a mere optimization thing, but more like a code generation utility which happens to be faster. In this point of view, this kind of `inline` should be controlled by the coder, not the compiler. To make it clear that we are not talking about optimization, maybe we should call it another name, like 'mixin function'? BTW, the Kotlin language recently get a new released, which added support for declare site force inline, the team argues its necessity here: http://blog.jetbrains.com/kotlin/2014/03/m7-release-available/#more-1439 in the comments: It’s traditional to think about inlining as a mere optimization, but this dates back to the times >when software was shipped as one huge binary file. Why we think inline should be a language feature: 1. Other language features (to be implemented soon) depend on it. Namely, non-local returns >and type-dependent functions. Basically, inline functions are very restricted macros, and this is definitely a language feature. 2. Due to dynamic linking and binary compatibility issues it can not be up to the compiler >whether to inline something or not on the JVM: if bodies of inline functions change, all >dependent code should be recompiled, i.e. it’s the library author’s liability to preserve >functionality, so such functions must be explicitly marked. On Thursday, 20 March 2014 at 02:08:16 UTC, Manu wrote: On 20 March 2014 06:23, <7d89a89974b0ff40.invalid@internationalized.invalid>wrote: On Wednesday, 19 March 2014 at 12:35:30 UTC, Manu wrote: Okay, do you have use cases for any of this stuff? Are you just making it up, or do you have significant experience to say this is what you need? I don't need anything, I hand optimize prematurely. And I don't want to do that. But yes, inner loops benefits from exhaustive inlining because you get to move common expressions out of the loop or change them to delta increments. It is only when you trash the caches that inlining does not pay off. I do it by hand. I don't want to do it by hand. If you ask me, I have no value in recursive inlining, infact, that would anger me considerably. Why? You could always set the depth to 1, or make 1 the default. And it isn't difficult to implement. The problem is upside down. If you want to inline multiple levels, you start from the leaves and move downwards, not from the root moving upwards (leaving a bunch of leaves perhaps not inlined), which is what you're really suggesting. Inlining should be strictly deliberate, there's nothing to say that every function called in a tree should be inlined. There's a high probability there's one/some that shouldn't be among a few that should. Remember too, that call-site inlining isn't the only method, there would also be always-inline. I think always-inline is what you want for some decidedly trivial functions (although these will probably be heuristically inlined anyway), not call-site inlining. I just don't see how recursive call-site inlining is appropriate, considering that call trees are often complex, subject to change, and may even call functions that you don't have source for. You can cascade the mixin keyword if you want to, that's very simple. I'd be highly surprised if you ever encountered a call tree where you wanted to inline everything (and the optimiser didn't do it for you). As soon as you encounter a single function in the tree that shouldn't be inlined, then you'll be forced to do it one level at a time anyway.
Re: Should we deprecate comma?
On 3/23/14, 7:45 PM, Daniel Murphy wrote:
"Andrei Alexandrescu" wrote in message
news:lgo5ei$1tne$1...@digitalmars.com...
One concession we could make would be to disallow using the result of
the operator. That might actually catch all bugs discussed herein.
if (condition) ++i, ++j; // fine
foreach (e; exp1, exp2) {} // ERROR
if(pMgr->ShouldRecordEvent(eSE_Weapon), pOwnerRaw) // ERROR
return pMgr->RecordEvent(eSE_Weapon), pOwnerRaw; // ERROR
I think this would be a compromise worth looking into.
I could live with that, although I'd still rather see it die.
Boil the frog slowly. -- Andrei
Re: Should we deprecate comma?
On Monday, 24 March 2014 at 02:50:18 UTC, Adam D. Ruppe wrote:
(and is also the most likely place where it was used
unintentionally).
Actually, this is overreaching, the if(function(call), misplaced)
is probably the most likely place it is used unintentionally.
But still, if we make this change at all, I see no reason to keep
if(a) b, c; given the extreme rarity of that case and the ease
with which i can be replaced with if(a) { b; c; }
I'd prefer to remove it entirely over keeping this compromise.
Re: Should we deprecate comma?
From what I see on Wikipedia(http://en.wikipedia.org/wiki/Comma_operator) Go language has no comma operator.
Re: Should we deprecate comma?
On Monday, 24 March 2014 at 02:31:46 UTC, Andrei Alexandrescu
wrote:
On 3/23/14, 7:21 PM, Kenji Hara wrote:
At least I can imagine two reasonable cases.
1. If the code is ported from C/C++, breaking it is not
reasonable.
2. If the two expressions are strongly related, using comma
operator is
reasonable to represent the intensity. I think rather it's an
*ability*
to represent code meaning by using code style.
Kenji Hara
One concession we could make would be to disallow using the
result of the operator. That might actually catch all bugs
discussed herein.
if (condition) ++i, ++j; // fine
foreach (e; exp1, exp2) {} // ERROR
if(pMgr->ShouldRecordEvent(eSE_Weapon), pOwnerRaw) // ERROR
return pMgr->RecordEvent(eSE_Weapon), pOwnerRaw; // ERROR
I think this would be a compromise worth looking into.
Andrei
I could live with that too but I suggest to extend if(condition)
to allow assignment too:
if(condition) x = 2, y = 3; // fine
if(condition) f(),x=3; // ERRROR
What do you think?
Re: Should we deprecate comma?
On Monday, 24 March 2014 at 02:31:46 UTC, Andrei Alexandrescu
wrote:
One concession we could make would be to disallow using the
result of the operator. That might actually catch all bugs
discussed herein.
If we go that far, we might as well just kill the whole thing,
since half* the reason of using an expression in the first place
is to use the result. Otherwise, you might as well use a
statement.
if (condition) ++i, ++j; // might as well be { ++i; ++j; }
* The other half of the uses being where you want a statement,
but the grammar won't allow it... but even in those cases, the
ONLY time I can think of where this is the case AND you don't
need the result is the increment expression of the for loop.
So with that compromise, it is equivalent to banning the comma
expression except in the special case of the for loop and in code
that has no real reason to use it in the first place (and is also
the most likely place where it was used unintentionally).
** Concrete example of where I (/very/ rarely apparently)
consciously use the comma operator:
int a = something == 1 ? 1
: something == 2 ? 2
: (assert(0), 0);
There, I want the assert(0) to trigger in the default case, but
the ternary operator still needs a value to assign to the
variable a, so the ,0 provides that. Never actually used, but
required for the common type of the ternary to match up.
Re: Should we deprecate comma?
"Andrei Alexandrescu" wrote in message
news:lgo5ei$1tne$1...@digitalmars.com...
One concession we could make would be to disallow using the result of the
operator. That might actually catch all bugs discussed herein.
if (condition) ++i, ++j; // fine
foreach (e; exp1, exp2) {} // ERROR
if(pMgr->ShouldRecordEvent(eSE_Weapon), pOwnerRaw) // ERROR
return pMgr->RecordEvent(eSE_Weapon), pOwnerRaw; // ERROR
I think this would be a compromise worth looking into.
I could live with that, although I'd still rather see it die.
Re: Should we deprecate comma?
On Monday, 24 March 2014 at 02:31:46 UTC, Andrei Alexandrescu
wrote:
One concession we could make would be to disallow using the
result of the operator. That might actually catch all bugs
discussed herein.
if (condition) ++i, ++j; // fine
foreach (e; exp1, exp2) {} // ERROR
if(pMgr->ShouldRecordEvent(eSE_Weapon), pOwnerRaw) // ERROR
return pMgr->RecordEvent(eSE_Weapon), pOwnerRaw; // ERROR
I think this would be a compromise worth looking into.
Andrei
That's a good idea. I never personally use the comma operator, as
I think that it makes code less readable having multiple
expressions evaluated on a single line. For the same reason, I
almost never put multiple semicolon-delimited statements on the
same line. Code like the above I find particularly egregious. It
plays havoc with the programmer's expectation that they can parse
the code left-to-right to figure out the result of an expression,
forcing them to read in spirals. This is just as bad as the
pointer declaration syntax for C/C++, just not as common.
Re: Should we deprecate comma?
On Monday, 24 March 2014 at 02:21:20 UTC, Kenji Hara wrote:
2014-03-24 10:38 GMT+09:00 Daniel Murphy
:
"Kenji Hara" wrote in message
news:mailman.27.1395624482.25518.digitalmar...@puremagic.com...
2014-03-24 10:09 GMT+09:00 bearophile
:
if (cond) exp1, exp2; // in most case, this is not a
bug.
It's not a bug, but this does the same thing - so why use the
comma
operator?
if (cond) { exp1; exp2; }
It catches bugs that are otherwise very difficult to spot.
At least I can imagine two reasonable cases.
1. If the code is ported from C/C++, breaking it is not
reasonable.
Kenji Hara
What about the compiler make some effort to detect this usage and
suggests the appropriated solution? just like it does when using
C's array/cast style. i.e., split the expression separed by the
comma operator in a list of expressions separed by semicolon
inside a compund statement. It isn't too hard to implement.
Re: Should we deprecate comma?
On Monday, 24 March 2014 at 02:12:20 UTC, Adam D. Ruppe wrote: On Monday, 24 March 2014 at 01:48:15 UTC, Daniel Murphy wrote: Try it on your code, you might be surprised! hmm, I am surprised about one thing: it didn't detect a single use of the comma operator in the ~10,000 lines of my code I fed it. I know I don't use it often, but I thought surely there'd be at least one or two uses in all that! I think I've never used this. Seriously. Not even in PHP. To me it always a horrible thing.
Re: Should we deprecate comma?
On 3/23/14, 7:21 PM, Kenji Hara wrote:
At least I can imagine two reasonable cases.
1. If the code is ported from C/C++, breaking it is not reasonable.
2. If the two expressions are strongly related, using comma operator is
reasonable to represent the intensity. I think rather it's an *ability*
to represent code meaning by using code style.
Kenji Hara
One concession we could make would be to disallow using the result of
the operator. That might actually catch all bugs discussed herein.
if (condition) ++i, ++j; // fine
foreach (e; exp1, exp2) {} // ERROR
if(pMgr->ShouldRecordEvent(eSE_Weapon), pOwnerRaw) // ERROR
return pMgr->RecordEvent(eSE_Weapon), pOwnerRaw; // ERROR
I think this would be a compromise worth looking into.
Andrei
Re: Should we deprecate comma?
Here's another. https://d.puremagic.com/issues/show_bug.cgi?id=2659 Also, kill it with fire. I do use it, but only in incomprehensible C++ algorithm competitions, where it saves a few strokes. Everywhere else it has only been a nasty surprise.
Re: Should we deprecate comma?
if (cond) exp1, exp2; // in most case, this is not a bug.
So, completely removing comma operator will cause negative
affect in
some cases.
Kenji Hara
In this case you should use { exp1; exp2; } There's two
expressions, so same number of ';' should appear and it make code
more clean. I know it's personal. It's just IMHO.
Re: Should we deprecate comma?
On Monday, 24 March 2014 at 01:36:46 UTC, bearophile wrote: C code should not silently behave differently in D, even five years from now, so I am not interested in using the C comma syntax for D tuples. I am OK with a D tuple syntax that is not allowed in C. It won't silently break. I concede it will break.
Re: Challenge: write a really really small front() for UTF8
On 3/23/14, 6:53 PM, Michel Fortin wrote:
On 2014-03-23 21:22:58 +, Andrei Alexandrescu
said:
Here's a baseline: http://goo.gl/91vIGc. Destroy!
Optimizing for smallest assembly size:
dchar front(char[] s)
{
size_t bytesize;
dchar result;
switch (s[0])
{
case 0b: .. case 0b0111:
return s[0];
case 0b1100: .. case 0b1101:
return ((s[0] & 0b0001) << 6) | (s[1] & 0b0001);
case 0b1110: .. case 0b1110:
result = s[0] & 0b;
bytesize = 3;
break;
case 0b: .. case 0b0111:
result = s[0] & 0b0111;
bytesize = 4;
default:
return dchar.init;
}
foreach (i; 1..bytesize)
result = (result << 6) | (s[i] & 0b0011);
return result;
}
Nice, thanks! I'd hope for a short path for the ASCII subset, could you
achieve that?
Andrei
Re: Should we deprecate comma?
2014-03-24 10:38 GMT+09:00 Daniel Murphy :
> "Kenji Hara" wrote in message
> news:mailman.27.1395624482.25518.digitalmar...@puremagic.com...
>
> 2014-03-24 10:09 GMT+09:00 bearophile :
>
> if (cond) exp1, exp2; // in most case, this is not a bug.
>>
>
> It's not a bug, but this does the same thing - so why use the comma
> operator?
>
> if (cond) { exp1; exp2; }
>
> It catches bugs that are otherwise very difficult to spot.
>
At least I can imagine two reasonable cases.
1. If the code is ported from C/C++, breaking it is not reasonable.
2. If the two expressions are strongly related, using comma operator is
reasonable to represent the intensity. I think rather it's an *ability* to
represent code meaning by using code style.
Kenji Hara
Re: Should we deprecate comma?
On Monday, 24 March 2014 at 01:48:15 UTC, Daniel Murphy wrote: Try it on your code, you might be surprised! hmm, I am surprised about one thing: it didn't detect a single use of the comma operator in the ~10,000 lines of my code I fed it. I know I don't use it often, but I thought surely there'd be at least one or two uses in all that! I'd compile my whole everything, but apparently I need to get git druntime* and phobos too for that to actually work (or patch my other dmd without getting the other changes) and meh, I don't care that much. I guess it being even more rare than I thought moves me a bit more into "meh" territory though.
Re: Should we deprecate comma?
On Monday, 24 March 2014 at 01:16:47 UTC, Andrei Alexandrescu wrote: On 3/23/14, 6:09 PM, bearophile wrote: Andrei Alexandrescu: Discuss: https://github.com/D-Programming-Language/dmd/pull/3399 Are you going to listen to people in this thread or are just going to say that people in the newsgroup are not representative of the whole community of D users? Argumentum ad populum has low pull on me. Come with good arguments, not "half a dozen people can't be wrong". It is understood, but this has been discussed to death, and yourself agreed in the past that this was to be done. The topic has been recurrent for 5 years. It could have been through the deprecation process several time by now. Points goes as follow : - This construct has little usefulness. - It create hard to debug bugs (if you switch , and ; in typo for instance). - It prevents moving forward with tuples/multiple returns value with a nice syntax. - Most people hate it. Why is that we need to either cast thing in stone or change by breaking everything Atila style ? The more we wait, the greater the pain.
Re: Challenge: write a really really small front() for UTF8
On 2014-03-23 22:58:32 +, Andrei Alexandrescu
said:
Array bounds checking takes care of that.
If you want the smallest assembly size with array bound checking, make
the function @safe and see the disaster it causes to the assembly size.
That's what you have to optimize. If you're going to optimize while
looking at the assembly, better check for bounds manually:
dchar front(char[] s)
{
if (s.length < 1) return dchar.init;
size_t bytesize;
dchar result;
switch (s[0])
{
case 0b: .. case 0b0111:
return s[0];
case 0b1100: .. case 0b1101:
result = s[0] & 0b0001;
bytesize = 2;
break;
case 0b1110: .. case 0b1110:
result = s[0] & 0b;
bytesize = 3;
break;
case 0b: .. case 0b0111:
result = s[0] & 0b0111;
bytesize = 4;
default:
return dchar.init;
}
if (s.length < bytesize) return dchar.init;
foreach (i; 1..bytesize)
result = (result << 6) | (s[i] & 0b0011);
return result;
}
--
Michel Fortin
michel.for...@michelf.ca
http://michelf.ca
Re: Challenge: write a really really small front() for UTF8
On 2014-03-23 21:22:58 +, Andrei Alexandrescu
said:
Here's a baseline: http://goo.gl/91vIGc. Destroy!
Optimizing for smallest assembly size:
dchar front(char[] s)
{
size_t bytesize;
dchar result;
switch (s[0])
{
case 0b: .. case 0b0111:
return s[0];
case 0b1100: .. case 0b1101:
return ((s[0] & 0b0001) << 6) | (s[1] & 0b0001);
case 0b1110: .. case 0b1110:
result = s[0] & 0b;
bytesize = 3;
break;
case 0b: .. case 0b0111:
result = s[0] & 0b0111;
bytesize = 4;
default:
return dchar.init;
}
foreach (i; 1..bytesize)
result = (result << 6) | (s[i] & 0b0011);
return result;
}
--
Michel Fortin
michel.for...@michelf.ca
http://michelf.ca
Re: Should we deprecate comma?
"Adam D. Ruppe" wrote in message news:cchwhwpquenzkbuaf...@forum.dlang.org... My vote is no, though I don't feel strongly about it since I can still get work done either way; there's alternatives to the comma operator in every case I can think of in D. But I just don't see any compelling reason to make the change. The compelling reason is it catches bugs. Try it on your code, you might be surprised!
Re: Should we deprecate comma?
Kenji Hara:
1. I think removing comma operator does not have useful effect
for tuple syntax discussion.
I agree, see my recent answer to Andrei.
2. Indeed in some case comma operator is bug-prone, but if it
is used directly on the ExpStatement, it's still useful to me.
foreach (e; exp1, exp2) {} // maybe bug?
If I see a foreach like that, I refactor the code to remove the
comma. Apparently I am not very good at keeping the semantics of
the comma operator in my head, so I prefer to kill them in the
code I work on.
Bye,
bearophile
Re: Should we deprecate comma?
My vote is no, though I don't feel strongly about it since I can still get work done either way; there's alternatives to the comma operator in every case I can think of in D. But I just don't see any compelling reason to make the change. I don't find the tuple arguments convincing and the comma operator has not been a noteworthy source of bugs in my experience. The new tuple syntax need to outcompete the simple tuple() or TypeTuple!() possibilities we have today, and personally, I don't think they tuple proposals even stand on their own, much less outcompete the status quo. So again, my position is no, leaning toward meh whatever.
Re: Should we deprecate comma?
Andrei Alexandrescu: And by the way the irony here is that you seem to ignore my argument. Yes, sorry, politics is not for me. Better to go back discussing technical matters. Some examples of what you're trying to achieve would be great,< Tuples are simple entities, so in past threads I have given examples of all my usages cases. If you want I can copy them again here (usage examples don't ask for a specific syntax, they are just about the desired semantics). with the understanding that you're looking at at least five years until we'd be able to change anything about the use of comma.< C code should not silently behave differently in D, even five years from now, so I am not interested in using the C comma syntax for D tuples. I am OK with a D tuple syntax that is not allowed in C. I want to remove comma operators from D to avoid bugs and to make D code more readable. For me those are very important things, more important than the little code breaking it causes. Bye, bearophile
Re: Should we deprecate comma?
"Kenji Hara" wrote in message
news:mailman.27.1395624482.25518.digitalmar...@puremagic.com...
2014-03-24 10:09 GMT+09:00 bearophile :
if (cond) exp1, exp2; // in most case, this is not a bug.
It's not a bug, but this does the same thing - so why use the comma
operator?
if (cond) { exp1; exp2; }
It catches bugs that are otherwise very difficult to spot.
Re: Should we deprecate comma?
2014-03-24 10:09 GMT+09:00 bearophile :
> Andrei Alexandrescu:
>
> Discuss: https://github.com/D-Programming-Language/dmd/pull/3399
>>
>
> Regarding the "progress", I'd like a good built-in syntax to unpack tuples
> in assignments, inside function signatures, in foreach statements, and
> more, because the syntactic contortions I currently adopt to use tuples in
> D are bad.
>
I'm partially against to it.
1. I think removing comma operator does not have useful effect for tuple
syntax discussion. For example:
1a. If you want to use parenthesis syntax (...) for tuple, we should
resolve one-element tuple ambiguity first.
(exp) // one-element tuple, or just an expression ?
And, removing comma operator does not resolve this issue.
1b. If you choose other syntax for tuple, comma operator will be no
longer related to tuple syntax discussion.
{exp, exp2} // eg. using brace for tuple syntax no longer touch to
comma operator
2. Indeed in some case comma operator is bug-prone, but if it is used
directly on the ExpStatement, it's still useful to me.
foreach (e; exp1, exp2) {} // maybe bug?
if (cond) exp1, exp2; // in most case, this is not a bug.
So, completely removing comma operator will cause negative affect in
some cases.
Kenji Hara
Re: Should we deprecate comma?
On 3/23/14, 6:09 PM, bearophile wrote: Andrei Alexandrescu: Discuss: https://github.com/D-Programming-Language/dmd/pull/3399 Are you going to listen to people in this thread or are just going to say that people in the newsgroup are not representative of the whole community of D users? Argumentum ad populum has low pull on me. Come with good arguments, not "half a dozen people can't be wrong". Regarding the "progress", I'd like a good built-in syntax to unpack tuples in assignments, inside function signatures, in foreach statements, and more, because the syntactic contortions I currently adopt to use tuples in D are bad. Some examples of what you're trying to achieve would be great, with the understanding that you're looking at at least five years until we'd be able to change anything about the use of comma. Andrei
Re: Should we deprecate comma?
Andrei Alexandrescu: The extent of the breakage is NOT among the top factors. Once a piece of code goes from "compiles" to "doesn't compile" that lowers the acceptance level by an order of magnitude. Only after that, the extent of the breakage has any import. Are you going to ignore the voices in this thread? If that's true, what's the point of asking to the newsgroup? Perhaps just to collect few people that agree with you, to show you are listening? Bye, bearophile
Re: Should we deprecate comma?
On 3/23/14, 6:18 PM, bearophile wrote: Andrei Alexandrescu: The extent of the breakage is NOT among the top factors. Once a piece of code goes from "compiles" to "doesn't compile" that lowers the acceptance level by an order of magnitude. Only after that, the extent of the breakage has any import. Are you going to ignore the voices in this thread? If that's true, what's the point of asking to the newsgroup? Perhaps just to collect few people that agree with you, to show you are listening? And by the way the irony here is that you seem to ignore my argument. Andrei
Re: Should we deprecate comma?
On 3/23/14, 6:18 PM, bearophile wrote: Andrei Alexandrescu: The extent of the breakage is NOT among the top factors. Once a piece of code goes from "compiles" to "doesn't compile" that lowers the acceptance level by an order of magnitude. Only after that, the extent of the breakage has any import. Are you going to ignore the voices in this thread? I'm not going to ignore good argument made by the voices in this thread. -- Andrei
Re: Should we deprecate comma?
Andrei Alexandrescu: Discuss: https://github.com/D-Programming-Language/dmd/pull/3399 Are you going to listen to people in this thread or are just going to say that people in the newsgroup are not representative of the whole community of D users? Regarding the "progress", I'd like a good built-in syntax to unpack tuples in assignments, inside function signatures, in foreach statements, and more, because the syntactic contortions I currently adopt to use tuples in D are bad. Bye, bearophile
Re: Should we deprecate comma?
On 3/23/14, 5:41 PM, Meta wrote: On Sunday, 23 March 2014 at 20:56:45 UTC, Andrei Alexandrescu wrote: Discuss: https://github.com/D-Programming-Language/dmd/pull/3399 Andrei You mentioned on the Github PR that this broke some Phobos (and Druntime?) code. What was the extent of the breakage? If it's small, I'd say give it a year-long deprecation period and then be done with it forever. The extent of the breakage is NOT among the top factors. Once a piece of code goes from "compiles" to "doesn't compile" that lowers the acceptance level by an order of magnitude. Only after that, the extent of the breakage has any import. Top factors: 0. Any silent breakages or changes in semantics? 1x 1. How frequent is the breakage? Is most code going to still work? 100x 2. How much does fixing the breakage improve code? Was the breaking code incorrect for the most part? 100x Andrei
Re: Improve D's syntax to make it more python like
On 3/23/14, 9:36, Marco Leise wrote: Am Sun, 23 Mar 2014 08:09:03 -0500 schrieb 1100110 <0b1100...@gmail.com>: A "stickied" post on the announce forum would work. stickied ... in a NNTP news group ... :) Haha, I just meant bump it so that it stays active. There's a reason I used quotes! =P
Re: Should we deprecate comma?
On Sunday, 23 March 2014 at 20:56:45 UTC, Andrei Alexandrescu wrote: Discuss: https://github.com/D-Programming-Language/dmd/pull/3399 Andrei You mentioned on the Github PR that this broke some Phobos (and Druntime?) code. What was the extent of the breakage? If it's small, I'd say give it a year-long deprecation period and then be done with it forever.
Re: Challenge: write a really really small front() for UTF8
On 3/23/2014 5:32 PM, Mike wrote: This example only considers encodings of up to 4 bytes, but UTF-8 can encode code points in as many as 6 bytes. Is that not a concern? It's not anymore. The 5 and 6 byte encodings are now illegal.
Re: Challenge: write a really really small front() for UTF8
On 2014-03-24 00:32, Mike wrote: On Sunday, 23 March 2014 at 21:23:18 UTC, Andrei Alexandrescu wrote: Here's a baseline: http://goo.gl/91vIGc. Destroy! Andrei This example only considers encodings of up to 4 bytes, but UTF-8 can encode code points in as many as 6 bytes. Is that not a concern? Mike RFC 3629 (http://tools.ietf.org/html/rfc3629) restricted UTF-8 to conform to constraints in UTF-16, removing all 5- and 6-byte sequences. -- Simen
Re: Should we deprecate comma?
On 2014-03-23 20:56, Andrei Alexandrescu wrote: Discuss: https://github.com/D-Programming-Language/dmd/pull/3399 Andrei I'd shed no tears if the comma operator were gone. -- Simen
Re: Challenge: write a really really small front() for UTF8
On Sunday, 23 March 2014 at 21:23:18 UTC, Andrei Alexandrescu wrote: Here's a baseline: http://goo.gl/91vIGc. Destroy! Andrei This example only considers encodings of up to 4 bytes, but UTF-8 can encode code points in as many as 6 bytes. Is that not a concern? Mike
Re: Challenge: write a really really small front() for UTF8
On 3/23/14, 4:28 PM, Anonymous wrote:
dchar front(char[] s) {
uint c = s[0];
ubyte p = ~s[0];
if (p>>7)
return c;
c = c<<8 | s[1];
if (p>>5)
return c;
c = c<<8 | s[2];
if (p>>4)
return c;
return c<<8 | s[3];
}
That's smaller but doesn't seem to do the same!
Andrei
Re: Should we deprecate comma?
Am 23.03.2014 22:08, schrieb Asman01: On Sunday, 23 March 2014 at 20:56:45 UTC, Andrei Alexandrescu wrote: Discuss: https://github.com/D-Programming-Language/dmd/pull/3399 Andrei Then things like this c = f(),b*c; became invalid? if so, yes. I did a lot of C and never found this useful just unlike. Interesting interview questions. :)
Re: Challenge: write a really really small front() for UTF8
dchar front(char[] s) {
uint c = s[0];
ubyte p = ~s[0];
if (p>>7)
return c;
c = c<<8 | s[1];
if (p>>5)
return c;
c = c<<8 | s[2];
if (p>>4)
return c;
return c<<8 | s[3];
}
Re: Should we deprecate comma?
On Sunday, 23 March 2014 at 20:56:45 UTC, Andrei Alexandrescu wrote: Should we deprecate comma? Yes, please.
Re: Walter's DConf 2014 Talks - Topics in Finance
On 3/23/2014 12:42 PM, Russel Winder wrote: On Sun, 2014-03-23 at 10:35 -0700, Walter Bright wrote: On 3/23/2014 12:13 AM, Russel Winder wrote: But for real time you would just have to remove the GC completely to have the needed guarantees. malloc/free cannot be used in hard real time systems, either. malloc/free do not have latency guarantees. By estimating the resource needs and preallocating a freelist, you can get round this issue. C++ is quite good at supporting this sort of stuff. Yes, and you can do that in D, the same way.
Re: Walter's DConf 2014 Talks - Topics in Finance
Am 23.03.2014 22:04, schrieb Nick Sabalausky: On 3/22/2014 9:47 AM, Paulo Pinto wrote: Assuming those 10% still happen if the test was done today as suggested, how much are trade companies willing to pay for developers to achieve those 10% in C++ vs having a system although 10% slower, still fast enough for operations while saving salaries for more cheaper developers? If the domain is high-performance, high-volume, (hard|soft) realtime, then I doubt very much you can get away with significantly cheaper developers, even if it is Java. Unless it just happens to be a sub-par company with a questionable future. My question was precisely because I tend to see that a lot in general, as on my area saving project costs seems to be more valuable than quality. -- Paulo
Re: Should we deprecate comma?
Kill it with fire. It has no purpose in D.
Re: Challenge: write a really really small front() for UTF8
On 3/23/14, 3:10 PM, Dmitry Olshansky wrote: 24-Mar-2014 01:34, Andrei Alexandrescu пишет: On 3/23/14, 2:29 PM, Dmitry Olshansky wrote: 24-Mar-2014 01:22, Andrei Alexandrescu пишет: Here's a baseline: http://goo.gl/91vIGc. Destroy! Assertions to check encoding?! I thought it would detect broken encoding and do a substitution at least. That implementation does zero effort to optimize checks themselves, and indeed puts them in asserts. I think there's value in having such a primitive down below. Just how much you are willing to assert? You don't even check length. Array bounds checking takes care of that. In short - what are the specs of this primitive and where you see it being used. A replacement for front() in arrays of char and wchar. Andrei
add byCodeunit, byChar, byWchar and byDchar to std.utf
We've talked about adding these algorithms at length here in the n.g., so here they are. https://github.com/D-Programming-Language/phobos/pull/2043 They're intended as 'adapter' style algorithms. The .byCodeunit is intended as "by gum, I don't want auto-decode". byCodeunit was suggested earlier in the n.g., I don't recall who (speak up!).
Re: Should we deprecate comma?
Andrei Alexandrescu: Discuss: https://github.com/D-Programming-Language/dmd/pull/3399 +1. Bye, bearophile
Re: Should we deprecate comma?
On 3/23/14, Andrei Alexandrescu wrote: > Discuss: https://github.com/D-Programming-Language/dmd/pull/3399 Some previous discussions: comma operator causes hard to spot bugs http://forum.dlang.org/thread/jmu8sg$2b2q$1...@digitalmars.com?page=1 DIP19: Remove comma operator from D and provision better syntactic support for tuples http://forum.dlang.org/thread/k3ns2a$1ndc$1...@digitalmars.com?page=1
Re: Challenge: write a really really small front() for UTF8
24-Mar-2014 01:34, Andrei Alexandrescu пишет: On 3/23/14, 2:29 PM, Dmitry Olshansky wrote: 24-Mar-2014 01:22, Andrei Alexandrescu пишет: Here's a baseline: http://goo.gl/91vIGc. Destroy! Assertions to check encoding?! I thought it would detect broken encoding and do a substitution at least. That implementation does zero effort to optimize checks themselves, and indeed puts them in asserts. I think there's value in having such a primitive down below. Just how much you are willing to assert? You don't even check length. In short - what are the specs of this primitive and where you see it being used. Andrei -- Dmitry Olshansky
Re: Should we deprecate comma?
On Sunday, 23 March 2014 at 20:56:45 UTC, Andrei Alexandrescu wrote: Discuss: https://github.com/D-Programming-Language/dmd/pull/3399 Andrei Yep. In the interests of clarity, kill the comma...
Re: Should we deprecate comma?
On Sunday, 23 March 2014 at 20:56:45 UTC, Andrei Alexandrescu wrote: Discuss: https://github.com/D-Programming-Language/dmd/pull/3399 Andrei Kill it. Eventually we may be able to reclaim it as something more useful.
Re: Should we deprecate comma?
On Sunday, 23 March 2014 at 20:56:45 UTC, Andrei Alexandrescu wrote: Discuss: https://github.com/D-Programming-Language/dmd/pull/3399 Andrei Yes, kill it please.
Re: Appropriateness of posts
On 3/23/14, 13:13, "Ola Fosheim Grøstad" " wrote: On Sunday, 23 March 2014 at 18:08:09 UTC, 1100110 wrote: I just want to point out that somehow the thread about how we need to maintain a professional attitude in the forums deteriorated into discussing in depth racism. Actually, racism was not discussed. What was discussed was cultural bias in what is appropriate using racial terms as an example. Tomato, tomato. I just found it slightly amusing that this is where the conversation went, not trying to call anyone or say that anything said was racist. I realize too late that my message could be interpreted in a way I didn't intend. However, I do question the public slandering of Ramon in a thread about appropriateness of posts. I don't think there is any cultural bias in that. Yeah... I think I would have been ok with that had he been using an obvious alias(Anonymous, etc) or at least wasn't mentioned by name... It does seem in poor taste.
Re: Challenge: write a really really small front() for UTF8
On 3/23/14, 2:29 PM, Dmitry Olshansky wrote: 24-Mar-2014 01:22, Andrei Alexandrescu пишет: Here's a baseline: http://goo.gl/91vIGc. Destroy! Assertions to check encoding?! I thought it would detect broken encoding and do a substitution at least. That implementation does zero effort to optimize checks themselves, and indeed puts them in asserts. I think there's value in having such a primitive down below. Andrei
Re: Should we deprecate comma?
On Sunday, 23 March 2014 at 20:56:45 UTC, Andrei Alexandrescu wrote: Discuss: https://github.com/D-Programming-Language/dmd/pull/3399 Andrei Yes please. This has been discussed to death several time.
Re: Improve D's syntax to make it more python like
On 3/23/2014 9:01 AM, 1100110 wrote: I find I think of the type as an adjective, and since I'm only fluent in english it makes perfect sense that the "adjective" would come before the "noun". What is X? X is an integer. Integer describes what X is. "type after variable name" just doesn't have that mental model to it, hence I like it less. I like "type name;" order because I usually know the type I want (even if it's just "auto") before I know what I want to name the variable. So it's more natural for me to write. I've done plenty of "name : type;" code before, and I'm fine with it, but I usually end up either writing the type first and then moving back to write the name, or come up with a name first while making sure not to forget what type I'd already had in mind. So a little bit more awkward for me.
Re: Challenge: write a really really small front() for UTF8
24-Mar-2014 01:22, Andrei Alexandrescu пишет: Here's a baseline: http://goo.gl/91vIGc. Destroy! Assertions to check encoding?! I thought it would detect broken encoding and do a substitution at least. Andrei -- Dmitry Olshansky
Challenge: write a really really small front() for UTF8
Here's a baseline: http://goo.gl/91vIGc. Destroy! Andrei
Re: Should we deprecate comma?
On Sunday, 23 March 2014 at 20:56:45 UTC, Andrei Alexandrescu wrote: Discuss: https://github.com/D-Programming-Language/dmd/pull/3399 Andrei Then things like this c = f(),b*c; became invalid? if so, yes. I did a lot of C and never found this useful just unlike.
