Re: The Serpent Game Framework - Open Source!!
On Thursday, 27 February 2020 at 22:29:41 UTC, 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. [...] Ikey did an interview with Foss and he said something about why he uses D. It's interested and funny as well. Having done a lot of Go development, I started researching alternatives to C that were concurrency-aware, string-sane, and packed with a powerful cross-platform standard library. This is the part where everyone will automatically tell you to use Rust. Unfortunately, I’m too stupid to use Rust because the syntax literally offends my eyes. I don’t get it, and I never will. Rust is a fantastic language and as academic endeavours go, highly successful. Unfortunately, I’m too practically minded and seek comfort in C-style languages, having lived in that world too long. So, D was the best candidate to tick all the boxes, whilst having C & C++ interoptability. Pew! Pew!! Nailed it. https://itsfoss.com/ikey-doherty-serpent-interview/
Re: The Serpent Game Framework - Open Source!!
On Thursday, 27 February 2020 at 23:10:26 UTC, Steven Schveighoffer wrote: 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 Already asking him on Twitter.
Re: Our HOPL IV submission has been accepted!
On Saturday, 29 February 2020 at 01:00:40 UTC, Andrei Alexandrescu wrote: Walter, Mike, and I are happy to announce that our paper submission "Origins of the D Programming Language" has been accepted at the HOPL IV (History of Programming Languages) conference. https://hopl4.sigplan.org/track/hopl-4-papers Getting a HOPL paper in is quite difficult, and an important milestone for the D language. We'd like to thank the D community which was instrumental in putting the D language on the map. The HOPL IV conference will take place in London right before DConf. With regard to travel, right now Covid-19 fears are on everybody's mind; however, we are hopeful that between now and then the situation will improve. That's great. Congratulations to the three of you and thanks for all the hard work on this.
Re: Our HOPL IV submission has been accepted!
On Saturday, 29 February 2020 at 01:00:40 UTC, Andrei Alexandrescu wrote: Walter, Mike, and I are happy to announce that our paper submission "Origins of the D Programming Language" has been accepted at the HOPL IV (History of Programming Languages) conference. https://hopl4.sigplan.org/track/hopl-4-papers Getting a HOPL paper in is quite difficult, and an important milestone for the D language. We'd like to thank the D community which was instrumental in putting the D language on the map. The HOPL IV conference will take place in London right before DConf. With regard to travel, right now Covid-19 fears are on everybody's mind; however, we are hopeful that between now and then the situation will improve. Congrats! Indeed a meaningful accomplishment.
Re: DIP 1027---String Interpolation---Format Assessment
On Saturday, 29 February 2020 at 00:57:54 UTC, aliak wrote: Also another note, this tuple expansion should really not be called string interpolation, since it does not result in a string :/ It's more string expansion really. Yeah, me and Steven agreed on this too in the other thread, and I thought I updated my DIP but I guess not. wait a minute yes i did https://gist.github.com/adamdruppe/a58f097d974b364ae1cbc8c050dd9a3f on the gist version, I called it "Formatted string tuple literals", but I never saved tht back to my local or github versions. oops. But basically I see our new thing as being a string builder rather than a string per se.
Our HOPL IV submission has been accepted!
Walter, Mike, and I are happy to announce that our paper submission "Origins of the D Programming Language" has been accepted at the HOPL IV (History of Programming Languages) conference. https://hopl4.sigplan.org/track/hopl-4-papers Getting a HOPL paper in is quite difficult, and an important milestone for the D language. We'd like to thank the D community which was instrumental in putting the D language on the map. The HOPL IV conference will take place in London right before DConf. With regard to travel, right now Covid-19 fears are on everybody's mind; however, we are hopeful that between now and then the situation will improve.
Re: DIP 1027---String Interpolation---Format Assessment
On Friday, 28 February 2020 at 19:16:08 UTC, Steven Schveighoffer
wrote:
On 2/28/20 5:17 AM, Jacob Carlborg wrote:
On Friday, 28 February 2020 at 03:10:48 UTC, Walter Bright
wrote:
I don't know Swift, but this looks like the "generate strings
and concatenate them" approach.
No, it basically lowers to bunch of method calls. Here's an
example of how it could look like with D syntax:
auto a = 3;
auto b = i"foo $a bar";
Could be lowered to:
auto _temp = StringInterpolation(8 /* literal capacity */, 1
/* interpolation count */);
_temp.appendLiteral("foo ");
_temp.appendInterpolation(a);
_temp.appendLiteral(" bar");
auto b = _temp.toString();
I think Walter's point is that swift is still appending strings
and then returning that. This requires allocations, and is not
as preferable as directly processing the data. Not only that,
but it's generating temporary strings just to add them to the
larger thing that will be printed (I'm assuming this is not
just a big string but an array/list, due to the beginning of
the video and s1+s2+s3+s4).
I'd much prefer for example, printing using DIP1027 than
constructing a string (even if the memory is reasonably fast,
like malloc) just to throw it away.
I watched a lot of that video, it didn't impress me much. I use
swift interpolation strings quite a bit, and they are useful.
But I think D's will be much more performant and more
straightforward for hooking (if they ever get in).
-Steve
I actually didn't realize it was a video, thought it was just an
article! - But anyway, it was just to point out that swift lowers
to specialized types when it comes to interpolation (which is
what you and adam are trying to get through). And therefor you
can detect interpolations being given to you and deal with them
the way you want and you can do a lot when you know you're
getting an interpolation. You can create types like
let example: SQLStatment = "select * from blah where a=\(a),
b=\(b) ... "
I also didn't realize the takeaway would be that swift does
appending 😆- which by the way, is not completely accurate. And it
does not generate temporaries (unless you mean passing in
parameters? There's no way around that if you want to end up with
a string based on runtime values - it'll have to be processed in
to a string somewhere).
You can also get an interpolated string directly in to "print
processing" if you wanted to: https://swift.godbolt.org/z/muAzgm
And for the record I think the tuple generation is great as well.
I highly doubt it'll be easier to use than swift (case in point:
no need to call idup or whatever to convert to a string, since a
string in swift is a type that is "interpolation aware"). Hook in
to maybe, it depends on the APIs provided to hook in to them. An
opaque type will not be easier to hook in to and a "concrete"
named interface (aka protocol in swift).
When it comes to printing it really doesn't matter if you
construct a string on the stack and pass it along. You're IO
bound anyway.
By the by: if you or anyone is interested in swift's string
interpolation design decisions (for inspiration or whatever) then
here's the full discussion:
https://forums.swift.org/t/string-interpolation-revamp-design-decisions/12624
One very interesting thing of note is the way they combine named
arguments with string interpolations.
Also another note, this tuple expansion should really not be
called string interpolation, since it does not result in a string
:/ It's more string expansion really.
Re: DIP 1027---String Interpolation---Format Assessment
On 2/28/20 5:17 AM, Jacob Carlborg wrote:
On Friday, 28 February 2020 at 03:10:48 UTC, Walter Bright wrote:
I don't know Swift, but this looks like the "generate strings and
concatenate them" approach.
No, it basically lowers to bunch of method calls. Here's an example of
how it could look like with D syntax:
auto a = 3;
auto b = i"foo $a bar";
Could be lowered to:
auto _temp = StringInterpolation(8 /* literal capacity */, 1 /*
interpolation count */);
_temp.appendLiteral("foo ");
_temp.appendInterpolation(a);
_temp.appendLiteral(" bar");
auto b = _temp.toString();
I think Walter's point is that swift is still appending strings and then
returning that. This requires allocations, and is not as preferable as
directly processing the data. Not only that, but it's generating
temporary strings just to add them to the larger thing that will be
printed (I'm assuming this is not just a big string but an array/list,
due to the beginning of the video and s1+s2+s3+s4).
I'd much prefer for example, printing using DIP1027 than constructing a
string (even if the memory is reasonably fast, like malloc) just to
throw it away.
I watched a lot of that video, it didn't impress me much. I use swift
interpolation strings quite a bit, and they are useful. But I think D's
will be much more performant and more straightforward for hooking (if
they ever get in).
-Steve
Re: DIP 1027---String Interpolation---Format Assessment
On Fri, Feb 28, 2020 at 05:45:35PM +, Atila Neves via Digitalmars-d-announce wrote: > On Thursday, 27 February 2020 at 20:00:52 UTC, H. S. Teoh wrote: [...] > > For all the trouble they've given us, built-in AA's is one of the > > primary reasons I love D. > > [...] > > The reason for C++ forcing users to do that is the lack of > compile-time reflection. Whatever the reason may be, the result is a total usability nightmare compared to D's convenience. Even a supposedly "flawed" feature like AA's in D compares favorably to C++; I seriously can't bring myself to write C++ code anymore. D has ruined my life. :-P T -- Those who don't understand D are condemned to reinvent it, poorly. -- Daniel N
Re: DIP 1027---String Interpolation---Format Assessment
On Thursday, 27 February 2020 at 20:00:52 UTC, H. S. Teoh wrote: On Thu, Feb 27, 2020 at 11:26:37AM -0800, Walter Bright via Digitalmars-d-announce wrote: [...] [...] [...] For all the trouble they've given us, built-in AA's is one of the primary reasons I love D. [...] The reason for C++ forcing users to do that is the lack of compile-time reflection.
Re: DIP 1027---String Interpolation---Format Assessment
On Thursday, 27 February 2020 at 14:32:29 UTC, Petar Kirov [ZombineDev] wrote: On Thursday, 27 February 2020 at 09:30:30 UTC, Walter Bright wrote: 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 Funnily enough the only contribution by Walter in that 14 year old bug is him trying to close it without there having been a solution implemented. The spec is also still wrong, after 14 years. https://dlang.org/spec/expression.html#integer_comparisons
Re: DIP 1027---String Interpolation---Format Assessment
On Thursday, 27 February 2020 at 18:58:40 UTC, Walter Bright
wrote:
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.
It isn't that efficient. There are a lot of implementations
faster than it, and funnily enough they allocate memory, use
exceptions, and RAII.
People often overlook how *expensive* RAII is. Turn exception
handling on and have a look at the generated code.
There was a whole other thread about this, and people found the
assembly generated isn't all that different. Yes throwing
exceptions is expensive, but what you are talking about, the cost
of not throwing them, it really isn't. You are making it out to
be a bigger problem than it actually is. If it caused such a huge
performance hit, then exceptions simply wouldn't be used at all
in C++. But that's not the case.
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.
There are quite a few places that D has large hidden costs. Hell
GC and any feature or otherwise that uses it is a large and
hidden cost. You can't really say D is not about unexpected large
and hidden costs when it has a GC integrated into quite a few
features that make it invisible.
Re: DIP 1027---String Interpolation---Format Assessment
On Friday, 28 February 2020 at 03:10:48 UTC, Walter Bright wrote:
I don't know Swift, but this looks like the "generate strings
and concatenate them" approach.
No, it basically lowers to bunch of method calls. Here's an
example of how it could look like with D syntax:
auto a = 3;
auto b = i"foo $a bar";
Could be lowered to:
auto _temp = StringInterpolation(8 /* literal capacity */, 1 /*
interpolation count */);
_temp.appendLiteral("foo ");
_temp.appendInterpolation(a);
_temp.appendLiteral(" bar");
auto b = _temp.toString();
There's nothing here that says that this needs to use the GC to
allocate the final string. "StringInterpolation" could contain
something like OutBuffer from DMD or, if the arguments were
passed as template arguments, it could allocate on the stack.
--
/Jacob Carlborg
