Re: Overloads not returning appropriate info. [Field reflunkory]
On Wed, Apr 10, 2019 at 11:05:27PM +, Adam D. Ruppe via Digitalmars-d-learn
wrote:
> On Wednesday, 10 April 2019 at 19:29:13 UTC, Alex wrote:
> > I wonder if there are some interesting patterns of nesting is's?
> >
> > is(...is(...is(...)...)...)
>
> No, at least not like that. You'd get nothing out of it, even if you
> made it work.
>
> But, I have in the past nested static ifs with different is things in
> order to handle very complex patterns that are difficult to express in
> one.
>
> I can't remember what those are right now though... but if one level
> fails, you might do
>
> static if(is( something ))
> static if(is( details )) {
>
> }
>
> to drill down. But while I know I have done this before, it is rare
> enough that I cannot recall it!
It happens when your static if condition has two or more clauses, and
the compilability of one of the later clauses depend on the truth of a
previous clause. Static if conditions do respect && short-circuit
evaluation, but they do not allow you to bypass compilability, so if you
have something like:
static if (A & B) { ... }
where B is not compilable unless A is true, then you cannot write it
this way, and have to nest it like you wrote above.
T
--
We've all heard that a million monkeys banging on a million typewriters will
eventually reproduce the entire works of Shakespeare. Now, thanks to the
Internet, we know this is not true. -- Robert Wilensk
Re: Overloads not returning appropriate info. [Field reflunkory]
On Wednesday, 10 April 2019 at 19:29:13 UTC, Alex wrote:
I wonder if there are some interesting patterns of nesting is's?
is(...is(...is(...)...)...)
No, at least not like that. You'd get nothing out of it, even if
you made it work.
But, I have in the past nested static ifs with different is
things in order to handle very complex patterns that are
difficult to express in one.
I can't remember what those are right now though... but if one
level fails, you might do
static if(is( something ))
static if(is( details )) {
}
to drill down. But while I know I have done this before, it is
rare enough that I cannot recall it!
Re: Dummy template parameter vs empty template parameter list
On Wednesday, 10 April 2019 at 20:37:38 UTC, Ben Jones wrote: Looking through Phobos code there's a bunch functions defined with dummy template types: void whatever(TDummy = void)( int x, ...) //TDummy is never used Why not just use an empty template parameter list? void whatever()(int x, ...) My gut tells me that his is a workaround for an old limitation preventing empty template lists, but figured I'd ask. It depends on the specific function, but there's lots of old code in Phobos. In this case it could be that it was a workaround for a DMD bug or limitation that has since been fixed. So never be afraid to question Phobos code and give it the full scrutiny it needs. A good rule of thumb is that if all unittests still pass, the reason was historic ;-)
Re: Templates - What's Up with the template keyword?
On 04/10/2019 05:07 AM, Ron Tarrant wrote: >> the book's index: >> >> http://ddili.org/ders/d.en/ix.html > Oops! Not at all. One of the most useful parts of the book has been the index section for me. I occasionally search in there... like just yesterday for the positional format specifier %1$. :) Ali
Dummy template parameter vs empty template parameter list
Looking through Phobos code there's a bunch functions defined with dummy template types: void whatever(TDummy = void)( int x, ...) //TDummy is never used Why not just use an empty template parameter list? void whatever()(int x, ...) My gut tells me that his is a workaround for an old limitation preventing empty template lists, but figured I'd ask.
Re: Overloads not returning appropriate info. [Field reflunkory]
On Tuesday, 9 April 2019 at 21:00:55 UTC, H. S. Teoh wrote: On Tue, Apr 09, 2019 at 08:49:17PM +, Alex via Digitalmars-d-learn wrote: On Tuesday, 9 April 2019 at 18:56:58 UTC, H. S. Teoh wrote: [...] My point has been and is that there is a better way that is more natural. I make no claims about anything else. It may be a cop out to say something that is a tautology but I make the claim as an emphasis that I believe that it is more true in this case than others. i.e., D's traits are PITA. Ok, they are not as bad as some things but I know they can be better since I have used other languages that have far more logical reflection(such as C#) than D. As I said, __traits was never designed to be user-friendly, or even "logical". It was supposed to be a quick-and-easy way to tap into compiler internals, and std.traits was supposed to be the proper API to introspection. But std.traits, as it stands, is far, far from what it ought to be, and so we have today's sorry situation. That's unfortunate... but at least they are generally pretty functional. I remember trying to do basic type comparisons in C#'s reflection and didn't have the capability(I think it got it later but I believe that was the time I left for D). I can understanding adding traits int he way it was, but at some point it has to be brought to the same standard as the rest of the language. It's just far too important to neglect. After all, Even most of phobos is using meta programming. (And on a side note: don't even get me started on is(...) expressions.) Anyway, since you seem to be passionate about this, this could be your chance of making std.traits what it ought to have been all along, or making a sensible reflection library that can for all practical purposes replace std.traits. The problem is, I believe to do it right, it should be done in the compiler(at least some changes) and I know virtually nothing about the design and internals, so it would be much more time consuming than I'd like). I feel if I were going to go down that route I'd rather spend time writing a compiler or getting better as functional programming. I, for one thing, would appreciate a nicer API to introspection than what we currently have. One of the main things that drew me to D was its metaprogramming capabilities, and while overall it has been a positive experience, there *are* flies in the ointment like __traits, is(...) expressions, etc.. If you or somebody else could come up with a saner way to do introspection in D, it'd be very much appreciated. Basically same here. D is one of those love/hate relationships ;/ Meta programming is the next stage of evolution of programming. It is necessary for simplifying the complex problems of the modern computing world. D does have quite a nice syntax for most of this and does reasonably well(Although I believe functional programming blows D's type system out the water since it deals with structural mapping directly without "special cases").
Re: Overloads not returning appropriate info. [Field reflunkory]
On Wednesday, 10 April 2019 at 02:19:42 UTC, Adam D. Ruppe wrote: On Tuesday, 9 April 2019 at 20:45:18 UTC, Alex wrote: On Tuesday, 9 April 2019 at 18:33:21 UTC, Seb wrote: Have you considered writing a DIP? No, because I expect it won't even be considered. You won't pass review if you don't show knowledge of the existing language, but there's a lot of people who are interested in a few changes. A few years ago, there was a proposal for a magical `meta` namespace that would call into the compiler for syntax sugar on CT reflection. The old idea was to replace `__traits(X, args)` with `meta.X(args)` - pure syntax change - but you could perhaps revive and expand that as the entry point to your new idea and get some people on board. Yeah, but that isn't really effective, virtually identical. I am talking about one level higher abstraction. I mean, it's all the same but I'd like things to be sorta based in oop and ranges(UFCS like stuff). I haven't though about it enough to know how it would work out but I imagine things could be done very nicely. E.g., some accessors get information and some process that information and one can combine and match as needed. X.Type.name, X.Members.Select!"foo".Memebers.Select!"bar"(assuming foo is an aggregate), etc. Range functionality could even be used to process arrays(I guess the return of the traits would need to be ranges). I'm skeptical of any reflection library, but compiler changes might be able to change that. The status quo for D's reflection libraries are: 1) weird bugs and/or omissions since the language does not let you express all the function parameter details as return values or local variables. 2) slow compile times (you said your thing was 10 seconds! that's utterly unacceptable) It actually is not to bad. I haven't done much testing but at least repeatedly calling the Reflect on the same base type added little overhead(it wasn't scaling linearly with the number of calls). So maybe it has a chance. Still will never be as efficient as doing it internally though. 3) not actually significantly easier to use than language built-ins (if they are actually easier to use at all!) So any library without compiler changes is, as of today, I believe *impossible* to get right, and getting as close as you can is horribly slow. So, your DIP would necessarily include language+compiler changes. And the compiler is *already* (almost) fully capable, so changing that needs to show that the change is worth it. Maybe you can do that, even little cosmetic things can indeed be a win, but to write a convincing case here, you'll need to compare and contrast various cases. I'd definitely rather see this in the compiler. I just no zero about Dmd's design and the specifics. It's not something I'm capable of doing without a significant investment that I'm not willing to do(only if I could add the design on top without having to "learn" everything about the compiler). My goal was to sort of bridge the gap of the ideal solution and what we have. Something I could use personally to solve most of the frustrations I have but I wasn't thinking of trying to make it in to something ideal.
Re: Overloads not returning appropriate info. [Field reflunkory]
On Wednesday, 10 April 2019 at 14:06:53 UTC, Adam D. Ruppe wrote: On Wednesday, 10 April 2019 at 10:18:35 UTC, H. S. Teoh wrote: [...] There's a little bit weird about it, but it makes sense. I used to find it hard to even remember how it works, but then I had to describe it for the book and it all came together. Consider this. [...] I wonder if there are some interesting patterns of nesting is's? is(...is(...is(...)...)...)
Cyclic dependency between module A and B
Recently (before refactoring) my application complained right after invocation: object.Error@src/rt/minfo.d(371): Cyclic dependency between module Filebrowser and App Filebrowser* -> App* -> Filebrowser* Is it possible to detect this dependency before the program is started? Perhaps during linking?
DCD 0 symbols cached?
Total newbie to D, trying to get it to play nice with Neovim using ncm2-d and DCD. Issue: DCD never caches any symbols even when I point it directly to DMD's include files. Hate to ask for tech support on this forum but it's all I've got, Googling has brought no luck. Using dcd version v0.11.0 Output from dcd-server -I /usr/include/dmd/phobos -I /usr/include/dmd/druntime/import : 2019-04-10T11:34:43.386 [info] main.d:130:runServer Starting up... 2019-04-10T11:34:43.386 [info] main.d:157:runServer Cleaning up old socket file at /run/user/1000/dcd.socket 2019-04-10T11:34:43.387 [info] main.d:164:runServer Listening at /run/user/1000/dcd.socket 2019-04-10T11:34:43.387 [info] main.d:181:runServer Import directories: /usr/include/dmd/phobos /usr/include/dmd/druntime/import 2019-04-10T11:34:43.387 [info] main.d:187:runServer 0 symbols cached. 2019-04-10T11:34:43.387 [info] main.d:188:runServer Startup completed in 0 milliseconds. Any tips or guidance would be greatly appreciated. Thank you.
Re: DRuntime arguments
On Wednesday, 10 April 2019 at 12:11:06 UTC, Cym13 wrote: Where can I find a list of all druntime arguments supported? Things like --DRT-covopt='merge:1' or --DRT-gcopt='gc:profile=1' are not easy to guess and I can't find any centralized documentation. There isn't any yet.
Re: Overloads not returning appropriate info. [Field reflunkory]
On Wednesday, 10 April 2019 at 10:18:35 UTC, H. S. Teoh wrote:
The functionality rocks, but the syntax is a horrendous
hairball of inconsistencies and design-by-chance.
There's a little bit weird about it, but it makes sense.
I used to find it hard to even remember how it works, but then I
had to describe it for the book and it all came together.
Consider this.
Declaring a normal local variable:
---
int foo = 0;
---
We can generalize that to
---
Type_Name Local_Name Operator Initial_Value
---
Well, now, compare to the is expression:
---
is(typeof(func) Params == __parameters)
---
It is a bit of a stretch, but the general shape is the same. We
can define the is expression generally to be:
is(Type_Name Local_Name Deconstruction_Pattern)
And then both Local_Name and Deconstruction_Pattern are optional.
This gives us all the forms from the website
https://dlang.org/spec/expression.html#IsExpression (from point
#5 there)
1: is(Type). This has the type, but left out the local name and
deconstruction pattern. All it cares about is if the type exists.
2: is(Type : something). This deconstruction pattern, using :,
means "can implicitly convert to something"
The deconstruction pattern mimics common ways of writing such
types; class A : B {} defines a type A that can implicitly cast
to B, so is(A : B) would pass and return true.
3: is(Type == something). This deconstruction pattern, using ==,
just needs an exact match. It is probably the easiest one for
people to remember.
4: is(Type Identifier). This skips the deconstruction pattern,
meaning it is the most basic "this type must exist" check, but
includes the local name.
Like with `int a;`, the name comes after the type.
5: is(Type Identifier : something). This is just #2 again, but
including the optional local name.
6: is(Type Identifier == something). Just #3 including the
optional local name.
At this point, the documentation also includes other
deconstruction patterns, like the `class` keyword, etc. These are
mostly very simple, but it is slightly magical in places because
it can initialize Identifier to other thing.. but is that really
weird?
int a = 10;
The value of a is dependent on the right side, and so is the
Identifier here.
It looks totally wrong because it is using == here rather than =,
so we intuitively think
is(A B == C)
is comparing B and C... but just rewrite in your brain that this
is actually declaring a variable with a funky deconstruction
initializer and it will make sense again.
So the whole `== C` part is the deconstruction pattern, and B is
the variable being set to it. And being a deconstruction pattern,
it is trying to pull layers off, so stuff like
is(MyClass Parents == super),
the ==super pattern is deconstructing its super keyword; its base
classes.
Think of it not as comparison, but as matching a deconstruction
pattern and it will make more sense.
I know its weird, but we can work with it. Let's move on:
7: This one has a lot of examples, but it really just expands on
the deconstruction pattern. For example:
static if(is(int[10] == T[N], T, size_t N))
What's the pattern here?
== means use exact comparison, not implicitly converting
comparison.
T[N] writes out a model of what the declaration is expected to
look like.
Then commas separate the definitions of each placeholder
variable, just as if they were template argument definitions.
Same syntax, different location.
The one tricky thing is the compiler will not tell you when you
malformed the pattern (for the most part), just nothing will
happen to match it. So match it on some known quantity to test
via static assert or something.
To use a complex pattern with the optional name:
static if(is(int[10] OriginalType == T[N], T, size_t N))
that's all the pieces together. Not so bad when you know how it
breaks down.
Re: Templates - What's Up with the template keyword?
On Wednesday, 10 April 2019 at 00:42:11 UTC, Ali Çehreli wrote: Your code did not work because Point is not a type but a type template. (On the other hand, Point!double is a type). The whole program: Thanks very much, Ali! Obviously, I've got some studying ahead of me.
DRuntime arguments
Where can I find a list of all druntime arguments supported? Things like --DRT-covopt='merge:1' or --DRT-gcopt='gc:profile=1' are not easy to guess and I can't find any centralized documentation.
Re: Templates - What's Up with the template keyword?
On Wednesday, 10 April 2019 at 00:22:47 UTC, Ali Çehreli wrote: On 04/08/2019 05:23 AM, Ron Tarrant wrote: > But in "Programming in D," (self, 2009-2018) by Ali Çehreli, there's no > mention of the 'template' keyword in any of his examples. 'template' keyword is introduced here: http://ddili.org/ders/d.en/templates_more.html#ix_templates_more.template I found that page by clicking on one of the two 'template' entries under T in the book's index: http://ddili.org/ders/d.en/ix.html Ali Oops! Sorry, Ali. Since the advent of PDF, I rarely think to look in a book's index. I shall go blush now. And apologies for making such a blanket statement about not mentioning the template keyword. I've learned a lot from your book and I don't want to create the impression I haven't.
Re: Templates - What's Up with the template keyword?
On Tuesday, 9 April 2019 at 20:48:45 UTC, Steven Schveighoffer wrote: The thing that made it click for me is that a template is very akin to a macro substitution -- where you just copy and paste the given parameter wherever its substitute is found. Nicely put. Thanks, Steve. I at least get the basics now.
Re: Overloads not returning appropriate info. [Field reflunkory]
On Wed, Apr 10, 2019 at 02:22:35AM +, Adam D. Ruppe via Digitalmars-d-learn wrote: > On Tuesday, 9 April 2019 at 21:00:55 UTC, H. S. Teoh wrote: > > (And on a side note: don't even get me started on is(...) > > expressions.) > > is expressions rock. And I betcha if we did do libraries for them, it > would eventually go full circle, with someone doing a pattern-matching > DSL that reinvents the original syntax, just much slower to compile :P The functionality rocks, but the syntax is a horrendous hairball of inconsistencies and design-by-chance. T -- It's bad luck to be superstitious. -- YHL
Re: Iterate/sort associative array by value?
On 2019-04-08 08:31:33 +, Dennis said: As Sebastian said, you can do `import std.experimental.all;` or from version 2.086 `import std;` to import the entire standard library. Well, that's more like a brute force approach. So it would be always best to use "import *" :-) I like selective imports, because it gives a clear hint where things are coming from. I don't like that I have to do it manually. Maybe a 2-pass approach would help: DMD spitting out the minimal selective import statements at the end, which you could cut & paste into your code. If dmd as a library pans out, a language server might automatically suggest imports for unresolved symbols like common Java and C# IDEs do. Yep, good approach too. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: Iterate/sort associative array by value?
On 2019-04-08 08:29:24 +, Julian said: It does do this, so the question should be: why aren't its warnings more extensive? Ok, I had the impression that I saw such a message in the past but wasn't sure about it... -- Robert M. Münch http://www.saphirion.com smarter | better | faster
