A way to mixin during runtime?
Is there a way to do mixin or similar during runtime? I'm trying to read a csv file and extract data types. Any ideas on how this should be approached in D are greatly appreciated.
Re: A little help with Ranges
On Friday, 27 August 2021 at 04:01:19 UTC, Ali Çehreli wrote:
On 8/26/21 7:17 PM, Merlin Diavova wrote:
[...]
Then the operations downstream will not produce any results.
For example, the array will be empty below:
import std.stdio;
import std.range;
import std.algorithm;
import std.string;
import std.functional;
void main() {
auto significantLines = stdin
.byLineCopy
.map!strip
.filter!(not!empty)
.filter!(line => line.front != '#')
.array;
if (significantLines.empty) {
writeln("There were no significant lines.");
} else {
writefln!"The lines: %-(\n%s%)"(significantLines);
}
}
Ali
And there it is!
I was missing
```d
.filter!(not!empty)
```
My code now works exactly how I wanted. Thanks!
Re: A little help with Ranges
On 8/26/21 7:17 PM, Merlin Diavova wrote:
What I meant about the handling an empty filter is, what if I want to
take an alternative route if the filter returns empty?
Then the operations downstream will not produce any results. For
example, the array will be empty below:
import std.stdio;
import std.range;
import std.algorithm;
import std.string;
import std.functional;
void main() {
auto significantLines = stdin
.byLineCopy
.map!strip
.filter!(not!empty)
.filter!(line => line.front != '#')
.array;
if (significantLines.empty) {
writeln("There were no significant lines.");
} else {
writefln!"The lines: %-(\n%s%)"(significantLines);
}
}
Ali
Re: A little help with Ranges
On Friday, 27 August 2021 at 02:17:21 UTC, Merlin Diavova wrote: On Friday, 27 August 2021 at 02:10:48 UTC, Stefan Koch wrote: On Friday, 27 August 2021 at 01:51:42 UTC, Merlin Diavova wrote: Hi all, I'm Merlin, I'm just starting out in D and super excited. My questions are:- 1. In a range pipeline how does one handle the event of a filter range returning empty? 2. How does one unwrap a single result from a range operation? Look forward to your assistance! Merlin 1. you don't have to handle it. it just won't go. 2. `takeOne` put it into the search on the dlang site Thanks for the quick response! Took a look at takeOne and yep that's the ticket. What I meant about the handling an empty filter is, what if I want to take an alternative route if the filter returns empty? You check if it's by calling empty. or do you want a default value? I am sure there is a convince function for that somewhere in phobos.
Re: A little help with Ranges
On Friday, 27 August 2021 at 02:10:48 UTC, Stefan Koch wrote: On Friday, 27 August 2021 at 01:51:42 UTC, Merlin Diavova wrote: Hi all, I'm Merlin, I'm just starting out in D and super excited. My questions are:- 1. In a range pipeline how does one handle the event of a filter range returning empty? 2. How does one unwrap a single result from a range operation? Look forward to your assistance! Merlin 1. you don't have to handle it. it just won't go. 2. `takeOne` put it into the search on the dlang site Thanks for the quick response! Took a look at takeOne and yep that's the ticket. What I meant about the handling an empty filter is, what if I want to take an alternative route if the filter returns empty?
Re: A little help with Ranges
On Friday, 27 August 2021 at 01:51:42 UTC, Merlin Diavova wrote: Hi all, I'm Merlin, I'm just starting out in D and super excited. My questions are:- 1. In a range pipeline how does one handle the event of a filter range returning empty? 2. How does one unwrap a single result from a range operation? Look forward to your assistance! Merlin 1. you don't have to handle it. it just won't go. 2. `takeOne` put it into the search on the dlang site
A little help with Ranges
Hi all, I'm Merlin, I'm just starting out in D and super excited. My questions are:- 1. In a range pipeline how does one handle the event of a filter range returning empty? 2. How does one unwrap a single result from a range operation? Look forward to your assistance! Merlin
Re: Scope of Mixins
On Thursday, 26 August 2021 at 19:31:54 UTC, DLearner wrote:
if (typeof(v).stringof == "int" ) {
Tip: you can instead of string of do
if (is(typeof(v) == int))
That is operator lets you compare types directly.
(stringof is something you will almost never use as you learn
more of the language)
Re: Scope of Mixins
On Thursday, 26 August 2021 at 16:28:22 UTC, Adam D Ruppe wrote:
On Thursday, 26 August 2021 at 16:16:55 UTC, DLearner wrote:
Please confirm that mixins of format:
You really shouldn't use string mixins like this at all. If you
want to work with a variable, pass the variable itself as an
argument to the function and use it with regular code instead
of passing names as strings.
void do_something(alias v)() {
// use v like a normal variable
}
int a;
do_someting!a; // pass the variable a as an alias so you can
use it inside
Thank you for your suggestion.
For the record, the code below behaves as expected.
```
void main() {
int VarInt;
int* VarIntPtr;
double VarDbl;
do_something!VarInt;
do_something!VarIntPtr;
do_something!VarDbl;
}
void do_something(alias v)() {
import std.stdio;
if (typeof(v).stringof == "int" ) {
writeln("int var detected");
} else if (typeof(v).stringof == "int*") {
writeln("int* var detected");
} else {
writeln("Unrecognised type");
}
}
```
Re: Scope of Mixins
On Thursday, 26 August 2021 at 18:07:48 UTC, Ali Çehreli wrote: In some cases it's more useful to have a 'static if' inside a single function template instead of two separate function templates. In most cases that's better. A template constraint is really a way to say "this template cannot accept this". When you use it to overload, the conditions get ugly fast since you need to make sure they're all mutually exclusive and the error messages get wrong since the compiler isn't sure if the thing can or can't be accepted. What you generally want to do here is if the call - from the user's perspective - should work, make sure it gets through the constraint. Then do the details of branches inside.
Re: Scope of Mixins
On 8/26/21 10:45 AM, Adam D Ruppe wrote:
On Thursday, 26 August 2021 at 17:39:16 UTC, Ali Çehreli wrote:
String mixins are appealing because they can inject code like C macros
do. It's not trivially possible to do the same with template mixins.
Template mixins are great, but obviously totally inappropriate here. I'm
just talking about using a normal function, possibly with an alias
argument, instead of any kind of mixin.
Too often D programmers reach for fancy code generation when a simpler
function is a better fit.
Agreed. Something like the following for the OP:
import std.traits : isPointer;
auto valueFrom(T)(T var)
if (isPointer!(typeof(var))) {
return *var;
}
auto valueFrom(T)(T var)
if (!isPointer!(typeof(var))) {
return var;
}
void main() {
int x;
int i = 42;
x = valueFrom(i);
int * p = &i;
x = valueFrom(p);
}
In some cases it's more useful to have a 'static if' inside a single
function template instead of two separate function templates.
Ali
Re: Scope of Mixins
On Thursday, 26 August 2021 at 17:39:16 UTC, Ali Çehreli wrote: String mixins are appealing because they can inject code like C macros do. It's not trivially possible to do the same with template mixins. Template mixins are great, but obviously totally inappropriate here. I'm just talking about using a normal function, possibly with an alias argument, instead of any kind of mixin. Too often D programmers reach for fancy code generation when a simpler function is a better fit.
Re: Scope of Mixins
On 8/26/21 10:06 AM, Adam D Ruppe wrote:
On Thursday, 26 August 2021 at 17:01:06 UTC, DLearner wrote:
The object was to take a variable, and do alternative things with it
depending on (say) whether it was an 'int' or an 'int*'.
That's *very* easy to do with the alias. You can just check `typeof(v)`
in there.
String mixins are appealing because they can inject code like C macros
do. It's not trivially possible to do the same with template mixins.
import std.traits : isPointer;
import std.stdio : writeln;
mixin template valueFrom(alias var)
if (isPointer!(typeof(var))) {
writeln("Dereferencing a pointer"); // ERROR
x = *var;
}
mixin template valueFrom(alias var)
if (!isPointer!(typeof(var))) {
writeln("Using a scalar"); // ERROR
x = var;
}
void main() {
int x;
int i = 42;
mixin valueFrom!i;
int * p = &i;
mixin valueFrom!p;
}
Yes, there are tricks one can play or change the design but when it
comes to "injecting code", template mixins are not as convenient as
string mixins.
Ali
Re: Scope of Mixins
On Thursday, 26 August 2021 at 17:01:06 UTC, DLearner wrote: The object was to take a variable, and do alternative things with it depending on (say) whether it was an 'int' or an 'int*'. That's *very* easy to do with the alias. You can just check `typeof(v)` in there.
Re: Scope of Mixins
On Thursday, 26 August 2021 at 16:28:22 UTC, Adam D Ruppe wrote:
On Thursday, 26 August 2021 at 16:16:55 UTC, DLearner wrote:
Please confirm that mixins of format:
You really shouldn't use string mixins like this at all. If you
want to work with a variable, pass the variable itself as an
argument to the function and use it with regular code instead
of passing names as strings.
void do_something(alias v)() {
// use v like a normal variable
}
int a;
do_someting!a; // pass the variable a as an alias so you can
use it inside
The object was to take a variable, and do alternative things with
it depending on (say) whether it was an 'int' or an 'int*'.
Since entirely possible (indeed likely) that operations on 'int'
invalid or meaningless with 'int*', to me seemed better to find a
way that at _compile-time_ detected the difference, and only
generated code valid for the type used.
Originally, there were mixins that only coped with each type.
These work, but a chore to update mixin name as variable type
changed.
So idea is just one mixin which can compile-time detect variable
type
and generate appropriate code.
Got it to work, except for this scoping issue...
Re: Scope of Mixins
On Thursday, 26 August 2021 at 16:16:55 UTC, DLearner wrote:
Please confirm that mixins of format:
You really shouldn't use string mixins like this at all. If you
want to work with a variable, pass the variable itself as an
argument to the function and use it with regular code instead of
passing names as strings.
void do_something(alias v)() {
// use v like a normal variable
}
int a;
do_someting!a; // pass the variable a as an alias so you can use
it inside
Re: Scope of Mixins
On Thursday, 26 August 2021 at 16:16:55 UTC, DLearner wrote:
Please confirm that mixins of format:
```
string mxn1(string VarName) {
...
}
```
Invoked like:
```
mixin(mxn1("Var1"));
```
Have a wider scope than mixins like:
```
string mxn2(string VarName)() {
...
}
```
Invoked like:
```
mixin(mxn2!"Var2");
```
If the strings produced by `mxn1("Var1")` and `mxn2!"Var2"` are
the same, mixing them in will have the same result. `mixin()`
does not care where the string you pass to it comes from.
I tried direct replacement of former by the latter, could not
get clean compile until definition moved into same module.
Something you are doing in the body of the functions is causing
this, but because you have not included function bodies in your
post, I cannot tell you what.
Scope of Mixins
Please confirm that mixins of format:
```
string mxn1(string VarName) {
...
}
```
Invoked like:
```
mixin(mxn1("Var1"));
```
Have a wider scope than mixins like:
```
string mxn2(string VarName)() {
...
}
```
Invoked like:
```
mixin(mxn2!"Var2");
```
I tried direct replacement of former by the latter, could not get
clean compile until definition moved into same module.
Best regards
Re: foreach() behavior on ranges
On Wednesday, 25 August 2021 at 11:02:23 UTC, Steven
Schveighoffer wrote:
On 8/25/21 4:31 AM, frame wrote:
On Tuesday, 24 August 2021 at 21:15:02 UTC, Steven
Schveighoffer wrote:
I'm surprised you bring PHP as an example, as it appears
their foreach interface works EXACTLY as D does:
Yeah, but the point is, there is a rewind() method. That is
called every time on foreach().
It seems what you are after is forward ranges. Those are able
to "rewind" when you are done with them. It's just not done
through a rewind method, but via saving the range before
iteration:
```d
foreach(val; forwardRange.save)
{
...
break;
}
// forwardRange hasn't been iterated here
```
-Steve
This could be any custom method for my ranges or forward range
returned by some function.
But that doesn't help if some thirdparty library function would
break and return just an input range. Then it seems that it must
be very properly implemented like postblit technics mentioned
before. Some author may never care about.
That it works in 99% of all cases should not be an excuse for a
design flaw.
The documentation really need to mention this.
Re: foreach() behavior on ranges
On Wednesday, 25 August 2021 at 19:51:36 UTC, H. S. Teoh wrote: What I understand from what Andrei has said in the past, is that a range is merely a "view" into some underlying storage; it is not responsible for the contents of that storage. My interpretation of this is that .save will only save the *position* of the range, but it will not save the contents it points to, so it will not (should not) deep-copy. That definition is potentially misleading if we take into account that a range is not necessarily iterating over some underlying storage: ranges can also be defined by algorithmic processes. (Think e.g. iota, or pseudo-RNGs, or a range that iterates over the Fibonacci numbers.) However, if the range is implemented by a struct that contains a reference to its iteration state, then yes, to satisfy the definition of .save it should deep-copy this state. Right. And in the case of algorithmic ranges (rather than container-derived ranges), the state is always and only the iteration state. And then as well as that there are ranges that are iterating over external IO, which in most cases can't be treated as forward ranges but in a few cases might be (e.g. saving the cursor position when iterating over a file's contents). Arguably I think a lot of problems in the range design derive from not thinking through those distinctions in detail (external-IO-based vs. algorithmic vs. container-based), even though superficially those seem to map well to the input vs forward vs bidirectional vs random-access range distinctions. That's also not taking into account edge cases, e.g. stuff like RandomShuffle or RandomSample: here one can in theory copy the "head" of the range but one arguably wants to avoid correlations in the output of the different copies (which can arise from at least 2 different sources: copying under-the-hood pseudo-random state of the sampling/shuffling algorithm itself, or copying the underlying pseudo-random number generator). Except perhaps in the case where one wants to take advantage of the pseudo-random feature to reproduce those sequences ... but then one wants that to be a conscious programmer decision, not happening by accident under the hood of some library function. (Rabbit hole, here we come.) Andrei has mentioned before that in retrospect, .save was a design mistake. The difference between an input range and a forward range should have been keyed on whether the range type has reference semantics (input range) or by-value semantics (forward range). But for various reasons, including the state of the language at the time the range API was designed, the .save route was chosen, and we're stuck with it unless Phobos 2.0 comes into existence. Either way, though, the semantics of a forward range pretty much dictates that whatever type a range has, if it claims to be a forward range then .save must preserve whatever iteration state it has at that point in time. If this requires deep-copying some state referenced from a struct, then that's what it takes to satisfy the API. This may take the form of a .save method that copies state, or a copy ctor that does the same, or simply storing iteration state as PODs in the range struct so that copying the struct equates to preserving the iteration state. Yes. FWIW I agree that when _implementing_ a forward range one should probably make sure that copying by value and the `save` method produce the same results. But as a _user_ of code implemented using the current range API, it might be a bad idea to assume that a 3rd party forward range implementation will necessarily guarantee that.
Re: Unnable to join Discord
On Thursday, 12 August 2021 at 18:24:44 UTC, Tejas wrote: On Thursday, 12 August 2021 at 18:11:20 UTC, nayy wrote: Hi I cannot seems to be able to join the discord server It gives me the following error: "unable to accept invit" Is the invitation link expired? https://dlang.org/community.html https://discord.gg/bMZk9Q4 I joined last week with the same link. It worked. Try updating your app, maybe? I am using the web version, I am not sure what to do, I tried to create a new account but it gives me the same error code, are the invitations not allowed anymore? Can anyone check please? Thanks
Re: Unnable to join Discord
Maybe it doesn't like a VPN usage? I will try without it
