Re: Why not allow elementwise operations on tuples?
On Wednesday, 18 January 2023 at 16:42:00 UTC, JG wrote: I guess such a method wouldn't be particularly generic since a tuple does not need to consist of types that have the same operations e.g. Tuple!(int,string) etc That's where `areCompatibleTuples` function comes in!
Re: Why not allow elementwise operations on tuples?
On Friday, 13 January 2023 at 15:27:26 UTC, H. S. Teoh wrote: On Fri, Jan 13, 2023 at 02:22:34PM +, Sergei Nosov via Digitalmars-d-learn wrote: Hey, everyone! I was wondering if there's a strong reason behind not implementing elementwise operations on tuples? Say, I've decided to store 2d points in a `Tuple!(int, int)`. It would be convenient to just write `a + b` to yield another `Tuple!(int, int)`. I've written a Vec type that implements precisely this, using tuples behind the scenes as the implementation, and operator overloading to allow nice syntax for vector arithmetic. Yeah, that's clear that such an implementation is rather straightforward. Although, I'm a bit confused with your implementation - 1. it doesn't seem to use tuples behind the scenes despite your claim (it uses static array) 2. `alias impl this;` introduces some unexpected interactions (e.g. `~` and `toString` are "intercepted" by the array implementation and yield "wrong" results). Anyway, my original question was primarily about reasoning - why there's no implementation specifically for `std.Tuple`? If it's a "feature, not a bug" - what's the best way to provide an implementation on the client side?
Why not allow elementwise operations on tuples?
Hey, everyone!
I was wondering if there's a strong reason behind not
implementing elementwise operations on tuples?
Say, I've decided to store 2d points in a `Tuple!(int, int)`. It
would be convenient to just write `a + b` to yield another
`Tuple!(int, int)`.
I can resort to using `int []` arrays and write elementwise
operations as `c[] = a[] + b[]` which is almost fine - but it
uses dynamic allocation and forces the user to create an explicit
destination variable.
It seems a bit awkward given that it's fairly straightforward to
write smth as
```
T opBinary(string op, T)(T lhs, T rhs)
if (isTuple!T)
{
T result;
static foreach (i; 0 .. T.Types.length)
{
mixin("result.field[i] =
lhs.field[i]"~op~"rhs.field[i];");
}
return result;
}
```
You only need to turn it into a member function to make it work.
You can even make it more general and allow such operations for
different, but compatible tuple types (there's a function
`areCompatibleTuples` to check for such compatibility). Yet,
there's only a specialization for tuple concatenation of
`opBinary` (and an implementation of `opCmp` and `opAssign`).
So, to repeat the question - is this a deliberate decision to not
implement the default elementwise operation?
Re: Can you simplify nested Indexed types?
On Tuesday, 27 December 2022 at 16:43:49 UTC, Ali Çehreli wrote: On 12/27/22 07:09, Sergei Nosov wrote: If what you are looking for is a way of defining a variable for "any InputRange that produces a specific type (size_t in this case)", then there is inputRangeObject, which uses OOP: https://dlang.org/phobos/std_range_interfaces.html#InputRange I have an additional example here: http://ddili.org/ders/d.en/ranges_more.html#ix_ranges_more.inputRangeObject Ali Thanks, everyone! I guess, this answer is the closest to what I was looking for. Somehow, I missed the range interfaces (and was considering to use `Variant` or smth). It does seem to answer the original question, albeit with layer(s) of indirection. ``` auto indicies = iota(3); RandomAccessFinite!int ai = indexed(a, indicies).inputRangeObject; ai = indexed(ai, iota(2)).inputRangeObject; ``` Still, my gut feel is that some compile-time solution is possible - will, probably, tinker with it for a little more. Why not use filter(), isn't it important to filter out what's in range? That does something different. Well, pretty sure this isn't what you meant by "same variable" but since it technically does what you want, I decided to share it: Basically I'm abusing array and this thing might be pretty memory heavy... Yeah, using arrays is another alternative, but as you mention, it uses more memory and makes index evaluation eager (vs lazy).
Re: Can you simplify nested Indexed types?
On Tuesday, 27 December 2022 at 15:20:24 UTC, Salih Dincer wrote: On Tuesday, 27 December 2022 at 15:09:11 UTC, Sergei Nosov wrote: Consider, I have the following code: ```d auto a = [3, 6, 2, 1, 5, 4, 0]; auto indicies = iota(3); auto ai = indexed(a, indicies); //ai = indexed(ai, iota(2)); writeln(ai); ``` I confuse about comment line that I mark... SDB@79 Not sure I'll be more helpful, but I'll try to add more details. I have an array and I use `indexed` on it. Conceptually, I now have a second array, but it doesn't exist in memory explicitly - only a function to map indicies from "second array" to "first array" is stored; all the values are stored once - in the "first array". Now, I want to have third array that will do the same trick with the second array. The problem is that the second array is not really an array (but, conceptually, it is an array with random access). If I create a new variable with `auto` as type - obviously, it works. But can I use the same variable I used to store the "second array"? (In the provided code that doesn't work because of the type mismatch).
Re: Apparently there's some dlang action in spacemacs
On Thursday, 13 October 2016 at 13:32:42 UTC, Andrei Alexandrescu wrote: https://github.com/syl20bnr/spacemacs/issues/7374 Anyone familiar with the editor? It's basically a sophisticated "config file" for GNU Emacs that aims to provide a "modern text editor" experience out-of-the-box within Emacs (the vanilla Emacs looks pretty alien to a newcomer/come-by-er). As far as I can tell, the thing is pretty popular within Emacs community (my guess is ~10,000 users - based on the "number of downloads" jump after one of my packages was included into spacemacs). The project is also well-documented and well-maintained, communication with maintainers is always a pleasure.
Re: AST like coding syntax. Easy upgrade!
On Monday, 7 September 2015 at 02:50:06 UTC, Adam D. Ruppe wrote: On Sunday, 6 September 2015 at 23:33:17 UTC, Walter Bright wrote: I'd always thought Javascript was an ideal extension language for a text editor. Well, I don't think *ideal*, but indeed, it wouldn't be bad. C'mon, kind sirs! Haven't you heard anything about Emacs Lisp? =)
Re: Reggae v0.0.5 super alpha: A build system in D
On Tuesday, 7 April 2015 at 08:25:02 UTC, Dicebot wrote: See, the problem with this approach is that you can trivially get out of 1GB of memory with DMD even when compiling single module, all you need is to do enough compile-time magic. Separate compilation here delays the issue but does not actually solve it. Yeah, absolutely agree. But at the moment separate compilation is the most forgiving one. Like, if it doesn't work - anything else won't work either. And given that personally I don't recognize the (possibly) increased compilation time as an issue, it's the solution that works for me. If any effort is to be put into supporting this scenario (on-server compilation), it is better to be put in reducing actual memory hog of compiler, not supporting another workaround. Agreed, too. The whole forget about frees approach sounds a little too controversial to me. Especially, after I have faced the dark side of it. So, I'm all for improving in that regard. But it seems like it's not recognized as a (high-priority) issue at the moment. So, we (the users) have to live with that. Also you can still achieve the similar profile by splitting your project in small enough static libraries, so it is not completely out of question. As I described, my project was just a couple of files. Building vibe.d was the actual problem. I don't think it is feasible to expect that a user of a library will start splitting it into small enough libraries, when faced with this problem. A more structured approach is needed.
Re: Lost a new commercial user this week :(
On Friday, 19 December 2014 at 08:57:56 UTC, Walter Bright wrote: I've debugged a lot of D code with no debugger at all (how else could I port it to various platforms like Win64?). I've actually not found debuggers to be of much use other than telling me where the seg fault was and giving a stack trace. I think the most valuable point Manu made is that there are excellent and good programmers. The difference is not so much in the actual skills, but in the willing to spend time on programming. Excellent programmers spend a great amount of time learning things. It takes a huge part of their free time and it really takes a lot of passion and diligence. But most of the professional programmers are simply good. They code at work and that's it. They don't spend any time beyond that on programming and, especially, learning new things. If we're speaking about excellent programmers category, then almost everything about D is already good enough for these people. You can tell it by a number of truly fascinating D projects. And it looks like the guys who work on D are mostly excellent programmers, which speak pretty different language compared to the good programmers. Probably, this is the main cause of misunderstanding. In the debugger case, Manu's point is that it's unusable. And Walter's implied point is debuggers aren't that useful anyway, so why it was a showstopper?. My personal observation is that excellent programmers share the Walter's point on debuggers - they practically don't use it. And the uselessness is so obvious, that there's nothing even to talk about. At the same time, good programmers use it extensively, especially on Windows. It is so useful to them, that there's nothing even to talk about! So, Manu speaks from the good programmer position, and Walter speaks from the excellent programmer position, implying if you'd become a better programmer, you wouldn't have no problems using D. This implication is mostly true. But it's orthogonal to Manu's point - good programmers have troubles using D. The probable solution to this is to attract some good programmers to point out and work on the aforementioned issues - site, documentation, tooling, etc. But I'm not sure it's possible to do this for D with volunteer efforts.
Re: Lost a new commercial user this week :(
On Friday, 19 December 2014 at 11:16:41 UTC, Walter Bright wrote: On 12/19/2014 2:47 AM, Sergei Nosov wrote: The probable solution to this is to attract some good programmers to point out and work on the aforementioned issues - site, documentation, tooling, etc. But I'm not sure it's possible to do this for D with volunteer efforts. Sure it's possible - but the issues have to be specific. Need more examples, for example (!), is nice but not helpful to anyone trying to improve the documentation. Saying I need an example for std.foo.bar() is an actionable item. I'm afraid, the answer to this specific question is - Every function needs an example. Consider, e.g. http://en.cppreference.com/w/ or http://www.cplusplus.com/reference/ It's hard to find a function that doesn't have a usage example. Granted, the mentioned references are most likely volunteer effort (are they?). But it took C++ something like 20 years and a wide corporate adoption for that to happen. I guess, it took less time for other languages, like Python or Ruby, but that's, probably, because those languages looked really interesting and fun at their times. So they attracted a lot of good programmers. D poses itself as a more serious language (at least it's how it looks like). And, probably, nobody will say that it's bad. But, as a consequence, it makes it less attractive to good programmers. Especially now, when there's lot of successful toy languages. D is not flashy enough these days.
Re: Lost a new commercial user this week :(
On Friday, 19 December 2014 at 11:54:42 UTC, ketmar via Digitalmars-d wrote: On Fri, 19 Dec 2014 10:47:27 + Sergei Nosov via Digitalmars-d digitalmars-d@puremagic.com wrote: In the debugger case, Manu's point is that it's unusable. And Walter's implied point is debuggers aren't that useful anyway, so why it was a showstopper?. My personal observation is that excellent programmers share the Walter's point on debuggers - they practically don't use it. And the uselessness is so obvious, that there's nothing even to talk about. At the same time, good programmers use it extensively, especially on Windows. It is so useful to them, that there's nothing even to talk about! one of the things one can do if he is in corresponding position is to ban debuggers. i found that after month or two people start producing better code with better documentation and control knobs. and surprisingly faster. debugger is just a kind of bad habit, and when people faced the fact that they will not be payed for work simulation (and why should we?), they either go or becomes more productive. Exactly. But you also imply something like it would be great if every good programmer became excellent, which is not very realistic. The example is a little abstract, but smoking is also a bad habit. However, there's no way you can fight it and win for the observable future.
Re: the traits trap
On Friday, 21 November 2014 at 04:08:52 UTC, Steven Schveighoffer wrote: Can anyone figure out a good solution to this problem? I like template constraints, but they are just too black-boxy. Would we have to signify that some enum is actually a trait and so the compiler would know to spit out the junk of compiling? Would it make sense to add some __traits function that allows one to signify that this is a special trait thing? This is one area that D's templates are very user-unfriendly. -Steve I would second this. Personally, I have the same not very pleasant experience debugging template constraints. Since more often than not the constraints have the form of: if (clause1 clause2 clause3 ...) my naive proposal would be to show which clause was first to be false in the error message. However, I have no idea if this could be implemented easily.
Re: vibe.d 0.7.21 has been released
On Tuesday, 18 November 2014 at 17:23:48 UTC, Sönke Ludwig wrote: Just quickly (finally) announcing the release of the next vibe.d version. This one was originally scheduled for start of September, but I got extremely busy with no time left for tidying everything up. The list of changes is long with notable improvements to the web interface generator, the Redis client and the SSL/TLS implementation (including added SNI support). However, the improvements are all over the place. It also compiles on the latest DMD compiler releases (there have been some breaking changes in 2.066). The full list of changes/fixes can be found at http://vibed.org/blog/posts/vibe-release-0.7.21 Homepage: http://vibed.org/ DUB package: http://code.dlang.org/packages/vibe-d GitHub: https://github.com/rejectedsoftware/vibe.d For some reason, the download link in the top right corner suggests a 0.7.20 beta.
Re: D support in Exuberant Ctags 5.8 for Windows
On Tuesday, 11 November 2014 at 18:44:23 UTC, ANtlord wrote: Wake up dead topic! :) On Tuesday, 25 September 2012 at 04:22:13 UTC, p.crimsonsphere wrote: Hi there. So, anyway, have you found any live link to download Ctags 5.8 working for D programming language? I found here http://pastie.org/971968 and applied it to http://dfrank.ru/ctags581 I downloaded compiler for Ctags, I mean, BCC32 and failed to compile it. If anyone has a Ctags 5.8 or 5.81 for D language, please~ Regards. If it is actually, you can use that https://github.com/snosov1/ctags-d. I wanted to suggest this link as well (snosov1 is me). It is ctags 5.8 with the aforementioned patch applied and few other fixes on top. It's not perfect, but works reasonable. I didn't use Dscanner for that functionality much, but I expect it to have better quality.
Re: Interview with Andrei Alexandrescu on the D Programming Language
On Saturday, 11 October 2014 at 09:21:21 UTC, Walter Bright wrote: https://www.youtube.com/watch?v=tvdoIJaPooI On reddit: https://www.reddit.com/r/programming/comments/2iws85/interview_with_andrei_alexandrescu_on_the_d/ Andrei mentions in this talk, that C++ support is implemented to the extent, when you can pass std::vector from C++ to D and in the opposite direction without friction. Are the any pointers on how I can try it out? Like, is it in git master? Where can I find a documentation or an article about that? The corresponding section on the site (http://dlang.org/cpp_interface.html) says: D templates have little in common with C++ templates, and it is very unlikely that any sort of reasonable method could be found to express C++ templates in a link-compatible way with D. This means that the C++ STL, and C++ Boost, likely will never be accessible from D. And I assume this is no longer true. So, anywhere I can look for it?
Re: A Briefer Syntax for Using Concepts
On Wednesday, 7 May 2014 at 11:57:51 UTC, w0rp wrote: Here is a question, is it possible for D, or any future language, to eventually take something like this... void foo(InputRange)(InputRange range) if(isInputRange!InputRange); ...and to instead be able to write it like this? void foo(InputRange range); Where the latter expands into something like the former, and InputRange is not a type. How to declare such a thing in the first place doesn't matter that much. There are many ways that could be done. I'm just wondering if the above is possible at all. C++ concepts has similar syntax. http://isocpp.org/blog/2013/02/concepts-lite-constraining-templates-with-predicates-andrew-sutton-bjarne-s templateSortable Cont void sort(Cont container); I don't think making InputRange behave as you suggest in void foo(InputRange range); is a valid options, since - how do you handle the situation when you want to accept 2 InputRanges of possibly distinct types? void foo(InputRange range1, InputRange range2); // how to specify that InputRange should be exactly the same type? or possibly distinct types?
Re: DIP61: redone to do extern(C++,N) syntax
On Sunday, 27 April 2014 at 19:54:50 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP61
Quote:
Unlike C++, namespaces in D will be 'closed' meaning that new
declarations cannot be inserted into a namespace after the
closing }. C++ Argument Dependent Lookup (aka Koenig Lookup)
will not be supported.
Do I understand it correctly, that if I have namespace members
defined in different files, like
// a.cpp
namespace ns { int foo(); }
// b.cpp
namespace ns { int bar(); }
I have the only option to put those in a single D file, like
// c.d
extern (C++, ns) { int foo(); int bar(); }
?
And the only way it's more flexible than the hypothetical
extern(C++) module ns; is that you can put several namespaces to
a single file?
