Re: B Revzin - if const expr isn't broken (was Re: My Meeting C++ Keynote video is now available)
On Thursday, 17 January 2019 at 01:59:29 UTC, Walter Bright wrote: On 1/16/2019 4:19 PM, H. S. Teoh wrote: On Wed, Jan 16, 2019 at 11:43:19PM +, John Carter via Digitalmars-d-announce wrote: [...] Yes, that's one of the outstanding qualities of D, and one that I was immensely impressed with when I perused the Phobos source code for the first time. Bartosz Milewski is a C++ programmer and a Haskell fan. He once gave a presentation at NWCPP where he wrote a few lines of Haskell code. Then, he showed the same code written using C++ template metaprogramming. The Haskell bits in the C++ code were highlighted in red. It was like a sea of grass with a shrubbery here and there. Interestingly, by comparing the red dots in the C++ code with the Haskell code, you could understand what the C++ was doing. Without the red highlighting, it was a hopeless wall of < > :-) Was that a pre C++11 version of C++, or a more modern one? It would be instructive to see that example with C++17 or even 20 and D next to each other.
Re: B Revzin - if const expr isn't broken (was Re: My Meeting C++ Keynote video is now available)
On Thursday, 17 January 2019 at 16:06:39 UTC, bpr wrote: On Thursday, 17 January 2019 at 01:59:29 UTC, Walter Bright wrote: Bartosz Milewski is a C++ programmer and a Haskell fan. He once gave a presentation at NWCPP where he wrote a few lines of Haskell code. Then, he showed the same code written using C++ template metaprogramming. The Haskell bits in the C++ code were highlighted in red. It was like a sea of grass with a shrubbery here and there. Interestingly, by comparing the red dots in the C++ code with the Haskell code, you could understand what the C++ was doing. Without the red highlighting, it was a hopeless wall of < > :-) Was that a pre C++11 version of C++, or a more modern one? It would be instructive to see that example with C++17 or even 20 and D next to each other. The presentation was given at BoostCon 2011, and is (at least partially) available on youtube [1]. There is also a blog post from 2009, "What Does Haskell Have to Do with C++?" [2] that uses the same format, and presumably covers the same material. The examples in the blog post were tested with "the GNU C++ compiler v. 4.4.1 with the special switch -std=c++0x", which according to the GCC documentation [3] includes many (but not all) features from C++11. [1] https://www.youtube.com/watch?v=GjhsSzRtTGY [2] https://bartoszmilewski.com/2009/10/21/what-does-haskell-have-to-do-with-c/ [3] https://gcc.gnu.org/gcc-4.4/cxx0x_status.html
Re: B Revzin - if const expr isn't broken (was Re: My Meeting C++ Keynote video is now available)
On Thu, Jan 17, 2019 at 06:03:07PM +, Paul Backus via Digitalmars-d-announce wrote: [...] > [2] > https://bartoszmilewski.com/2009/10/21/what-does-haskell-have-to-do-with-c/ [...] Haha, seems D did better than C++ in this respect, but not quite at the level of Haskell. The C++ example of a template that takes templates and arguments and declares another template is a perfect example of why C++ template syntax is utterly horrible for doing these sorts of things. Coming back to the D example at the end, I totally agree with the sentiment that D templates, in spite of their significant improvements over C++ syntax, ultimately still follow the same recursive model. Yes, you can use CTFE to achieve the same thing at runtime, but it's not the same thing, and CTFE cannot manipulate template argument lists (aka AliasSeq aka whatever it is you call them). This lack of symmetry percolates down the entire template system, leading to the necessity of the hack that Bartosz refers to. Had template argument lists / AliasSeq been symmetric w.r.t. runtime list manipulation, we would've been able to write a foreach loop that manipulates the AliasSeq in the most readable way without needing to resort to hacks or recursive templates. // Lately, as I've been pondering over these fundamental language design issues, I've become more and more convinced that symmetry is the way to go. And by symmetry, I mean the mathematical sense of being "the same under some given mapping (i.e., transformation or substitution)". Why is C++ template syntax such a mess to work with? Because it's a separate set of syntax and idioms grafted onto the original core language with little or no symmetry between them. Where the core language uses < and > as comparison operators, template syntax uses < and > as delimiters. This asymmetry leads to all kinds of nastiness, like earlier versions of C++ being unable to parse `templateA>` properly (the >> gets wrongly lexed as a bitshift operator). An intervening space is required to work around this asymmetry. This is just one trivial example. A more fundamental example, which also afflicts D, is that the template instantiation mechanism is inherently recursive rather than iterative, so when you need to write a loop, you have to paraphrase it as a recursive template. This is asymmetric with the runtime part of the language, where constructs like `foreach` are readily available to express the desired semantics. On a different note, the same principle of symmetry applies to built-in types vs. user-defined types. In TDPL Andrei alludes to programmers disliking built-in types having "magic" behaviour that's different from user-defined types. Why the dislike? Because of asymmetry. Built-in types have special behaviour that cannot be duplicated by user-defined types, so when you want the special behaviour but built-in types don't quite meet your needs, you find yourself without any recourse. It is frustrating because the reasoning goes "if built-in type X can have magic behaviour B, why can't user-defined type Y have behaviour B too?" The desire for behaviour B to be possible both for built-in types and user-defined types stems from the desire for symmetry. Why is alias this so powerful? Because it lets a new type Y behave as if it were an existing type X -- it's symmetry. Similarly, the Liskov Substitution Principle is essentially a statement of symmetry in the universe of OO polymorphism. Why is the Unix "everything is a file" abstraction so useful? Because of symmetry: whether it's a physical file, a network socket, or pipe, it exposes the same API. Code that works with the data don't have to care about what kind of object it is; it can simply use the API that is symmetric across different types of objects. Similarly, why are D ranges so powerful? Because they make containers, data sources, data generators, etc., symmetric under the range API operations. It allows code to be decoupled from the details of the concrete types, and focus directly on the problem domain. Why does the GC simplify many programming tasks so much? Because it makes every memory-allocated object symmetric w.r.t. memory management: you stop worrying about whether something is stack-allocated or heap-allocated, whether it has cycles, or whether somebody else still holds a reference to it -- you focus on the problem domain and let the GC do its job. At a higher level: in the old days, programming languages used to distinguish between functions and procedures (and maybe some languages still do, but they seem rare these days). But eventually this distinction was ditched in favor of things like returning `void` (C, C++, Java, D), or some other equivalent construct. Why? So that instead of having two similar but asymmetric units of code encapsulation, everything is just a "function" (it just so happens some functions don't return a meaningful value). IOW, introduce symmetry, get rid of the asymmetry. On the flip side,
Re: B Revzin - if const expr isn't broken (was Re: My Meeting C++ Keynote video is now available)
On 1/17/19 2:31 PM, H. S. Teoh wrote:
On Thu, Jan 17, 2019 at 06:03:07PM +, Paul Backus via
Digitalmars-d-announce wrote:
[...]
[2]
https://bartoszmilewski.com/2009/10/21/what-does-haskell-have-to-do-with-c/
[...]
Haha, seems D did better than C++ in this respect, but not quite at the
level of Haskell.
The C++ example of a template that takes templates and arguments and
declares another template is a perfect example of why C++ template
syntax is utterly horrible for doing these sorts of things.
Coming back to the D example at the end, I totally agree with the
sentiment that D templates, in spite of their significant improvements
over C++ syntax, ultimately still follow the same recursive model. Yes,
you can use CTFE to achieve the same thing at runtime, but it's not the
same thing, and CTFE cannot manipulate template argument lists (aka
AliasSeq aka whatever it is you call them). This lack of symmetry
percolates down the entire template system, leading to the necessity of
the hack that Bartosz refers to.
Had template argument lists / AliasSeq been symmetric w.r.t. runtime
list manipulation, we would've been able to write a foreach loop that
manipulates the AliasSeq in the most readable way without needing to
resort to hacks or recursive templates.
well, there was no static foreach for that article (which I admit I
didn't read, but I know what you mean).
But it's DEFINITELY not as easy as it could be:
import std.conv;
alias AliasSeq(P...) = P;
template staticMap(alias Transform, Params...)
{
alias seq0 = Transform!(Params[0]);
static foreach(i; 1 .. Params.length)
{
mixin("alias seq" ~ i.to!string ~ " = AliasSeq!(seq" ~
(i-1).to!string ~ ", Transform!(Params[" ~ i.to!string ~ "]));");
}
mixin("alias staticMap = seq" ~ (Params.length-1).to!string ~ ";");
}
alias Constify(T) = const(T);
void main()
{
alias someTypes = AliasSeq!(int, char, bool);
pragma(msg, staticMap!(Constify, someTypes)); // (const(int),
const(char), const(bool))
}
Note, that this would be a LOT easier with string interpolation...
mixin("alias seq${i} = AliasSeq!(seq${i-1},
Transform!(Params[${i}]));".text);
-Steve
Re: Top Five World’s Most Underrated Programming Languages
On Monday, 14 January 2019 at 20:21:25 UTC, Andrei Alexandrescu wrote: Of possible interest: https://www.technotification.com/2019/01/most-underrated-programming-languages.html What's interesting here is the language nim, which perhaps has some lessons for D. https://nim-lang.org/
Re: B Revzin - if const expr isn't broken (was Re: My Meeting C++ Keynote video is now available)
Am 17.01.19 um 23:20 schrieb Stefan Koch: > For 2 years I have pondered this problem, and I did come up with a > solution. > It's actually not that hard to have CTFE interact with type-tuples. > You can pass them as function parameters, or return them if you wish. > Of course a type-tuple returning ctfe function, is compile-time only. > This solved one more problem that ctfe has: > helper functions required for ctfe can only be omitted from the binary, > if you use the trick of putting them into a module which is the import > path but never explicitly given on the command line. > newCTFE has the facility to be extended for this, and implementing > type-functions is at least on my personal roadmap. > > At Dconf 2018 Andrei and Walter said, a DIP which is substantiated > enough might make it. > However due to lack of time, (and productivity-reducing internal > changes) it will take some time until I can get started on this. > > Also I plan for newCTFE to be in shape before I add type-manipulation > abilities. > > Cheers, > > Stefan > > P.S. There is one caveat: because of how type-functions work they > cannot, you cannot create a non-anonymous symbol inside a type-function, > because there is no way to infer a mangle. > You can however create an anonymous symbol and alias it inside a > template body, which gives it a mangle and it can behave like a regular > symbol. > > This is one of the most exciting things i have read in recent times!
Re: B Revzin - if const expr isn't broken (was Re: My Meeting C++ Keynote video is now available)
On Thursday, 17 January 2019 at 19:31:24 UTC, H. S. Teoh wrote: On Thu, Jan 17, 2019 at 06:03:07PM +, Paul Backus via Digitalmars-d-announce wrote: [...] [2] https://bartoszmilewski.com/2009/10/21/what-does-haskell-have-to-do-with-c/ [...] Coming back to the D example at the end, I totally agree with the sentiment that D templates, in spite of their significant improvements over C++ syntax, ultimately still follow the same recursive model. Yes, you can use CTFE to achieve the same thing at runtime, but it's not the same thing, and CTFE cannot manipulate template argument lists (aka AliasSeq aka whatever it is you call them). This lack of symmetry percolates down the entire template system, leading to the necessity of the hack that Bartosz refers to. Had template argument lists / AliasSeq been symmetric w.r.t. runtime list manipulation, we would've been able to write a foreach loop that manipulates the AliasSeq in the most readable way without needing to resort to hacks or recursive templates. For 2 years I have pondered this problem, and I did come up with a solution. It's actually not that hard to have CTFE interact with type-tuples. You can pass them as function parameters, or return them if you wish. Of course a type-tuple returning ctfe function, is compile-time only. This solved one more problem that ctfe has: helper functions required for ctfe can only be omitted from the binary, if you use the trick of putting them into a module which is the import path but never explicitly given on the command line. newCTFE has the facility to be extended for this, and implementing type-functions is at least on my personal roadmap. At Dconf 2018 Andrei and Walter said, a DIP which is substantiated enough might make it. However due to lack of time, (and productivity-reducing internal changes) it will take some time until I can get started on this. Also I plan for newCTFE to be in shape before I add type-manipulation abilities. Cheers, Stefan P.S. There is one caveat: because of how type-functions work they cannot, you cannot create a non-anonymous symbol inside a type-function, because there is no way to infer a mangle. You can however create an anonymous symbol and alias it inside a template body, which gives it a mangle and it can behave like a regular symbol.
Re: B Revzin - if const expr isn't broken (was Re: My Meeting C++ Keynote video is now available)
On Thursday, 17 January 2019 at 22:44:08 UTC, H. S. Teoh wrote:
On Thu, Jan 17, 2019 at 10:20:24PM +, Stefan Koch via
Digitalmars-d-announce wrote:
P.S. There is one caveat: because of how type-functions work
they cannot, you cannot create a non-anonymous symbol inside a
type-function, because there is no way to infer a mangle.
You can however create an anonymous symbol and alias it inside
a template body, which gives it a mangle and it can behave
like a regular symbol.
Interesting. Is it possible to assign a "fake" mangle to type
functions that never actually gets emitted into the object
code, but just enough to make various internal compiler stuff
that needs to know the mangle work properly?
No this is not possible, a symbol which is only used at
compile-time is actually really rare. Actually If the symbol is
constrained to a compile-time only context (e.g. inside is() or
taking the .sizeof) this problem does not arise, and it could be
allowed.
Imagine you want to return a struct type which has all the
fields of a given base struct but adds a member.
module ct_helper;
alias f(alias baseT, alias newMemberType, string newMember_name)
{
struct Extended
{
baseT base;
mixin("newMemberType " ~ newMemberName);
}
return typeof(Extended.init);
}
--
module user
struct S1 { int x; }
alias S2 = f!(S1, float, "y") // looks like a
template-instantiation but it's not!, I am just reusing it, to
not confuse the parser to much.
which mangle should this get?
S2 ? - doesn't work there is no mangle for an alias.
ct_helper.f.Extended? doesn't work if we call the type-function
again with diffrent arguments
make it an anonymous type ? - If we do that than this means that
the type-function is no longer pure as two anonymous types can
never Equal each other
include the arguments to the type-function and it's parameters in
the mangle? - that's possible but type-functions are not meant to
leave any sign of their existence in order to not introduce ABI
issues.
In short for now I'd rather side-step the problem by not allowing
freshly minted types to escape into a runtime context without
going through a template wrapper (which also handles caching and
has proper behavior in is-expressions).
Re: B Revzin - if const expr isn't broken (was Re: My Meeting C++ Keynote video is now available)
On Wed, Jan 16, 2019 at 05:59:29PM -0800, Walter Bright via Digitalmars-d-announce wrote: [...] > Bartosz Milewski is a C++ programmer and a Haskell fan. He once gave a > presentation at NWCPP where he wrote a few lines of Haskell code. > Then, he showed the same code written using C++ template > metaprogramming. > > The Haskell bits in the C++ code were highlighted in red. It was like > a sea of grass with a shrubbery here and there. Interestingly, by > comparing the red dots in the C++ code with the Haskell code, you > could understand what the C++ was doing. Without the red highlighting, > it was a hopeless wall of < > :-) [...] I don't know Haskell, but I've worked with Scheme (another Lisp dialect / derivative) a little, and sometimes I feel like the core of my logic is little bits of shrubbery lost in an ocean of parentheses. :-P T -- I don't trust computers, I've spent too long programming to think that they can get anything right. -- James Miller
Re: My Meeting C++ Keynote video is now available
On Sunday, 13 January 2019 at 04:04:14 UTC, Walter Bright wrote: One major takeaway is that the bugs/line are the same regardless of the language used. This means that languages that enable more expression in fewer lines of code result in fewer bugs for the same functionality. Is the data to support this conclusion freely available on the web somewhere? My impression is that Python is considered the easiest language to use. If it has no more bugs per line than a statically typed program that seems to suggest that non-speed-critical work should be done in Python.
Re: My Meeting C++ Keynote video is now available
On Thu, Jan 17, 2019 at 11:17:18AM +, Tony via Digitalmars-d-announce wrote: > On Sunday, 13 January 2019 at 04:04:14 UTC, Walter Bright wrote: > > > One major takeaway is that the bugs/line are the same regardless of > > the language used. This means that languages that enable more > > expression in fewer lines of code result in fewer bugs for the same > > functionality. > > > Is the data to support this conclusion freely available on the web > somewhere? > > My impression is that Python is considered the easiest language to > use. If it has no more bugs per line than a statically typed program > that seems to suggest that non-speed-critical work should be done in > Python. No, if the number of bugs is truly proportional to the number of lines, then we should all ditch D and write APL instead. :-P T -- Leather is waterproof. Ever see a cow with an umbrella?
Re: B Revzin - if const expr isn't broken (was Re: My Meeting C++ Keynote video is now available)
On Thu, Jan 17, 2019 at 10:20:24PM +, Stefan Koch via Digitalmars-d-announce wrote: > On Thursday, 17 January 2019 at 19:31:24 UTC, H. S. Teoh wrote: [...] > > Coming back to the D example at the end, I totally agree with the > > sentiment that D templates, in spite of their significant > > improvements over C++ syntax, ultimately still follow the same > > recursive model. Yes, you can use CTFE to achieve the same thing at > > runtime, but it's not the same thing, and CTFE cannot manipulate > > template argument lists (aka AliasSeq aka whatever it is you call > > them). This lack of symmetry percolates down the entire template > > system, leading to the necessity of the hack that Bartosz refers to. > > > > Had template argument lists / AliasSeq been symmetric w.r.t. runtime > > list manipulation, we would've been able to write a foreach loop > > that manipulates the AliasSeq in the most readable way without > > needing to resort to hacks or recursive templates. > > > For 2 years I have pondered this problem, and I did come up with a > solution. It's actually not that hard to have CTFE interact with > type-tuples. You can pass them as function parameters, or return them > if you wish. Of course a type-tuple returning ctfe function, is > compile-time only. YES! This is the way it should be. Type-tuples become first class citizens, and you can pass them around to functions and return them from functions, the only stipulation being that they can only exist at compile-time, so it's an error to use them at runtime. In other words, they become symmetric to other built-in language types, and can be manipulated by conventional means, instead of being an oddball exception with special-case behaviour that requires special-case syntax dedicated to manipulating them. Again, the root of the problem is asymmetry, and the solution is to make it symmetric. > This solved one more problem that ctfe has: > helper functions required for ctfe can only be omitted from the > binary, if you use the trick of putting them into a module which is > the import path but never explicitly given on the command line. Exactly. Yet another problem caused by the asymmetry of type-tuples w.r.t. other built-in types, and naturally solved by making them symmetric. > newCTFE has the facility to be extended for this, and implementing > type-functions is at least on my personal roadmap. Awesome. > At Dconf 2018 Andrei and Walter said, a DIP which is substantiated > enough might make it. > However due to lack of time, (and productivity-reducing internal > changes) it will take some time until I can get started on this. > > Also I plan for newCTFE to be in shape before I add type-manipulation > abilities. Yes, let's please get the Minimum Viable Product of newCTFE merged into master first, before we expand the scope (and delay the schedule :-P) yet again! [...] > P.S. There is one caveat: because of how type-functions work they > cannot, you cannot create a non-anonymous symbol inside a > type-function, because there is no way to infer a mangle. > > You can however create an anonymous symbol and alias it inside a > template body, which gives it a mangle and it can behave like a > regular symbol. Interesting. Is it possible to assign a "fake" mangle to type functions that never actually gets emitted into the object code, but just enough to make various internal compiler stuff that needs to know the mangle work properly? T -- Why do conspiracy theories always come from the same people??
Re: Top Five World’s Most Underrated Programming Languages
On Monday, 14 January 2019 at 20:21:25 UTC, Andrei Alexandrescu wrote: Of possible interest: https://www.technotification.com/2019/01/most-underrated-programming-languages.html Because no software can use it. examples: 1. Docker use golang. 2. Middleware system use java. 3. Shell use python. 4. AI use python and R. 5. Desktop application use QT / C#. 6. Web framework & database use php's laravel and java's sprint-boot. 7. Web use Javascript / typescript.
Re: Top Five World’s Most Underrated Programming Languages
Gotta laugh at Ruby being listed as "Underrated", though. --bb On Mon, Jan 14, 2019 at 12:25 PM Andrei Alexandrescu via Digitalmars-d-announce wrote: > Of possible interest: > > > https://www.technotification.com/2019/01/most-underrated-programming-languages.html >
Re: Top Five World’s Most Underrated Programming Languages
On Friday, 18 January 2019 at 01:15:06 UTC, Bill Baxter wrote: Gotta laugh at Ruby being listed as "Underrated", though. --bb On Mon, Jan 14, 2019 at 12:25 PM Andrei Alexandrescu via Digitalmars-d-announce wrote: Of possible interest: https://www.technotification.com/2019/01/most-underrated-programming-languages.html I get the feeling that Ruby's popularity is waning with the rise of Node.js and the broad ecosystem of Javascript-based web application frameworks. At one time it probably came close to rivaling Python in popularity and sheer volume of new development, but I think that's firmly in the past now (not that it is dead, by any means).
Re: B Revzin - if const expr isn't broken (was Re: My Meeting C++ Keynote video is now available)
On 1/17/2019 8:06 AM, bpr wrote: Was that a pre C++11 version of C++, or a more modern one? pre C++11
Re: B Revzin - if const expr isn't broken (was Re: My Meeting C++ Keynote video is now available)
On 1/17/2019 11:31 AM, H. S. Teoh wrote: [...] Thanks for the thoughtful and well-written piece. But there is a counterpoint: symmetry in mathematics is one thing, but symmetry in human intuition is not. Anytime one is dealing in human interfaces, one runs into this. I certainly did with the way imports worked in D. The lookups worked exactly the same for any sort of symbol lookup. I thought it was great. But I was unable to explain it to others. Nobody could understand it when I said imported symbol lookup worked exactly like any lookup in a name space. They universally said it was "unintuitive", filed bug reports, etc. Eventually, I had to give it up. Now import lookup follows special different rules, people are happy, and I learned (again) that symmetry doesn't always produce the best outcomes. User interfaces (and programming languages certainly are user interfaces) are hard and (ironically) are anything but intuitive to design.
