Re: std.functional.compose compilation error
On Thursday, 25 August 2016 at 14:30:00 UTC, Meta wrote:
On Thursday, 25 August 2016 at 14:06:32 UTC, Antonio Corbi
wrote:
Hello,
Trying to compile this example from Chuck Allison:
---
import std.stdio;
import std.functional;
void main() {
auto div3 = (double x) => x/3.0;
auto sq = (double x) => x*x;
auto pls1 = (double x) => x+1.0;
alias compose!(div3,sq,pls1) comp;
writeln(comp(2.0)); // 3 == (2.0+1.0)^^2 / 3.0
alias pipe!(div3,sq,pls1) pip;
writeln(pip(2.0)); // 1.4 == (2.0/3.0)^^2 + 1.0
}
I get this error (with DMD64 D Compiler v2.071.1 in linux):
compose.d(8): Error: template instance compose!(div3, sq,
pls1) compose is not a template declaration, it is a module
But the error disappears if I use this import:
import std.functional:compose,pipe;
Is this a bug or is it the expected behaviour under the recent
'import' changes?
Thanks!
Try renaming your source file to something other than
compose.d, I think that's confusing the compiler.
Yep, that did the trick!
I also noticed that 'old' compilers like:
- gdc: gdc (GCC) 6.1.1 20160501
- ldc: LDC - the LLVM D compiler (1.0.0): based on DMD v2.070.2
and LLVM 3.8.0
*do* compile the original code posted without error.
Thank's to all of you for your answers.
Re: Judy Arrays
On Thursday, 25 August 2016 at 20:42:42 UTC, Illuminati wrote: http://judy.sourceforge.net/downloads/10minutes.htm Would be nice to have such an implementation. Supposedly one of the best all around data structures in existence? Maybe D could be used to make them work with arbitrary cache-sizes? Anyone up for the challenge? Also, I think it would be best to avoid the GC, so it works in both GC code and non-gc code.
Judy Arrays
http://judy.sourceforge.net/downloads/10minutes.htm Would be nice to have such an implementation. Supposedly one of the best all around data structures in existence? Maybe D could be used to make them work with arbitrary cache-sizes? Anyone up for the challenge?
Re: Nogc Associative Array?
On Thursday, 25 August 2016 at 20:11:32 UTC, Laeeth Isharc wrote: On Thursday, 25 August 2016 at 18:14:42 UTC, Illuminati wrote: Does D have a non-gc based associative array? If not, what would be a good way to go about creating one? See EMSI containers in code.dlang.org Thanks.
Re: union mutability
On Thursday, August 25, 2016 19:43:49 Jack Applegame via Digitalmars-d-learn wrote: > Also I hate Rebindable. Yeah, well, without a language change, it's the best that we have for dealing with the problem that it's designed to solve. D just isn't designed with the idea that there's any distinction between the type of a class reference and the type of the class it refers to. - Jonathan M Davis
Re: Nogc Associative Array?
On Thursday, 25 August 2016 at 18:14:42 UTC, Illuminati wrote: Does D have a non-gc based associative array? If not, what would be a good way to go about creating one? See EMSI containers in code.dlang.org
Re: union mutability
On Thursday, 25 August 2016 at 19:19:49 UTC, Jonathan M Davis wrote: Why? I don't know exactly what that PR is supposed to do, but std.datetime uses immutable time zone objects, and if that PR made it so that you couldn't have an immutable instance of a class, then it would have failed the auto-tester. And it clearly doesn't stop having unions with immutable members, or it would have failed to compile because of Rebindable (though it may be that Rebindable can no longer be used in @safe code). - Jonathan M Davis Because lack of mutable references to immutable classes in @safe code is big PITA for me. It is easier to not use immutable classes at all.
Re: union mutability
Also I hate Rebindable.
Re: union mutability
On Thursday, August 25, 2016 18:27:25 Jack Applegame via Digitalmars-d-learn wrote: > On Thursday, 25 August 2016 at 17:01:40 UTC, Meta wrote: > > This should be fixed pretty soon: > > https://github.com/dlang/dmd/pull/5940 > > Bye-bye immutable classes. :'( Why? I don't know exactly what that PR is supposed to do, but std.datetime uses immutable time zone objects, and if that PR made it so that you couldn't have an immutable instance of a class, then it would have failed the auto-tester. And it clearly doesn't stop having unions with immutable members, or it would have failed to compile because of Rebindable (though it may be that Rebindable can no longer be used in @safe code). - Jonathan M Davis
Re: union mutability
On Thursday, 25 August 2016 at 17:01:40 UTC, Meta wrote: This should be fixed pretty soon: https://github.com/dlang/dmd/pull/5940 Bye-bye immutable classes. :'(
Re: nested enum
On Thursday, 25 August 2016 at 01:37:05 UTC, Mike Parker wrote:
On Wednesday, 24 August 2016 at 23:04:25 UTC, Illuminati wrote:
How can I create nested enum like structures?
instead of Enum.X_Y I would like to access like Enum.X.Y
Yet I want it to behave exactly as an enum. I just want to
not use _ as .'s are better as they express more clearly what
I want.
struct MyEnum {
enum X { Y = 10, Z = 20 }
}
void main() {
import std.stdio;
int y = MyEnum.X.Y;
writeln(y);
}
Thanks. I should have thought of that.
Re: std.functional.compose compilation error
On Thursday, August 25, 2016 17:50:44 bachmeier via Digitalmars-d-learn wrote: > On Thursday, 25 August 2016 at 17:49:26 UTC, bachmeier wrote: > > On Thursday, 25 August 2016 at 15:04:43 UTC, Jonathan M Davis > > > > wrote: > >> Yes. Because the module is compose, within that file, compose > >> will refer to the module, not anything you import. The > >> selective import essentially creates a local alias like > >> > >> alias compose = std.functional.compose; > >> > >> as part of the import, so then within that scope, compose > >> refers to that alias and not to the module. You'll run into > >> the same problem any time that you give a module the same name > >> as a symbol that you're importing. > >> > >> - Jonathan M Davis > > > > Is there a reason there is not a warning for this when > > compiling? I think it explains a problem I had some time ago > > that cost me a lot of time. > > I mean there should be a better message. If you have a suggestion for a better message, then feel free to open a bug report for it - https://issues.dlang.org - or even create a pull request to fix it if you're feeling ambitious. But shadowing like this is a normal part of the module system. You'd get the same problem if your module was named something else, and you declared a function named compose in your module and then tried to use the compose from std.functional without fully qualifying it. It can certainly be annoying if you don't realize that that's what's happening, but how is the compiler going to know that what you meant to use the version of compose from another module rather than the one in the current module? All it knows is that you're using it wrong. - Jonathan M Davis
Nogc Associative Array?
Does D have a non-gc based associative array? If not, what would be a good way to go about creating one?
Re: std.functional.compose compilation error
On Thursday, 25 August 2016 at 17:49:26 UTC, bachmeier wrote: On Thursday, 25 August 2016 at 15:04:43 UTC, Jonathan M Davis wrote: Yes. Because the module is compose, within that file, compose will refer to the module, not anything you import. The selective import essentially creates a local alias like alias compose = std.functional.compose; as part of the import, so then within that scope, compose refers to that alias and not to the module. You'll run into the same problem any time that you give a module the same name as a symbol that you're importing. - Jonathan M Davis Is there a reason there is not a warning for this when compiling? I think it explains a problem I had some time ago that cost me a lot of time. I mean there should be a better message.
Re: std.functional.compose compilation error
On Thursday, 25 August 2016 at 15:04:43 UTC, Jonathan M Davis wrote: Yes. Because the module is compose, within that file, compose will refer to the module, not anything you import. The selective import essentially creates a local alias like alias compose = std.functional.compose; as part of the import, so then within that scope, compose refers to that alias and not to the module. You'll run into the same problem any time that you give a module the same name as a symbol that you're importing. - Jonathan M Davis Is there a reason there is not a warning for this when compiling? I think it explains a problem I had some time ago that cost me a lot of time.
Re: union mutability
On Thursday, 25 August 2016 at 15:22:23 UTC, Jack Applegame wrote:
Code:
union A {
immutable int f;
}
union B {
immutable int f;
int e;
}
void main() {
A a = A(1);
//a = A(2); // a.f is immutable, fails to compile as
expected
B b = B(1);
b = B(2); // compiles!!!
}
It turns out that if the union contains at least one mutable
member, then the entire union is considered to be mutable.
It's logical, but does it meet the specs? I couldn't find
description of this behavior.
This should be fixed pretty soon:
https://github.com/dlang/dmd/pull/5940
Re: union mutability
On Thursday, August 25, 2016 15:22:23 Jack Applegame via Digitalmars-d-learn
wrote:
> Code:
>
> union A {
> immutable int f;
> }
>
> union B {
> immutable int f;
> int e;
> }
>
> void main() {
> A a = A(1);
> //a = A(2); // a.f is immutable, fails to compile as expected
>
> B b = B(1);
> b = B(2); // compiles!!!
> }
>
> It turns out that if the union contains at least one mutable
> member, then the entire union is considered to be mutable.
> It's logical, but does it meet the specs? I couldn't find
> description of this behavior.
Well, Rebindable depends on it (though Rebindable is in a legal grey area at
best and technically in violation of the rules at worst). It's basically the
same as when you cast away const or immutable - it's fine as long as you
don't mutate the variable and thus break the guarantees that compiler has
for const or immutable objects. But I don't know how you can really do
anything with it without violating immutable. Certainly, in any case other
than what Rebindable is up to, I wouldn't do it, and even then, I suspect
that Rebindable is in a situation where it's technically violating the
compiler's guarantees but does so in a way that will never actually result
in problems in practice.
But yes, this behavior is known, albeit questionable.
- Jonathan M Davis
Re: nested enum
On Thursday, 25 August 2016 at 11:09:43 UTC, Cauterite wrote: On Thursday, 25 August 2016 at 10:36:21 UTC, Daniel Kozak wrote: Btw, tehre is no need for extra semicolon (`;`) after enum and struct definition Thanks. This forum insists on reminding me every time I write code here. Warning about this is now an enhancement request: https://issues.dlang.org/show_bug.cgi?id=16430
union mutability
Code:
union A {
immutable int f;
}
union B {
immutable int f;
int e;
}
void main() {
A a = A(1);
//a = A(2); // a.f is immutable, fails to compile as expected
B b = B(1);
b = B(2); // compiles!!!
}
It turns out that if the union contains at least one mutable
member, then the entire union is considered to be mutable.
It's logical, but does it meet the specs? I couldn't find
description of this behavior.
Re: std.functional.compose compilation error
On Thursday, August 25, 2016 14:30:00 Meta via Digitalmars-d-learn wrote:
> On Thursday, 25 August 2016 at 14:06:32 UTC, Antonio Corbi wrote:
> > Hello,
> >
> > Trying to compile this example from Chuck Allison:
> > ---
> > import std.stdio;
> > import std.functional;
> >
> > void main() {
> >
> > auto div3 = (double x) => x/3.0;
> > auto sq = (double x) => x*x;
> > auto pls1 = (double x) => x+1.0;
> > alias compose!(div3,sq,pls1) comp;
> > writeln(comp(2.0)); // 3 == (2.0+1.0)^^2 / 3.0
> > alias pipe!(div3,sq,pls1) pip;
> > writeln(pip(2.0)); // 1.4 == (2.0/3.0)^^2 + 1.0
> >
> > }
> >
> >
> > I get this error (with DMD64 D Compiler v2.071.1 in linux):
> >
> > compose.d(8): Error: template instance compose!(div3, sq, pls1)
> > compose is not a template declaration, it is a module
> >
> > But the error disappears if I use this import:
> >import std.functional:compose,pipe;
> >
> > Is this a bug or is it the expected behaviour under the recent
> > 'import' changes?
> > Thanks!
>
> Try renaming your source file to something other than compose.d,
> I think that's confusing the compiler.
Yes. Because the module is compose, within that file, compose will refer to
the module, not anything you import. The selective import essentially
creates a local alias like
alias compose = std.functional.compose;
as part of the import, so then within that scope, compose refers to that
alias and not to the module. You'll run into the same problem any time that
you give a module the same name as a symbol that you're importing.
- Jonathan M Davis
Re: std.functional.compose compilation error
On Thursday, 25 August 2016 at 14:06:32 UTC, Antonio Corbi wrote:
Hello,
Trying to compile this example from Chuck Allison:
---
import std.stdio;
import std.functional;
void main() {
auto div3 = (double x) => x/3.0;
auto sq = (double x) => x*x;
auto pls1 = (double x) => x+1.0;
alias compose!(div3,sq,pls1) comp;
writeln(comp(2.0)); // 3 == (2.0+1.0)^^2 / 3.0
alias pipe!(div3,sq,pls1) pip;
writeln(pip(2.0)); // 1.4 == (2.0/3.0)^^2 + 1.0
}
I get this error (with DMD64 D Compiler v2.071.1 in linux):
compose.d(8): Error: template instance compose!(div3, sq, pls1)
compose is not a template declaration, it is a module
But the error disappears if I use this import:
import std.functional:compose,pipe;
Is this a bug or is it the expected behaviour under the recent
'import' changes?
Thanks!
Try renaming your source file to something other than compose.d,
I think that's confusing the compiler.
std.functional.compose compilation error
Hello,
Trying to compile this example from Chuck Allison:
---
import std.stdio;
import std.functional;
void main() {
auto div3 = (double x) => x/3.0;
auto sq = (double x) => x*x;
auto pls1 = (double x) => x+1.0;
alias compose!(div3,sq,pls1) comp;
writeln(comp(2.0)); // 3 == (2.0+1.0)^^2 / 3.0
alias pipe!(div3,sq,pls1) pip;
writeln(pip(2.0)); // 1.4 == (2.0/3.0)^^2 + 1.0
}
I get this error (with DMD64 D Compiler v2.071.1 in linux):
compose.d(8): Error: template instance compose!(div3, sq, pls1)
compose is not a template declaration, it is a module
But the error disappears if I use this import:
import std.functional:compose,pipe;
Is this a bug or is it the expected behaviour under the recent
'import' changes?
Thanks!
Re: nested enum
On Thursday, 25 August 2016 at 10:36:21 UTC, Daniel Kozak wrote: Btw, tehre is no need for extra semicolon (`;`) after enum and struct definition Thanks. This forum insists on reminding me every time I write code here.
Re: nested enum
Btw, tehre is no need for extra semicolon (`;`) after enum and struct
definition
Dne 25.8.2016 v 12:23 Cauterite via Digitalmars-d-learn napsal(a):
On Wednesday, 24 August 2016 at 23:04:25 UTC, Illuminati wrote:
Well those other answers aren't wrong, but I envisioned that you'd
have multiple categories within your sub-enums and whatnot, so you'd
need something more like this:
struct A {
enum X {
one,
two,
three,
};
enum Y {
four = X.max + 1,
five,
six,
};
enum Z {
seven = Y.max + 1,
eight,
nine,
};
};
Continuing each enumeration from the end of the previous ensures you
won't get any fields with the same values.
Re: nested enum
On Wednesday, 24 August 2016 at 23:04:25 UTC, Illuminati wrote:
Well those other answers aren't wrong, but I envisioned that
you'd have multiple categories within your sub-enums and whatnot,
so you'd need something more like this:
struct A {
enum X {
one,
two,
three,
};
enum Y {
four = X.max + 1,
five,
six,
};
enum Z {
seven = Y.max + 1,
eight,
nine,
};
};
Continuing each enumeration from the end of the previous ensures
you won't get any fields with the same values.
