Re: Repost: make foreach(i, a; range) "just work"
On Friday, 21 February 2014 at 02:34:30 UTC, Jesse Phillips wrote: I don't see enough benefit for making this a language feature. foreach(i, v1, v2; tuple(0,1).repeat(10).enumerate) writeln(i, "\t", v1, "\t", v2); This works today! And once enumerate is part of Phobos it will just need an import std.range to use it. This.
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
On Thursday, 20 February 2014 at 20:26:40 UTC, Russel Winder wrote: On Mon, 2014-02-17 at 22:19 +, ponce wrote: […] Granted code bloat is a real thing and you _might_ have instruction cache problems, but the problem only ever show itself […] Code bloat in what sense? Go is founded on static compilation so as to avoid the dynamic library binding "problem". So executable are 5 to 100MB which is code blat in my book. On the other hand they don't have library versioning problems which is the bane of Posix. I meant it in the sense of actual slowdown related to binary size, or impossibility to fit a program on some embedded hardware.
Re: Implement the "unum" representation in D ?
On Friday, 21 February 2014 at 05:21:53 UTC, Frustrated wrote: I think though adding a "repeating" bit would make it even more accurate so that repeating decimals within the bounds of maximum bits used could be represented perfectly. e.g., 1/3 = 0.... could be represented perfectly with such a bit and sliding fp type. With proper cpu support one could have 0.... * 3 = 1 exactly. I believe that the repeating decimals, or better, repeating binary fractions, will hardly be more useful than a rational representation like p/q. The reason is, if we take a reciprocal 1/q and represent it as a binary, decimal, or other fixed-base fraction, the representation is surely periodic, but the upper bound on the length of its period is as high as q-1, and it is not unlikely to be the exact bound. For example, at http://en.wikipedia.org/wiki/Binary_number#Fractions , note that the binary fraction for 1/11 has period 10, and for 1/13 the period is 12. Thus repeating decimal for a fraction p/q will take up to q-1 bits when we store it as a repeating decimal, but log(p)+log(q) bits when stored as a rational number (numerator and denominator). Ivan Kazmenko.
Re: Implement the "unum" representation in D ?
On Thursday, 20 February 2014 at 23:43:18 UTC, Nordlöw wrote: The unum variable length encoding is very similar to how msgpack packs integers. See msgpack-d on github for a superb implementation in D. msgpack-d is indeed a great library that makes serialization almost instant to implement. I implemented CBOR another binary encoding scheme and it was obvious CBOR brings nothing over msgpack, it even did worse with integer encoding.
Re: Preflight of DUB 0.9.21 (RC 5)
Am 20.02.2014 21:38, schrieb Jordi Sayol: El 20/02/14 17:04, Sönke Ludwig ha escrit: Hopefully the final release candidate has been uploaded. The new RPM package could need some testing: http://code.dlang.org/files/dub-0.9.21-0.rc.5.x86_64.rpm http://code.dlang.org/download dub rc5 binaries properly tested on Debian 6. New rpm package properly tested on Fedora 14, Fedora 18 and OpenSUSE 12.4 Thanks a lot for testing! I'll tag this as a release if nothing else happens until then. Will be a rpm 32-bit version? Yes, should be no problem, but I'd like to load that off to the next version together with an outstanding automation issue (the RPM still needs to be uploaded manually in contrast to all the other files) and an improved download page layout.
Re: Ada conference, Ada and Spark
On Thursday, 20 February 2014 at 08:03:47 UTC, Paulo Pinto wrote: [cut] I have been following Ada at FOSDEM for the last years, and its use seems to be increasing in Europe for safety critical systems, mainly thanks to C and C++ issues. Maybe this is an area where D could be pushed as well. I don't think so: given that D is "C++ done right", it would require many (unlikely to happen) changes to become an interesting alternative for Ada: for example changing the semantic of integers! That said, one question I should ask to Rust devs is why they didn't base Rust on Ada given their goals.. renoX
Re: Repost: make foreach(i, a; range) "just work"
On Thu, 20 Feb 2014 16:30:42 -, Justin Whear
wrote:
On Thu, 20 Feb 2014 13:04:55 +, w0rp wrote:
More importantly, this gets in the way of behaviour which may be
desirable later, foreach being able to unpack tuples from ranges.
I would like if it was possible to return Tuple!(A, B) from front() and
write foreach(a, b; range) to interate through those thing, unpacking
the values with an alias, so this...
foreach(a, b; range) {
}
... could rewrite to roughly this. (There may be a better way.)
foreach(_someInternalName; range) {
alias a = _someInternalName[0];
alias b = _someInternalName[1];
}
Tuple unpacking already works in foreach. This code has compiled since
at least 2.063.2:
import std.stdio;
import std.range;
void main(string[] args)
{
auto tuples = ["a", "b", "c"].zip(iota(0, 3));
// unpack the string into `s`, the integer into `i`
foreach (s, i; tuples)
writeln(s, ", ", i);
}
Does this work for more than 2 values? Can the first value be something
other than an integer?
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Correct comparison of signed type with unsigned type (and vice versa)
On Thursday, 20 February 2014 at 20:52:23 UTC, Xinok wrote: The following statement prints false: writeln(-1 < uint.max); I don't see this as a bug, this is exactly what I expect from a language with intact C integer semantics. This came up in another topic recently. I think this is silly and an unnecessary source of bugs (it's bitten me before and presumably many others as well). I'm making a proposal to add an extra check so that comparisons of signed with unsigned types is always correct. Simply, if the signed type is negative, it is by default less than the unsigned value. That subtly breaks C compatiblity. Others have suggested disallowing comparing a signed type with an unsigned type. I think this is a better solution. Currently in C the unsigned vs signed operations all follow the same rules. If you do this, would you also disallow unsigned vs signed addition, subtraction, divide? I feel this would make porting C code much longer, and it's already quite a bit of work.
Re: Correct comparison of signed type with unsigned type (and vice versa)
On Thursday, 20 February 2014 at 22:52:55 UTC, Meta wrote:
I can't think of any C code that would rely on such behaviour,
but I think it'd just be safer all-around to make it an error.
Eg this optimization:
if ((unsigned int)(a - min) < (max - min)) // only one
comparison instead of two
{
}
And there is many C codes relying on unsigned promotion, since
signed overflow in C99 is undefined behaviour. The easiest way to
force an operation is then to use one cast.
Re: Repost: make foreach(i, a; range) "just work"
My current thinking:
- I still think adding index to range foreach is a good idea.
- I realise that scheme #2 isn't workable.
- I still like scheme #1 over tuple expansion as it avoids all the issues
which make scheme #2 unworkable.
- enumerate is not as flexible as many people seem to think.
On Fri, 21 Feb 2014 02:34:28 -, Jesse Phillips
wrote:
On Thursday, 20 February 2014 at 11:15:14 UTC, Regan Heath wrote:
I am posting this again because I didn't get any feedback on my idea,
which may be TL;DR or because people think it's a dumb idea and they
were politely ignoring it :p
I certainly have wanted counts of the range iteration, but I do believe
it becomes too complex to support and that even if we state 'i' is to
represent a count and not an index, people will still want an index and
expect it to be an index of their original range even though it makes no
possible sense from the perspective of iterating over a different range
from the original.
I don't understand how this is "complex to support"? It's simple. It's a
count, not an index unless the range is indexable. If people are going to
expect an index here, they will expect one with enumerate as well - and
are going to be equally disappointed. So, they need to be aware of this
regardless.
I also don't find myself needing to count iterations very often, and I
believe when I do, it is because I want to use that count as an index
(possibly needing to add to some global count, but I don't need it
enough to remember).
The justification for this change is the same as for enumerate.
It is common enough to make it important, and when it happens it's
frustrating enough that it needs fixing.
My specific example didn't want an index, or rather it wanted an index
into the result set which I believe is just as common if not more common
than wanting an index into the source - especially given that they are
often the same thing.
For example, I find myself using an index to control loop behaviour, most
often for detecting the first and last iterations than anything else. A
counter will let you do that just as well as an index.
Scheme 1)
As Marc said, "ails backwards-compatibility." A change like this will
never exist if it isn't backwards compatible. There are very few changes
which will be accepted if backwards compatibility isn't preserved.
Sure. I personally find this idea compelling enough to warrant some
breakage, it is simple, powerful and extensible and avoids all the issues
of optional indexes with tuple expansion. But, I can see how someone
might disagree.
Scheme 2)
However, if a type is given and the type can be unambiguously matched
to a single tuple component then do so.
double[string] AA;
foreach (string k; AA) {} // k is "key"
While probably not common, what if one needed to switch key/value
string[double] AA;
or something similar, the type system no longer helps. But again, this
seems pretty much uneventful.
Perhaps I wasn't clear, this would work fine:
string[double] AA;
foreach (string v; AA) {} // v is "value"
foreach (double k; AA) {} // k is "key"
or am I missing the point you're making?
foreach (i, k, v; AA.byPairs.enumerate) {}
foreach (i, k, v; AA) {} // better
Bringing this back to range iteration:
foreach(i, v1, v2; tuple(0,1).repeat(10))
writeln(i, "\t",v1, "\t",v2);
Later the range gets a new value, the foreach would still compile but be
wrong:
foreach(i, v1, v2; tuple(0,1,2).repeat(10))
writeln(i, "\t",v1, "\t",v2);
With enumerate, there is an error.
foreach(i, v1, v2; tuple(0,1,2).repeat(10).enumerate)
writeln(i, "\t", v1, "\t", v2);
Error: cannot infer argument types
Sure, this is an issue with having the optional index/count variable,
which is not something foreach with enumerate allows. This is another
reason I prefer scheme #1, you never have this issue no matter what.
foreach(i, v1, v2; tuple(0,1).repeat(10).enumerate)
writeln(i, "\t", v1, "\t", v2);
This works today! And once enumerate is part of Phobos it will just need
an import std.range to use it.
I don't believe this works today. My understanding of what is currently
supported is..
foreach(index, value; array) { }
foreach(value; range) { }// no support for index/count
foreach(key, value; tuple) { } // no support for index/count
And, my understanding of enumerate is that it simply creates a tuple from
an index and a range value, taking it from the range foreach case above,
to the tuple foreach case.
This is not extensible to more than 2 values. In fact, it's pretty
limited until we get full built-in tuple expansion support.
To test this understanding I pulled down the source for enumerate and
coded this up:
import std.stdio;
import std.range;
import std.typecons;
..paste enumerate here.. // line 5
void main()
{
forea
Re: Repost: make foreach(i, a; range) "just work"
On Fri, 21 Feb 2014 10:02:43 -, Regan Heath
wrote:
On Thu, 20 Feb 2014 16:30:42 -, Justin Whear
wrote:
On Thu, 20 Feb 2014 13:04:55 +, w0rp wrote:
More importantly, this gets in the way of behaviour which may be
desirable later, foreach being able to unpack tuples from ranges.
I would like if it was possible to return Tuple!(A, B) from front() and
write foreach(a, b; range) to interate through those thing, unpacking
the values with an alias, so this...
foreach(a, b; range) {
}
... could rewrite to roughly this. (There may be a better way.)
foreach(_someInternalName; range) {
alias a = _someInternalName[0];
alias b = _someInternalName[1];
}
Tuple unpacking already works in foreach. This code has compiled since
at least 2.063.2:
import std.stdio;
import std.range;
void main(string[] args)
{
auto tuples = ["a", "b", "c"].zip(iota(0, 3));
// unpack the string into `s`, the integer into `i`
foreach (s, i; tuples)
writeln(s, ", ", i);
}
Does this work for more than 2 values? Can the first value be something
other than an integer?
Answered this myself. What is supported is:
foreach(key, value; tuple) { }
But, what is not supported is more than 2 values.
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Repost: make foreach(i, a; range) "just work"
On Thu, 20 Feb 2014 17:09:31 -, Steven Schveighoffer
wrote:
On Thu, 20 Feb 2014 11:07:32 -0500, Regan Heath
wrote:
Only if the compiler prefers opApply to range methods, does it?
It should. If it doesn't, that is a bug.
The sole purpose of opApply is to interact with foreach. If it is masked
out, then there is no point for having opApply.
Thanks.
So, if we had this support which I am asking for:
foreach(index, value; range) { }
And, if someone adds opApply to that range, with a different type for the
first variable then an existing foreach (using index, value) is likely to
stop compiling due to type problems.
This seems acceptable to me.
There is an outside chance it might keep on compiling, like if 'i' is not
used in a strongly typed way, i.e. passed to a writefln or similar. In
this case we have silently changed behaviour.
Is this acceptable?
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Formal review of std.lexer
http://wiki.dlang.org/Review/std.lexer This is follow-up by Brian to his earlier proposal (http://wiki.dlang.org/Review/std.d.lexer). This time proposed module focuses instead on generic lexer generation as discussed in matching voting thread. Docs: http://hackerpilot.github.io/experimental/std_lexer/phobos/lexer.html Code: https://github.com/Hackerpilot/Dscanner/blob/master/stdx/lexer.d Example topics to evaluate during review: - Feasibility of overall design and concept - Quality of documentation - Consistency with existing Phobos modules - Overall quality of implementation Initial review will end on March the 8th.
Re: Correct comparison of signed type with unsigned type (and vice versa)
On Thursday, 20 February 2014 at 20:52:23 UTC, Xinok wrote: Others have suggested disallowing comparing a signed type with an unsigned type. I think this is a better solution. Yes, it will add a small bit of overhead, but I believe it's more important for code to be correct than to be fast. I totally agree. However, since we need correct code, we need way more features than this. I was surprised to find out that we don't have any "SafeInt" type in D... I was sure someone had made it but I wasn't able to find it anywhere. My ideal int type: -Has an equivalent of NaN, meaning it doesn't have "0 initialization" which is somewhat bug-prone. -Is able to signal errors like overflow/division by zero, would be nice if throwing could be avoided. -Signed, but can be flagged as ">0 only", and signals an error if it gets assigned a negative value. -Some extra features that are surely awesome but I'm forgetting right now. Any takers? Man, I wish I had time :S
Re: Why is int implicitly convertible to ulong?
The specific problem here was when working with std.json.
std.json distinguishes between UINTEGER and INTEGER, so I had
code like
static if(is(T : ulong)) {
// must be UINTEGER
} else static if(is(T : long)) {
// can be either INTEGER or UINTEGER
}
I've since found out about isSigned and isUnsigned, still it was
mighty confusing for me that the first case was selected for
signed types.
Re: Formal review of std.lexer
On Friday, 21 February 2014 at 12:12:17 UTC, Dicebot wrote:
http://wiki.dlang.org/Review/std.lexer
First of all, thank you for the great work. This is a very
important project.
I'll begin with reviewing the documentation.
Summary
Some simple explanation of the terminology and concepts would be
nice. At least a link to Wikipedia.
Create the string array costants for your language.
Typo ("costants")
Examples:
An inline complete example of a very simple language would be
nice.
A lexer for D is available here.
Although good to have, this is too much to take in all at once,
for documentation purposes.
A lexer for Lua is available here.
Nary a comment in sight. This might serve as the example lexer if
only it was better commented. The comments can be copy-pasted
from the module documentation, even that would make the code much
easier to grok.
Template Parameter Definitions
What does this mean? Parameters to what template?
Can this section be moved to inside the documentation of Lexer,
and Lexer be moved to the first documented symbol in the file?
A function that serves as the default token lexing function.
For most languages this will be the identifier lexing function.
Should the function signature and contracts be explained here?
This function must return bool and take a single size_t
argument representing the number of bytes to skip over before
looking for a separating character.
I think it's better to describe the signature in D syntax rather
than English.
A listing of tokens whose value is variable, such as
whitespace, identifiers, number literals, and string literals.
No mention of how the list is represented (is it an array? what
type of elements should the array have? how are the array values
used?), the reader is left to figure that out from the example
below.
Template for determining the type used for a token type.
Selects the smallest unsigned integral type that is able to
hold the value staticTokens.length + dynamicTokens.length +
possibleDefaultTokens.length. For example if there are 20
static tokens, 30 dynamic tokens, and 10 possible default
tokens, this template will alias itself to ubyte, as 20 + 30 +
10 < ubyte.max.
Should this be documented? I understand that this will be
instantiated only once, by std.lexer.
Utility declarations should preferably be at the end of the
module, so that they appear last in the documentation.
Generates the token type identifier for the given symbol. There
are two special cases:
Are these magic constants necessary? Why not declare them as
enums?
In all cases this template will alias itself to a constant of
type IdType. This template will fail at compile time if symbol
is not one of the staticTokens, dynamicTokens, or
possibleDefaultTokens.
Style nit: D symbols should be wrapped in the $D(...) macro.
== overload for the the token type.
Is it really necessary to document opEquals?
But since it's here: how does it interact with extraFields?
The Column number at which this token occurs.
There was a lot of bikeshedding regarding the correct terminology
to use when adding -vcolumns to DMD (
https://github.com/D-Programming-Language/dmd/pull/3077 ). I
think the documentation should at least mention what exactly it
is counting.
A function that serves as the default token lexing function.
For most languages this will be the identifier lexing function.
What should the function's name be? How will it interact with
Lexer? (It's not clear that this refers to the
defaultTokenFunction parameter, especially after the previous
list item, popFront, is a different piece of the puzzle.)
The documentation for Lexer's arguments seem to be thrown all
around the module. I suggest to document them only once, all in
Lexer's DDoc, add example signatures, and move Lexer to the top
of the module.
Examples:
struct CalculatorLexer
I think this should be expanded into a full, well-documented
example featured in the module DDoc.
_popFront();
Where did that come from? Perhaps you meant Lexer's DDoc to say
"which should call this mixin's _popFront()", and the DDoc
escaped the _ character? If so, why not use a named mixin to
disambiguate instead of _?
struct LexerRange;
struct StringCache;
These are thoroughly documented, but will they be used by
anything other than std.lexer?
Re: Ada conference, Ada and Spark
On Friday, 21 February 2014 at 10:01:41 UTC, renoX wrote: On Thursday, 20 February 2014 at 08:03:47 UTC, Paulo Pinto wrote: [cut] I have been following Ada at FOSDEM for the last years, and its use seems to be increasing in Europe for safety critical systems, mainly thanks to C and C++ issues. Maybe this is an area where D could be pushed as well. I don't think so: given that D is "C++ done right", it would require many (unlikely to happen) changes to become an interesting alternative for Ada: for example changing the semantic of integers! That said, one question I should ask to Rust devs is why they didn't base Rust on Ada given their goals.. renoX That is easy to answer, I doubt they could with their rule of not having more than 5 characters per keyword. :) -- Paulo
Re: Ada conference, Ada and Spark
On Friday, 21 February 2014 at 12:56:32 UTC, Paulo Pinto wrote: That is easy to answer, I doubt they could with their rule of not having more than 5 characters per keyword. :) Wait, what? REALLY? What kind of rule is that. ahahahha... are they stuck to the 70's? :D
Re: Why is int implicitly convertible to ulong?
On Friday, February 21, 2014 12:41:07 Hannes Steffenhagen wrote:
> The specific problem here was when working with std.json.
>
> std.json distinguishes between UINTEGER and INTEGER, so I had
> code like
>
> static if(is(T : ulong)) {
> // must be UINTEGER
> } else static if(is(T : long)) {
> // can be either INTEGER or UINTEGER
> }
>
>
> I've since found out about isSigned and isUnsigned, still it was
> mighty confusing for me that the first case was selected for
> signed types.
Well, it is using : - which means implicit conversion, which is always
something that you should be careful with in generic code. Technically,
something like
struct S
{
ulong ul;
alias ul this;
}
would match it as well, and depending on what the code inside the static if is
like, it might work, but there's also a good chance that it wouldn't. Using
is(T == ulong) if you want to require that it be exactly ulong, or
isUnsigned!T if you want any unsigned integral type. Using implicit conversion
in generic code _can_ be useful, but you need to be _very_ careful with it.
- Jonathan M Davis
Re: Correct comparison of signed type with unsigned type (and vice versa)
On 20/02/2014 20:52, Xinok wrote: Others have suggested disallowing comparing a signed type with an unsigned type. Yes, that solution is pre-approved: https://d.puremagic.com/issues/show_bug.cgi?id=259 I think that's a very important bug to solve.
Re: Ada conference, Ada and Spark
On Friday, 21 February 2014 at 13:08:37 UTC, Francesco Cattoglio wrote: On Friday, 21 February 2014 at 12:56:32 UTC, Paulo Pinto wrote: That is easy to answer, I doubt they could with their rule of not having more than 5 characters per keyword. :) Wait, what? REALLY? What kind of rule is that. ahahahha... are they stuck to the 70's? :D Yes really, http://forum.dlang.org/post/glnafbocwjodiwrqw...@forum.dlang.org I just cannot find the Reddit thread any longer.
Re: Repost: make foreach(i, a; range) "just work"
On Fri, 21 Feb 2014 06:21:39 -0500, Regan Heath
wrote:
On Thu, 20 Feb 2014 17:09:31 -, Steven Schveighoffer
wrote:
On Thu, 20 Feb 2014 11:07:32 -0500, Regan Heath
wrote:
Only if the compiler prefers opApply to range methods, does it?
It should. If it doesn't, that is a bug.
The sole purpose of opApply is to interact with foreach. If it is
masked out, then there is no point for having opApply.
Thanks.
So, if we had this support which I am asking for:
foreach(index, value; range) { }
And, if someone adds opApply to that range, with a different type for
the first variable then an existing foreach (using index, value) is
likely to stop compiling due to type problems.
This seems acceptable to me.
I think any type that does both opApply and range iteration is asking for
problems :) D has a nasty way of choosing "all or nothing" for overloads,
meaning it may decide "this is a range" or "this is opApply", but if you
have both, it picks one or the other.
I'd rather see it do:
1. can I satisfy this foreach using opApply? If yes, do it.
2. If not, can I satisfy this foreach using range iteration?
This may be how it works, I honestly don't know.
There is an outside chance it might keep on compiling, like if 'i' is
not used in a strongly typed way, i.e. passed to a writefln or similar.
In this case we have silently changed behaviour.
Is this acceptable?
Adding opApply is changing the API of the range. If the range does
something different based on whether you use the range interface or
opApply, then this is a logic error IMO.
The easiest thing is to just not use opApply and range primitives together
:) One separation I like to use in my code is that you use opApply on a
container, but range primitives on a range for that container. And a
container is not a range.
-Steve
Re: Preflight of DUB 0.9.21 (RC 5)
On Thu, 2014-02-20 at 17:04 +0100, Sönke Ludwig wrote: > Hopefully the final release candidate has been uploaded. The new RPM > package could need some testing: > > http://code.dlang.org/files/dub-0.9.21-0.rc.5.x86_64.rpm > http://code.dlang.org/download The 64-bit Tarball for Linux works for me on Debian Unstable. Haven't had chance to test other things yet. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: switch()
On 2/16/14, Manu wrote:
> requiring an empty 'default: break;' line at the end is annoying and noisy.
Guys, I keep seeing this line being mentioned but you don't actually
have to type "break":
-
void main()
{
int x;
switch (x)
{
case 1:
break;
// this works fine
default:
}
}
-
Re: Repost: make foreach(i, a; range) "just work"
On Fri, 21 Feb 2014 14:29:37 -, Steven Schveighoffer
wrote:
On Fri, 21 Feb 2014 06:21:39 -0500, Regan Heath
wrote:
On Thu, 20 Feb 2014 17:09:31 -, Steven Schveighoffer
wrote:
On Thu, 20 Feb 2014 11:07:32 -0500, Regan Heath
wrote:
Only if the compiler prefers opApply to range methods, does it?
It should. If it doesn't, that is a bug.
The sole purpose of opApply is to interact with foreach. If it is
masked out, then there is no point for having opApply.
Thanks.
So, if we had this support which I am asking for:
foreach(index, value; range) { }
And, if someone adds opApply to that range, with a different type for
the first variable then an existing foreach (using index, value) is
likely to stop compiling due to type problems.
This seems acceptable to me.
I think any type that does both opApply and range iteration is asking
for problems :) D has a nasty way of choosing "all or nothing" for
overloads, meaning it may decide "this is a range" or "this is opApply",
but if you have both, it picks one or the other.
I'd rather see it do:
1. can I satisfy this foreach using opApply? If yes, do it.
2. If not, can I satisfy this foreach using range iteration?
This may be how it works, I honestly don't know.
There is an outside chance it might keep on compiling, like if 'i' is
not used in a strongly typed way, i.e. passed to a writefln or
similar. In this case we have silently changed behaviour.
Is this acceptable?
Adding opApply is changing the API of the range. If the range does
something different based on whether you use the range interface or
opApply, then this is a logic error IMO.
The easiest thing is to just not use opApply and range primitives
together :) One separation I like to use in my code is that you use
opApply on a container, but range primitives on a range for that
container. And a container is not a range.
Makes sense to me. :)
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Repost: make foreach(i, a; range) "just work"
"Steven Schveighoffer" wrote in message news:op.xbmyjnnzeav7ka@stevens-macbook-pro.local... I'd rather see it do: 1. can I satisfy this foreach using opApply? If yes, do it. 2. If not, can I satisfy this foreach using range iteration? This may be how it works, I honestly don't know. It is.
Re: More Illuminating Introductory Code Example on dlang.org
On Wednesday, 12 February 2014 at 20:49:54 UTC, Nordlöw wrote: On Wednesday 19:th of Februari I'm giving my first talk on D for my fellow collegues at my consultant firm office HiQ, Linköping, Sweden. If any of you are in the neighbourhood please let me know and I will invite you. The lecture will most likely be held in Swedish. I couldn't make it. How did it go?
Re: Repost: make foreach(i, a; range) "just work"
On Friday, 21 February 2014 at 11:12:54 UTC, Regan Heath wrote:
- enumerate is not as flexible as many people seem to think.
Only seeing the enumerate missing the ability to optionally add
an index, but if you aren't adding an index you don't need
enumerate.
On Fri, 21 Feb 2014 02:34:28 -, Jesse Phillips
wrote:
I don't understand how this is "complex to support"? It's
simple. It's a count, not an index unless the range is
indexable. If people are going to expect an index here, they
will expect one with enumerate as well - and are going to be
equally disappointed. So, they need to be aware of this
regardless.
You've provided 3 schemes to support this feature. This suggest
there are several "right" ways to bring this into the language,
while you prefer 1 someone may prefer 3.
At least with enumerate one will need to go to the documentation
which explains enumerate doesn't provide an index... I haven't
actually reviewed the docs.
I also don't find myself needing to count iterations very
often, and I believe when I do, it is because I want to use
that count as an index (possibly needing to add to some global
count, but I don't need it enough to remember).
The justification for this change is the same as for enumerate.
It is common enough to make it important, and when it happens
it's frustrating enough that it needs fixing.
I disagree. Enumerate is satisfactory (since it isn't in Phobos I
can see it as frustrating).
For example, I find myself using an index to control loop
behaviour, most often for detecting the first and last
iterations than anything else. A counter will let you do that
just as well as an index.
I wonder if there is a change to the algorithm which would allow
you to not need the first/last iteration. I think this is the
main reason I don't need a count, I've learned different ways to
solve a problem. Which is beneficial since it leads to chaining
functions instead of relying on foreach.
Sure. I personally find this idea compelling enough to warrant
some breakage, it is simple, powerful and extensible and avoids
all the issues of optional indexes with tuple expansion. But,
I can see how someone might disagree.
Yes, I understand. But D is at a stage in its life when not every
little detail can be polished. Believe me, D has other areas
which need polishing but can't be.
string[double] AA;
or something similar, the type system no longer helps. But
again, this seems pretty much uneventful.
Perhaps I wasn't clear, this would work fine:
string[double] AA;
foreach (string v; AA) {} // v is "value"
foreach (double k; AA) {} // k is "key"
or am I missing the point you're making?
if AA is changed to a double[string], then your value loop
iterates on keys and your key loop iterates on values.
foreach(i, v1, v2; tuple(0,1).repeat(10).enumerate)
writeln(i, "\t", v1, "\t", v2);
This works today! And once enumerate is part of Phobos it will
just need an import std.range to use it.
I tested all my claims about enumerate. You need it to import
std.traits or else is(Largest(...)) will always be false.
Re: Ada conference, Ada and Spark
On Friday, 21 February 2014 at 14:27:48 UTC, Paulo Pinto wrote: On Friday, 21 February 2014 at 13:08:37 UTC, Francesco Cattoglio wrote: On Friday, 21 February 2014 at 12:56:32 UTC, Paulo Pinto wrote: That is easy to answer, I doubt they could with their rule of not having more than 5 characters per keyword. :) Wait, what? REALLY? What kind of rule is that. ahahahha... are they stuck to the 70's? :D Yes really, http://forum.dlang.org/post/glnafbocwjodiwrqw...@forum.dlang.org I just cannot find the Reddit thread any longer. That is not true, Rust has several keywords that are more than 5 characters, such as 'continue'. The full list is here: http://static.rust-lang.org/doc/master/rust.html#keywords . It is true that they prefer short keywords over long ones. It used to be the case that 'loop' could mean 'continue' but people found it confusing so it was fixed.
Re: Repost: make foreach(i, a; range) "just work"
On Fri, 21 Feb 2014 15:35:44 -, Jesse Phillips
wrote:
You've provided 3 schemes to support this feature. This suggest there
are several "right" ways to bring this into the language, while you
prefer 1 someone may prefer 3.
Ignore the 3 schemes they were just me thinking about how what I actually
want will affect built in tuple expansion etc.
I want just 1 thing to change (at this time), an index added to foreach
over ranges so that it matches arrays, e.g.
foreach(index, value; range) { }
The code change is likely quite literally just adding an int to the
foreach handler for ranges, passing it to the foreach body, and
incrementing it afterwards. That's it, well, plus the front end code to
bind the variable.
All I am suggesting is that we take what we currently have:
foreach([index, ]value; array) { }
foreach(value; range) { }
foreach(key, value; tuple) { }
and make this possible too:
foreach([index, ]value; range) { }
string[double] AA;
or something similar, the type system no longer helps. But again, this
seems pretty much uneventful.
Perhaps I wasn't clear, this would work fine:
string[double] AA;
foreach (string v; AA) {} // v is "value"
foreach (double k; AA) {} // k is "key"
or am I missing the point you're making?
if AA is changed to a double[string], then your value loop iterates on
keys and your key loop iterates on values.
No, I was actually suggesting a change here, the compiler would use type
matching not ordering to assign the variables. So because 'v' is a
string, it is bound to the value not the key.
foreach(i, v1, v2; tuple(0,1).repeat(10).enumerate)
writeln(i, "\t", v1, "\t", v2);
This works today! And once enumerate is part of Phobos it will just
need an import std.range to use it.
I tested all my claims about enumerate. You need it to import std.traits
or else is(Largest(...)) will always be false.
Thanks! Ok, so how is this working? ahh, ok I think I get it. enumerate
returns a range, whose values are Tuples of index/value where value is
also a tuple so is flattened, and then the whole lot is flattened into the
foreach.
So, while the range foreach only supports:
foreach(value; range) { }
value in this case is a flattened tuple of (index, v1, v2, ...)
Yes?
I had completely forgotten about tuple flattening.
I don't think this affects what I actually want to change, we can have:
foreach(index, value; range) { }
and still flatten tuples into value, you would simply have to provide one
extra variable to get an index.
Make sense?
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Repost: make foreach(i, a; range) "just work"
On Fri, 21 Feb 2014 09:58:58 -0500, Daniel Murphy wrote: "Steven Schveighoffer" wrote in message news:op.xbmyjnnzeav7ka@stevens-macbook-pro.local... I'd rather see it do: 1. can I satisfy this foreach using opApply? If yes, do it. 2. If not, can I satisfy this foreach using range iteration? This may be how it works, I honestly don't know. It is. Good, thank you for checking! -Steve
Re: Why is int implicitly convertible to ulong?
On 02/21/2014 04:41 AM, Hannes Steffenhagen wrote:
The specific problem here was when working with std.json.
std.json distinguishes between UINTEGER and INTEGER, so I had code like
static if(is(T : ulong)) {
// must be UINTEGER
} else static if(is(T : long)) {
// can be either INTEGER or UINTEGER
}
I've since found out about isSigned and isUnsigned, still it was mighty
confusing for me that the first case was selected for signed types.
I have something like the following in an experimental std.json code
that converts to JSONValue.
Since std.json uses long for the value, I attempt to detect data loss
when the value is a large ulong:
JSONValue to(Target : JSONValue, T)(T value)
{
/* ... */
} else static if (is (T : long)) {
static if (is (T == ulong)) {
enforce(value <= long.max,
format("Data loss: %s %s cannot fit a long.",
T.stringof, value));
}
json.type = JSON_TYPE.INTEGER;
json.integer = value;
} else static if (is (T : real)) {
Ali
Re: Formal review of std.lexer
On Friday, 21 February 2014 at 12:12:17 UTC, Dicebot wrote: http://wiki.dlang.org/Review/std.lexer This is follow-up by Brian to his earlier proposal (http://wiki.dlang.org/Review/std.d.lexer). This time proposed module focuses instead on generic lexer generation as discussed in matching voting thread. Docs: http://hackerpilot.github.io/experimental/std_lexer/phobos/lexer.html Code: https://github.com/Hackerpilot/Dscanner/blob/master/stdx/lexer.d Thanks for all the work Brian. Read through the previous threads about the development of this code (links at the bottom) and I can see a lot of effort has gone into it. So the following comments may come across as uninformed, but hopefully they will be helpful. 1. StringCache is a custom hash table. It looks like it's primary role is to reduce some sort of duplication. Hash tables, though, are difficult to get right. So perhaps could a benchmark comparison be made against the built-in HT to show what savings it brings? Since it is in the public interface should its payload also be public? Although it is built using GC.malloc how about the in-the-works std.allocator module? Perhaps a version 1 could use GC.malloc but if a later PR could make it possible to use a custom allocator that would be nice. 2. I like the fact that a range interface is provided. I realize that the previous discussions stipulated the use of ubyte to avoid encoding work during scanning. The reasoning about performance makes sense to me. That being the case, could a code example be provided showing how to use this module to scan a UTF-8 encoded string? Even if this is going to focus only on scanning code files, the D language spec allows for arbitrary Unicode in a code file. How is this possible? (I have a general idea, just looking for some explicit code sample help). 3. I tried to understand the reason for and usage of the "extraFields" parameter in "TokenStructure" but couldn't figure it out. Could some more explanation of its intent and usage be provided? 4. Do you want the commented-out pragma statement left over on line 601? 5. Should the template "TokenId" perhaps be something like "generateTokenId" instead? I am not sure what an "Id" for a token means. Is it an integral hash value? Had difficulty seeing how it ties in with the concept of "value" in the header documentation. If this is a numerical hash of a string token, why is the string still stored and used in "tokenStringRepresentation"? I probably am missing something big but couldn't the number be used to represent the string everywhere, saving on time and space? 6. I tried but had difficulty understanding the difference between the four token types -- "staticTokens", "dynamicTokens", "possibleDefaultTokens", "tokenHandlers" -- provided as arguments to "Lexer". What is a token that has a value that changes versus a token that does not change? I am not sure where to put my token definitions. 7. Just thinking about using the module and I would like to use it to make a scanner for xml, json, csv, c/c++, etc. I wasn't able to figure out how to do so, however. The initial code example is nice. But could some additional guidance be provided? Also, I wasn't sure how to make use of a lexer once created. The documentation focuses well on how to initialize a "Lexer" but could some guidance also be provided on how to use one past initialization? 8. Andrei's trie search (http://forum.dlang.org/thread/eeenynxifropasqcu...@forum.dlang.org?page=4#post-l2nm7m:2416e1:241:40digitalmars.com) seemed like a really interesting idea. And I saw in that thread you continued with his ideas. Does this module incorporate that work? Or was it less performant in the end? 9. I ran "dmd -cov" against the module and got zero percent unit test coverage. Perhaps adding some test code will help clarify usage patterns? You have put a lot of work into this code so I apologize if the above comes across as picking it apart. Just some questions I had in trying to make use of the code. Hopefully some of it is helpful. Joseph Other related posts http://forum.dlang.org/thread/jsnhlcbulwyjuqcqo...@forum.dlang.org http://forum.dlang.org/thread/dpdgcycrgfspcxenz...@forum.dlang.org http://forum.dlang.org/thread/eeenynxifropasqcu...@forum.dlang.org
Re: Correct comparison of signed type with unsigned type (and vice versa)
On Friday, 21 February 2014 at 10:45:50 UTC, ponce wrote: I don't see this as a bug, this is exactly what I expect from a language with intact C integer semantics. I didn't call it a bug. I said that it's prone to causing bugs. That subtly breaks C compatibility. Personally, I wish we would drop some of the C semantics and allow the language evolve. In it's place, add a function attribute which would enable C semantics for the sake of migrating code. Currently in C the unsigned vs signed operations all follow the same rules. If you do this, would you also disallow unsigned vs signed addition, subtraction, divide? Unfortunately, those operations don't have such simple solutions. D is a statically typed language and the compiler simply can't predict what the resultant type should be. However, comparisons do have a simple fix with minimal overhead.
Re: Implement the "unum" representation in D ?
On Friday, 21 February 2014 at 09:04:40 UTC, Ivan Kazmenko wrote: I believe that the repeating decimals, or better, repeating binary fractions, will hardly be more useful than a rational representation like p/q. Yeah, in retrospect I would say that a binary layout like: numberator length | +- | numerator | divisor Might be a stronger solution, or at least one which offers different advantages over what we have today. It still wouldn't be able to represent pi accurately, since it isn't a rational number, but I wouldn't be surprised if a rational number exists that could be represented than can be represented in IEEE format.
Re: Ada conference, Ada and Spark
On Friday, 21 February 2014 at 17:25:48 UTC, Francesco Cattoglio wrote: On Friday, 21 February 2014 at 15:57:32 UTC, Thiez wrote: That is not true, Rust has several keywords that are more than 5 characters, such as 'continue'. The full list is here: http://static.rust-lang.org/doc/master/rust.html#keywords . It is true that they prefer short keywords over long ones. I knew there was no hard-coded limit, but this "try to keep keywords short" sounds really stupid to me. No offence to designers, but I really don't think we should save some spar characters in 2014... I do all my coding on a remote SSH, but still I have plenty of screen space to spare ;) My first glance: "priv" instead of "private"... bleah! At least it's clear enough "mut"... what is this? "mutable", "mutex", perhaps "mute"? "impl" could be several different things, too, but I guess it's "implements" And "continue" being a different keyword some time ago. In the end they changed it. Tons of discussions and stuff; was it worth saving 3 characters, after all? I hope their standard library is at least WAY more verbose... Otherwise I pity casual Rust programmers :D Depends on how often and where you write those keywords. mut seems to be quite common and even in D I would not like 'reference' more than 'ref', especially since it is used in parameter lists.
Re: Ada conference, Ada and Spark
On Friday, 21 February 2014 at 14:27:48 UTC, Paulo Pinto wrote: On Friday, 21 February 2014 at 13:08:37 UTC, Francesco Cattoglio wrote: On Friday, 21 February 2014 at 12:56:32 UTC, Paulo Pinto wrote: That is easy to answer, I doubt they could with their rule of not having more than 5 characters per keyword. :) Wait, what? REALLY? What kind of rule is that. ahahahha... are they stuck to the 70's? :D Yes really, http://forum.dlang.org/post/glnafbocwjodiwrqw...@forum.dlang.org I just cannot find the Reddit thread any longer. Obviously, there is no rule in Rust that keywords have no more than 5 letters (return, extern, ...) but the designers favor short keywords, maybe a bit much for my taste. OTOH, I prefer their preference for favoring immutability and expression oriented style to D's statement oriented preference. The latest version of Ada tries to fix Ada a bit in this regard http://www.ada-auth.org/standards/12rat/html/Rat12-1-3-2.html but it's a bit late. I'm glad to hear that Ada use is increasing somewhere, but I don't see it in any market I look at. The Rust designers are targetting C and C++ users, with a different vision than Walter and Andrei's as to what constitutes "C++ done right", and some specific applications, like Servo. -- Brian
Re: Formal review of std.lexer
On 2014-02-21 18:06, Andrei Alexandrescu wrote: Can we please defer this by one week? Just make the review period one week longer. -- /Jacob Carlborg
Re: Ada conference, Ada and Spark
On Friday, 21 February 2014 at 15:57:32 UTC, Thiez wrote: That is not true, Rust has several keywords that are more than 5 characters, such as 'continue'. The full list is here: http://static.rust-lang.org/doc/master/rust.html#keywords . It is true that they prefer short keywords over long ones. I knew there was no hard-coded limit, but this "try to keep keywords short" sounds really stupid to me. No offence to designers, but I really don't think we should save some spar characters in 2014... I do all my coding on a remote SSH, but still I have plenty of screen space to spare ;) My first glance: "priv" instead of "private"... bleah! At least it's clear enough "mut"... what is this? "mutable", "mutex", perhaps "mute"? "impl" could be several different things, too, but I guess it's "implements" And "continue" being a different keyword some time ago. In the end they changed it. Tons of discussions and stuff; was it worth saving 3 characters, after all? I hope their standard library is at least WAY more verbose... Otherwise I pity casual Rust programmers :D
Re: Formal review of std.lexer
On 2/21/14, 2:12 PM, Dicebot wrote: http://wiki.dlang.org/Review/std.lexer This is follow-up by Brian to his earlier proposal (http://wiki.dlang.org/Review/std.d.lexer). This time proposed module focuses instead on generic lexer generation as discussed in matching voting thread. Docs: http://hackerpilot.github.io/experimental/std_lexer/phobos/lexer.html Code: https://github.com/Hackerpilot/Dscanner/blob/master/stdx/lexer.d Example topics to evaluate during review: - Feasibility of overall design and concept - Quality of documentation - Consistency with existing Phobos modules - Overall quality of implementation Initial review will end on March the 8th. Can we please defer this by one week? Thanks, Andrei
Re: Repost: make foreach(i, a; range) "just work"
On Fri, 21 Feb 2014 10:02:43 +, Regan Heath wrote:
> On Thu, 20 Feb 2014 16:30:42 -, Justin Whear
> wrote:
>
>> On Thu, 20 Feb 2014 13:04:55 +, w0rp wrote:
>>>
>>> More importantly, this gets in the way of behaviour which may be
>>> desirable later, foreach being able to unpack tuples from ranges.
>>> I would like if it was possible to return Tuple!(A, B) from front()
>>> and write foreach(a, b; range) to interate through those thing,
>>> unpacking the values with an alias, so this...
>>>
>>> foreach(a, b; range) {
>>> }
>>>
>>> ... could rewrite to roughly this. (There may be a better way.)
>>>
>>> foreach(_someInternalName; range) {
>>> alias a = _someInternalName[0];
>>> alias b = _someInternalName[1];
>>> }
>>
>> Tuple unpacking already works in foreach. This code has compiled since
>> at least 2.063.2:
>>
>> import std.stdio;
>> import std.range;
>> void main(string[] args)
>> {
>> auto tuples = ["a", "b", "c"].zip(iota(0, 3));
>>
>> // unpack the string into `s`, the integer into `i`
>> foreach (s, i; tuples)
>> writeln(s, ", ", i);
>> }
>
> Does this work for more than 2 values? Can the first value be something
> other than an integer?
>
> R
Yes to both questions. In the following example I use a four element
tuple, the first element of which is a string:
import std.stdio;
import std.range;
void main(string[] args)
{
auto tuples = ["a", "b", "c"].zip(iota(0, 3), [1.2, 2.3, 3.4], ['x',
'y', 'z']);
foreach (s, i, f, c; tuples)
writeln(s, ", ", i, ", ", f, ", ", c);
}
Compiles with dmd 2.063.2
Re: Ada conference, Ada and Spark
Am 21.02.2014 16:57, schrieb Thiez: On Friday, 21 February 2014 at 14:27:48 UTC, Paulo Pinto wrote: On Friday, 21 February 2014 at 13:08:37 UTC, Francesco Cattoglio wrote: On Friday, 21 February 2014 at 12:56:32 UTC, Paulo Pinto wrote: That is easy to answer, I doubt they could with their rule of not having more than 5 characters per keyword. :) Wait, what? REALLY? What kind of rule is that. ahahahha... are they stuck to the 70's? :D Yes really, http://forum.dlang.org/post/glnafbocwjodiwrqw...@forum.dlang.org I just cannot find the Reddit thread any longer. That is not true, Rust has several keywords that are more than 5 characters, such as 'continue'. The full list is here: http://static.rust-lang.org/doc/master/rust.html#keywords . It is true that they prefer short keywords over long ones. It used to be the case that 'loop' could mean 'continue' but people found it confusing so it was fixed. What I was arguing in that old thread was things like pub vs public, mut vs mutable and so on. I have a strong ML background as my university teachers were quite found of ML and we had a few courses using Caml Light. So I do like Rust and my issue back then was why to short those keywords and similar. Then again as I come from Pascal family of languages and always liked a bit verbosity, instead of the write only way of C. -- Paulo
Re: Implement the "unum" representation in D ?
On Friday, 21 February 2014 at 07:42:36 UTC, francesco cattoglio wrote: On Friday, 21 February 2014 at 05:21:53 UTC, Frustrated wrote: I think though adding a "repeating" bit would make it even more accurate so that repeating decimals within the bounds of maximum bits used could be represented perfectly. e.g., 1/3 = 0.... could be represented perfectly with such a bit and sliding fp type. With proper cpu support one could have 0.... * 3 = 1 exactly. By having two extra bits one could represent constants to any degree of accuracy. e.g., the last bit says the value represents the ith constant in some list. This would allow very common irrational constants to be used: e, pi, sqrt(2), etc... Unfortunately maths (real world maths) isn't made by "common" constants. More, such a "repeating bit" should become a "repeating counter", since you usually get a certain number of repeating digits, not just a single one. I disagree. Many computations done by computers involve constants in the calculation... pi, e, sqrt(2), sqrt(-1), many physical constants, etc. The cpu could store these constants at a higher bit resolution than standard, say 128 bits or whatever. For floating points, the 3rd last bit could represent a repeating decimal or they could be used in the constants for common repeating decimals. (since chances are, repeated calculations would not produce repeating decimals) Things like those are cool and might have their application (I'm thinking mostly at message passing via TCP/IP), but have no real use in scientific computation. If you want good precision, you might as well be better off with bignum numbers. Simply not true. Maple, for example, uses constants and can compute using constants. It might speed up the calculations significantly if one could compute at the cpu level using constants. e.g. pi*sqrt(2) is just another constant. 2*pi is another constant. Obviously there is a limit to the number of constants one can store but one can encode many constants easily without storage. (where the "index" itself is used as the value) Also, the cpu could reduce values to constants... so if you have a fp value that is 3.14159265. or whatever, the cpu could convert this to the constant pi since for all purposes it is pi(even if it is just an approximation or pi - 1/10^10). Basically the benefit of this(and potential) outweigh the cost of 1 bit out of 64-bits. I doubt anyone would miss it. In fact, probably no real loss NaN could be a constant, in which case you would have only one rather than the 2 billion or whatever you have now).
Re: Repost: make foreach(i, a; range) "just work"
On Friday, 21 February 2014 at 16:41:00 UTC, Regan Heath wrote:
and make this possible too:
foreach([index, ]value; range) { }
I understand the user interface is simple, but you created 3
statements about how it could be achieved and work/not work with
the existing setup. Each have their positives and negatives, it
would not make sense to "just choose one" and hope it all works
out.
if AA is changed to a double[string], then your value loop
iterates on keys and your key loop iterates on values.
No, I was actually suggesting a change here, the compiler would
use type matching not ordering to assign the variables. So
because 'v' is a string, it is bound to the value not the key.
And string is the key, double[string] is not the same as
string[double].
Also string[string], ambiguous yet common.
There are many things to consider when adding a feature, it is
not good to ignore what can go wrong.
Thanks! Ok, so how is this working? ahh, ok I think I get it.
enumerate returns a range, whose values are Tuples of
index/value where value is also a tuple so is flattened, and
then the whole lot is flattened into the foreach.
Sounds like you understand it, seams foreach will flatten all
tuples.
I don't think this affects what I actually want to change, we
can have:
foreach(index, value; range) { }
and still flatten tuples into value, you would simply have to
provide one extra variable to get an index.
Make sense?
Yes, but I'm saying we don't need it because
foreach(index, value; range.enumerate) { }
is good enough. Not perfect, but good enough.
Re: More Illuminating Introductory Code Example on dlang.org
On Wednesday, 12 February 2014 at 20:49:54 UTC, Nordlöw wrote: What do you think, fellow D programmers? What are the odds of getting a color-enabled "terminal output"? We could try to produce some simple ascii art :D
Re: Formal review of std.lexer
On Friday, 21 February 2014 at 17:15:41 UTC, Jacob Carlborg wrote: On 2014-02-21 18:06, Andrei Alexandrescu wrote: Can we please defer this by one week? Just make the review period one week longer. This. There is no real rationale behind existing default review period so extending it until March the 15th won't cause any issues.
Re: Formal review of std.lexer
Does this mean that you're finally getting approval to release your lexer generator? On Friday, 21 February 2014 at 17:06:23 UTC, Andrei Alexandrescu wrote: Can we please defer this by one week? Thanks, Andrei
Re: Implement the "unum" representation in D ?
On Friday, 21 February 2014 at 19:12:39 UTC, Frustrated wrote: Simply not true. Maple, for example, uses constants and can compute using constants. You are mixing symbolic calculus and numerical computations. The two are completely unrelated. Basically the benefit of this(and potential) outweigh the cost of 1 bit out of 64-bits. Unless I'm completely mistaken, what you are proposing is basically creating a tagged union type. It's pretty much unrelated from the "unum" proposed by the PDF.
Re: Ada conference, Ada and Spark
On 21 February 2014 20:00, Tobias Pankrath wrote:
>
> Depends on how often and where you write those keywords. mut seems to be
> quite common and even in D I would not like 'reference' more than 'ref',
> especially since it is used in parameter lists.
>
I think Rust's "pub", "priv" and "fn" are just silly. But I don't mind
"mut". However it might've been nicer if you didn't have to write "let mut"
but just "mut".
What made Rust a no-go for me was when I tried to write a generic sort. I
still can't figure out how to swap two elements in an array ("vector"). The
implementation in their std lib for "swap" has an unsafe block... (And I
don't want a GC or RC requirement for the array.)
Re: Implement the "unum" representation in D ?
On Friday, 21 February 2014 at 19:59:36 UTC, Francesco Cattoglio wrote: On Friday, 21 February 2014 at 19:12:39 UTC, Frustrated wrote: Simply not true. Maple, for example, uses constants and can compute using constants. You are mixing symbolic calculus and numerical computations. The two are completely unrelated. Basically the benefit of this(and potential) outweigh the cost of 1 bit out of 64-bits. Unless I'm completely mistaken, what you are proposing is basically creating a tagged union type. It's pretty much unrelated from the "unum" proposed by the PDF. Yes, I mentioned that would could extend floating points to include other representations that are more efficient and reduce errors and such.
Re: Implement the "unum" representation in D ?
On Friday, 21 February 2014 at 09:04:40 UTC, Ivan Kazmenko wrote: On Friday, 21 February 2014 at 05:21:53 UTC, Frustrated wrote: I think though adding a "repeating" bit would make it even more accurate so that repeating decimals within the bounds of maximum bits used could be represented perfectly. e.g., 1/3 = 0.... could be represented perfectly with such a bit and sliding fp type. With proper cpu support one could have 0.... * 3 = 1 exactly. I believe that the repeating decimals, or better, repeating binary fractions, will hardly be more useful than a rational representation like p/q. The reason is, if we take a reciprocal 1/q and represent it as a binary, decimal, or other fixed-base fraction, the representation is surely periodic, but the upper bound on the length of its period is as high as q-1, and it is not unlikely to be the exact bound. For example, at http://en.wikipedia.org/wiki/Binary_number#Fractions , note that the binary fraction for 1/11 has period 10, and for 1/13 the period is 12. Thus repeating decimal for a fraction p/q will take up to q-1 bits when we store it as a repeating decimal, but log(p)+log(q) bits when stored as a rational number (numerator and denominator). No, you are comparing apples to oranges. The q is not the same in both equations. The number of bits for p/q when p and q are stored separately is log[2](p) + log[2](q). But when p/q is stored as a repeating decimal(assuming it repeats), then it is a fixed constant dependent on the number of bits. So in some cases the rational expression is cheaper and in other cases the repeating decimal is cheaper. e.g., .1 in theory could take 1 bit to represent wile 1/9 takes 1 + 4 = 5. (the point being is that the rational representation sometimes takes way more bits than the repeating decimal representation, other times it doesn't. Basically if we use n bits to represent the repeating decimal we can't represent repetitions that require more than n bits, in this case a rational expression may be cheaper. If we use some type of compression then rational expressions would, in general, be cheaper the larger n is. e.g., 1/9 takes 5 bits to represent as as a rational faction(4 if we require the numerator to be 1). 0.1 takes 1 bit to represent in theory but for n bits, it takes n bits. e.g., 1/9 = /10^8 = 0.000111... in decimal. Which takes 6 bits to store(000111). If n was large and fixed then I think statistically it would be best to use rational expressions rather than repeating decimals. But rational expressions are not unique and that may cause some problems with representation... unless the cpu implemented some algorithms for reduction. 1/9 = 10/90 but 10/90 takes way more bits to represent than 1/9 even though they represent the same repeating decimal and the repeating decimals bits are fixed. In any case, if the fpu had a history of calculations it could potentially store the calculations in an expression tree and attempt to reduce them. e.g., p/q*(q/p) = 1. A history could also be useful for constants in that multiplying several constants together could produce a new constant which would not introduce any new accumulation errors.
Future of D on alternate platforms
How difficult is it to port D code to future projects on alternate platforms(mainly coming from win) and, if needed be, a compiler for those platforms? At this point, I'm wondering how difficult code I'm writing for windows will be to port to, say, the iOS, mac, arm, and more likely, embedded systems such as the tigerSharc, etc. I've heard many times the LLVM compiler mentioned in the forums and it seems to be able to compile D code to any platform the compiler supports(but somehow independent of D... maybe it compiles it to an intermediate language?). My goal at this point is to use D on windows to create some algorithmic software and then potentially port it to some embedded system with minimal rewrite of the core code. e.g., I don't want to have to rewrite the algorithms in C and use the compiler tools for that system. If that was the case there is little reason to use D in the first place. Obviously there is no magic compiler that will do it all. I'm curious though as to the possibility. In 2 years could one expect D to be more widely used on other systems? I see people already getting D started on ARM and iOS so it seems feasible that in the near future it would be relatively easy to port the code(obviously there are functional differences due to the OS but I'm talking about the cpu issues at this point).
Re: More Illuminating Introductory Code Example on dlang.org
On Friday, 21 February 2014 at 16:06:04 UTC, NVolcz wrote: On Wednesday, 12 February 2014 at 20:49:54 UTC, Nordlöw wrote: On Wednesday 19:th of Februari I'm giving my first talk on D for my fellow collegues at my consultant firm office HiQ, Linköping, Sweden. If any of you are in the neighbourhood please let me know and I will invite you. The lecture will most likely be held in Swedish. I couldn't make it. How did it go? It went great! At least four of them said they will start hacking D as soon as they get the time. I will be holding more lectures in Linköping if I get the chance. Here's a reference to my lecture notes: https://drive.google.com/file/d/0BySO22MoUSXDZlBsVzllX1hsWjg/edit?usp=sharing Please correct anything if you get the chance. There's also the Facebook group "Software Craftsmanship Group Linköping" you could follow at https://www.facebook.com/groups/493309790788180/ /Per
Re: More Illuminating Introductory Code Example on dlang.org
On Friday, 21 February 2014 at 16:06:04 UTC, NVolcz wrote: On Wednesday, 12 February 2014 at 20:49:54 UTC, Nordlöw wrote: On Wednesday 19:th of Februari I'm giving my first talk on D for my fellow collegues at my consultant firm office HiQ, Linköping, Sweden. If any of you are in the neighbourhood please let me know and I will invite you. The lecture will most likely be held in Swedish. I couldn't make it. How did it go? How are you by the way? Do you live in Sweden? /Per
Open Source Report Card
Someone shared a fun little website with me. It does some kind of analysis on information it can find about you on the web and give you a summary of who you are as a programmer. http://osrc.dfm.io/w0rp "w0rp is a trend setting D coder who loves pushing code." :D It's pretty cool how it refers you to other people in the D community.
Re: Open Source Report Card
On 2/21/14, 16:38, w0rp wrote: Someone shared a fun little website with me. It does some kind of analysis on information it can find about you on the web and give you a summary of who you are as a programmer. http://osrc.dfm.io/w0rp "w0rp is a trend setting D coder who loves pushing code." :D It's pretty cool how it refers you to other people in the D community. Ah osrc.dfm.io, you flatter me. But I assure you I am amateur at best, Script kiddie at worst. But that's a pretty neat website.
Re: Formal review of std.lexer
On 2/21/14, Joseph Cassman wrote:
> 1. StringCache is a custom hash table. It looks like it's primary
> role is to reduce some sort of duplication.
It's used for string interning.
> 3. I tried to understand the reason for and usage of the
> "extraFields" parameter in "TokenStructure" but couldn't figure
> it out. Could some more explanation of its intent and usage be
> provided?
You could used it to inject a toString method. Here's what I did when I used it:
alias Token = TokenStructure!(TokID,
q{
/// Better string representation
void toString(scope void delegate(const(char)[]) sink) const
{
import std.conv;
import %s;
sink("(");
sink(this.line.to!string);
sink(":");
sink(this.column.to!string);
sink(")");
sink(": ");
sink(this.text ? this.text : tokToString(this.type));
}
}.format(__MODULE__)
);
Side-note: Note how I've had to inject an import statement to my own
module because the string is mixed-in at the declaration site of a
module which I can't modify, where IIRC tokToString didn't exist
because it's located in *my* module. It's interesting how you can use
this feature in D, IOW:
-
module mymodule;
import other_module;
void foo() { }
mixin_elsewhere!("import mymodule; foo();");
-
-
module other_module;
void mixin_elsewhere(string str)()
{
mixin(str);
}
-
P.S. the DLexer links here: https://github.com/Hackerpilot/lexer-demo/
I've used it to learn how to use DLexer, here's my more-documented
version of the above if it helps anyone, which also takes the D
parser's whitespace function and uses that in order to track column
numbers, it injects a toString like I've mentioned, and adds some
static asserts for sanity checks:
https://github.com/AndrejMitrovic/lexer-demo
Re: Formal review of std.lexer
On 2/21/14, Andrej Mitrovic wrote: > I've used it to learn how to use DLexer, here's my more-documented > version of the above if it helps anyone, which also takes the D > parser's whitespace function and uses that in order to track column > numbers, it injects a toString like I've mentioned, and adds some > static asserts for sanity checks: > > https://github.com/AndrejMitrovic/lexer-demo Hmm, maybe I should make a pull request upstream?
Re: Formal review of std.lexer
On 2/21/14, 9:51 PM, Brian Schott wrote: Does this mean that you're finally getting approval to release your lexer generator? Affirmative. It'll happen Real Soon Now(tm). Andrei
Re: Open Source Report Card
Am 21.02.2014 22:38, schrieb w0rp: Someone shared a fun little website with me. It does some kind of analysis on information it can find about you on the web and give you a summary of who you are as a programmer. http://osrc.dfm.io/w0rp "w0rp is a trend setting D coder who loves pushing code." :D It's pretty cool how it refers you to other people in the D community. Quite funny, I had a laugh when applied to my projects.
Re: Formal review of std.lexer
On Friday, 21 February 2014 at 22:14:36 UTC, Andrej Mitrovic wrote: Hmm, maybe I should make a pull request upstream? You should.
Re: Open Source Report Card
On Friday, 21 February 2014 at 21:38:30 UTC, w0rp wrote: Someone shared a fun little website with me. It does some kind of analysis on information it can find about you on the web and give you a summary of who you are as a programmer. http://osrc.dfm.io/w0rp "w0rp is a trend setting D coder who loves pushing code." :D It's pretty cool how it refers you to other people in the D community. I found it an hour ago as I'd searched for an old project of mine. I was shocked at first. But nice thing.
Modules and debugging in DWARF
Hi all, I've been making some changes in GDC that will eventually be made updated to be specially handled in GDB when it comes to non-local symbol lookup, completion, etc. Here's the current implementation in a brief nutshell. It's a bit rough, but hopefully someone with knowledge of DMD's internals may understand it well enough to update the DMD backend to produce the correct debug code. The the debug generation of 'module foo' emits a DW_TAG_module at the file name and location of the module foo. If there is no module declaration in the file, then the location defaults to line 1 in the source file. /* module foo; */ <1><2d>: Abbrev Number: 2 (DW_TAG_module) <2e> DW_AT_name: foo <32> DW_AT_decl_file : 1 <33> DW_AT_decl_line : 2 Packages are handled by emitting the parent tags first, then the sub-modules in order. Children of parent modules are referenced using DW_AT_sibling. /* module std.foo; */ <1><2d>: Abbrev Number: 2 (DW_TAG_module) <2e> DW_AT_name: std <32> DW_AT_decl_file : 1 <33> DW_AT_decl_line : 2 <2><38>: Abbrev Number: 3 (DW_TAG_module) <39> DW_AT_name: (indirect string, offset: 0xe0): foo <3d> DW_AT_decl_file : 1 <3e> DW_AT_decl_line : 2 ... /* module std.bar; */ <1><4d>: Abbrev Number: 2 (DW_TAG_module) <4e> DW_AT_name: std <52> DW_AT_decl_file : 2 <53> DW_AT_decl_line : 3 <2><58>: Abbrev Number: 3 (DW_TAG_module) <59> DW_AT_name: (indirect string, offset: 0x4b): bar <5d> DW_AT_decl_file : 2 <5e> DW_AT_decl_line : 3 The DW_TAG_module being emitted twice isn't intentional here. And more a side effect of the front-end sending two different instantiations of the same 'std' package to the backend. If it is genuinely needed, then expect this to change when I come round to it. Imported modules are tagged with DW_TAG_imported_module, and the DW_AT_import points to the external module declaration. /* import object.d. */ <3><3f>: Abbrev Number: 4 (DW_TAG_imported_module) <40> DW_AT_decl_file : 1 <41> DW_AT_decl_line : 1 <42> DW_AT_import : <0x53> [Abbrev Number: 6 (DW_TAG_module)] ... <1><53>: Abbrev Number: 6 (DW_TAG_module) <54> DW_AT_name: (indirect string, offset: 0x0): object <58> DW_AT_declaration : 1 Renamed imports are identical, but with the addition of DW_AT_name to reference the alias. /* import simd = core.simd; */ <3><46>: Abbrev Number: 5 (DW_TAG_imported_module) <47> DW_AT_decl_file : 1 <48> DW_AT_decl_line : 4 <49> DW_AT_name: (indirect string, offset: 0x81): simd <4d> DW_AT_import : <0x63> [Abbrev Number: 6 (DW_TAG_module)] ... <1><58>: Abbrev Number: 7 (DW_TAG_module) <59> DW_AT_name: (indirect string, offset: 0x8d): core <5d> DW_AT_decl_file : 2 <5e> DW_AT_decl_line : 13 <5f> DW_AT_sibling : <0x69> <2><63>: Abbrev Number: 6 (DW_TAG_module) <64> DW_AT_name: (indirect string, offset: 0x81): simd <68> DW_AT_declaration : 1 And currently I'm testing selective imports to be represented as DW_TAG_imported_declaration. Don't have any examples for yet, but it looks like it would be the imported declaration tag pointing to the real declaration. Regards Iain.
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
On Thursday, 20 February 2014 at 22:33:34 UTC, Paulo Pinto wrote: Am 20.02.2014 23:09, schrieb Walter Bright: On 2/20/2014 12:17 PM, Paulo Pinto wrote: I used common base object in Turbo Pascal, C++, Oberon(-2), Java and C#, before the said languages got any form of generics. I don't miss those days. Isn't it interesting how the "OOP everywhere" mantra of the late 80's / early 90's has largely disappeared? Yes, like every new paradigm I think people tend to go overboard. Last example is the discussion about OOP vs FP, when most languages used in such discussions are actually multi-paradigm, even if they are functional first vs object first. Regarding OO, it is interesting to see how after all those years we are finally getting to the interfaces/traits usage coupled with generics, with little inheritance. Ideally of course, many people still haven't got to it. -- Paulo That makes me sad that D has Java's object model rather than let's say, scala's (which work with traits/interfaces).
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
On 2/21/2014 5:27 PM, deadalnix wrote: That makes me sad that D has Java's object model rather than let's say, scala's (which work with traits/interfaces). D's object model works with interfaces.
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
On Saturday, 22 February 2014 at 01:36:48 UTC, Walter Bright wrote: On 2/21/2014 5:27 PM, deadalnix wrote: That makes me sad that D has Java's object model rather than let's say, scala's (which work with traits/interfaces). D's object model works with interfaces. I'm talking about this: http://joelabrahamsson.com/learning-scala-part-seven-traits/
Re: Open Source Report Card
On Friday, 21 February 2014 at 21:38:30 UTC, w0rp wrote: Someone shared a fun little website with me. It does some kind of analysis on information it can find about you on the web and give you a summary of who you are as a programmer. http://osrc.dfm.io/w0rp "w0rp is a trend setting D coder who loves pushing code." :D It's pretty cool how it refers you to other people in the D community. Ha, it said the same thing about me, and all I've ever done is submit a few typo corrections to some D related projects. I wish it were true.
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
On Saturday, 22 February 2014 at 01:39:28 UTC, deadalnix wrote: On Saturday, 22 February 2014 at 01:36:48 UTC, Walter Bright wrote: On 2/21/2014 5:27 PM, deadalnix wrote: That makes me sad that D has Java's object model rather than let's say, scala's (which work with traits/interfaces). D's object model works with interfaces. I'm talking about this: http://joelabrahamsson.com/learning-scala-part-seven-traits/ https://gist.github.com/JesseKPhillips/9147869 Two notes, Creating an array required casting the first item to the common type. D doesn't let you creating a new object and implement an interface. It seems that std.typecons is getting tripped up on the final method fly() so it can't be used either.
Re: Open Source Report Card
On Fri, 21 Feb 2014 15:38:29 -0600, w0rp wrote: Someone shared a fun little website with me. It does some kind of analysis on information it can find about you on the web and give you a summary of who you are as a programmer. http://osrc.dfm.io/w0rp "w0rp is a trend setting D coder who loves pushing code." :D It's pretty cool how it refers you to other people in the D community. http://osrc.dfm.io/Orvid Apparently I am a C# coder (have been for the last 3 years, only came into real D dev within the last year or so), and yet "It seems like Orvid is—or should be—friends with jacob-carlborg."
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
On Saturday, 22 February 2014 at 02:52:37 UTC, Jesse Phillips wrote: On Saturday, 22 February 2014 at 01:39:28 UTC, deadalnix wrote: On Saturday, 22 February 2014 at 01:36:48 UTC, Walter Bright wrote: On 2/21/2014 5:27 PM, deadalnix wrote: That makes me sad that D has Java's object model rather than let's say, scala's (which work with traits/interfaces). D's object model works with interfaces. I'm talking about this: http://joelabrahamsson.com/learning-scala-part-seven-traits/ https://gist.github.com/JesseKPhillips/9147869 Two notes, Creating an array required casting the first item to the common type. D doesn't let you creating a new object and implement an interface. It seems that std.typecons is getting tripped up on the final method fly() so it can't be used either. This code works fine: http://dpaste.dzfl.pl/c0b3a941d917
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
On Saturday, 22 February 2014 at 03:03:18 UTC, Meta wrote: This code works fine: http://dpaste.dzfl.pl/c0b3a941d917 That is an anonymous class, that is defining and instantiating the class, which isn't what the scala code was doing. (BTW this feature was added because Java could do it).
Re: [Fwd: Re: [go-nuts] Re: Generics false dichotomy]
On Saturday, 22 February 2014 at 03:41:29 UTC, Jesse Phillips wrote: On Saturday, 22 February 2014 at 03:03:18 UTC, Meta wrote: This code works fine: http://dpaste.dzfl.pl/c0b3a941d917 That is an anonymous class, that is defining and instantiating the class, which isn't what the scala code was doing. (BTW this feature was added because Java could do it). Sorry, I thought you meant it doesn't allow you to create a new object that implements a certain interface, instead of creating a new object and then implement an interface. Looking at the Scala example again, I see it is indeed different.
Re: Repost: make foreach(i, a; range) "just work"
On Thursday, 20 February 2014 at 19:34:17 UTC, w0rp wrote:
I suppose the next step after that would be to
support nested unpacking, but that would require a change in
syntax so it would be much more complicated.
You mean this?
void main() {
import std.typecons : tuple;
import std.range : repeat;
foreach(k,v1, v2; tuple(1, tuple(2, 3)).repeat(4))
{}
}
Yeah, that works.
Re: Open Source Report Card
On Friday, 21 February 2014 at 21:38:30 UTC, w0rp wrote: Someone shared a fun little website with me. It does some kind of analysis on information it can find about you on the web and give you a summary of who you are as a programmer. http://osrc.dfm.io/w0rp "w0rp is a trend setting D coder who loves pushing code." :D It's pretty cool how it refers you to other people in the D community. http://osrc.dfm.io/rikkimax "Richard Andrew Cattermole is an epic D coder (one of the 28% most active D users) who loves pushing code. Richard is a fulltime hacker who works best around midnight." Tis interesting this site.
