Re: stri: string format/interpolation library for D. how to embed variables into string like shell scripts
On Sunday, 29 July 2018 at 14:55:46 UTC, Shigeki Karita wrote:
This library is very similar to Scala or shell scripts.
- https://github.com/ShigekiKarita/stri/tree/master
-
https://docs.scala-lang.org/overviews/core/string-interpolation.html
## example
import stri : s;
// runtime/compile-time variables
auto a = 1;
enum _a0 = "D-lang";
struct A {
static a = 0.123;
}
// you can use the default %s and custom ones e.g., %.3f
mixin s!"${a} is one. ${_a0} is nice. ${A.a%.3f}" i;
assert(i.str == "1 is one. D-lang is nice. 0.123");
Seems fairly similar to `interp` in scriptlike:
https://github.com/Abscissa/scriptlike
BTW it wouldn't be so hard to add string interpolation to the
language and compiler, there have been two PRs now. This was the
latest:
https://github.com/dlang/dmd/pull/7988
I think someone just needs to take a bit of time and write a DIP,
so that A can't say no ;-)
Re: autowrap v0.0.1 - Automatically wrap existing D code for use in Python and Excel
Eg turn this into a function and try wrapping this instead:
auto intp = interpreter(dmdEngine());
Actually, I manage to export the `interpret` method
export:
auto intp(char[] txt) {
return interpreter(dmdEngine()).interpret(txt);
}
and tested it in ipython successfully.
But when I try to export the whole dmdEngine
export:
auto engine(char[] txt) {
return interpreter(dmdEngine());
}
it complains about copying Interpreter!(DMDEngine).Interpreter
../../../.dub/packages/pyd-master/pyd/infrastructure/pyd/make_object.d(249,30):
Error: struct drepl.interpreter.Interpreter!(DMDEngine).Interpreter is not
copyable because it is annotated with @disable
I removed @disable, but then complained about accessing the
members `_engine` and `_incomplete` in Interpreter
(https://github.com/dlang-community/drepl/blob/master/src/drepl/interpreter.d#L147-L148)
../../../.dub/packages/pyd-master/pyd/infrastructure/pyd/struct_wrap.d-mixin-56(56,15):
Deprecation: std.array.Appender!(char[]).Appender._data is not visible from
module
../../../.dub/packages/pyd-master/pyd/infrastructure/pyd/struct_wrap.d-mixin-56(56,15):
Error: struct std.array.Appender!(char[]).Appender member _data is not
accessible
After I made those public, it complained about `Appender`
../../../.dub/packages/pyd-master/pyd/infrastructure/pyd/struct_wrap.d-mixin-56(56,15):
Deprecation: std.array.Appender!(char[]).Appender._data is not visible from
module
../../../.dub/packages/pyd-master/pyd/infrastructure/pyd/struct_wrap.d-mixin-56(56,15):
Error: struct std.array.Appender!(char[]).Appender member _data is not
accessible
Is there something I can do here or would it better to talk to
the Drepl guys?
Thank you
Re: autowrap v0.0.1 - Automatically wrap existing D code for use in Python and Excel
Ok, I made a stupid mistake. It works now. Thanks a lot!
stri: string format/interpolation library for D. how to embed variables into string like shell scripts
This library is very similar to Scala or shell scripts.
- https://github.com/ShigekiKarita/stri/tree/master
-
https://docs.scala-lang.org/overviews/core/string-interpolation.html
## example
import stri : s;
// runtime/compile-time variables
auto a = 1;
enum _a0 = "D-lang";
struct A {
static a = 0.123;
}
// you can use the default %s and custom ones e.g., %.3f
mixin s!"${a} is one. ${_a0} is nice. ${A.a%.3f}" i;
assert(i.str == "1 is one. D-lang is nice. 0.123");
Re: On D in competitive programming
On Sunday, 29 July 2018 at 07:51:00 UTC, Jim Balter wrote: Actually, map!something does not drop empty parentheses, so mentioning that does not help. Parentheses containing 0 or 1 arguments can be omitted ... and you omit them for 1 argument in 3 places, and no instances of omitted empty parentheses. And I think it would be less confusing to an unfamiliar reader to mention UFCS, because the chained calls don't fit the function !(args1) (args2) syntax that you mention. While that's technically right, I'd like to skip further explanations of the syntax. The same as I skipped why the problem is solved by such code at all (and it's even less obvious). In both cases, careful explanations would require a good paragraph or two, but are beside the point. The point of the article is more to just show how it feels and to spark interest than to explain everything. On the other hand, if I had to write a guide for competitive programmers on how to use D, such things sure would be included. Ivan Kazmenko.
Re: On D in competitive programming
On Sunday, 29 July 2018 at 07:51:00 UTC, Jim Balter wrote: On Saturday, 28 July 2018 at 21:33:04 UTC, Ivan Kazmenko wrote: [snip] 2. When you briefly explain templates I think it's important to mention that empty parentheses may be omitted to allow the reader to make the link between function!(arg1)(arg2) and map!something. Explaining UFCS isn't necessary there though I think since it's obvious that there is some kind of chaining at play (not that you did, just thinking out loud). Yeah, good point, mentioned it now. Actually, map!something does not drop empty parentheses, so mentioning that does not help. Parentheses containing 0 or 1 arguments can be omitted ... and you omit them for 1 argument in 3 places, and no instances of omitted empty parentheses. And I think it would be less confusing to an unfamiliar reader to mention UFCS, because the chained calls don't fit the function !(args1) (args2) syntax that you mention. [snip] While it's certainly not exact I think it's fine, there's no need to rewrite the language specification. Even for the parentheses, once you know they may be dropped in unambiguous cases you are bound to assume that the author didn't start talking of the ! sign for no reason and that you ought to consider that parentheses may be dropped even not knowing all the reasons. The same goes for UFCS, it's made very clear by the article that the functions are chained. Whether they are actually functions, or function templates or methods or something else entirely isn't important. I think the reader can be expected to understand how it works without understanding why. They even know what the program does already so the chaining part isn't hard. Maybe I was wrong that it needed any addition after all. Or maybe the explaination of templates should be more streamlined toward what is in the code like “map here is a template, the ! sign is the equivalent of <> in C++" and no more.
Re: Blogpost about the T.init problem
On Wednesday, 11 July 2018 at 16:58:53 UTC, Greatsam4sure wrote: On Tuesday, 10 July 2018 at 13:41:56 UTC, FeepingCreature wrote: [...] Every language is plague with one bug or the order. For those will great love for the language they lend a helping hand to fixed the bug. I expect you to help also in whatsoever capacity you can. What do you think pull requests are? I am just learning D but I am thoroughly satisfy with the language. For me it is truly joy. Goody for you, but how does that help?
Re: Blogpost about the T.init problem
On Wednesday, 11 July 2018 at 07:30:59 UTC, FeepingCreature wrote:
On Tuesday, 10 July 2018 at 21:08:32 UTC, Cym13 wrote:
First of all I must point that I would very much like to have
seen a code actually producing an error in that article.
Contrary to what is hinted just taking the struct and putting
using it with Nullable or format() caused no error for me and
worked as expected.
To reproduce the format issue, try to print the struct with
writefln!"%s"(MyDomainType()).
To reproduce the Nullable issue, you need to slightly modify
the struct. In Phobos, Nullable will (due to an abundance of
caution) refuse to initialize the struct if the default
constructor is disabled; also you need a destructor. However,
for this it is enough to use any type that has a destructor, so
that an implicit struct destructor is generated. For verbosity,
I'll write it out:
struct MyDomainData {
string username;
this(string username) @safe
in(!username.empty) // only non-empty usernames please!
do { this.username = username; }
// let's formalise the restriction.
invariant { assert(!username.empty); }
string toString() { return null; }
~this() @safe { }
}
Then just stick it in a Nullable. No explicit .init needed.
That said, I may be missing something obvious but what
prevents you from overloading the init field?
struct MyDomainData {
string username;
@disable this(); // don't make a MyDomainData() by
accident!
this(string username)
in(!username.empty) // only non-empty usernames please!
do { this.username = username; }
// let's formalise the restriction.
invariant { assert(!username.empty); }
string toString() { ... }
static @property MyDomainData init() {
return MyDomainData("uninitialized");
}
...
}
auto test = MyDomainData.init; // There, no error
Of course that value means nothing but .init isn't meant to
actually mean something anyway, it's just a valid value and
that's what that init is proposing, so it shouldn't cause any
more bugs than empty .init in a normal case.
That would work, it's just a really horrible hack and I hate
it. We're constructing a fictitious domain value that passes
our invariants while having zero correspondence to the real
world, *just to pass our invariants*. It's an obvious sign of a
language issue.
If so, then the only language solution is to remove either
invariants or .init, because as long as .init can be called but
cannot be made to conform to your invariant, then your design is
beyond the scope of the language and you're in a pickle.
But the fact is that it's not a language issue and there are
several ways in user code to guarantee that .init satisfies the
invariant. In fact that very statement suggests a solution that
Timothy Cour suggested earlier:
invariant {
if(this is typeof(this).init) return;
assert(!username.empty);
}
Re: Blogpost about the T.init problem
On Wednesday, 11 July 2018 at 16:54:18 UTC, Greatsam4sure wrote: On Tuesday, 10 July 2018 at 13:41:56 UTC, FeepingCreature wrote: [...] Sincerely speaking D language does not merit all these criticism. The magnitude of criticism on D language does not really make sense to me. I am yet to see a language so user friendly as D with such power and strength.I trust one day the world will see and know that D is a language build for programmers for great productivity and not just another money making machine Yeah, D is great so let's not even have a bug database, eh?
Re: On D in competitive programming
On Saturday, 28 July 2018 at 21:33:04 UTC, Ivan Kazmenko wrote: [snip] 2. When you briefly explain templates I think it's important to mention that empty parentheses may be omitted to allow the reader to make the link between function!(arg1)(arg2) and map!something. Explaining UFCS isn't necessary there though I think since it's obvious that there is some kind of chaining at play (not that you did, just thinking out loud). Yeah, good point, mentioned it now. Actually, map!something does not drop empty parentheses, so mentioning that does not help. Parentheses containing 0 or 1 arguments can be omitted ... and you omit them for 1 argument in 3 places, and no instances of omitted empty parentheses. And I think it would be less confusing to an unfamiliar reader to mention UFCS, because the chained calls don't fit the function !(args1) (args2) syntax that you mention. [snip]
