Re: DIP 1027---String Interpolation---Format Assessment
On 2/27/2020 3:44 AM, aliak wrote: Btw: Swift does this for string interpolation and it works very well -> https://www.hackingwithswift.com/articles/178/super-powered-string-interpolation-in-swift-5-0 I don't know Swift, but this looks like the "generate strings and concatenate them" approach.
Re: The Serpent Game Framework - Open Source!!
On 2/27/20 5:29 PM, aberba wrote: There's this ongoing open source game framework by Ikey. I knew him to be a diehard C guru (from the Solus Project) but is now rocking D, hence Serpent. Check is out and support if you can, please. I don't know how he does it but Ikey can code stuff like crazy. https://lispysnake.com/blog/2020/02/02/the-slippery-serpent/ Nice! have to update my ldc installation to try it out, but I'd love to see them at dconf (their address is in London). -Steve
The Serpent Game Framework - Open Source!!
There's this ongoing open source game framework by Ikey. I knew him to be a diehard C guru (from the Solus Project) but is now rocking D, hence Serpent. Check is out and support if you can, please. I don't know how he does it but Ikey can code stuff like crazy. https://lispysnake.com/blog/2020/02/02/the-slippery-serpent/
Re: DIP 1027---String Interpolation---Format Assessment
On Thu, Feb 27, 2020 at 11:26:37AM -0800, Walter Bright via Digitalmars-d-announce wrote: [...] > Magic types are not simple and inevitably lead to unexpected corners > and unresolvable problems. *cough* associative arrays *cough* [...] For all the trouble they've given us, built-in AA's is one of the primary reasons I love D. IMO, it's inexcusible for a programming language in this day and age not to have built-in AA's, either as part of the language, or as part of the standard library -- but with FULL LANGUAGE SUPPORT. Meaning that all built-in types can be used as AA keys without further ado, unlike C++'s standard hashtable which IMNSHO is a horrible piece of nigh-unusable crap, because you can't even declare a hashtable without defining your own hash function, you can't use structs as keys unless you also manually declare a hash function, a comparison function, and who knows what other onerous detail I can't recall, and then you have to use that horrendous iterator API to lookup anything at all. Once, I wanted to add a simple hashtable as a caching mechanism to one of my C++ projects. After *two days* it still wasn't working properly, because there is no default hash function for anything, not even ints, so I have to write my own, and the hash function must be wrapped in some kind of functional wrapper object because you can't pass functions to the template parameter, then to initialize the hashtable I have to jump through a whole bunch of hoops, mostly involving the fact that to create the hash function object I needed to pass the necessary context all over the place -- so I had to rewrite 70% of the internal API just to be able to pass the context to the right places. Then the dumb thing required C++11 or something like that, which broke my C++98 code in horrendous ways that required a full-scale refactor to fix some of the incompatibilities. Eventually I threw in the towel, and spent about a month's time to rewrite the whole danged project in D -- from scratch. I can't describe how refreshing it was to be able to just write: Value[Key] aa; and that's *it*. No fuss, no muss, it Just Works(tm). Sure, when there's a performance issue then I have to add opHash or opEquals or what-not to my types, but the important thing is, there are *sane defaults* for everything. The compiler isn't going to throw my code back in my face just because I used a custom type instead of string for the AA key (some languages have this problem), and the custom type may contain other custom types but it just knows to compute the default hash value accordingly. If D *didn't* have .opHash built-in, it would've been a totally different story, probably not too unlike my horrible experience with C++. If there wasn't a default hash function, and if I had to manually declare a whole bunch of stuff just to be able to use a struct containing a pair of ints as key, then it would have been a horrendous experience. TL;DR: I'm *glad* D has built-in AA's, in spite of whatever flaws they may have. It was the Right Choice, even though the execution, in retrospect, was a bit wanting. T -- MSDOS = MicroSoft's Denial Of Service
Re: [OT] Re: DIP 1027---String Interpolation---Format Assessment
On Thu, Feb 27, 2020 at 02:20:14PM -0500, Steven Schveighoffer via
Digitalmars-d-announce wrote:
> On 2/27/20 1:42 PM, H. S. Teoh wrote:
> > Making CTFE AAs usable at runtime is somewhat of a different beast,
> > though. The main problem is that you need to be able to instantiate the
> > binary representation of a runtime AA (the main hash table, and each
> > of the buckets) at compile-time, and do so in a way that the
> > compiler can turn into data in the data segment of the executable.
> > Regardless of what the CTFE representation is, it needs an explicit
> > transformation step to turn it into something the runtime code can
> > decipher.
>
> I think this is not too difficult. This works, and it's not much
> different:
>
> static immutable rbt = new RedBlackTree!int(1,2, 3, 4);
>
> In other words, I have pretty much faith that if the AA becomes a
> template, then whatever call is made for ["hello": 1, "world": 2] can
> be callable at compile time, and generate a compatible runtime AA.
>
> The CTFE AA can be whatever CTFE likes, just when it moves to runtime
> land, it gets translated to an AA literal.
[...]
Interesting. So it looks like the problem is "merely" that the AA
implementation is opaque to the compiler (the current implementation is
PIMPL), so it doesn't know how to turn it into static data. What if we
explicitly cast it into the implementation type, or into a parallel
declaration of the implementation type(s), then forcibly cast it back to
V[K]? Something like this:
struct AANode { /* implementation here */ }
static immutable AANode* aaImpl = /* CTFE AA here */;
static immutable aa = cast(V[K]) aaImpl;
Not 100% sure about that last line, you probably have to force it into
void* or something at some point, I dunno.
T
--
MASM = Mana Ada Sistem, Man!
Re: DIP 1027---String Interpolation---Format Assessment
On 2/27/2020 6:32 AM, Petar Kirov [ZombineDev] wrote: I'm not sure where exactly you draw the line, but I would say that C# follows C's syntax about as much as D does. C# is very different from C. D is not so different, and close enough that DasBetterC is very viable. Hindsight being 20/20, if I was doing a do-over with D I might even make it able to compile unmodified C code. Yet it doesn't import some of the broken C semantics like implicit narrowing conversions (luckily, neither does D) and allowing mixed sign comparisons (the oldest open D issue :( [0]). I don't like C#'s solution to mixed sign comparisons for various reasons. Or Java's "solution", which is to not have unsigned types. My point is that if D didn't follow the usual arithmetic conversions, much fewer newcomers would even notice compared to extremely large backlash that we may get if go with the string interpolation -> raw tuple approach. As opposed to backlash from another gc-required feature and low performance and not usable with printf nor writef nor any user-built functions like OutBuffer.printf and all the ones used by dmd. 1. Have a simple pragma(inline, true) wrapper function that will convert the distinct type to printf-style args. This wrapper function can even be named printf as it would work by virtue of function overloading. This is O(1) additional code that once written no one will need to bother with. 2. Have the new type implicitly convert to printf-style args. I think this is what Adam is proposing. While nice to have, I don't think it's necessary. It's better to build things from simple components than try to break up a complex feature into components. As for std.stdio.write(f)(ln), there's no reason why any garbage would need to be created, as again, a simple overload that accepts the distinct type will be able to handle it just like it would (performance-wise) with DIP1027. However, with DIP1027, only writef and writefln can be used, while write and writeln will produce wrong results (wrong according to people that have used string interpolation in other languages). Magic types are not simple and inevitably lead to unexpected corners and unresolvable problems. *cough* associative arrays *cough* You can have everything you want with DIP1027 interpolated strings by wrapping it in a function call to a function you specify. And so can everyone else. DIP1027 will also likely lead to a number of unexpected treasures, as has happened repeatedly when simple building blocks were added, while complex ones just caused trouble.
Re: DIP 1027---String Interpolation---Format Assessment
On Thursday, 27 February 2020 at 18:19:03 UTC, Adam D. Ruppe wrote: On Thursday, 27 February 2020 at 17:41:12 UTC, Petar Kirov [ZombineDev] wrote: [...] Right, that actually is what my old proposal was (and I fought for it on the first few pages of the last thread), and this is very close to what C# does successfully, but I decided to leave it behind because: [...] Should this maybe be called tuple interpolation instead of string interpolation? It is unique to D it seems, this feature that is. And then it might help with the “wait why can I not assign an interpolated string to a string”?? And on top maybe change the prefix to t instead of i?
Re: [OT] Re: DIP 1027---String Interpolation---Format Assessment
On 2/27/20 1:42 PM, H. S. Teoh wrote: Making CTFE AAs usable at runtime is somewhat of a different beast, though. The main problem is that you need to be able to instantiate the binary representation of a runtime AA (the main hash table, and each of the buckets) at compile-time, and do so in a way that the compiler can turn into data in the data segment of the executable. Regardless of what the CTFE representation is, it needs an explicit transformation step to turn it into something the runtime code can decipher. I think this is not too difficult. This works, and it's not much different: static immutable rbt = new RedBlackTree!int(1,2, 3, 4); In other words, I have pretty much faith that if the AA becomes a template, then whatever call is made for ["hello": 1, "world": 2] can be callable at compile time, and generate a compatible runtime AA. The CTFE AA can be whatever CTFE likes, just when it moves to runtime land, it gets translated to an AA literal. -Steve
Re: DIP 1027---String Interpolation---Format Assessment
On 2/27/2020 1:45 AM, Rainer Schuetze wrote:
The string buffer could also be stack allocated or manually managed with
malloc/free by the string interpolation type.
It's quite a big deal to make that work, and does not address the inherent
inefficiency of it.
printf, for all its faults, is very efficient, and one reason is it does not
require arbitrary temporary storage. Another is it does not require exception
handlers. I, for one, simply would not use such when printf is available.
People often overlook how *expensive* RAII is. Turn exception handling on and
have a look at the generated code.
It's a minor syntactic convenience with an unexpected large and hidden cost.
That's not what D is about.
Leave this at the user's discretion with:
f(format("hello %betty"));
where the user chooses via the format function which method of handling
temporaries he finds appropriate.
---
Note that the reason outbuffer.d has a printf member function is because it is
fast and efficient to format data directly into the output buffer rather than
going through a series of temporary strings first.
Re: [OT] Re: DIP 1027---String Interpolation---Format Assessment
On Thu, Feb 27, 2020 at 10:11:07AM -0500, Steven Schveighoffer via Digitalmars-d-announce wrote: [...] > Large hidden invisible types are not the problem (look at normal > dynamic arrays, the large hidden type built into the runtime is a huge > success I think). The problem is that the compiler gives special > features to such types. > > In the case of AA, the ONLY missing piece that cannot be implemented > by user types is this: > > int[string][string] aalist; > > aalist["hello"]["world"] = 5; > > In essence, the compiler knows how to make this work. The operators > available do not allow this expression to be captured properly by user > code (i.e. we don't have opIndexIndexAssign or > opIndexIndexIndexAssign, nor does that scale). It's not that hard: https://issues.dlang.org/show_bug.cgi?id=7753 Somebody just has to do it, that's all. > I believe the last person to try and implement a full template type > that could replace AAs is H. S. Teoh. He would have a better > explanation (and possibly contradict me, I don't know). Actually, I may have been the *first* one to try to do this, but I don't think I was the last. Over the years various pieces of the AA implementation has been templatized and moved to druntime, though the core implementation is still in aaA.d. I think, on the basis of this other work, that we're in a far better position now to fully move AA's into a template implementation. I haven't been keeping track, though, so I don't know what issues might remain that hinder this migration. > Other than that, we've ripped out all other "magic" into templates in > the language. If we could get that one feature (not sure how to do > this in a scalable way), I think we have a full library type that can > be further factored out of the compiler. We might even be able to > avoid using TypeInfo, and make CTFE AAs compatible with runtime ones. [...] Yeah, most of the work on removing AA magic from the compiler has been done by someone else, IIRC Martin Nowak among them, and probably others. Making CTFE AAs usable at runtime is somewhat of a different beast, though. The main problem is that you need to be able to instantiate the binary representation of a runtime AA (the main hash table, and each of the buckets) at compile-time, and do so in a way that the compiler can turn into data in the data segment of the executable. Regardless of what the CTFE representation is, it needs an explicit transformation step to turn it into something the runtime code can decipher. Basically, you have to create an .init value for the final object that doesn't require calling a runtime memory allocation function, but nonetheless still points to legit instances of AA buckets and their contents. This cannot be directly cast from the CTFE AA, because CTFE AA buckets won't have legit runtime addresses that can be assigned to the hash table's pointers. I think this *might* be possible to do via a string mixin that creates explicit variables for each AA bucket then the main hash table by taking their addresses. Of course, some hackish casts will probably be required to make it all work with the current runtime AA implementation. T -- Why can't you just be a nonconformist like everyone else? -- YHL
Re: DIP 1027---String Interpolation---Format Assessment
On Thursday, 27 February 2020 at 18:07:19 UTC, Arine wrote:
On Thursday, 27 February 2020 at 09:34:23 UTC, Walter Bright
wrote:
On 2/26/2020 7:41 AM, Arine wrote:
Yah, what's unwanted about that?
1. unwanted extra string allocation
2. poor performance
3. doesn't work with printf
4. doesn't work with writef
5. non-default formats require extra temp strings to be
generated
Sometimes I wonder if you even bother to read posts to
understand.
This is a problem with YOUR DIP. Where you said, "what's wrong
with that, it's working as intended".
void CreateWindow(string title, int w = -1, int h = -1);
int a;
CreateWindow(i"Title $a");
// becomes
CreateWindow("Title %s", a);
That's what your fine with, that's what the DIP your wrote
would allow.
It's like you are just reading what you want to, instead of
actually understanding what people are saying. I'd have more
luck talking to a brick wall at the rate this thread is going,
jesus.
Come on, this isn't Reddit. Be more civil.
Re: DIP 1027---String Interpolation---Format Assessment
On Thursday, 27 February 2020 at 17:41:12 UTC, Petar Kirov
[ZombineDev] wrote:
auto s = new_type!(
"hi ", spec(null), ", you are visitor ", spec("%2d")
)(name, count);
I.e. the referenced arguments are passed to the constructor of
new_type.
Right, that actually is what my old proposal was (and I fought
for it on the first few pages of the last thread), and this is
very close to what C# does successfully, but I decided to leave
it behind because:
1. It doesn't work very nicely in templates:
int a;
foo!i"test $a"; // error, a cannot be evaluated at compile time
Even if `foo` otherwise could handle it (e.g. an `alias`
parameter), passing the data to an intermediate object prohibits
this.
I personally think that is worth losing in exchange for the other
benefits it brings, which you correctly identified at the end of
your message, but there's more we lose too:
2. It brings complication with features like `ref` (cannot have a
ref struct member so once we pass it, it is gone...) and
potentially `scope`, etc., or even UDAs are lost with an
intermediary (though UDAs affecting printing might be weird af,
the door is totally closed with it and possibly open without).
But bottom line: this means it wouldn't work with non-copyable
types.
---
// in theory printable, has a toString method
struct NoCopy { @disable this(this); void toString(dg) {...} }
NoCopy nc;
// but this works with a tuple... not with an intermediary, unless
// the intermediary allocates a string upon construction, of
course, but
// that gets us into the hidden GC worries again
print(i"i can print it without copying it $nc");
---
`print` there might take its arguments by `auto ref` and work
just fine, but an intermediate object wouldn't have that option.
(ref also means you could do an interpolated `readf` string too,
though I kinda think that is a little weird anyway personally,
but some people in the other thread did have uses where it could
be useful, so if we can avoid breaking it, we should. I think the
non-copy print is more compelling though.)
3. As Walter pointed out with GC too, it is easy to go from tuple
to object (just do `.whatever` to pass it to an object
constructor/helper function), but object to tuple is not so
simple. (of course there is `.tupleof`, but the details lost
through the intermediate object can never be recovered.) So if
there's other use cases we miss, the tuple has fewer potential
regrets.
4. Just want to point out that some people feel strongly that the
implicit conversion to fully interpolated string is altogether a
bad idea because it would be a hidden GC allocation. I don't
agree - I don't think it is that hidden since `alias this` only
triggers if you name `string` and if you want to avoid GC allocs
there's plenty of other ways to do it - but still a few people
said it last thread so I wanna mention it here too.
If you like, we could copy/paste this into my DIP too, might be
useful for future reference. I didn't spend much time on this
since I was focused on just advocating for my amendment to
Walter's and assumed the point was moot anyway (Walter's proposal
shares these strengths since it also uses the tuple at its core).
But yeah, it is a good idea... just I think my new DIP as
written, with a typed format string and a tuple of arguments, is
a better idea since it works with more of D's unique features in
addition to doing most of what C# can do - just sans the implicit
conversion.
Re: DIP 1027---String Interpolation---Format Assessment
On Thursday, 27 February 2020 at 09:34:23 UTC, Walter Bright
wrote:
On 2/26/2020 7:41 AM, Arine wrote:
Yah, what's unwanted about that?
1. unwanted extra string allocation
2. poor performance
3. doesn't work with printf
4. doesn't work with writef
5. non-default formats require extra temp strings to be
generated
Sometimes I wonder if you even bother to read posts to understand.
This is a problem with YOUR DIP. Where you said, "what's wrong
with that, it's working as intended".
void CreateWindow(string title, int w = -1, int h = -1);
int a;
CreateWindow(i"Title $a");
// becomes
CreateWindow("Title %s", a);
That's what your fine with, that's what the DIP your wrote would
allow.
It's like you are just reading what you want to, instead of
actually understanding what people are saying. I'd have more luck
talking to a brick wall at the rate this thread is going, jesus.
Re: DIP 1027---String Interpolation---Format Assessment
On Thursday, 27 February 2020 at 14:58:20 UTC, Adam D. Ruppe
wrote:
On Thursday, 27 February 2020 at 14:32:29 UTC, Petar Kirov
[ZombineDev] wrote:
2. Have the new type implicitly convert to printf-style args.
I think this is what Adam is proposing. While nice to have, I
don't think it's necessary.
You can read my document for more detail
https://github.com/dlang/DIPs/pull/186
But basically
writefln(i"hi $name, you are visitor ${%2d}(count)");
gets turned into:
writefln(
// the format string is represented by this type
new_type!("hi ", spec(null), ", you are visitor ",
spec("%2d"))(),
// then the referenced arguments are passed as a tuple
name,
count
)
So very, very, very similar to Walter's proposal, just instead
of the compiler generating the format string as a plain string,
the format string is represented by a new type, defined by the
spec and implemented by druntime. As a result, no more guess
work - it is clear that this is meant to be interpreted as a
format string. It is clear which parts are
placeholders/specifiers for which arguments.
Perhaps my assumptions were based on an old version of your
proposal.
What I want is for:
auto s = i"hi $name, you are visitor ${%2d}(count)";
to lower to:
auto s = new_type!(
"hi ", spec(null), ", you are visitor ", spec("%2d")
)(name, count);
I.e. the referenced arguments are passed to the constructor of
new_type.
That way new_type can offer implicit conversion to string, while
support for zero-allocation printf, write, writeln, writef,
writefln and so on can be done via function overloading.
Re: [OT] Re: DIP 1027---String Interpolation---Format Assessment
On Thursday, 27 February 2020 at 15:11:07 UTC, Steven Schveighoffer wrote: [snip] We're going very off topic here, but I wanted to address this. Large hidden invisible types are not the problem (look at normal dynamic arrays, the large hidden type built into the runtime is a huge success I think). The problem is that the compiler gives special features to such types. In the case of AA, the ONLY missing piece that cannot be implemented by user types is this: int[string][string] aalist; aalist["hello"]["world"] = 5; [snip] Thanks for writing that. I spent a few minutes reading about autovivification and was a little unsure of what the problem was as D's operator overloading is pretty flexible. However, I don't think I've ever used or seen used multi-dimensional associative arrays. It looks as if you cannot make use of aalist["hello", "world"] and have to use it like aalist["hello"]["world"].
Re: DIP 1027---String Interpolation---Format Assessment
On Thursday, 27 February 2020 at 15:12:23 UTC, Adam D. Ruppe
wrote:
error: cannot implicitly convert argument of type interpolated
tuple to type string. Tip: use `.idup` to explicitly convert it
to string.
Oh, that pretty much sorts out my problem there, sorry if I
glanced over it being mentioned previously.
We've already argued this at length and the community is not
willing to lose
what we'd lose (ref, scope, compile-time usage, and more)
And that also explains to me why having the values packed into a
struct (e.g. C# FormattableString) wouldn't be acceptable either.
Again, sorry if I missed it being mentioned before.
My main other argument was the possible complexity/bugginess of
having functions that provide special support for these strings,
as from Walter's DIP it seemed each function would have to
implement their own parsing of the format string. But I see your
DIP already addresses that (_d_interpolated_format_spec("")).
I'm kind of struggling to see now why your changes were so
vehemently rejected now.
Other than that, just pretend my misinformed post doesn't exist.
[OT] Re: DIP 1027---String Interpolation---Format Assessment
On 2/27/20 9:32 AM, Petar Kirov [ZombineDev] wrote: An example of this is the built-in associative array, which has a series of fairly intractable problems as a result. Another example is the built-in complex type in D, which turned out to be a bad idea - a much better one is building it as a library type. AFAIR, most of the problems with D's built-in AAs are that they have an extern (C) interface that relies on typeinfo. If they are fully converted to templated library types, the situation would be much better. IIRC, one of the blocking issues was that D didn't have autovivification [1] operators, so a library type wouldn't be a complete replacement without additional help from the compiler. We're going very off topic here, but I wanted to address this. Large hidden invisible types are not the problem (look at normal dynamic arrays, the large hidden type built into the runtime is a huge success I think). The problem is that the compiler gives special features to such types. In the case of AA, the ONLY missing piece that cannot be implemented by user types is this: int[string][string] aalist; aalist["hello"]["world"] = 5; In essence, the compiler knows how to make this work. The operators available do not allow this expression to be captured properly by user code (i.e. we don't have opIndexIndexAssign or opIndexIndexIndexAssign, nor does that scale). I believe the last person to try and implement a full template type that could replace AAs is H. S. Teoh. He would have a better explanation (and possibly contradict me, I don't know). Other than that, we've ripped out all other "magic" into templates in the language. If we could get that one feature (not sure how to do this in a scalable way), I think we have a full library type that can be further factored out of the compiler. We might even be able to avoid using TypeInfo, and make CTFE AAs compatible with runtime ones. -Steve
Re: DIP 1027---String Interpolation---Format Assessment
On Thursday, 27 February 2020 at 14:47:55 UTC, SealabJaster wrote: At that point, it begs the question of why even bother having string interpolation. I encourage you to read my document too: https://github.com/dlang/DIPs/pull/186 It addresses all these concerns. Walter's proposal is dead. It has been formally rejected. We shouldn't waste more time talking about it. I'd like to imagine that most newcomers/returning veterans of D would see "D has string interpolation!" and then expect it to work similar to how it does in most other languages. My proposal doesn't work exactly like in other languages - it is uniquely D so we don't waste our potential. It does everything C# can do, except the implicit conversion to string... BUT, if you assume it is the same as other languages, you get a compile error, and the error message tells you how to convert it to a regular string! f(i"hello $a"); error: cannot implicitly convert argument of type interpolated tuple to type string. Tip: use `.idup` to explicitly convert it to string. f(i"hello $a".idup); // works almost like other languages now! f2(i"hello $a", i"hello $b"); // type mismatch error, try idup f2(i"hello $a".idup, i"hello $b".idup); // works So education wise, it is only a few seconds: if you use it like in other languages, it doesn't work, but the compiler tells you how to fix it. If you find the error or `.idup` method unacceptable, then... I'm sorry, but you aren't going to win that one. We've already argued this at length and the community is not willing to lose what we'd lose (ref, scope, compile-time usage, and more) by making that work; the trade-offs are too steep.
Re: DIP 1027---String Interpolation---Format Assessment
On Thursday, 27 February 2020 at 14:32:29 UTC, Petar Kirov
[ZombineDev] wrote:
2. Have the new type implicitly convert to printf-style args. I
think this is what Adam is proposing. While nice to have, I
don't think it's necessary.
You can read my document for more detail
https://github.com/dlang/DIPs/pull/186
But basically
writefln(i"hi $name, you are visitor ${%2d}(count)");
gets turned into:
writefln(
// the format string is represented by this type
new_type!("hi ", spec(null), ", you are visitor ",
spec("%2d"))(),
// then the referenced arguments are passed as a tuple
name,
count
)
So very, very, very similar to Walter's proposal, just instead of
the compiler generating the format string as a plain string, the
format string is represented by a new type, defined by the spec
and implemented by druntime. As a result, no more guess work - it
is clear that this is meant to be interpreted as a format string.
It is clear which parts are placeholders/specifiers for which
arguments.
Re: DIP 1027---String Interpolation---Format Assessment
On 28/02/2020 3:47 AM, SealabJaster wrote:
Similarly, as far as I can tell even with the adjustment of making these
strings their own special type, something as simple (for other languages
as):
```
void f(string a, string b)
{ /*...*/ }
int foo = 20;
string bar = "lalafell";
f(i"You are a foo($foo)", i"I am not a $bar");
```
Isn't easily achieved without use of an extra helper function such as
i"...".format or .str, etc.
What you have suggested is a GC only language feature.
This will cut out numerous use cases for D, and will leave those people
swearing and complaining.
Unlike new users who may not discover this feature for a while, existing
users will complain and will not be happy guranteed.
This is something we as a community want to avoid.
Re: DIP 1027---String Interpolation---Format Assessment
On Thursday, 27 February 2020 at 09:30:30 UTC, Walter Bright
wrote:
You can make it behave like all those other languages simply
with:
f(format("hello $a"));
At that point, it begs the question of why even bother having
string interpolation.
I'd like to imagine that most newcomers/returning veterans of D
would see "D has string interpolation!" and then expect it to
work similar to how it does in most other languages.
They'd expect f(format("hello %s", a)) to be replaced by a much
more compact f("hello $a"), instead of some D-ism take on
interpolation that doesn't really provide much in the way of the
main use of the feature: easily creating formatted strings.
People more used to D will likely go "Oh, that's kind of weird
yet cool" once they learn what it lowers down to, yet newcomers
who aren't too caught up with the language's features will simply
be annoyed and confused that it 'feels' (not necessarily is) more
complicated than needed.
It appears the main focus in these dicussions are "What super
super cool and niche (in comparison to string formatting) things
can we do with this feature!" while mostly blind-siding that it's
generally an easy-to-use, easy-to-understand feature in other
languages.
Similarly, as far as I can tell even with the adjustment of
making these strings their own special type, something as simple
(for other languages as):
```
void f(string a, string b)
{ /*...*/ }
int foo = 20;
string bar = "lalafell";
f(i"You are a foo($foo)", i"I am not a $bar");
```
Isn't easily achieved without use of an extra helper function
such as i"...".format or .str, etc.
My view on it is that this is generally a QoL feature, which some
languages (C#, Swift) have had success in keeping the basic
principle of interpolation while also granting user code the
power to perform some of the things being suggested (e.g. In C#,
string interpolation works as-expected, yet check out functions
such as FromSqlInterpolated[1] which can directly access the
format string & values simply by taking a special
`FormattableString` type)
To be honest, if D's take on interpolation makes people scratch
their head in confusion at the most basic use case, then it's
probably not even worth adding to the language.
[1]
https://docs.microsoft.com/en-us/dotnet/api/microsoft.entityframeworkcore.relationalqueryableextensions.fromsqlinterpolated?view=efcore-3.1
Re: DIP 1027---String Interpolation---Format Assessment
On Thursday, 27 February 2020 at 09:34:23 UTC, Walter Bright wrote: On 2/26/2020 7:41 AM, Arine wrote: Yah, what's unwanted about that? [snip] You're arguing against a strawman. The other poster's comment was showing a likely problem with the (rejected) dip 1027, that our new proposal fixes. The new proposal does not allocate a new string, so none of your points apply to it.
Re: DIP 1027---String Interpolation---Format Assessment
On Thursday, 27 February 2020 at 09:30:30 UTC, Walter Bright
wrote:
On 2/27/2020 12:27 AM, Petar Kirov [ZombineDev] wrote:
I'm well aware that allocation is inevitable if we want this
behavior. My argument is that this behavior is so ubiquitous
that not following it would be surprising to much more people,
than if D didn't follow C's Usual Arithmetic Conversions
rules. For example, Rust not following those conversion rules
is considered a good thing,
Rust does not follow C syntax at all, so nobody will reasonably
expect it to have C semantics. D does follow it, it's a
feature, so people will have expectations.
I'm not sure where exactly you draw the line, but I would say
that C# follows C's syntax about as much as D does. Yet it
doesn't import some of the broken C semantics like implicit
narrowing conversions (luckily, neither does D) and allowing
mixed sign comparisons (the oldest open D issue :( [0]).
My point is that if D didn't follow the usual arithmetic
conversions, much fewer newcomers would even notice compared to
extremely large backlash that we may get if go with the string
interpolation -> raw tuple approach.
[0]: https://issues.dlang.org/show_bug.cgi?id=259
while if D decided to be different than all other languages
w.r.t. string interpolation,
You can make it behave like all those other languages simply
with:
f(format("hello $a"));
and there it is. But having it generate a GC allocated string
is not so easy to unwind, i.e. it'll be useless with printf and
generate unacceptable garbage with writefln. The extra string
will always make it slow. Essentially, it'll be crippled.
Making D behave like a scripting language will yield scripting
performance.
I know, I know. Though I think you misunderstood. There several
ways to make printf work with zero allocations. For example:
1. Have a simple pragma(inline, true) wrapper function that will
convert the distinct type to printf-style args. This wrapper
function can even be named printf as it would work by virtue of
function overloading. This is O(1) additional code that once
written no one will need to bother with.
2. Have the new type implicitly convert to printf-style args. I
think this is what Adam is proposing. While nice to have, I don't
think it's necessary.
As for std.stdio.write(f)(ln), there's no reason why any garbage
would need to be created, as again, a simple overload that
accepts the distinct type will be able to handle it just like it
would (performance-wise) with DIP1027. However, with DIP1027,
only writef and writefln can be used, while write and writeln
will produce wrong results (wrong according to people that have
used string interpolation in other languages).
D is a language built up from simple, orthogonal parts (or at
least that is a goal). A language built from larger indivisible
parts is much, much less user-adaptable.
I appreciate the sentiment. Having orthogonal features in D is
important to me as well. However, I think DIP1027 falls short
here because it produces a single format string and that way
loses all of the structure. This is ok for printf, but not for
third-party libraries and even our own std.format, as with a
distinct type we won't need to parse the whole format string at
all, just the individual format specifiers. In other words, a
distinct type would make nothrow std.format a much more tractable
problem (at least for some cases).
An example of this is the built-in associative array, which has
a series of
fairly intractable problems as a result. Another example is the
built-in
complex type in D, which turned out to be a bad idea - a much
better one is
building it as a library type.
AFAIR, most of the problems with D's built-in AAs are that they
have an extern (C) interface that relies on typeinfo. If they are
fully converted to templated library types, the situation would
be much better. IIRC, one of the blocking issues was that D
didn't have autovivification [1] operators, so a library type
wouldn't be a complete replacement without additional help from
the compiler.
So in conclusion, having a distinct library-defined type (in
druntime) seems the best way to go to me, as it's more flexible
than raw tuples, could allow easy GC-backed conversion to string
for script-like code and would offer a superset of the
functionality that DIP1027 would offer, while still allowing easy
(although not 100% direct) calls to printf.
[1]: https://en.wikipedia.org/wiki/Autovivification
Re: DIP 1027---String Interpolation---Format Assessment
On Thursday, 27 February 2020 at 09:30:30 UTC, Walter Bright wrote: On 2/27/2020 12:27 AM, Petar Kirov [ZombineDev] wrote: I'm well aware that allocation is inevitable if we want this behavior. My argument is that this behavior is so ubiquitous that not following it would be surprising to much more people, than if D didn't follow C's Usual Arithmetic Conversions rules. For example, Rust not following those conversion rules is considered a good thing, Rust does not follow C syntax at all, so nobody will reasonably expect it to have C semantics. D does follow it, it's a feature, so people will have expectations. As shown, string interpolation in other languages (not only 'stript', as you wrote) has a so well established way of performing it that everybody will reasonably expect D to behave the same. Said that, better having no string interpolation at all in D, if the introduced feature is not at least comparable with the solution that the others out there are using: no surprise behaviour, please! and there it is. But having it generate a GC allocated string is not so easy to unwind, i.e. it'll be useless with printf and generate unacceptable garbage with writefln. The extra string will always make it slow. Essentially, it'll be crippled. Making D behave like a scripting language will yield scripting performance. It seems that the other compiled languages doing it in that way have raised no concerns at all on the above matters
Re: DIP 1027---String Interpolation---Format Assessment
On Thursday, 27 February 2020 at 09:34:23 UTC, Walter Bright
wrote:
On 2/26/2020 7:41 AM, Arine wrote:
Yah, what's unwanted about that?
1. unwanted extra string allocation
2. poor performance
3. doesn't work with printf
4. doesn't work with writef
5. non-default formats require extra temp strings to be
generated
Pretty sure he meant that this call:
int a;
CreateWindow(i"Title $a");
Would call CreateWindow like:
CreateWindow("Title %s", a);
Which is what is unwanted.
Btw: with the adam-steve-twist you fix everything that is
unwanted, including enforcing explicitness when someone wants it
to act as a string, without the danger of mistakenly calling the
wrong overloads of functions because of switching to string
interpolation.
And it seems to me there's precedent in typeid
i.e. typeid is an construct in D that lowers to a TypeInfo type,
which is defined somewhere (is that object.d?) Anyway. The same
would happen with the interpolated string.
Btw: Swift does this for string interpolation and it works very
well ->
https://www.hackingwithswift.com/articles/178/super-powered-string-interpolation-in-swift-5-0
Re: DIP 1027---String Interpolation---Format Assessment
On Thursday, 27 February 2020 at 09:45:06 UTC, Rainer Schuetze wrote: On 27/02/2020 01:20, Walter Bright wrote: On 2/26/2020 3:13 AM, Petar Kirov [ZombineDev] wrote: In all other languages with string interpolation that I'm familiar with, `a` is not passed to the `i` parameter. All rely on a garbage collected string being generated as an intermediate variable. The string buffer could also be stack allocated or manually managed with malloc/free by the string interpolation type. Don't forget LDC does GC to stack optimisations. There ought to be no need to do anything manually if you care about perf.
Re: DIP 1027---String Interpolation---Format Assessment
On 27/02/2020 01:20, Walter Bright wrote: > On 2/26/2020 3:13 AM, Petar Kirov [ZombineDev] wrote: >> In all other languages with string interpolation that I'm familiar >> with, `a` is not passed to the `i` parameter. > > All rely on a garbage collected string being generated as an > intermediate variable. The string buffer could also be stack allocated or manually managed with malloc/free by the string interpolation type.
Re: DIP 1027---String Interpolation---Format Assessment
On 2/26/2020 7:41 AM, Arine wrote: Yah, what's unwanted about that? 1. unwanted extra string allocation 2. poor performance 3. doesn't work with printf 4. doesn't work with writef 5. non-default formats require extra temp strings to be generated
Re: Beta 2.091.0
On Thursday, 27 February 2020 at 09:05:47 UTC, JN wrote: "Class deallocator have been deprecated in v2.080.0 (see ), and turned into an error in v2.087.0. They have now been completely removed from the language, and the parser won't recognize them anymore." missing a link after the see Thanks, corrected: https://github.com/dlang/dmd/pull/10841
Re: DIP 1027---String Interpolation---Format Assessment
On 2/27/2020 12:27 AM, Petar Kirov [ZombineDev] wrote:
I'm well aware that allocation is inevitable if we want this behavior. My
argument is that this behavior is so ubiquitous that not following it would be
surprising to much more people, than if D didn't follow C's Usual Arithmetic
Conversions rules. For example, Rust not following those conversion rules is
considered a good thing,
Rust does not follow C syntax at all, so nobody will reasonably expect it to
have C semantics. D does follow it, it's a feature, so people will have
expectations.
while if D decided to be different than all other
languages w.r.t. string interpolation,
You can make it behave like all those other languages simply with:
f(format("hello $a"));
and there it is. But having it generate a GC allocated string is not so easy to
unwind, i.e. it'll be useless with printf and generate unacceptable garbage with
writefln. The extra string will always make it slow. Essentially, it'll be
crippled. Making D behave like a scripting language will yield scripting
performance.
D is a language built up from simple, orthogonal parts (or at least that is a
goal). A language built from larger indivisible parts is much, much less
user-adaptable. An example of this is the built-in associative array, which has
a series of fairly intractable problems as a result. Another example is the
built-in complex type in D, which turned out to be a bad idea - a much better
one is building it as a library type.
Re: Blog post on calling C from Python via D
On Wednesday, 26 February 2020 at 20:57:53 UTC, H. S. Teoh wrote: On Wed, Feb 26, 2020 at 08:45:31PM +, Atila Neves via Digitalmars-d-announce wrote: On Wednesday, 26 February 2020 at 17:39:14 UTC, jmh530 wrote: > On Wednesday, 26 February 2020 at 14:51:06 UTC, Atila Neves > wrote: > > [snip] > > > > A lot of the comments were about how stupid I was for not > > just using ctypes or cffi. I tried today and both of them > > are horrible. As I say in the blog post below, either they > > didn't read the article (people on the internet commenting > > on things they didn't even read? Shock! Horror!) or just > > aren't lazy enough. > > > > My followup: > > > > https://atilaoncode.blog/2020/02/26/seriously-just-use-d-to-call-c-from-python/ > > I basically just ignored any of the comments about ctypes or > cffi having looked at them briefly once like 5-10 years ago > and throwing up my hands. But I also throw up my hands a lot! I didn't know anything about them last week, so I didn't think I could reply properly. After looking into them today I just shook my head a lot. It's incredible the lengths that people go to justifying their pre-existing beliefs. At this point, I don't know how to convince the masses if "nanomsg in Python in 4 lines of code" isn't enough! Perhaps a side-by-side comparison of how clean the D version would look vs how lousy the equivalent ctypes/cffi version is? Just a thought. That was exactly what I was going to do yesterday with cffi and I even started writing the code. Midway through I realised how much work it was going to be and decided that ain't nobody got time for that. Then shook my head vigorously that anyone would dare suggest this was "easy" and in any way comparable to what I'd shown to be possible.
Re: DIP 1027---String Interpolation---Format Assessment
On 2/26/2020 10:38 PM, FeepingCreature wrote:
On Thursday, 27 February 2020 at 03:50:35 UTC, Walter Bright wrote:
On 2/26/2020 4:46 PM, Adam D. Ruppe wrote:
But DIP1027 had a fatal flaw: it made type safety impossible.
I don't see how that is true.
Because it turned a format string into a list of built-in types
indistinguishable from a set of manual parameters. You cannot in principle tell
the difference between "test $i" and ("test %s", i) - you cannot write a
function that takes a string and then *any other type* and is also protected
from being accidentally called with a format string.
That isn't a type safety error.
Re: Beta 2.091.0
On Wednesday, 26 February 2020 at 12:17:43 UTC, Martin Nowak wrote: Glad to announce the first beta for the 2.091.0 release, ♥ to the 55 contributors. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.091.0.html Due to updating several components in the build pipeline, this beta and release are unfortunately delayed. 2.091.0 is now planned to be released one week later on March 8th. As usual please report any bugs at https://issues.dlang.org -Martin "Class deallocator have been deprecated in v2.080.0 (see ), and turned into an error in v2.087.0. They have now been completely removed from the language, and the parser won't recognize them anymore." missing a link after the see
Re: DIP 1027---String Interpolation---Format Assessment
On Thursday, 27 February 2020 at 00:20:27 UTC, Walter Bright wrote: On 2/26/2020 3:13 AM, Petar Kirov [ZombineDev] wrote: In all other languages with string interpolation that I'm familiar with, `a` is not passed to the `i` parameter. All rely on a garbage collected string being generated as an intermediate variable. I'm well aware that allocation is inevitable if we want this behavior. My argument is that this behavior is so ubiquitous that not following it would be surprising to much more people, than if D didn't follow C's Usual Arithmetic Conversions rules. For example, Rust not following those conversion rules is considered a good thing, while if D decided to be different than all other languages w.r.t. string interpolation, most newcomers would consider this a bad thing and not elegant and innovative as we are aiming for. I agree with Adam, Steven and others that string interpolation expression should yield a distinct type and not a tuple. By doing this we would be able to overload functions so they could accept both strings (which would cause GC allocation when the argument is a interpolated string), and the new distinct type, in which case the allocation could be avoided.
