Re: Template constraints for reference/value types?
On Wednesday, 7 September 2016 at 00:40:27 UTC, Jonathan M Davis
wrote:
On Tuesday, September 06, 2016 21:16:05 Jon Degenhardt via
Digitalmars-d-learn wrote:
On Tuesday, 6 September 2016 at 21:00:53 UTC, Lodovico Giaretta
wrote:
> On Tuesday, 6 September 2016 at 20:46:54 UTC, Jon Degenhardt
>
> wrote:
>> Is there a way to constrain template arguments to reference
>> or value types? I'd like to do something like:
>>
>> T foo(T)(T x)
>>
>> if (isReferenceType!T)
>>
>> { ... }
>>
>> --Jon
>
> You can use `if(is(T : class) || is(T : interface))`.
>
> If you also need other types, std.traits contains a bunch of
> useful templates: isArray, isAssociativeArray, isPointer, ...
Thanks. This looks like a practical approach.
It'll get you most of the way there, but I don't think that
it's actually possible to test for reference types in the
general case
[snip]
- Jonathan M Davis
Thanks, very helpful. I've concluded that what I wanted to do
isn't worth pursuing at the moment (see the thread on associative
arrays in the General forum). However, your description is
helpful to understand the details involved.
Re: Template constraints for reference/value types?
On Tuesday, September 06, 2016 21:16:05 Jon Degenhardt via Digitalmars-d-learn
wrote:
> On Tuesday, 6 September 2016 at 21:00:53 UTC, Lodovico Giaretta
>
> wrote:
> > On Tuesday, 6 September 2016 at 20:46:54 UTC, Jon Degenhardt
> >
> > wrote:
> >> Is there a way to constrain template arguments to reference or
> >> value types? I'd like to do something like:
> >>
> >> T foo(T)(T x)
> >>
> >> if (isReferenceType!T)
> >>
> >> { ... }
> >>
> >> --Jon
> >
> > You can use `if(is(T : class) || is(T : interface))`.
> >
> > If you also need other types, std.traits contains a bunch of
> > useful templates: isArray, isAssociativeArray, isPointer, ...
>
> Thanks. This looks like a practical approach.
It'll get you most of the way there, but I don't think that it's actually
possible to test for reference types in the general case - the problem being
structs with postblit constructors. In many cases, it's possible to detect
that a struct has to be a value type, and it's often possible to detect that
a struct is a reference type (by looking at the types of the member
variables in both cases), but as soon as postblit constructors get involved,
it's not possible anymore, because the exact semantics depend on the
implementation of the postblit constructor. For instance,
struct S
{
int* i;
}
is clearly a reference type, but
struct S
{
this(this)
{
...
}
int* i;
}
may or may not be one. In this particular case, the postblit constructor
_probably_ does a deep copy of the member variables, but it might also just
print out that the postblit constructor was called or do some other
non-obvious thing that the person who wrote it thought that it should do.
So, there will be some types where you cannot determine whether they're
reference types or value types. And that doesn't even take into
consideration types like dynamic arrays or structs like this
struct S
{
int* i;
byte b;
}
which are pseudo-reference types, because part of their state is local and
part of it is on the heap.
So, depending on what you're trying to do, checking for classes, interfaces,
and pointers may get you what you're looking for, and you can get really
fancy with trying to determine whether a struct might be a value type or
reference type if that suits your purposes, but you're not going to
determine the copy semantics of all types. You can figure it out for a lot
of them though.
- Jonathan M Davis
Re: Template constraints for reference/value types?
On Tuesday, 6 September 2016 at 21:00:53 UTC, Lodovico Giaretta
wrote:
On Tuesday, 6 September 2016 at 20:46:54 UTC, Jon Degenhardt
wrote:
Is there a way to constrain template arguments to reference or
value types? I'd like to do something like:
T foo(T)(T x)
if (isReferenceType!T)
{ ... }
--Jon
You can use `if(is(T : class) || is(T : interface))`.
If you also need other types, std.traits contains a bunch of
useful templates: isArray, isAssociativeArray, isPointer, ...
Thanks. This looks like a practical approach.
Re: Template constraints for reference/value types?
On Tuesday, 6 September 2016 at 20:46:54 UTC, Jon Degenhardt
wrote:
Is there a way to constrain template arguments to reference or
value types? I'd like to do something like:
T foo(T)(T x)
if (isReferenceType!T)
{ ... }
--Jon
You can use `if(is(T : class) || is(T : interface))`.
If you also need other types, std.traits contains a bunch of
useful templates: isArray, isAssociativeArray, isPointer, ...
Template constraints for reference/value types?
Is there a way to constrain template arguments to reference or
value types? I'd like to do something like:
T foo(T)(T x)
if (isReferenceType!T)
{ ... }
--Jon
Re: Unicode function name? ∩
On Tuesday, 6 September 2016 at 19:58:11 UTC, Jesper Tholstrup wrote: On Tuesday, 6 September 2016 at 18:46:52 UTC, Illuminati wrote: [...] You are somewhat of topic here. [...] A lot of code is written by non-mathematicians and has to be maintained by non-mathematicians. Mathematicians will be confused when people start using the symbols incorrectly, simply because they try to be clever. Sure, some developers would probably mix up english words like 'intersect' and 'union', but I think that it is less common. [...] Ok, continue your game I see you are quite involved with it.
Re: Unicode function name? ∩
On Tuesday, 6 September 2016 at 18:46:52 UTC, Illuminati wrote: Symbols are inherently meaningless so you are not making sense. Clever is what got humans out the jungle, I think it is a good thing. No need to denigrate it when you benefit from people being clever. Of course, you could argue that staying in the jungle would have been the best thing... You are somewhat of topic here. Mathematicians don't seem to get confused by symbols. A lot of code is written by non-mathematicians and has to be maintained by non-mathematicians. Mathematicians will be confused when people start using the symbols incorrectly, simply because they try to be clever. Sure, some developers would probably mix up english words like 'intersect' and 'union', but I think that it is less common. You have simply memorized what those groups of symbols mean and you are too lazy to memorize what some other symbol means. Personal... and wrong... Once you realize the game you are playing with yourself then it becomes easier to break the bad habit and not get caught up in the nonsense. Personal... and wrong... My argument goes towards code maintainability and it is still valid. The reason why ∩ is better than intersect is because it is quicker to see and analyze(due to its "size"). True, it is more ambiguous, as ambiguity depends on size, but at least in this case it has been well established just as π and 1,2,3..., etc. But if you are so concerned about ambiguity then why not intersectsetofarithmeticintegerswithsetofarithmeticintegers? That is far less ambiguous than intersect. As long as humans write software I think (personal estimate) that few would call 'intersectsetofarithmeticintegerswithsetofarithmeticintegers' a readable symbol. I suppose that our invention of snake case, camel case, pascal case, ect. lends some support to my claim. My point is, you are playing games. You might not realize it but that is what is going on. If you want to be truthful, it is better to say "I prefer to use my own personal standardized notation that I have already learned since it takes precious time away from my own life.". Personal, again. No real content. You do realize that 'my own personal standardized notation' encompass >99% of all software thus far - right? Your argument is exactly analogous to "I don't speak french! Use English you stupid french speaking person, french is for idiots anyways". I'm not a native English speaker, so I'm not sure that your argument is valid here. I have learned different languages and various diciplines of natural science. I still don't think that methods/functions should contain e.g. math symbols. The tone is irrelevant, the point is acting like one superficial system is better than some other superficial system simply because of perspective/laziness/arrogance/etc. The only issues are that either you are failing to see the systems as superficial or you are failing to see that your own personal center of the universe is not actually the center of the universe. Personal, again... and it could easily be the other way around I think. So just be real. The reason you don't like it is because it confuses you. Personal, again... and not really If it didn't, you wouldn't have a problem with it. If you could speak French and English then you, if you were that hypothetical person, wouldn't care what language was used. So far of the topic. All I can say is that everyone is confused until they learn something. But don't confuse your confusion with some innate scale of better/worse, it only leads to more confusion. The solution to all confusion is familiarity. Become familiar with your confusion(e.g., using ∩) and it won't be confusing anymore. Personal, again. I'm not really confused (I think). The reason the mathematical symbols don't phase me is because I spent years using them. In my mind ∩ = intersection of sets(which I have a non-verbal meaning in my own mind on what that means). I see no difference between ∩ and intersect. Hence I am not confused. Cool, the *years* of usage really payed off... If someone comes along and uses ∩ to mean what I call union. Then it won't confuse me either. Because I realize they have just relabeled stuff. Okay, thats quite a statement... I would argue that many developers, not you of course, could oversee the incorrect symbol. Sure I have to keep track, but as long as they are logical(consistent) then I'll get used to(familiar) with their system and it won't be a problem. Okay. I won't get angry or upset that they are trying to pull the rug out from underneath me. I'll realize that they just speak French and if I want to communicate with them I'll learn French. No big deal, I'll be more enlightened from doing so. Sure it takes some time, but what else do we humans have to do? Everything we do just superficial anyways. Eh, okay... You will win in terms of their usage,
Re: Unicode function name? ∩
On Tuesday, 6 September 2016 at 13:41:22 UTC, Jesper Tholstrup wrote: On Tuesday, 6 September 2016 at 02:22:50 UTC, Illuminati wrote: It's concise and has a very specific meaning. Well, only if we can agree on what the symbols mean. I'm not sure that every symbol is concise and specific across the fields of mathematics, statistics, and physics. The worst part, however, is our (humans, that is) intrinsic desire to be "clever". There will be an endless incorrect use of symbols, which will render code very difficult to understand Friday afternoon when things break. Symbols are inherently meaningless so you are not making sense. Clever is what got humans out the jungle, I think it is a good thing. No need to denigrate it when you benefit from people being clever. Of course, you could argue that staying in the jungle would have been the best thing... The whole point of symbols is to simplify, ∩ is more simple than intersect as the first requires 1 symbol and the second requires 8 symbols. I don't buy that argument - fewer symbols is better? If so disagree, its a lot easier to make and a lot harder to catch a ∩ vs ∪ error compared to 'intersect()' vs 'union()' error. How is Unicode normalization handled? It is my impression that certain symbols can be represented in more than one way. I could be wrong... Mathematicians don't seem to get confused by symbols. intersect is a symbol. It is no different than ∩ or any other symbol. It is just chicken scratch. There is no inherent meaning in the wavy lines. If you think there is then you are deluding yourself. You have simply memorized what those groups of symbols mean and you are too lazy to memorize what some other symbol means. Once you realize the game you are playing with yourself then it becomes easier to break the bad habit and not get caught up in the nonsense. The reason why ∩ is better than intersect is because it is quicker to see and analyze(due to its "size"). True, it is more ambiguous, as ambiguity depends on size, but at least in this case it has been well established just as π and 1,2,3..., etc. But if you are so concerned about ambiguity then why not intersectsetofarithmeticintegerswithsetofarithmeticintegers? That is far less ambiguous than intersect. My point is, you are playing games. You might not realize it but that is what is going on. If you want to be truthful, it is better to say "I prefer to use my own personal standardized notation that I have already learned since it takes precious time away from my own life.". When do you this, I cannot argue with you, but then you also have to accept that you cannot argue with me(or anyone else). Because what makes sense or works for you might not work for me or someone else. Your argument is exactly analogous to "I don't speak french! Use English you stupid french speaking person, french is for idiots anyways". The tone is irrelevant, the point is acting like one superficial system is better than some other superficial system simply because of perspective/laziness/arrogance/etc. The only issues are that either you are failing to see the systems as superficial or you are failing to see that your own personal center of the universe is not actually the center of the universe. So just be real. The reason you don't like it is because it confuses you. If it didn't, you wouldn't have a problem with it. If you could speak French and English then you, if you were that hypothetical person, wouldn't care what language was used. All I can say is that everyone is confused until they learn something. But don't confuse your confusion with some innate scale of better/worse, it only leads to more confusion. The solution to all confusion is familiarity. Become familiar with your confusion(e.g., using ∩) and it won't be confusing anymore. The reason the mathematical symbols don't phase me is because I spent years using them. In my mind ∩ = intersection of sets(which I have a non-verbal meaning in my own mind on what that means). I see no difference between ∩ and intersect. Hence I am not confused. If someone comes along and uses ∩ to mean what I call union. Then it won't confuse me either. Because I realize they have just relabeled stuff. Sure I have to keep track, but as long as they are logical(consistent) then I'll get used to(familiar) with their system and it won't be a problem. I won't get angry or upset that they are trying to pull the rug out from underneath me. I'll realize that they just speak French and if I want to communicate with them I'll learn French. No big deal, I'll be more enlightened from doing so. Sure it takes some time, but what else do we humans have to do? Everything we do just superficial anyways.
Re: Templates problem
On Tuesday, 6 September 2016 at 14:50:17 UTC, Lodovico Giaretta wrote: From a quick look, it looks like `results` is a `const(TickDuration[3])`, that is a fixed-length array. And fixed-length arrays aren't ranges. If you explicitly slice them, they become dynamic arrays, which are ranges. So the solution is to call `map` with `results[]` instead of `results`. exactly. static arrays doesn't have `popFront`, hence `isInputRange` fails. yet there is no way to tell that to user, so one should just learn what those cryptic error messages really means. or just get used to always slice arrays, it's cheap. ;-)
Re: Templates problem
On Tuesday, 6 September 2016 at 14:38:54 UTC, Russel Winder wrote:
The code fragment:
const results = benchmark!(run_mean, run_mode, run_stdDev)(1);
const times = map!((TickDuration t) { return
(to!Duration(t)).total!"seconds"; })(results);
seems entirely reasonable to me. However rdmd 20160627 begs to
differ:
run_checks.d(20): Error: template
std.algorithm.iteration.map!(function (TickDuration t) =>
to(t).total()).map cannot deduce function from argument types
!()(const(TickDuration[3])), candidates are:
/usr/include/dmd/phobos/std/algorithm/iteration.d(450):
std.algorithm.iteration.map!(function (TickDuration t) =>
to(t).total()).map(Range)(Range r) if (isInputRange!(Unqual!Range))
Failed: ["dmd", "-v", "-o-", "run_checks.d", "-I."]
and I have no idea just now why it is complaining, nor what to
do to fix it.
From a quick look, it looks like `results` is a
`const(TickDuration[3])`, that is a fixed-length array. And
fixed-length arrays aren't ranges. If you explicitly slice them,
they become dynamic arrays, which are ranges.
So the solution is to call `map` with `results[]` instead of
`results`.
Templates problem
The code fragment:
const results = benchmark!(run_mean, run_mode, run_stdDev)(1);
const times = map!((TickDuration t) { return
(to!Duration(t)).total!"seconds"; })(results);
seems entirely reasonable to me. However rdmd 20160627 begs to differ:
run_checks.d(20): Error: template std.algorithm.iteration.map!(function
(TickDuration t) => to(t).total()).map cannot deduce function from argument
types !()(const(TickDuration[3])), candidates are:
/usr/include/dmd/phobos/std/algorithm/iteration.d(450):
std.algorithm.iteration.map!(function (TickDuration t) =>
to(t).total()).map(Range)(Range r) if (isInputRange!(Unqual!Range))
Failed: ["dmd", "-v", "-o-", "run_checks.d", "-I."]
and I have no idea just now why it is complaining, nor what to do to
fix it.
--
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
signature.asc
Description: This is a digitally signed message part
Re: Unicode function name? ∩
On Tuesday, 6 September 2016 at 02:22:50 UTC, Illuminati wrote: It's concise and has a very specific meaning. Well, only if we can agree on what the symbols mean. I'm not sure that every symbol is concise and specific across the fields of mathematics, statistics, and physics. The worst part, however, is our (humans, that is) intrinsic desire to be "clever". There will be an endless incorrect use of symbols, which will render code very difficult to understand Friday afternoon when things break. The whole point of symbols is to simplify, ∩ is more simple than intersect as the first requires 1 symbol and the second requires 8 symbols. I don't buy that argument - fewer symbols is better? If so disagree, its a lot easier to make and a lot harder to catch a ∩ vs ∪ error compared to 'intersect()' vs 'union()' error. How is Unicode normalization handled? It is my impression that certain symbols can be represented in more than one way. I could be wrong...
Re: dependency analysis for makefile construction
On Monday, 5 September 2016 at 18:49:25 UTC, Basile B. wrote: On Monday, 5 September 2016 at 18:22:08 UTC, ag0aep6g wrote: On 09/04/2016 12:07 AM, dan wrote: Are there any FOSS tools for doing dependency analysis of [...] [...] I'm not aware of a standalone tool that does something like this. If you want to write one, you could do like rdmd and use `dmd -deps`/`dmd -v`, or you could use a standalone D parser like libdparse. http://code.dlang.org/packages/libdparse I have one in dastworx, based on dparse: https://github.com/BBasile/Coedit/blob/master/dastworx/src/imports.d#L64 It would be very easy to make it a standalone tool (dastworx is a standalone tool but its main() is specific to Coedit) or to add such an anlayzer to Dscanner. about 200 SLOCs not more. Oops, big mouth syndrome here, it would be actually more complex because a persistent associative array is needed to link filenames to modules, projects to filename, date stamps to filename, etc...Otherwise at each execution there are a lot of stuff to parse. dastworx does not implement these features because they are done in an IDE module (the "libman").
