digitalmars.D.announce - DConf 2013 Day 2 Talk 6: Higgs, an experimental JIT compiler written
- Andrei Alexandrescu (8/8) Jun 07 2013 Reddit:
- Graham Fawcett (11/21) Jun 07 2013 I've also cross-posted it to "/r/d_language":
- Nick Sabalausky (4/19) Jun 07 2013 Torrents up, and list of links updated:
- bearophile (51/64) Jun 08 2013 A nice talk. Some comments on the slides:
- =?UTF-8?B?QWxpIMOHZWhyZWxp?= (4/11) Jun 08 2013 There is std.stdint but it is not used much:
- Walter Bright (9/15) Jun 08 2013 It would only be a trivial problem for 5 minutes, only for ex-C/C++ prog...
- bearophile (12/19) Jun 08 2013 The size of "byte" is easy, it's 1 byte, but if you ask me a byte
- Andrej Mitrovic (3/5) Jun 08 2013 You, me, and Don, and probably others as well. It's easy to forget
- Marco Leise (14/20) Jun 08 2013 I found the integer names and sizes intuitive from the
- Walter Bright (3/6) Jun 08 2013 It's also seen in other obscure languages like Java and C#.
- Jonathan M Davis (16/40) Jun 08 2013 If I had been designing the language, I might have gone for int8, uint8,...
- Peter Williams (15/21) Jun 08 2013 It's the ghost of problems past when the sizes many of the various
- Rob T (9/27) Jun 13 2013 It was a relief to go from C++ to D and be guaranteed the sizes.
- bearophile (8/15) Jun 13 2013 There are many applications for compile-time computation, this
- Jonathan M Davis (11/31) Jun 08 2013 I'm well aware of that. I work in C++ for a living and have to deal with...
Reddit: http://www.reddit.com/r/programming/comments/1fv4zx/dconf_2013_day_2_talk_6_higgs_an_experimental_jit/ Hackernews: https://news.ycombinator.com/item?id=5839283 Twitter: https://twitter.com/D_Programming/status/343019685744369664 Facebook: http://facebook.com/dlang.org/posts/652988644714820 Youtube: http://youtube.com/watch?v=hJUNHX0vakI Please drive discussions on the social channels, they help D a lot. Andrei
Jun 07 2013
On Friday, 7 June 2013 at 15:05:15 UTC, Andrei Alexandrescu wrote:Reddit: http://www.reddit.com/r/programming/comments/1fv4zx/dconf_2013_day_2_talk_6_higgs_an_experimental_jit/ Hackernews: https://news.ycombinator.com/item?id=5839283 Twitter: https://twitter.com/D_Programming/status/343019685744369664 Facebook: http://facebook.com/dlang.org/posts/652988644714820 Youtube: http://youtube.com/watch?v=hJUNHX0vakI Please drive discussions on the social channels, they help D a lot. AndreiI've also cross-posted it to "/r/d_language": http://redd.it/1fv8y2 /r/programming is great for PR and engagement, but I like /r/d_language for its very high signal:noise (for one thing, it's easier to find past posts!). /r/d_language currently has 857 subscribers (http://stattit.com/r/d_language/). Looking forward to some growth there, as all these videos attract interested newcomers. Regards, Graham
Jun 07 2013
On Fri, 07 Jun 2013 11:05:14 -0400 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:Reddit: http://www.reddit.com/r/programming/comments/1fv4zx/dconf_2013_day_2_talk_6_higgs_an_experimental_jit/ Hackernews: https://news.ycombinator.com/item?id=5839283 Twitter: https://twitter.com/D_Programming/status/343019685744369664 Facebook: http://facebook.com/dlang.org/posts/652988644714820 Youtube: http://youtube.com/watch?v=hJUNHX0vakI Please drive discussions on the social channels, they help D a lot. AndreiTorrents up, and list of links updated: http://semitwist.com/download/misc/dconf2013/
Jun 07 2013
Andrei Alexandrescu:http://www.reddit.com/r/programming/comments/1fv4zx/dconf_2013_day_2_talk_6_higgs_an_experimental_jit/A nice talk. Some comments on the slides: ------------------------ Slide 34:- If you know C++, you can write D code - Similar enough, easy adaptation - Slightly less verboseIf you write functional-style D code that uses UCFS a lot, the code is different from the usual C++ code and much shorter (and slower). ------------------------ Slide 53:Needed template with list of integer argumentsI agree that arrays as template arguments is a natural enhancement for D. ------------------------ Slide 57:Unit Tests Blocks - Don't support naming unit tests - Failing tests not reported at the end - The main function is still called normally Higgs starts a REPL by default - No way to select which tests are run - Tempted to write our own frameworkI agree that in the built-in unittests some essential features are missing. ------------------------ Slide 58: static this() { codeGenFns[&SET_TRUE] = &gen_set_true; codeGenFns[&SET_FALSE] = &gen_set_false; codeGenFns[&SET_UNDEF] = &gen_set_undef; codeGenFns[&SET_MISSING] = &gen_set_missing; codeGenFns[&SET_NULL] = &gen_set_null; ... } ==> static this() { codeGenFns = [&SET_TRUE: &gen_set_true, &SET_FALSE: &gen_set_false, &SET_UNDEF: &gen_set_undef, &SET_MISSING: &gen_set_missing, &SET_NULL: &gen_set_null, ...]; } (That associative array can even be generated with a string mixin, if there's enough RAM). ------------------------ Slide 64:Precompile most library code used in CTFEWhere to put such compiled code? ------------------------ Slide 67: - D integer types have guaranteed sizes, but they're not obvious from the name - Why not have int8, uint8, int32, uint32, etc. in default namespace, encourage their use? I agree. It's hard to guess the size and signedness of types as byte, ubyte, wchar, dchar. I prefer names that are more clear. Bye, bearophile
Jun 08 2013
On 06/08/2013 02:23 PM, bearophile wrote:Slide 67: - D integer types have guaranteed sizes, but they're not obvious from the name - Why not have int8, uint8, int32, uint32, etc. in default namespace, encourage their use? I agree. It's hard to guess the size and signedness of types as byte, ubyte, wchar, dchar. I prefer names that are more clear.There is std.stdint but it is not used much: http://dlang.org/phobos/std_stdint.html Ali
Jun 08 2013
On 6/8/2013 2:23 PM, bearophile wrote:- D integer types have guaranteed sizes, but they're not obvious from the name - Why not have int8, uint8, int32, uint32, etc. in default namespace, encourage their use? I agree. It's hard to guess the size and signedness of types as byte, ubyte, wchar, dchar. I prefer names that are more clear.It would only be a trivial problem for 5 minutes, only for ex-C/C++ programmers who are used to suffering under variable sized ints, and will never be a problem again. Is it really a problem to guess the size of 'byte'? Or that 'ubyte' is unsigned? Come on, bearophile! And frankly, int32, long64, etc., have a large 'yech' factor for me. Besides, if you really do want them, import core.stdc.stdint;
Jun 08 2013
Walter Bright:It would only be a trivial problem for 5 minutes, only for ex-C/C++ programmers who are used to suffering under variable sized ints, and will never be a problem again. Is it really a problem to guess the size of 'byte'? Or that 'ubyte' is unsigned? Come on, bearophile!The size of "byte" is easy, it's 1 byte, but if you ask me a byte is unsigned. I have learnt to be careful with byte/ubyte in D and now I think I don't use one for the other by mistake, but I have had some bugs caused by them. It took me two or three years to to remember what's the length of dchar and wchar. New D programmer should not be need to learn such arbitrary naming scheme, inherited from C++ :-)And frankly, int32, long64, etc., have a large 'yech' factor for me.I think you meant to say int32 and int64 :-) Bye, bearophile
Jun 08 2013
On 6/9/13, bearophile <bearophileHUGS lycos.com> wrote:The size of "byte" is easy, it's 1 byte, but if you ask me a byte is unsigned. I have learnt to be careful with byte/ubyte in DYou, me, and Don, and probably others as well. It's easy to forget though that bytes are signed.
Jun 08 2013
Am Sun, 9 Jun 2013 01:53:23 +0200 schrieb Andrej Mitrovic <andrej.mitrovich gmail.com>:On 6/9/13, bearophile <bearophileHUGS lycos.com> wrote:I found the integer names and sizes intuitive from the beginning! And there was no confusion for me ever. It starts with a 'u', it is unsigned, signed otherwise. And the sizes are common in other programming languages, too. long being the only confusing one, but since int is already the 32-bit version it should be clear that it must be 64-bit. Though I can understand people who think of a byte as an unsigned type, I was much more confused by C's signed chars. Oh really? A character can be negative? Is this programming or sociology? -- MarcoThe size of "byte" is easy, it's 1 byte, but if you ask me a byte is unsigned. I have learnt to be careful with byte/ubyte in DYou, me, and Don, and probably others as well. It's easy to forget though that bytes are signed.
Jun 08 2013
On 6/8/2013 4:08 PM, bearophile wrote:It took me two or three years to to remember what's the length of dchar and wchar.I don't believe that!New D programmer should not be need to learn such arbitrary naming scheme, inherited from C++ :-)
Jun 08 2013
On Saturday, June 08, 2013 15:55:17 Walter Bright wrote:On 6/8/2013 2:23 PM, bearophile wrote:If I had been designing the language, I might have gone for int8, uint8, int16, uint16, etc. (in which case, _all_ of them would have had sizes with no aliases without - it seems overkill to me to have both), but I also don't think that it's a big deal for them to not have the numbers either, and I don't understand why anyone would think that it's all that hard to learn and remember what the various sizes are - especially when Java did something very close to what we did, and programmers seem to be fine with that. And the signed vs unsigned integers should be generally clear given that all of the integral types which are unsigned start with u and all those that don't, don't. The only exception is size_t which is already a bit of an oddity among the others, since its size can vary. So, while some people might find the sizes of the types to be a little confusing at first, I find it very hard to believe that anyone finds them to be confusing for long. It's all quite straightforward on the whole. - Jonathan M Davis- D integer types have guaranteed sizes, but they're not obvious from the name - Why not have int8, uint8, int32, uint32, etc. in default namespace, encourage their use? I agree. It's hard to guess the size and signedness of types as byte, ubyte, wchar, dchar. I prefer names that are more clear.It would only be a trivial problem for 5 minutes, only for ex-C/C++ programmers who are used to suffering under variable sized ints, and will never be a problem again. Is it really a problem to guess the size of 'byte'? Or that 'ubyte' is unsigned? Come on, bearophile! And frankly, int32, long64, etc., have a large 'yech' factor for me. Besides, if you really do want them, import core.stdc.stdint;
Jun 08 2013
On 09/06/13 14:03, Jonathan M Davis wrote:If I had been designing the language, I might have gone for int8, uint8, int16, uint16, etc. (in which case, _all_ of them would have had sizes with no aliases without - it seems overkill to me to have both), but I also don't think that it's a big deal for them to not have the numbers either, and I don't understand why anyone would think that it's all that hard to learn and remember what the various sizes areIt's the ghost of problems past when the sizes many of the various integer/natural types in C were "implementation dependent". Maybe it only afflicts programmers over a certain age :-) Platform dependent macros such as int32 mapping to the appropriate type for the implementation were a mechanism for making code portable and old habits die hard. Peter PS the numbered int/uint versions would allow "short" and "long" to be removed from the set of keywords (eventually). PPS I think the numbering paradigm would be good for floating point types as well. The mathematician in me is unsettled by a digital type called "real" as real numbers can't be represented in digital form - only approximated. So, if it wasn't already too late, I'd go for float32, float64 and float80.
Jun 08 2013
On Saturday, 8 June 2013 at 22:55:20 UTC, Walter Bright wrote:On 6/8/2013 2:23 PM, bearophile wrote:It was a relief to go from C++ to D and be guaranteed the sizes. No 'u' is signed, 'u' is unsigned, simple as simple gets. Took me a little while to learn and adjust, but not much. I didn't know about core.stdc.stdint; I may use it for the few cases where the size is very important with no room for erroneously choosing the wrong one. Slam dunk! --rt- D integer types have guaranteed sizes, but they're not obvious from the name - Why not have int8, uint8, int32, uint32, etc. in default namespace, encourage their use? I agree. It's hard to guess the size and signedness of types as byte, ubyte, wchar, dchar. I prefer names that are more clear.It would only be a trivial problem for 5 minutes, only for ex-C/C++ programmers who are used to suffering under variable sized ints, and will never be a problem again. Is it really a problem to guess the size of 'byte'? Or that 'ubyte' is unsigned? Come on, bearophile! And frankly, int32, long64, etc., have a large 'yech' factor for me. Besides, if you really do want them, import core.stdc.stdint;
Jun 13 2013
Slide 61:- Be open minded: faster CTFE opens doors - Generating procedural content at compile time - "If you build it, they will come"There are many applications for compile-time computation, this small thread discusses about applications of a compile-time constraint solver: http://lambda-the-ultimate.org/node/4762 The question:C's type system can be seen as a constraint checker; Haskell's as a constraint solver. If you had a general purpose constraint solver at compile-time what could you use it for other than type checking?<Bye, bearophile
Jun 13 2013
On Sunday, June 09, 2013 15:40:40 Peter Williams wrote:On 09/06/13 14:03, Jonathan M Davis wrote:I'm well aware of that. I work in C++ for a living and have to deal with variable-sized integral types all the time. But that doesn't mean that it's not easy to learn and remember that D made its integral types fixed size and what that size is for each of them.If I had been designing the language, I might have gone for int8, uint8, int16, uint16, etc. (in which case, _all_ of them would have had sizes with no aliases without - it seems overkill to me to have both), but I also don't think that it's a big deal for them to not have the numbers either, and I don't understand why anyone would think that it's all that hard to learn and remember what the various sizes areIt's the ghost of problems past when the sizes many of the various integer/natural types in C were "implementation dependent". Maybe it only afflicts programmers over a certain age :-) Platform dependent macros such as int32 mapping to the appropriate type for the implementation were a mechanism for making code portable and old habits die hard.PPS I think the numbering paradigm would be good for floating point types as well. The mathematician in me is unsettled by a digital type called "real" as real numbers can't be represented in digital form - only approximated. So, if it wasn't already too late, I'd go for float32, float64 and float80.The size of real is implementation defined. You have no guarantee whatsoever that you even _have_ float80. real is defined to be the largest floating point type provided by the architecture or double - whichever is larger. On x86, that happens to be 80 bits, but it won't necessarily be 80 bits on other architectures. - Jonathan M Davis
Jun 08 2013