Re: Introducing vibe.d!
Great job. Thanks Soenke et al; - Built-in support for MongoDB and Redis databases MySQL. Like other folks here I need a SQL db, At least for MyQL 5.1 there is a socket based solution from Steve Teale. https://github.com/britseye/mysqln Means no licence trouble, and probably easier to establish async support. Quote Additional drivers are easy to port to vibe.d because of the blocking API - basically the only thing that has to be done is to replace the socket calls (send(), recv(), connect() etc.) with the corresponding vibe functions. EndQuote Can you elaborate a bit more ? Maybe using the vibe.d blog. There is also a socket based PostgreSQL driver available, but I have lost the link and dunno about the status quo. A MIT licenced *D2 crypto lib worth a look : http://www.dsource.org/projects/dcrypt/wiki/Features *not up to date Whishes: diet template documentation. diet template javascript example server side QR-code generation. (well may be I am able to contribute)
Re: Introducing vibe.d!
Am 29.04.2012 06:18, schrieb Martin Nowak: Very nice to see that someone took the async/Fiber idea that far. Some observations: - Wouldn't wrapping code in void main() instead of static this() make better front page examples. The static this() pattern is mainly there to appeal to users of similar systems in script languages, where you don't have a main function at all and just happily hack away. For larger projects it doesn't make a difference but for small projects it can actually be quite convenient. Maybe it would be a good idea to place a prominent example of how it's possible to define your own main() to gain additional control. - It would be interesting to know what made you write your own Stream/JSON implementations. Stream has a number of additional functions or parameters such as leastSize() that are required or extremely convenient in this context. Also to avoid dragging in something like std.stream.File which has sychronous behavior and would block the event loop without anyone noticing it until the resulting bad performance under high-load conditions shows. The reasons for writing an own Json implementation is that the interface of std.json is.. well.. nice if you write something in C. The implementation in vibe tries to let Json seem like a natural dynamic type of the language as far as it makes sense. The std.json parser can also only parse string buffers and I wanted to have something that can easily be used to work efficiently on a stream. Support for pretty printing was another reason (would of course also easy to add on top of std.json). - I think there is some interest in having the HTTP handling and the templates in a separate library. My considerations are that if you don't use the HTTP/... parts, it will neither occupy space in your app, nor will it drag in any additional dependencies. That separate library would basically be vibe.core and vibe.stream vs. the rest of modules. And dependency-wise they are already separate (core and stream have no outside dependencies to the library). If on the other hand you wanted to use the HTTP/... stuff together with other libraries in a blocking, non-fiber environment, it would also just work - all operations are also working and blocking outside of the event loop.
Re: Introducing vibe.d!
Am 29.04.2012 08:13, schrieb bls:
Great job. Thanks Soenke et al;
- Built-in support for MongoDB and Redis databases
MySQL.
Like other folks here I need a SQL db, At least for MyQL 5.1 there is a
socket based solution from Steve Teale.
https://github.com/britseye/mysqln
Means no licence trouble, and probably easier to establish async support.
This looks like an ideal starting point. The license is of course very
similar to the MIT license, but I would like to keep everything in the
core library under a uniform license. Otherwise it could of course also
be a VPM package. But in general this looks so simple to port that I
would even just do it if no one else wants to have a shot.
Quote
Additional drivers are easy to port to vibe.d because of the blocking
API - basically the only thing that has to be done is to replace the
socket calls (send(), recv(), connect() etc.) with the corresponding
vibe functions.
EndQuote
Can you elaborate a bit more ? Maybe using the vibe.d blog.
Good idea, it will put something together.
There is also a socket based PostgreSQL driver available, but I have
lost the link and dunno about the status quo.
A MIT licenced *D2 crypto lib worth a look :
http://www.dsource.org/projects/dcrypt/wiki/Features
*not up to date
Looks nice. If it had support for SSL/TLS, we could even drop the libssl
dependency. However, I'm currently leaning towards just wrapping
libcrypto since we need it anyway for libssl and it's actively maintained.
Whishes:
diet template documentation.
This is the next point on the documentation todo list.
diet template javascript example
I will add one. You can use something like
head
:javascript
function myFunction(){
...
}
But this was just added yesterday so you need a current GIT snapshot.
server side QR-code generation. (well may be I am able to contribute)
Would be great. If you want, you could also make a github repository for
this with a package.json file and I will put it into the VPM registry.
The registry is currently still a manual process but it will be extended
so that anyone can register and publish packages. Some features such as
package signing are still missing for that.
Re: Introducing vibe.d!
On Sun, 29 Apr 2012 08:13:40 +0200, bls b...@orange.fr wrote: There is also a socket based PostgreSQL driver available, but I have lost the link and dunno about the status quo. This? https://github.com/pszturmaj/ddb
Re: Introducing vibe.d!
On Sun, 29 Apr 2012 10:31:07 +0200, Sönke Ludwig slud...@outerproduct.org wrote: Quote Additional drivers are easy to port to vibe.d because of the blocking API - basically the only thing that has to be done is to replace the socket calls (send(), recv(), connect() etc.) with the corresponding vibe functions. EndQuote Can you elaborate a bit more ? Maybe using the vibe.d blog. Good idea, it will put something together. Something wrong with the blog engine? The published post doesn't show in the list, and it's cut off in the middle without any way to expand it: http://vibed.org/blog/posts/writing-native-db-drivers
Re: Introducing vibe.d!
On 2012-04-29 10:07, Sönke Ludwig wrote: The static this() pattern is mainly there to appeal to users of similar systems in script languages, where you don't have a main function at all and just happily hack away. For larger projects it doesn't make a difference but for small projects it can actually be quite convenient. Since you can't have code (besides declarations) at the module level I don't see how static this would be than main. -- /Jacob Carlborg
Re: Introducing vibe.d!
Am 29.04.2012 11:52, schrieb simendsjo: On Sun, 29 Apr 2012 10:31:07 +0200, Sönke Ludwig slud...@outerproduct.org wrote: Quote Additional drivers are easy to port to vibe.d because of the blocking API - basically the only thing that has to be done is to replace the socket calls (send(), recv(), connect() etc.) with the corresponding vibe functions. EndQuote Can you elaborate a bit more ? Maybe using the vibe.d blog. Good idea, it will put something together. Something wrong with the blog engine? The published post doesn't show in the list, and it's cut off in the middle without any way to expand it: http://vibed.org/blog/posts/writing-native-db-drivers It was a bug in the RSS generator. I just added the article without content to not forget about it but didn't publish it yet. The RSS generator, however, published it anyway.
Re: Introducing vibe.d!
Am 29.04.2012 15:22, schrieb Jacob Carlborg: On 2012-04-29 10:07, Sönke Ludwig wrote: The static this() pattern is mainly there to appeal to users of similar systems in script languages, where you don't have a main function at all and just happily hack away. For larger projects it doesn't make a difference but for small projects it can actually be quite convenient. Since you can't have code (besides declarations) at the module level I don't see how static this would be than main. You just don't have to care about how to parse command line arguments, how to initialize the library and to start the event loop.
Introducing synd
I'd like to announce that I am working on synd, a partial port of the STK library (https://ccrma.stanford.edu/software/stk/) to D. synd provides basic building blocks for synth design such as envelopes, oscillators, delays and a few effects. I do this while waiting for Linux shared library support to become available in D;)
Re: Introducing synd
On Sunday, 29 April 2012 at 19:38:38 UTC, Timo Westkämper wrote: I'd like to announce that I am working on synd, a partial port of the STK library (https://ccrma.stanford.edu/software/stk/) to D. synd provides basic building blocks for synth design such as envelopes, oscillators, delays and a few effects. I do this while waiting for Linux shared library support to become available in D;) like the name, 'synd' is swedish for 'sin' (biblical sense, not math). ;)
Re: Introducing vibe.d!
i would like to know a bit more about those extension modules for vibe and the vpm registry. e.g. can i write yet another web framework on top of the vibe io modules as an vibe extension and would you even encourage this?
Re: Introducing synd
On 4/29/12, Timo Westkämper\ timo.westkam...@gmail.com@puremagic.com Timo Westkämper\ timo.westkam...@gmail.com@puremagic.com wrote: I'd like to announce that I am working on synd, a partial port of the STK library (https://ccrma.stanford.edu/software/stk/) to D. Cool. Have you just started working on it or is there some alpha version available?
Re: Introducing synd
On Sunday, 29 April 2012 at 20:01:40 UTC, Andrej Mitrovic wrote: On 4/29/12, Timo Westkämper\ timo.westkam...@gmail.com@puremagic.com Timo Westkämper\ timo.westkam...@gmail.com@puremagic.com wrote: I'd like to announce that I am working on synd, a partial port of the STK library (https://ccrma.stanford.edu/software/stk/) to D. Cool. Have you just started working on it or is there some alpha version available? I just started working on it. I have ported most of the STK classes already, but I am still writing tests for them.
Re: Introducing synd
On Sunday, 29 April 2012 at 19:38:38 UTC, Timo Westkämper wrote: I'd like to announce that I am working on synd, a partial port of the STK library (https://ccrma.stanford.edu/software/stk/) to D. synd provides basic building blocks for synth design such as envelopes, oscillators, delays and a few effects. I do this while waiting for Linux shared library support to become available in D;) I just realized that I forgot the project link : https://github.com/timowest/synd
Re: Introducing vibe.d!
On Sunday, 29 April 2012 at 08:52:09 UTC, simendsjo wrote: On Sun, 29 Apr 2012 08:13:40 +0200, bls b...@orange.fr wrote: There is also a socket based PostgreSQL driver available, but I have lost the link and dunno about the status quo. This? https://github.com/pszturmaj/ddb Exactly. Thanks for the pointer, It is pretty hard to create a common db- interface.
Re: Introducing vibe.d!
On Sun, 29 Apr 2012 20:28:38 +0200, Sönke Ludwig slud...@outerproduct.org wrote: It was a bug in the RSS generator. I just added the article without content to not forget about it but didn't publish it yet. The RSS generator, however, published it anyway. Yeah, I was pretty quick to find out how to subscribe to the RSS feed :)
Re: Introducing synd
On 4/29/12, Timo Westkämper\ timo.westkam...@gmail.com@puremagic.com I just realized that I forgot the project link : https://github.com/timowest/synd Thanks. synd looks like it could use a good memory allocator of some sort, something that avoids using the GC and any locks.
Re: Wasn't someone trying to work on a C backend for DMD?
On 04/29/2012 01:53 AM, Daniel Murphy wrote: Chad Jchadjoan@__spam.is.bad__gmail.com wrote in message news:jniju1$1pf7$1...@digitalmars.com... Bummer, no commits in the last 3 months or so. It was never a serious project unfortunately, just an experiment. At any rate, I almost wonder if I can compile the output C code on the OpenVMS system at work. I have a project in C I work on from time to time, but it's an uncomfortable (to say the least) environment to work with. There is stuff like this: http://h30499.www3.hp.com/t5/Languages-and-Scripting/How-do-I-get-C-program-tracebacks-to-print-SOURCE-line-numbers/td-p/5570015 If I had DMD with C-backend at my disposal, then maybe I could instrument it with a calling convention that gives me exception handling and proper debug information. Then I'd also get arrays and various other really nice D features, even with just the basics. I wouldn't bother getting the GC to work, but it'd make me consider implementing some kind of reference counting. Even without ref counting I'd have way more at that point than what I have currently with straight C code. And if I /could/ get reference counting, and if the backend were solid enough, then the thing could probably be used for writing games. I'd have the ability to output extremely portable C code to pretty much any target except the web, and there's the JS backend for that. Very enticing! It is a lng way from being able to do that. Your best bet is probably to try and configure gdc or ldc to output c or compiled code for your platform. Completing MicroD would require porting most of druntime as well. I wonder what it would take to get this sort of thing merged into mainline. A huge amount of work. I was afraid you might say that. Thanks for the input!
Re: Does D have too many features?
H. S. Teoh hst...@quickfur.ath.cx wrote in message news:mailman.67.1335651468.24740.digitalmar...@puremagic.com... On Sat, Apr 28, 2012 at 11:12:38PM +0200, SomeDude wrote: On Saturday, 28 April 2012 at 20:59:48 UTC, q66 wrote: This kind of attitude we need big fat bullshit like Java and heavy use of OO and idioms and EH and all that other crap is broken and false. And you have no way to prove that Python for example wouldn't scale for large projects; its main fault is that the default implementation is rather slow, but it's not pretty much missing anything required for a large project. Python has two big drawbacks for large projects: - it's too slow - it's a dynamically-typed language The fact that it's flexible is because it uses duck typing, and AFAIK you can't do duck typing in a statically typed language. So it's cool for small programs, but it can't handle large ones because it's not statically typed. And this opinion doesn't come just out of thin air, I speak from my own professional experience. Who says D doesn't have duck-typing? Yea, templated code is structurally-typed (duck-typed) by default. Not a big fan of that personally, but I can live with it, and D is awesome enough that you can build nominal-typing out of it: http://www.semitwist.com/articles/EfficientAndFlexible/MultiplePages/Page5/
Re: Does D have too many features?
On 29.04.2012 5:06, bearophile wrote: Jonathan M Davis: * foreach_reverse is essentially redudant at this point (not to mention confusing if combined with delegates), since we have retro. retro() can't replace foreach_reverse until the front-end demonstrability produces asm code equally efficient. bleh C++ doesn't have reverse loop in the language. all there is rbegin() and rend(). And this attitude reminds me of the old STL days. What's wrong with you people? Am I back to 90s ? Loops _must_ be fully efficient, they are a basic language construct, this is very important. Even foreach() is sometimes not equally efficient as a for() in some cases... Doesn't have to do anything with the LANGUAGE. Yesterday I tried GDC. Damn I didn't regret it :) * I hate C style struct initializers and would really like to see them go, but for reasons that I don't understand, people actually use them rather than using a proper constructor call, For single structs I prefer D-style initialization. But take a look at this code, if you replace those C-style initializers with D-style, even using aliases to shorten the code to single letters, that data section becomes more noisy: http://rosettacode.org/wiki/Ray-casting_algorithm#D Such code (tables) is usually generated anyway. [snip reasonable parts ;)] -- Dmitry Olshansky
Re: Does D have too many features?
Marco Leise marco.le...@gmx.de wrote in message news:20120429075404.121a5a46@marco-leise... I don't know about Phobos. Some batteries included are nice and help the popularity. When it comes to bindings to third party products with many alternatives, like databases, I'd say one should cut it there definitly. Yea, it's a tradeoff either way. Once we have a mature D CPAN, there will be less reason to pack things into Phobos. But until that actually happens, a batteries included-style std lib is necessary. And of course, like you say, there are likely things that just aren't appropriate for the std lib either way.
Re: Does D have too many features?
SomeDude lovelyd...@mailmetrash.com wrote in message
news:sxzgfzztxfvsstwrq...@forum.dlang.org...
On Saturday, 28 April 2012 at 20:02:12 UTC, q66 wrote:
On Saturday, 28 April 2012 at 19:57:08 UTC, SomeDude wrote:
On Saturday, 28 April 2012 at 19:23:00 UTC, q66 wrote:
So you don't agree version() is horribly half assed without AND/OR (how
do you generate the same code for two different versions without copying
or creating a new version covering both cases then?) and that version =
FOO; makes no sense?
Sorry, with that, I agree. Nick Sabalausky proposed to remove version
entirely.
But I agree there could be something like:
version(LINUX|OSX){
...
} else {
...
}
FWIW, one of the big wins I see in migrating version to static if is
switching from the clumbsy defined/undefined model to a model of
true/false, undefined is an error. The current undefined is not an error
stuff is just so...ActionScript 2.
Re: Does D have too many features?
My list: * I'd start with getting rid of foreach completely. (not just foreach_reverse). C++ was criticized for a long time for NOT having foreach in the language. Now they have http://www2.research.att.com/~bs/C++0xFAQ.html#for. Also people were so desperate to gave it that even this http://www.boost.org/doc/libs/1_49_0/doc/html/foreach.html was considered a nice addition to boost (and still part of it). Obviously somehow you want to go into the opposite direction. Beats me. If it simplifies code, makes it easier, and is more consistent, having it is better than not having it. Like walter said in one of the recent videos (going native 2012) regarding having an assembler in a language: 'When you need it, you got to have it'. True most features can be re-written as work arounds, but if you don't have to then why insist on it? Backtracking by removing key features which make the language pleasant may throw us back into the C and C++ days. Yes you can do full memory management yourself, and use pointers and pass it's size to functions. We have fat pointers, so why insist on backtracking? At the worst case if it isn't breaking the language leave it alone. If you have good reasons for it, explain them in detail. At best those of us who know better will laugh and move on.
Re: Wasn't someone trying to work on a C backend for DMD?
Daniel Murphy yebbl...@nospamgmail.com wrote in message news:jnil1c$1qv8$1...@digitalmars.com... Chad J chadjoan@__spam.is.bad__gmail.com wrote in message news:jniju1$1pf7$1...@digitalmars.com... Bummer, no commits in the last 3 months or so. It was never a serious project unfortunately, just an experiment. After having done the experiment, do you feel it's a promising approach? Are there things you figure would be better done differently?
Re: More bugs...
On Saturday, 28 April 2012 at 09:36:55 UTC, Timon Gehr wrote:
On 04/28/2012 08:03 AM, Mehrdad wrote:
You expected that to work?
Uhm, why not?
templateclass T
struct F
{
FFT f() { return FFT (); }
};
int main()
{
Fint().f().f().f().f().f(); // etc.
return 0;
}
D templates are analysed eagerly upon instantiation, whereas
C++ templates are analysed lazily. This is not a bug, it is a
feature.
Furthermore, eager analysis is necessary for other D features
like CTFE and compile-time reflection. Honestly, in C++ I would
stay away from code like the above anyway, irrelevant of whether
it compiles, seems too magic-y for my tastes. I don't like
things not being explicit.
--
James Miller
Re: Does D have too many features?
Am 28.04.2012 20:47, schrieb Walter Bright: Andrei and I had a fun discussion last night about this question. The idea was which features in D are redundant and/or do not add significant value? A couple already agreed upon ones are typedef and the cfloat, cdouble and creal types. What's your list? - two different ways of creating function pointers is confusing (function and delegate) I understand the reasoning, but makes one think all the time when to use what. - sometimes D code looks like template and mixins gone mad While I do appreciate the power, it can be quite confusing to try to understand what the code does. Specially with the lack of support in mixin's debugging - __traits should be given a proper name It looks out of place in regard with the rest of the language, by making use of the underscores - AA should be a library type I am on the C++ and Scala camp where the language should be extendable via the library - misuse of enum to declare constants I prefer that the use of const would be possible - conditional compilation is hard to follow without syntax highlighting Other languages with conditional compilation make it easier to follow what is what. e.g. Turbo Pascal/Delphi, C#, Modula-3, Ada - unit tests I would rather have them as a library. While it is fun to discuss what we like and not like, I vote that priority should be given to make the language stable and have better tooling. We need to have safer languages with native code generation for systems programming in the mainstream OS, that take us away from the buffer overflow exploits and dagling pointers legacy that C and C++ brought upon us. Someone that does not know D and sees the amount of bugs still existing, or this type of discussions, will run away to Go or some future version of C#/Spec#/Bartok, or back to whatever he/she was using before. I don't agree D is complex, any language that aims to be used in large application domains, needs a certain set of abstractions. If it does not support them, it is condemmend to keep getting new features until it turns in what the language designers were fighting against. -- Paulo
Re: Does D have too many features?
Timon Gehr timon.g...@gmx.ch wrote in message
news:jnhpvv$ih4$1...@digitalmars.com...
On 04/28/2012 11:04 PM, Dmitry Olshansky wrote:
But how about:
alias thing = runSomeCtfe();
That would work in certain cases, where the initializer is not a single
symbol. But then, I kinda like the way 'enum' is generalized in D:
enum Foo{
member1,
member2,
member3,
}
= (allow non-integral enumerations)
enum Foo{
member1 = 1,
member2 = 2,
member3 = 3,
}
Those are good. They are essentially enumerations.
= (anonymous enums)
enum{
member1 = 1,
member2 = 2,
member3 = 3,
}
I don't think anonymous enum makes any sense at all. It's *not* an
enumeration by any stretch of the term, it's just a series of manifest
constants. The fact that they're grouped doesn't even have any semantic
consequence, as far as I'm aware.
= (a single member is okay)
enum{
member1 = 1,
}
= (syntactic sugar)
enum member1 = 1;
Just simpler examples of the above, which isn't any form of enumeration at
all.
And bring the usual alias to new_name = something;
form (even C++ finally got this right with C++11 aliases).
This is probably something that should be done.
Emphatic +1
I always have to stop and think carefully about the order when I write an
alias.
Implementing a compiler is probably harder for D, because of the interplay
of forward references, CTFE and compile time introspection.
Those make D more difficult to implement than many languages, but OTOH,
AIUI, C++ has some real nightmarish details with templates and even just
simply parsing. Probably some other bizarre cruft, too. IIRC, I think
Walter's occasionally mentioned something about the...overload rules?
Re: Does D have too many features?
On Sunday, April 29, 2012 09:53:15 Dmitry Olshansky wrote: On 29.04.2012 4:31, Jonathan M Davis wrote: For better or worse, the solution for smart pointers in D would be to use opDispatch, *cough* alias this *cough* That's not necessarily a good idea, depending on how it's used. You want to avoid having the smart pointer implicitly convert to what it holds such that a reference to it leaks. If you're dealing with a pointer to a struct, and alias this aliases to the struct (rather than the pointer), then you're okay. But if you're dealing with a class, you don't have that option. So, alias this ends up leaking a reference to the class, which defeats the purpose of the smart pointer. You have the same problem if alias this aliases to the pointer rather than what's pointed to. But regardless of whether you use alias this or opDispatch, you have the same problem with regards to -. In C++, . would be used to call the smart pointer's functions, and - would be used to call functions on the object pointed to. In D, the two aren't distinguished - both use . - so you can't have any functions on the type pointed to which conflict with the smart pointer's functions, or you won't be able to call them (unless another way to call them is provided somehow). So, it's definitely something that C++ does better with as far as that goes. - Jonathan M Davis
Re: Does D have too many features?
Am 28.04.2012 22:59, schrieb q66: On Saturday, 28 April 2012 at 20:35:40 UTC, SomeDude wrote: On Saturday, 28 April 2012 at 20:09:50 UTC, q66 wrote: On Saturday, 28 April 2012 at 20:05:30 UTC, SomeDude wrote: There are minimalistic languages that don't add too much complexity, instead it results in code being kept simple. I appreciate minimalistic languages. I love the simplicity of Scheme and the design of Lua. Lua and Python are extensible language, but truth be told, they cannot handle large scale programming. In fact, I don't know of any minimalistic language that can scale from hundreds of thousands to millions of lines of code. When you reach these sizes, their simple design becomes a drawback. You start missing lots of features. When you reach large scale programming, you want really powerful tools. That's basically what the Java designers discovered after experience. The original language was simple and easy, but that simplicity translated into way too much boilerplate code. So they kept adding features from version to version, generics, then annotations, a means to create new keywords. And now they would like to add delegates. These are all needed in large programs. D needs to do something it does really well and concentrate on that. Otherwise the language will remain being rather vague and doing a bit of everything, but nothing truly well. It does a lot of things well already. Our point of comparison should not be Python or Lua, it must be C, C++, C#, Haskell, Ocaml, i.e languages that are designed to develop large systems. But most of all it needs to stabilize and polish, not change all the time. I think its feature set is very good already. We are far from having explored all its possibilities. Instead of adding more and more features into a rigid language, it needs to be made more flexible and extensible, both syntactically and semantically. This kind of attitude we need big fat bullshit like Java and heavy use of OO and idioms and EH and all that other crap is broken and false. And you have no way to prove that Python for example wouldn't scale for large projects; its main fault is that the default implementation is rather slow, but it's not pretty much missing anything required for a large project. Python is my favorite scripting language, but I would never propose a dynamic language for programming on the large. My employer does consulting for big projects. The type of entreprise projects that require multi-site development scattered across the globe, sometimes with 300+ developers. There is no way a dynamic language would work in such scenarios, without having a constant broken build on the CI system. -- Paulo
Re: Wasn't someone trying to work on a C backend for DMD?
Nick Sabalausky seewebsitetocontac...@semitwist.com wrote in message news:jnimdk$1t1t$1...@digitalmars.com... It was never a serious project unfortunately, just an experiment. After having done the experiment, do you feel it's a promising approach? Are there things you figure would be better done differently? I actually found it a lot easier than expected. Most of the constructs that survive to the glue layer are c constructs, which naturally map very well to c code. Writing the actual code is quite straightforward, it's very similar to what is done in 'toCBuffer' for di generation. I never hit a roadblock, so it should be easy for someone else to continue on from there (as Adam has). That said, reconfiguring gdc or ldc to output c (or to target the intended platform) is probably a better idea than writing a new c backend. Either way, druntime needs to be ported.
Re: Does D have too many features?
On Sunday, 29 April 2012 at 00:40:01 UTC, Era Scarecrow wrote: On Saturday, 28 April 2012 at 23:50:22 UTC, foobar wrote: On Saturday, 28 April 2012 at 21:02:25 UTC, H. S. Teoh wrote: * di files - a library should encapsulate all the info required to use it. Java Jars, .Net assemblies and even old school; Pascal units all solved this long ago. I agree with the general notion here. Whatever the actual implementation details are, the API should be strongly tied to the binary in order to insure consistency and ease of use. I shouldn't need to worry if the header files match the binary library. Regarding the human readable API - that's why we have documentation for. Mmm well the main reason I see using .di files, is cases when the input library/file/dll doesn't give you much or any information. like... most dll's today. There's also tools to strip that extra debugging and structure information from your output file, so if you distribute a binary only, you still need to include it's .h file or .di file. Cases where this would be far more relevant could be in systems that don't have a lot of room (mini-distros or recovery disks for example). I've seen a recovery disk distro with everything you needed 2 floppies disks. Only reason I don't use floppies anymore is the ones being made are crap and don't keep data where as 14 years ago I could accidentally put mine through the wash and still access it's contents. (Cheap bastards) floppies, are you for real?! This is only relevant if you travel a decade or so back in time. The current generation dvd/Blu-ray discs and USB sticks aren't good enough for you?
Re: Does D have too many features?
On Sunday, 29 April 2012 at 06:11:00 UTC, Era Scarecrow wrote: My list: * I'd start with getting rid of foreach completely. (not just foreach_reverse). C++ was criticized for a long time for NOT having foreach in the language. Now they have http://www2.research.att.com/~bs/C++0xFAQ.html#for. Also people were so desperate to gave it that even this http://www.boost.org/doc/libs/1_49_0/doc/html/foreach.html was considered a nice addition to boost (and still part of it). Obviously somehow you want to go into the opposite direction. Beats me. If it simplifies code, makes it easier, and is more consistent, having it is better than not having it. Like walter said in one of the recent videos (going native 2012) regarding having an assembler in a language: 'When you need it, you got to have it'. True most features can be re-written as work arounds, but if you don't have to then why insist on it? Backtracking by removing key features which make the language pleasant may throw us back into the C and C++ days. Yes you can do full memory management yourself, and use pointers and pass it's size to functions. We have fat pointers, so why insist on backtracking? At the worst case if it isn't breaking the language leave it alone. If you have good reasons for it, explain them in detail. At best those of us who know better will laugh and move on. One of the ideas that I see regularly thrown around is to remove more and more things from the core language and put them in the libraries, because it's possible, and it would make for a thinner languages. Well, these are good reasons to do it, but there are many good reasons NOT to do it. Some general reasons: 1. code is uglier when in the libraries. One must add imports, and template code is uglier and harder to write than plain old code. 2. template code makes bigger size executables 3. error messages are more cryptic 4. we like to think that putting things in the library helps changing things easier, but my opinion is, changing fundamental structures in the standard library may actually break more code than changing them in the core language, because of the heavy interplay between modules, and also because the standard library is probably less well tested (in terms of number of regression tests) than the core language. 5. it makes work much harder for tools and parsers Specific to D: 6. my impression is, from what I've seen in Bugzilla, that Phobos bugs tend to stay around longer, because there is not enough workforce on it These a lot of drawbacks in my opinion. Basically, one of the main reasons the D code is clean, is because the core languages features so many useful things, with a nice, clean syntax. Moving them to the standard library will automatically make the code uglier and the language harder to use.
Re: Does D have too many features?
On Sunday, 29 April 2012 at 06:10:40 UTC, Nick Sabalausky wrote:
SomeDude lovelyd...@mailmetrash.com wrote in message
news:sxzgfzztxfvsstwrq...@forum.dlang.org...
On Saturday, 28 April 2012 at 20:02:12 UTC, q66 wrote:
On Saturday, 28 April 2012 at 19:57:08 UTC, SomeDude wrote:
On Saturday, 28 April 2012 at 19:23:00 UTC, q66 wrote:
So you don't agree version() is horribly half assed without
AND/OR (how do you generate the same code for two different
versions without copying or creating a new version covering
both cases then?) and that version = FOO; makes no sense?
Sorry, with that, I agree. Nick Sabalausky proposed to remove
version entirely.
But I agree there could be something like:
version(LINUX|OSX){
...
} else {
...
}
FWIW, one of the big wins I see in migrating version to
static if is
switching from the clumbsy defined/undefined model to a model
of
true/false, undefined is an error. The current undefined is
not an error
stuff is just so...ActionScript 2.
I don't mind changing the semantics of version, but replacing
the KEYWORD version with static if will make for code that is
harder to read for the eye, harder to parse for the tools, and
overall uglier. So I want to keep the keyword, which is a very
good addition in my opinion.
Re: Does D have too many features?
On Sunday, 29 April 2012 at 05:54:10 UTC, Marco Leise wrote: Am Sat, 28 Apr 2012 15:39:49 -0400 schrieb Nick Sabalausky seewebsitetocontac...@semitwist.com: q66 quake...@gmail.com wrote in message news:ihqjguujvoukhlqcw...@forum.dlang.org... - Phobos is too fat - it needs to shrink to just a few core modules, others being distributed via some system like CPAN for Perl - Properties - they're kinda broken at this point and the value is questionable - @trusted @system - Exception handling - a lot of runtime, questionable value That's just craziness! Madness even! AAs are soon mostly in the library and that's a good trade-off; @trusted @system needs to be there as long as there is @safe; exception handling - some people rely on it heavily. See it as the easy way to error out of a function that doesn't normally return anything and cascade up several calls, while being able to release resources in each. I don't know about Phobos. Some batteries included are nice and help the popularity. When it comes to bindings to third party products with many alternatives, like databases, I'd say one should cut it there definitly. I can agree on the rest. I don't want AA to be removed from the core language. That would be a big step backward in my opinion. Core language AAs are entirely adequate for a lot of applications, and they make for so much cleaner and easier to read/write code than template notation.
Re: Does D have too many features?
On Saturday, 28 April 2012 at 23:51:43 UTC, Jonathan M Davis wrote: But even just storing it in a local variable to use later could destroy the locality enough to defeat LDC's optimization. Huh? I can't think of a situation where a hash table lookup would entail less indirections than dereferencing a pointer stored in a register (resp. the stack, depending on scheduling). David
Re: Does D have too many features?
SomeDude lovelyd...@mailmetrash.com wrote in message news:jrdmqmchgbibqmrwz...@forum.dlang.org... On Sunday, 29 April 2012 at 05:54:10 UTC, Marco Leise wrote: Am Sat, 28 Apr 2012 15:39:49 -0400 Madness even! AAs are soon mostly in the library and that's a good trade-off; @trusted @system needs to be there as long as there is @safe; exception handling - some people rely on it heavily. See it as the easy way to error out of a function that doesn't normally return anything and cascade up several calls, while being able to release resources in each. I don't know about Phobos. Some batteries included are nice and help the popularity. When it comes to bindings to third party products with many alternatives, like databases, I'd say one should cut it there definitly. I can agree on the rest. I don't want AA to be removed from the core language. That would be a big step backward in my opinion. Core language AAs are entirely adequate for a lot of applications, and they make for so much cleaner and easier to read/write code than template notation. There will still be sugar in the compiler so they appear to be builtins. When the switch happens, I'm sure it'll be transparent - average users probably won't even notice. It's just that behind the scenes their implementation will move from DMD to Druntime.
Re: Does D have too many features?
Nick Sabalausky seewebsitetocontac...@semitwist.com wrote in message news:jnit81$29uh$1...@digitalmars.com... SomeDude lovelyd...@mailmetrash.com wrote in message news:jrdmqmchgbibqmrwz...@forum.dlang.org... On Sunday, 29 April 2012 at 05:54:10 UTC, Marco Leise wrote: Am Sat, 28 Apr 2012 15:39:49 -0400 Madness even! AAs are soon mostly in the library and that's a good trade-off; @trusted @system needs to be there as long as there is @safe; exception handling - some people rely on it heavily. See it as the easy way to error out of a function that doesn't normally return anything and cascade up several calls, while being able to release resources in each. I don't know about Phobos. Some batteries included are nice and help the popularity. When it comes to bindings to third party products with many alternatives, like databases, I'd say one should cut it there definitly. I can agree on the rest. I don't want AA to be removed from the core language. That would be a big step backward in my opinion. Core language AAs are entirely adequate for a lot of applications, and they make for so much cleaner and easier to read/write code than template notation. There will still be sugar in the compiler so they appear to be builtins. When the switch happens, I'm sure it'll be transparent - average users probably won't even notice. It's just that behind the scenes their implementation will move from DMD to Druntime. In fact, don't regular arrays already work like this?
Re: Does D have too many features?
On Sunday, April 29, 2012 10:07:38 David Nadlinger wrote:
On Saturday, 28 April 2012 at 23:51:43 UTC, Jonathan M Davis
wrote:
But even just storing it in a local variable to use later
could destroy the locality enough to defeat LDC's optimization.
Huh? I can't think of a situation where a hash table lookup would
entail less indirections than dereferencing a pointer stored in a
register (resp. the stack, depending on scheduling).
If you have something like
if(key in aa)
{
// lots of code
func(aa[key]);
}
the compiler is not necessarily going to be able to determine that the AA has
not been changed such that aa[key] can use the same lookup that key in aa did
rather than redoing the lookup. A prime example would be
if(key in aa)
{
foo(aa);
func(aa[key]);
}
The compiler doesn't necessarily know that foo won't remove key from aa, so it
can't save the result of key in aa to reuse rather than calling aa[key],
whereas the programmer could know that foo doesn't do anything to aa which
would make a pointer to the element invalid and can guarantee that only one
lookup occurs by doing
if(auto value = key in aa)
{
foo(aa);
func(value);
}
And that's just one case where the compiler can't make such an optimization
but the programmer can. It's _far_ better iMHO to have in return a pointer
than to rely on the compiler removing extraneous lookups.
- Jonathan M Davis
Re: Does D have too many features?
On Sunday, 29 April 2012 at 01:06:54 UTC, bearophile wrote:
retro() can't replace foreach_reverse until the front-end
demonstrability produces asm code equally efficient.
Loops _must_ be fully efficient, they are a basic language
construct, this is very important. Even foreach() is sometimes
not equally efficient as a for() in some cases...
Slightly related: For this:
---
import core.stdc.stdio;
import std.algorithm;
import std.range;
void main() {
int sum;
foreach (i; retro(iota(11))) sum += i;
printf(%d\n, sum);
}
---
LDC produces
---
__Dmain:
pushq %rax
movl$0x0037,%esi
xorb%al,%al
leaq_.str24(%rip),%rdi # str24 = %d\n
callq _printf
xorl%esi,%esi
movl%eax,0x04(%rsp)
movl%esi,%eax
popq%rdx
ret
---
Now that's constant folding… ;)
David
Re: How can D become adopted at my company?
SomeDude lovelyd...@mailmetrash.com wrote in message news:zmlqmuhznaynwtcyp...@forum.dlang.org... On Saturday, 28 April 2012 at 09:12:23 UTC, SomeDude wrote: Real time guarantees on a GC is not something we are going to offer anytime soon anyway. While a minimal library, loosely based on the C standard library, with some more bells and whistles that could be borrowed from Phobos, this is a goal that is achievable in a foreseeable future. And both game developers and embedded programmers would be interested. Note that Kenta Cho, who wrote fast games in D1, Actually, I think it was pre-D1. (They were fantastic games, too.) used this approach, and it worked very well for him. Interesting, I had wondered about that. I never dug quite that deep into the code, so I never knew he had done it that way.
Re: Does D have too many features?
On Sunday, 29 April 2012 at 08:20:59 UTC, Jonathan M Davis wrote: The compiler doesn't necessarily know that foo won't remove key from aa, so it can't save the result of key in aa to reuse rather than calling aa[key], whereas the programmer could know that foo doesn't do anything to aa which would make a pointer to the element invalid and can guarantee that only one lookup occurs by doing […] Yes, point taken, but what does this have to do with locality? David
Re: Does D have too many features?
On 04/29/2012 06:36 AM, Andrej Mitrovic wrote: On 4/29/12, Timon Gehrtimon.g...@gmx.ch wrote: - 'in' operator returning a pointer to the element. AFAIK this is a property of how the opIn_r function is implemented, nothing much to do with the language itself. Well, AAs are part of the language. But it does allow for some neat tricks, like: int[int] hash; hash[1] = 2; int value = *enforce(1 in hash, new Exception(1 not in hash)); assert(value == 2); or: if (auto val = 1 in hash) ...use val pointer (+ if it's a class/struct pointer you still have access to the dot syntax) else ... errors.. I know, but 'in' is somewhat of a misnomer. Anyway, it is not a huge issue.
Re: Does D have too many features?
On Sunday, 29 April 2012 at 08:13:53 UTC, Nick Sabalausky wrote: There will still be sugar in the compiler so they appear to be builtins. When the switch happens, I'm sure it'll be transparent - average users probably won't even notice. It's just that behind the scenes their implementation will move from DMD to Druntime. Hmmm, sounds nice, but bolting the language with the standard library is very risky (and a rather bad idea imho). Unless there is a very lightweight minimalistic core for Phobos (something which I advocate), you bolt a heavyweight library to your language, and that's not good. I'd rather keep the integrated the AAs, which are fine for most applications, and have templated AAs in the library for heavier use. Even though it may seem redundant, it's just as redundant as having arrays in the core language and std.array. Noone would want to remove arrays from the core language, right ?
Re: Does D have too many features?
On Sunday, April 29, 2012 10:22:44 David Nadlinger wrote: On Sunday, 29 April 2012 at 08:20:59 UTC, Jonathan M Davis wrote: The compiler doesn't necessarily know that foo won't remove key from aa, so it can't save the result of key in aa to reuse rather than calling aa[key], whereas the programmer could know that foo doesn't do anything to aa which would make a pointer to the element invalid and can guarantee that only one lookup occurs by doing […] Yes, point taken, but what does this have to do with locality? I think that you're thinking of something completely different about the term locality than I meant. I meant locality in terms of how close the aa[key] expression was to the key in aa expression within the function - i.e. how local they were to each other. I may have misused the term though. I don't know. - Jonathan M Davis
Re: Does D have too many features?
On Sunday, 29 April 2012 at 07:00:51 UTC, foobar wrote: floppies, are you for real?! This is only relevant if you travel a decade or so back in time. The current generation dvd/Blu-ray discs and USB sticks aren't good enough for you? What? I like my floppies... or did when they worked. Depends on what I'm doing; I mean a meg is a lot of space if your primarily doing text and using compression. But I accept it is an old technology and won't be coming back.
Re: Does D have too many features?
On Sunday, 29 April 2012 at 08:30:15 UTC, Jonathan M Davis wrote: On Sunday, April 29, 2012 10:22:44 David Nadlinger wrote: Yes, point taken, but what does this have to do with locality? I think that you're thinking of something completely different about the term locality than I meant. I meant locality in terms of how close the aa[key] expression was to the key in aa expression within the function - i.e. how local they were to each other. I may have misused the term though. I don't know. Okay, then it was just a misunderstanding, I thought about memory locality. David
Re: Does D have too many features?
On 04/29/2012 10:28 AM, SomeDude wrote: On Sunday, 29 April 2012 at 08:13:53 UTC, Nick Sabalausky wrote: There will still be sugar in the compiler so they appear to be builtins. When the switch happens, I'm sure it'll be transparent - average users probably won't even notice. It's just that behind the scenes their implementation will move from DMD to Druntime. Hmmm, sounds nice, but bolting the language with the standard library is very risky (and a rather bad idea imho). Unless there is a very lightweight minimalistic core for Phobos (something which I advocate), you bolt a heavyweight library to your language, and that's not good. druntime is the library it will be moved into, not Phobos.
Re: Does D have too many features?
On Sunday, 29 April 2012 at 08:31:57 UTC, Timon Gehr wrote: druntime is the library it will be moved into, not Phobos. Ah, that's ok, then.
Re: Does D have too many features?
On 04/29/2012 10:20 AM, Jonathan M Davis wrote:
On Sunday, April 29, 2012 10:07:38 David Nadlinger wrote:
On Saturday, 28 April 2012 at 23:51:43 UTC, Jonathan M Davis
wrote:
But even just storing it in a local variable to use later
could destroy the locality enough to defeat LDC's optimization.
Huh? I can't think of a situation where a hash table lookup would
entail less indirections than dereferencing a pointer stored in a
register (resp. the stack, depending on scheduling).
If you have something like
if(key in aa)
{
// lots of code
func(aa[key]);
}
the compiler is not necessarily going to be able to determine that the AA has
not been changed such that aa[key] can use the same lookup that key in aa did
rather than redoing the lookup. A prime example would be
if(key in aa)
{
foo(aa);
func(aa[key]);
}
The compiler doesn't necessarily know that foo won't remove key from aa, so it
can't save the result of key in aa to reuse rather than calling aa[key],
whereas the programmer could know that foo doesn't do anything to aa which
would make a pointer to the element invalid and can guarantee that only one
lookup occurs by doing
if(auto value = key in aa)
{
foo(aa);
func(value);
}
And that's just one case where the compiler can't make such an optimization
but the programmer can. It's _far_ better iMHO to have in return a pointer
than to rely on the compiler removing extraneous lookups.
- Jonathan M Davis
Well, what if the programmer knows that foo does not change 'aa', but
it actually does? Then there would possibly be a segmentation fault.
This implies that the 'in' operator cannot be used in @safe code. (Or
there would have to be a special case, that allows 'in' if the result is
directly cast to bool.)
Re: Does D have too many features?
On 04/29/2012 08:31 AM, Paulo Pinto wrote: Am 28.04.2012 20:47, schrieb Walter Bright: Andrei and I had a fun discussion last night about this question. The idea was which features in D are redundant and/or do not add significant value? A couple already agreed upon ones are typedef and the cfloat, cdouble and creal types. What's your list? - two different ways of creating function pointers is confusing (function and delegate) I understand the reasoning, but makes one think all the time when to use what. 'delegate' is more powerful, 'function' is more efficient. If you don't want to think about it, just use 'delegate'. I'd rather see 'function' implicitly convert to 'delegate' than to have it gone. D can be used for systems programming after all! - sometimes D code looks like template and mixins gone mad While I do appreciate the power, it can be quite confusing to try to understand what the code does. Specially with the lack of support in mixin's debugging pragma(msg, ...) ? - misuse of enum to declare constants I prefer that the use of const would be possible const infects the type and const-qualified data can exist at runtime, so it is not possible. - conditional compilation is hard to follow without syntax highlighting Other languages with conditional compilation make it easier to follow what is what. e.g. Turbo Pascal/Delphi, C#, Modula-3, Ada That is not a language issue. While it is fun to discuss what we like and not like, I vote that priority should be given to make the language stable and have better tooling. We need to have safer languages with native code generation for systems programming in the mainstream OS, that take us away from the buffer overflow exploits and dagling pointers legacy that C and C++ brought upon us. Someone that does not know D and sees the amount of bugs still existing, or this type of discussions, will run away to Go or some future version of C#/Spec#/Bartok, or back to whatever he/she was using before. I don't agree D is complex, any language that aims to be used in large application domains, needs a certain set of abstractions. If it does not support them, it is condemmend to keep getting new features until it turns in what the language designers were fighting against. I agree with this section.
Re: Does D have too many features?
On Sunday, April 29, 2012 10:37:10 Timon Gehr wrote: Well, what if the programmer knows that foo does not change 'aa', but it actually does? Then there would possibly be a segmentation fault. This implies that the 'in' operator cannot be used in @safe code. (Or there would have to be a special case, that allows 'in' if the result is directly cast to bool.) It's exactly as safe as any iterator or range which could be invalidated - both of which can occur in safe code. Any of those could blow up in entertaining ways if you use them after they've been invalidated. Pointers are considered safe. It's pointer arithmetic which isn't. - Jonathan M Davis
Re: More bugs...
On Sunday, 29 April 2012 at 06:22:34 UTC, James Miller wrote: D templates are analysed eagerly upon instantiation, whereas C++ templates are analysed lazily. This is not a bug, it is a feature. Furthermore, eager analysis is necessary for other D features like CTFE and compile-time reflection. Ah, I was wondering about that. Thank you for confirming. I will gladly ditch lazy template eval for something like CTFE. Honestly, in C++ I would stay away from code like the above anyway, irrelevant of whether it compiles, seems too magic-y for my tastes. I don't like things not being explicit. +1
Re: Does D have too many features?
On 04/29/2012 01:25 AM, foobar wrote:
On Saturday, 28 April 2012 at 20:43:38 UTC, Timon Gehr wrote:
On 04/28/2012 09:58 PM, foobar wrote:
On Saturday, 28 April 2012 at 18:48:18 UTC, Walter Bright wrote:
Andrei and I had a fun discussion last night about this question. The
idea was which features in D are redundant and/or do not add
significant value?
A couple already agreed upon ones are typedef and the cfloat, cdouble
and creal types.
What's your list?
D has a lot of ad-hock features which make the language
needlessly large and complex. I'd strive to replace these with
better general purpose mechanisms.
My list:
* I'd start with getting rid of foreach completely. (not just
foreach_reverse).
foreach is very useful. Have you actually used D?
I have used D and didn't claim that foreach isn't useful.
What I said that is that it belongs in the library, NOT the language.
Therefore you say that it is not useful as a language feature.
This is nothing more than a fancy function with
a delegate parameter.
That would be opApply.
Indeed but I'd go even further by integrating it with ranges so that
ranges would provide an opApply like method e.g.
auto r = BinaryTree!T.preOrder(); // returns range
r.each( (T elem) { ...use elem...}); // each method a-la Ruby
Well, I don't think this is better than built-in foreach (with full
break and continue and goto even for user-defined opApply!)
* enum - enum should be completely redesigned to only implement
what it's named after: enumerations.
What is the benefit?
On the one hand the current enum for manifest constants is a hack due to
weaknesses of the toolchain
I think that is actually not true. It might have been the original
motivation, but it has gone beyond that. Which weaknesses in particular?
I don't think that the toolchain can be improved in any way in this regard.
and on the other hand it doesn't provide
properly encapsulated enums
Those could in theory be added without removing the manifest constant usage.
such as for instance the Java 5.0 ones or
the functional kind.
An algebraic data type is not an 'enumeration', so this is a moot point.
* version - this does not belong in a programming language. Git
is a much better solution.
So you'd maintain a git branch for every OS if there is some small
part that is OS-dependent? I don't think that is a better approach at
all.
It is far better than having a pile of #ifdef styled spaghetti code.
I'd expect to have all the OS specific code encapsulated separately anyway,
not spread around the code base. Which is the current recommended way of
using
versions anyway. The inevitable conclusion would be to either use a
version management system like git or have separate implementation
modules for platform specific code and use the build tool to implement
the logic of select the modules to include in the build.
Which projects you are aware of actually use this kind of versioning?
* di files - a library should encapsulate all the info required
to use it. Java Jars, .Net assemblies and even old school; Pascal
units all solved this long ago.
* This is a big one: get rid of *all* current compile time
special syntax.
What would that be exactly?
This includes __traits, templates, static ifs, etc..
This is what makes D useful to me.
It should be replaced by a standard compilation
API and the compiler should be able to use plugins/addons.
Are you serious?
No I'm joking.
The current system is a pile of hacks on top of the broken model of c++
templates.
I should be able to use a *very* minimalistic system to write completely
_regular_ D code and run it at different times.
Examples in concrete syntax? How would you replace eg. string mixin
functionality?
This is a simple matter
of separation of concerns: what we want to execute (what code) is
separate to the concern of when we want to execute it.
It is not. For example, code that is only executed during CTFE does
never have to behave gracefully if the input is ill-formed.
Re: How can D become adopted at my company?
On 28 April 2012 04:10, H. S. Teoh hst...@quickfur.ath.cx wrote: On Sat, Apr 28, 2012 at 01:31:32AM +0200, SomeDude wrote: [...] The other thing that would make it attractive among the C++ developers, would be the development of a lightweight, high performance, minimal library that doesn't use the GC at all. Ideally, it would be compatible with Phobos. I bet if such a library existed, flocks of C++ developers would suddenly switch to D. I know the current GC leaves much room for improvement, but what's the hangup about the GC anyway? If -- and yes this is a very big if -- the GC has real-time guarantees, would that make it more palatable to C++ devs? Or is it just because they have trouble with the idea of having a GC in the first place? If the GC guarantees to behave in a deterministic and predictable way, I have no problem with it. And even if it doesn't, as long as it's lightning fast, and I can control the sweeps. One major concern to me is invisible allocations. I want to know when I'm allocating, I like allocate operations to be clearly visible. There are a lot of operations that cause invisible allocations in D, but they are avoidable. Games are both embedded and realtime code at the same time, this unions the strict requirements of both worlds into a system that demands very tight control of these things. Fragmentation is the enemy, so is losing 1ms (GC takes WAY longer than this currently) at random moments. There is a problem right now where the GC doesn't actually seem to work, and I'm seeing D apps allocating gigabytes and never releasing the memory. A great case study for the GC is VisualD, if any GC experts would like to check it out. It shows a use case where the GC utterly fails, and makes the software borderline unusable as a result. It seems to 'leak' memory, and collects can take 5-10 seconds at a time (manifested by locking up the entire application). VisualD has completely undermined by faith and trust in the GC, and I've basically banned using it. I can't afford to run into that situation a few months down the line.
Re: Does D have too many features?
On Sunday, 29 April 2012 at 08:58:24 UTC, Timon Gehr wrote:
[...]
Indeed but I'd go even further by integrating it with ranges
so that
ranges would provide an opApply like method e.g.
auto r = BinaryTree!T.preOrder(); // returns range
r.each( (T elem) { ...use elem...}); // each method a-la Ruby
Well, I don't think this is better than built-in foreach (with
full break and continue and goto even for user-defined opApply!)
I think we reached a matter of taste here. How often do you use
these features anyway in your regular code? I prefer a more
functional style with higher order functions
(map/reduce/filter/etc..) so for me foreach is about applying
something to all elements and doesn't entail usage of
break/continue/etc..
I'll use these constructs in a for loop but not a foreach loop.
* enum - enum should be completely redesigned to only
implement
what it's named after: enumerations.
What is the benefit?
On the one hand the current enum for manifest constants is a
hack due to
weaknesses of the toolchain
I think that is actually not true. It might have been the
original motivation, but it has gone beyond that. Which
weaknesses in particular? I don't think that the toolchain can
be improved in any way in this regard.
The weakness as far as I know is about link time optimization of
constants.
But regardless, my ideal implementation of so called
compile-time features, including compile time constants, would
be very different anyway.
and on the other hand it doesn't provide
properly encapsulated enums
Those could in theory be added without removing the manifest
constant usage.
such as for instance the Java 5.0 ones or
the functional kind.
An algebraic data type is not an 'enumeration', so this is a
moot point.
I disagree. They are a generalization of the concept. In fact,
functional languages such as ML implement c style enums as an
algebraic data type.
[...]
I should be able to use a *very* minimalistic system to write
completely
_regular_ D code and run it at different times.
Examples in concrete syntax? How would you replace eg. string
mixin functionality?
This is a simple matter
of separation of concerns: what we want to execute (what code)
is
separate to the concern of when we want to execute it.
It is not. For example, code that is only executed during CTFE
does never have to behave gracefully if the input is ill-formed.
I disagree - you should make sure the input is valid or all sorts
of bad things could potentially happen such as a compiler can get
stuck in an infinite loop. If you only use a batch mode compiler
you can simply kill the process which btw applies just the same
to your user program. However, if you use an integrated compiler
in your IDE that could cause me to lose part of my work if the
IDE crashes.
Re: How can D become adopted at my company?
On 28 April 2012 18:16, Peter Alexander peter.alexander...@gmail.comwrote: On Saturday, 28 April 2012 at 09:14:51 UTC, SomeDude wrote: On Saturday, 28 April 2012 at 09:12:23 UTC, SomeDude wrote: Real time guarantees on a GC is not something we are going to offer anytime soon anyway. While a minimal library, loosely based on the C standard library, with some more bells and whistles that could be borrowed from Phobos, this is a goal that is achievable in a foreseeable future. And both game developers and embedded programmers would be interested. Note that Kenta Cho, who wrote fast games in D1, used this approach, and it worked very well for him. I also write games in D. My approach is this: use the GC all you want during loading or other non-interactive parts of the game and then just make sure that you don't use it during gameplay. GC vs. manual memory allocation is a non-issue for real-time guarantees. The simple fact of the matter is that you should be using neither. I also don't use malloc/free during runtime because it has the same non-real-time problems as using the GC. A single malloc can stall for tens of milliseconds or more, and that's simply too much. Just learn how to write code that doesn't allocate memory. A bigger problem with GC for games is memory management i.e. controlling how much memory is currently allocated, and what systems are using what memory. Having deterministic memory usage is preferable for those cases because I know that as soon as I delete something that the memory is available for something else. I don't get that guarantee with a GC. I think that basically sums it up. I'm interested to know is whether using a new precise GC will guarantee ALL unreferenced stuff will be cleaned on any given sweep. I can imagine a model in games where I could: 1 Use the GC to allocate as much as I like during initialisation 2 During runtime you never allocate anyway, so disable the GC (this is when it is important to know about hidden allocations) 3 During some clean-up, first run the logic to de-reference all things that are no longer required 4 Finally, force a precise GC scan, which should guarantee that all no-longer referenced memory would be cleaned up at that time. This would actually be a very convenient working model for games. But it only works if I know everything that was released will definitely be cleaned, otherwise I may not be ale to allocate the next level (games often allocate all memory a machine has within 100k or so).
Re: Does D have too many features?
On Saturday, 28 April 2012 at 21:12:39 UTC, SomeDude wrote: On Saturday, 28 April 2012 at 20:59:48 UTC, q66 wrote: This kind of attitude we need big fat bullshit like Java and heavy use of OO and idioms and EH and all that other crap is broken and false. And you have no way to prove that Python for example wouldn't scale for large projects; its main fault is that the default implementation is rather slow, but it's not pretty much missing anything required for a large project. Python has two big drawbacks for large projects: - it's too slow - it's a dynamically-typed language The fact that it's flexible is because it uses duck typing, and AFAIK you can't do duck typing in a statically typed language. So it's cool for small programs, but it can't handle large ones because it's not statically typed. And this opinion doesn't come just out of thin air, I speak from my own professional experience. Go is a static duck typed language (when using interfaces anyway) AFAIK. http://golang.org/doc/go_faq.html#implements_interface http://research.swtch.com/interfaces /Jonas
Re: Does D have too many features?
On Saturday, 28 April 2012 at 21:12:39 UTC, SomeDude wrote: […] And this opinion doesn't come just out of thin air, I speak from my own professional experience. Regardless of the fact that I tend to agree with you on this one, isn't »my own professional experience« usually a synonym for »thin air«? ;) David
Re: Does D have too many features?
On Saturday, 28 April 2012 at 18:48:18 UTC, Walter Bright wrote: Andrei and I had a fun discussion last night about this question. The idea was which features in D are redundant and/or do not add significant value? A couple already agreed upon ones are typedef and the cfloat, cdouble and creal types. What's your list? garbage collector *duck and run* The point I'm trying to make is... normally I would use around 4-5 different languages depending on _what_ problem I'm currently solving... occasionally even languages I'm not particularly proficient with, just because a language might have an edge in a certain domain... however 'D' basically is good enough at everything... with some few exceptions. So what one person considers redundant, is integral to someone else with a different background... no, D doesn't have too many features.
Re: Does D have too many features?
Peter Alexander peter.alexander...@gmail.com wrote in message news:nvvuxboigxxfdqfhy...@forum.dlang.org... To be honest, I don't like the idea of member functions at all. Having two syntaxes for calling a function is the core problem, and UFCS is just an extra complication on top of it to try and mitigate the original problem. f(x) --- x.f() is not progress in language design. [...] I'm serious. I don't like overloaded syntax. foo.bar shouldn't also mean (*foo).bar -- it causes confusion and introduces ambiguities when either could work. Combine this with opDispatch, UFCS and function overloading and your in for some nasty headaches. [...] Glancing at that code, it looks like foo has two member variables. It is also not clear that each access involves a hash-table lookup. It sounds like you just simply don't like abstractions. I can understand that (although I don't agree with it), but it always puzzles me why such people even try to use high-level langauges at all instead of just binary machine code. And for the record, I've *never* seen anyone confused by foo.bar syntax being used on reference types.
Re: Does D have too many features?
On 04/29/2012 11:31 AM, foobar wrote:
On Sunday, 29 April 2012 at 08:58:24 UTC, Timon Gehr wrote:
[...]
Indeed but I'd go even further by integrating it with ranges so that
ranges would provide an opApply like method e.g.
auto r = BinaryTree!T.preOrder(); // returns range
r.each( (T elem) { ...use elem...}); // each method a-la Ruby
Well, I don't think this is better than built-in foreach (with full
break and continue and goto even for user-defined opApply!)
I think we reached a matter of taste here.
Certainly, and this applies to the other issues as well.
How often do you use these features anyway in your regular code?
Not too often, but it is awesome that it actually works. ;)
I prefer a more functional style
with higher order functions (map/reduce/filter/etc..) so for me foreach
is about applying something to all elements and doesn't entail usage of
break/continue/etc..
Some algorithms are better expressed in functional terms, some
algorithms are better expressed in imperative terms. I think a
combination of the two usually is the best choice.
I'll use these constructs in a for loop but not a foreach loop.
break can be used as an optimisation to stop execution of a loop that
performs a 'reduce' if the result cannot change after a certain point. I
use continue mostly for 'filter'-ing out elements from consideration.
Usually there is not a huge difference between imperative style and
functional style loops.
* enum - enum should be completely redesigned to only implement
what it's named after: enumerations.
What is the benefit?
On the one hand the current enum for manifest constants is a hack due to
weaknesses of the toolchain
I think that is actually not true. It might have been the original
motivation, but it has gone beyond that. Which weaknesses in
particular? I don't think that the toolchain can be improved in any
way in this regard.
The weakness as far as I know is about link time optimization of constants.
But regardless, my ideal implementation of so called compile-time
features, including compile time constants, would be very different anyway.
Well, you never elaborate on these things. BTW, what is your stance on
template haskell?
and on the other hand it doesn't provide
properly encapsulated enums
Those could in theory be added without removing the manifest constant
usage.
such as for instance the Java 5.0 ones or
the functional kind.
An algebraic data type is not an 'enumeration', so this is a moot point.
I disagree. They are a generalization of the concept. In fact,
functional languages such as ML implement c style enums as an algebraic
data type.
The current way enums can be used as manifest constants is a
generalization as well. The generalization takes place on the static
semantics level instead of on the conceptual level though.
[...]
I should be able to use a *very* minimalistic system to write completely
_regular_ D code and run it at different times.
Examples in concrete syntax? How would you replace eg. string mixin
functionality?
?
This is a simple matter
of separation of concerns: what we want to execute (what code) is
separate to the concern of when we want to execute it.
It is not. For example, code that is only executed during CTFE does
never have to behave gracefully if the input is ill-formed.
I disagree - you should make sure the input is valid or all sorts of bad
things could potentially happen such as a compiler can get stuck in an
infinite loop.
It could fail in a number of other ways. I don't think that this example
can be used to invalidate the statement.
If you only use a batch mode compiler you can simply kill
the process which btw applies just the same to your user program.
Maybe the user program should not be killed. See your IDE example.
However, if you use an integrated compiler in your IDE that could cause
me to lose part of my work if the IDE crashes.
Why would the IDE crash?
Re: Does D have too many features?
On 04/29/2012 08:35 AM, Nick Sabalausky wrote:
Timon Gehrtimon.g...@gmx.ch wrote in message
news:jnhpvv$ih4$1...@digitalmars.com...
On 04/28/2012 11:04 PM, Dmitry Olshansky wrote:
But how about:
alias thing = runSomeCtfe();
That would work in certain cases, where the initializer is not a single
symbol. But then, I kinda like the way 'enum' is generalized in D:
enum Foo{
member1,
member2,
member3,
}
= (allow non-integral enumerations)
enum Foo{
member1 = 1,
member2 = 2,
member3 = 3,
}
Those are good. They are essentially enumerations.
= (anonymous enums)
enum{
member1 = 1,
member2 = 2,
member3 = 3,
}
I don't think anonymous enum makes any sense at all. It's *not* an
enumeration by any stretch of the term,
enum{
member1,
member2,
member3,
}
static assert(member1+1==member2 member2+1==member3);
it's just a series of manifest
constants. The fact that they're grouped doesn't even have any semantic
consequence, as far as I'm aware.
The only differences are that they don't occupy their own namespace and
they don't define their own type. But non-anonymous enums are _just a
bunch of manifest constants_ as well! Therefore there are ways in which
the generalisation makes sense.
= (a single member is okay)
enum{
member1 = 1,
}
= (syntactic sugar)
enum member1 = 1;
Just simpler examples of the above, which isn't any form of enumeration at
all.
'enum' declares manifest constants whether or not it is anonymous. Afaik
go uses 'const' for enumerations and manifest constants. 'const' means a
different thing in D. (arguably, 'readonly' would be a better fit) I
don't think that the exact keywords matter a huge deal here.
Re: Does D have too many features?
On Sunday, 29 April 2012 at 11:23:17 UTC, Timon Gehr wrote:
On 04/29/2012 11:31 AM, foobar wrote:
On Sunday, 29 April 2012 at 08:58:24 UTC, Timon Gehr wrote:
[...]
Indeed but I'd go even further by integrating it with ranges
so that
ranges would provide an opApply like method e.g.
auto r = BinaryTree!T.preOrder(); // returns range
r.each( (T elem) { ...use elem...}); // each method a-la Ruby
Well, I don't think this is better than built-in foreach
(with full
break and continue and goto even for user-defined opApply!)
I think we reached a matter of taste here.
Certainly, and this applies to the other issues as well.
How often do you use these features anyway in your regular
code?
Not too often, but it is awesome that it actually works. ;)
I prefer a more functional style
with higher order functions (map/reduce/filter/etc..) so for
me foreach
is about applying something to all elements and doesn't entail
usage of
break/continue/etc..
Some algorithms are better expressed in functional terms, some
algorithms are better expressed in imperative terms. I think a
combination of the two usually is the best choice.
I agree and indeed I haven't argued to remove break/continue from
the language. Imperative style loops are already expressible with
for/while/etc where break/continue work as advertizes. IMO a
foreach loop is a higher level concept more suitable for
functional style loops.
In any case, break/continue is implemented via opApply's return
values and as such doesn't require anything special from the
compiler to implement a library based foreach.
I'll use these constructs in a for loop but not a foreach loop.
break can be used as an optimisation to stop execution of a
loop that performs a 'reduce' if the result cannot change after
a certain point. I use continue mostly for 'filter'-ing out
elements from consideration.
Well, I'll use a filter to filter out elements :)
Usually there is not a huge difference between imperative style
and functional style loops.
* enum - enum should be completely redesigned to only
implement
what it's named after: enumerations.
What is the benefit?
On the one hand the current enum for manifest constants is a
hack due to
weaknesses of the toolchain
I think that is actually not true. It might have been the
original
motivation, but it has gone beyond that. Which weaknesses in
particular? I don't think that the toolchain can be improved
in any
way in this regard.
The weakness as far as I know is about link time optimization
of constants.
But regardless, my ideal implementation of so called
compile-time
features, including compile time constants, would be very
different anyway.
Well, you never elaborate on these things. BTW, what is your
stance on template haskell?
I discussed this many times in the past...
I don't really know haskell. But I do like ML.
and on the other hand it doesn't provide
properly encapsulated enums
Those could in theory be added without removing the manifest
constant
usage.
such as for instance the Java 5.0 ones or
the functional kind.
An algebraic data type is not an 'enumeration', so this is a
moot point.
I disagree. They are a generalization of the concept. In fact,
functional languages such as ML implement c style enums as an
algebraic
data type.
The current way enums can be used as manifest constants is a
generalization as well. The generalization takes place on the
static semantics level instead of on the conceptual level
though.
A language is the interface between a human programmer and a
computer and should IMO provide clear conceptual level
abstractions for the benefit of the human. I realize that using
enum for manifest constants makes sense on the implementation
level but I feel the compiler should work for me and not the
other way around.
[...]
I should be able to use a *very* minimalistic system to
write completely
_regular_ D code and run it at different times.
Examples in concrete syntax? How would you replace eg. string
mixin
functionality?
?
macro testMacro() {
std.writeln(Hello world!);
| std.writeln(Hello world!); |
}
macro is a syntactic sugar on top of a regular function. You can
call it just like you call a regular function. The first line is
executed regularly and the second one is mixed-in [returned token
stream from the macro]
since the macro is evaluated by the compiler, the first line
would generate compile-time output. the second line would be part
of the generated code and would be thus executed during run-time
of my code.
Regarding syntax, the main difference is that it's a token stream
and not text but otherwise pretty much the same as current CTFE.
The important difference here is the execution model which is
different from CTFE.
This is a simple matter
of separation of concerns: what we want to execute (what
code) is
separate to the concern of when we want to execute
Re: Does D have too many features?
On 29.04.2012 10:42, Jonathan M Davis wrote: On Sunday, April 29, 2012 09:53:15 Dmitry Olshansky wrote: On 29.04.2012 4:31, Jonathan M Davis wrote: For better or worse, the solution for smart pointers in D would be to use opDispatch, *cough* alias this *cough* That's not necessarily a good idea, depending on how it's used. You want to avoid having the smart pointer implicitly convert to what it holds such that a reference to it leaks. If you're dealing with a pointer to a struct, and alias this aliases to the struct (rather than the pointer), then you're okay. But if you're dealing with a class, you don't have that option. So, alias this ends up leaking a reference to the class, which defeats the purpose of the smart pointer. You have the same problem if alias this aliases to the pointer rather than what's pointed to. Point taken. But regardless of whether you use alias this or opDispatch, you have the same problem with regards to -. In C++, . would be used to call the smart pointer's functions, and - would be used to call functions on the object pointed to. In D, the two aren't distinguished - both use . - so you can't have any functions on the type pointed to which conflict with the smart pointer's functions, or you won't be able to call them (unless another way to call them is provided somehow). So, it's definitely something that C++ does better with as far as that goes. So you just need not to have any _member_ functions on smart pointer? Just use free functions that take SmartPointer!T. UFCS may also lend a hand if T and SmartPointer do not have ambiguous funcs. -- Dmitry Olshansky
Re: Does D have too many features?
On Saturday, 28 April 2012 at 18:48:18 UTC, Walter Bright wrote:
What's your list?
My personal list of features I could easily live without – some
of these might be controversial, but yes, I have written
non-trivial amounts of code in both D1 and D2:
- Anonymous nested classes: They might be useful in Java,
particularly in older incarnations, but not so much in D –
never used them.
- Comma operator: Kill it with extreme prejudice, it is an
anti-feature (allow it in for loop expressions if you really want
to, but I think there are better solutions).
- Typesafe variadics: They look nice on paper, but I haven't
used them once. Often, you either explicitly need C-style
variadics, or you want to accept e.g. multiple ranges of the same
element type, where you need template variadics anyway.
- Unsigned right shift, but I can see how it can be useful
(simply underused?).
- HexString, DelimitedString, r-WysiwigString, TokenString: I
didn't ever use the former two (for including binary data in the
program, ImportExpression is imho much easier than generating a
source file containing a HexString). As for r, every time I
actually need WysiwigString, I use backticks, because such
strings often contain quotes anyway. Regarding TokenString(i.e.
q{}) – it is certainly a very nice idea, especially regarding
syntax highlighting, and I occasionally use them for CTFE code
generation. But without any kind of support for string
interpolation, I typically find myself using normal strings for
everything except small self-contained portions of code (where
mixin templates would probably be cleaner). The problem is that
can't just »interrupt« q{}s strings to do something like
»q{…} ~ identifierName ~ q{…}«, because there will most
likely be unmatched braces – but this is needed in assembling
mixin strings all the time…
- Concatenation of adjacent strings: Also an anti-feature, imho.
- Floating point comparison operators like != (yes, that _is_
valid D code): I must admit that I seldom write code relying on
the finer details of IEEE-754 semantics, but can't they just be
»lowered« to a combination of the more common ones?
- »Short« floating point literals like .4 instead of 0.4 and
4. instead of 4.0 – the saved characters are not worth the
syntax special cases, especially w.r.t. UFCS.
- new/delete issues have been discussed many times
- Built-in arrays and AAs: They are convenient to use, but as
far as I can see the single biggest GC dependency in the
language. Why not lower array and AA literals to expression
tuples (or whatever) to make the convenient syntax usable with
custom (possibly non-GC safe) containers as well? A GC'd default
implementation could then be provided in druntime, just like
today's arrays and AAs.
- shared: TLS by default is great, but only __gshared is really
usable right now. IMHO, shared had better been reserved for a
comprehensive take on the subject, rather than the half-baked
implementation we have right now.
David
Re: Does D have too many features?
On Sunday, April 29, 2012 16:28:23 Dmitry Olshansky wrote: On 29.04.2012 10:42, Jonathan M Davis wrote: But regardless of whether you use alias this or opDispatch, you have the same problem with regards to -. In C++, . would be used to call the smart pointer's functions, and - would be used to call functions on the object pointed to. In D, the two aren't distinguished - both use . - so you can't have any functions on the type pointed to which conflict with the smart pointer's functions, or you won't be able to call them (unless another way to call them is provided somehow). So, it's definitely something that C++ does better with as far as that goes. So you just need not to have any _member_ functions on smart pointer? Just use free functions that take SmartPointer!T. UFCS may also lend a hand if T and SmartPointer do not have ambiguous funcs. That could work (though they'd obviously have to be in the same module as the smart pointer - not exactly an onerous requirement - in order to be able to access its private members). - Jonathan M Davis
Re: Does D have too many features?
Am 29.04.2012 10:42, schrieb Timon Gehr: On 04/29/2012 08:31 AM, Paulo Pinto wrote: Am 28.04.2012 20:47, schrieb Walter Bright: Andrei and I had a fun discussion last night about this question. The idea was which features in D are redundant and/or do not add significant value? A couple already agreed upon ones are typedef and the cfloat, cdouble and creal types. What's your list? - two different ways of creating function pointers is confusing (function and delegate) I understand the reasoning, but makes one think all the time when to use what. 'delegate' is more powerful, 'function' is more efficient. If you don't want to think about it, just use 'delegate'. I'd rather see 'function' implicitly convert to 'delegate' than to have it gone. D can be used for systems programming after all! That is what I mean. The compiler could make the distinction between function and delegate itself. I am not arguing to remove the feature, rather to have the compiler check it for me. Surely it can see if I am passing the delegate to D code or extern C/C++ code and act accordingly. - sometimes D code looks like template and mixins gone mad While I do appreciate the power, it can be quite confusing to try to understand what the code does. Specially with the lack of support in mixin's debugging pragma(msg, ...) ? Too low level? - misuse of enum to declare constants I prefer that the use of const would be possible const infects the type and const-qualified data can exist at runtime, so it is not possible. Yeah, but it brings me back bad memories from the early days, when C++ compilers did not fully support C++98, and we had to resort to the enum trick to create constants. - conditional compilation is hard to follow without syntax highlighting Other languages with conditional compilation make it easier to follow what is what. e.g. Turbo Pascal/Delphi, C#, Modula-3, Ada That is not a language issue. How come? In the languages mentioned above, the conditional compilation stands out in clear text that is doing something at compile time. In D you need to be aware which statements are compile time and which are not. Not a big deal to argue about, but easy trap for D newbies. -- Paulo
Re: Does D have too many features?
On Sunday, 29 April 2012 at 12:41:37 UTC, Paulo Pinto wrote: I am not arguing to remove the feature, rather to have the compiler check it for me. Surely it can see if I am passing the delegate to D code or extern C/C++ code and act accordingly. How would this work? Function pointers are only a single word in D code as well (and a single unconditional jump to that address) , whereas delegates are two words. What is if a function accepts a delegate, but a function pointer is passed? What is if a delegate is passed to a (possibly C) function – does the compiler automatically emit a thunk for that? David
Re: Does D have too many features?
On 04/29/2012 02:26 PM, David Nadlinger wrote:
TokenString: [...]Regarding TokenString(i.e. q{}) – it is certainly a very
nice idea, especially regarding syntax highlighting, and I occasionally
use them for CTFE code generation. But without any kind of support for
string interpolation, I typically find myself using normal strings for
everything except small self-contained portions of code (where mixin
templates would probably be cleaner). The problem is that can't just
»interrupt« q{}s strings to do something like »q{…} ~ identifierName ~
q{…}«, because there will most likely be unmatched braces – but this is
needed in assembling mixin strings all the time…
Lack of string interpolation is not a reason to kill the token string,
because CTFE lets you provide the interpolation manually. I use token
strings often in this fashion for code generation.
- Floating point comparison operators like != (yes, that _is_ valid D
code): I must admit that I seldom write code relying on the finer
details of IEEE-754 semantics, but can't they just be »lowered« to a
combination of the more common ones?
I kinda like those ;D.
Re: Does D have too many features?
On 04/29/2012 02:17 PM, foobar wrote:
On Sunday, 29 April 2012 at 11:23:17 UTC, Timon Gehr wrote:
break can be used as an optimisation to stop execution of a loop that
performs a 'reduce' if the result cannot change after a certain point.
I use continue mostly for 'filter'-ing out elements from consideration.
Well, I'll use a filter to filter out elements :)
The filter condition is not always conveniently expressed in terms of a
lambda function.
...
The current way enums can be used as manifest constants is a
generalization as well. The generalization takes place on the static
semantics level instead of on the conceptual level though.
A language is the interface between a human programmer and a computer
and should IMO provide clear conceptual level abstractions for the
benefit of the human. I realize that using enum for manifest constants
makes sense on the implementation level but I feel the compiler should
work for me and not the other way around.
Well, I don't think that 'enum' for manifest constants asks a lot from
the programmer, but YMMV.
...
macro testMacro() {
std.writeln(Hello world!);
| std.writeln(Hello world!); |
}
macro is a syntactic sugar on top of a regular function. You can call it
just like you call a regular function. The first line is executed
regularly and the second one is mixed-in [returned token stream from the
macro]
since the macro is evaluated by the compiler, the first line would
generate compile-time output. the second line would be part of the
generated code and would be thus executed during run-time of my code.
Regarding syntax, the main difference is that it's a token stream and
not text but otherwise pretty much the same as current CTFE. The
important difference here is the execution model which is different from
CTFE.
We have the 'macro' keyword ;). Probably it should just be a built-in
primitive type of the language that represents an AST?
Re: How can D become adopted at my company?
On Apr 29, 2012, at 2:38 AM, Manu turkey...@gmail.com wrote: On 28 April 2012 18:16, Peter Alexander peter.alexander...@gmail.com wrote: On Saturday, 28 April 2012 at 09:14:51 UTC, SomeDude wrote: On Saturday, 28 April 2012 at 09:12:23 UTC, SomeDude wrote: Real time guarantees on a GC is not something we are going to offer anytime soon anyway. While a minimal library, loosely based on the C standard library, with some more bells and whistles that could be borrowed from Phobos, this is a goal that is achievable in a foreseeable future. And both game developers and embedded programmers would be interested. Note that Kenta Cho, who wrote fast games in D1, used this approach, and it worked very well for him. I also write games in D. My approach is this: use the GC all you want during loading or other non-interactive parts of the game and then just make sure that you don't use it during gameplay. GC vs. manual memory allocation is a non-issue for real-time guarantees. The simple fact of the matter is that you should be using neither. I also don't use malloc/free during runtime because it has the same non-real-time problems as using the GC. A single malloc can stall for tens of milliseconds or more, and that's simply too much. Just learn how to write code that doesn't allocate memory. A bigger problem with GC for games is memory management i.e. controlling how much memory is currently allocated, and what systems are using what memory. Having deterministic memory usage is preferable for those cases because I know that as soon as I delete something that the memory is available for something else. I don't get that guarantee with a GC. I think that basically sums it up. I'm interested to know is whether using a new precise GC will guarantee ALL unreferenced stuff will be cleaned on any given sweep. I can imagine a model in games where I could: 1 Use the GC to allocate as much as I like during initialisation 2 During runtime you never allocate anyway, so disable the GC (this is when it is important to know about hidden allocations) 3 During some clean-up, first run the logic to de-reference all things that are no longer required 4 Finally, force a precise GC scan, which should guarantee that all no-longer referenced memory would be cleaned up at that time. This would actually be a very convenient working model for games. But it only works if I know everything that was released will definitely be cleaned, otherwise I may not be ale to allocate the next level (games often allocate all memory a machine has within 100k or so). For a use pattern like this, one thing that may work is to add a GC proxy immediately before loading a level. To unload the level, terminate that GC.
Re: Does D have too many features?
Am 29.04.2012 15:24, schrieb David Nadlinger: On Sunday, 29 April 2012 at 12:41:37 UTC, Paulo Pinto wrote: I am not arguing to remove the feature, rather to have the compiler check it for me. Surely it can see if I am passing the delegate to D code or extern C/C++ code and act accordingly. How would this work? Function pointers are only a single word in D code as well (and a single unconditional jump to that address) , whereas delegates are two words. What is if a function accepts a delegate, but a function pointer is passed? What is if a delegate is passed to a (possibly C) function – does the compiler automatically emit a thunk for that? David Yes, that is what I had in mind. That is what is done in .NET as far as I am aware.
Re: Shared with no type in Druntime.
Am 29.04.2012 05:03, schrieb Adam Wilson: On Sat, 28 Apr 2012 19:23:28 -0700, Jonathan M Davis jmdavisp...@gmx.com wrote: On Saturday, April 28, 2012 18:32:00 Adam Wilson wrote: Ok, so that answers the legality of the issue, but it smacks of sloppy coding. We cannot ship the DRT as a dynamic library, as has been discussed and agreed to as a good idea, if their are variable declarations that rely on type inference from an assignment operation because those assignments will get stripped out of the DI. So what should I do then? Because shared stdin; by itself with no assignment to infer from IS illegal and there is not (that I can see) a way to separate an instantiation from an implementation and the whole point of DI files is too remove implementations. There's nothing sloppy about it whatsoever. If you think that that's sloppy coding, then you're going to think that auto is sloppy coding, and you're going to be very unhappy with a lot of D code. Taking advantage of such type inference is considered _good_ style in D. For the most part, you shouldn't use the type explicitly unless you actually need to. If you need to put a variable in a .di file without its initializer, then that's a case where you're going to need to use the type explicitly. That means that either the .di generator is going to leave the initializer in (which I expect is what it currently does) - in which case you'd need to change it by hand - or it's going to need to take the type of the initializer and use that in the variable's declaration in the .di file rather than using shared by itself or auto or whatever it was using that involved type inference. - Jonathan M Davis Ok, I can accept that. Explicit typing is lots of extra pointless typing when the compiler can just figure it out for me. But that leaves us with an interesting design question. Right now, DI gen is destructive, which means any changes I make to the DI file will get destroyed on the next build if I forget to remove the -H flags. Unfortunately that means that the DI generator is going to have to somewhat dictate coding style and we need to make sure that DI gen covers the broadest possible range of potential uses. Personally, I have no problem leaving in initializers for module level variables. Is that an acceptable solution to the community? Maybe I have been spoiled by doing too much programming in languages that have module systems, but why is the initialization shown in the .di file? This is an implementation issue on the module. -- Paulo
Re: Does D have too many features?
On 2012-04-28 20:47, Walter Bright wrote:
Andrei and I had a fun discussion last night about this question. The
idea was which features in D are redundant and/or do not add significant
value?
A couple already agreed upon ones are typedef and the cfloat, cdouble
and creal types.
What's your list?
* Some of the built-in properties could probably be move to a library
solution, specially now when we have UFCS.
* The with-statement isn't particular useful. Although I've started to
use it in one of my projects just so I don't have to use fully qualified
enum names.
* D embedded in HTML (don't know if this is still supported)
* Multiple syntax for wysiwyg strings. I think the r syntax can be remove.
* Do-while loops, how useful are those actually?
Then I think some features could be replaced with library solutions if D
got some other features. For example:
* foreach(_reverse)
* synchronized
These could probably be removed in favor of library solutions.
void foreach (T)(T[] arr, void delegate (ref T) dg)
{
for (size_t i = 0; i arr.length; i++)
dg(arr[i]);
}
foreach ([1, 2, 3, 4], (i) { writeln(i); });
The above already works today. If we can a bit syntax sugar for
delegates and inlinable delegates we could have this:
foreach ([1, 2, 3, 4] ; i) {
writeln(i);
}
The above syntax would be very useful in other cases as well.
The same could be done for synchronized as well. Might even be
possible to remove the for-statement and just have while left.
I we want get even more wild and crazy I think Scala's solution for
operator overloading looks really good. But that would require several
other features to work. Like:
* Everything is an object (might not be needed with UFCS)
* Everything is a method call on an object
* Infix notation for calling any method taking one argument
* Basically any symbol is allowed in method names
That is:
1 + 2
foo bar foo_bar
Would be translated to:
1.+(2)
foo.bar(foo_bar)
That is a very general way to handle operators and let the user create
new operators, not just overloading existing ones.
--
/Jacob Carlborg
Re: Does D have too many features?
On 2012-04-28 21:22, q66 wrote: On Saturday, 28 April 2012 at 18:48:18 UTC, Walter Bright wrote: Andrei and I had a fun discussion last night about this question. The idea was which features in D are redundant and/or do not add significant value? A couple already agreed upon ones are typedef and the cfloat, cdouble and creal types. What's your list? - AAs integrated in the language; you barely ever use AA literals and having them purely in Phobos would help get rid of the runtime fat, as well as better implementations - Phobos is too fat - it needs to shrink to just a few core modules, others being distributed via some system like CPAN for Perl - Properties - they're kinda broken at this point and the value is questionable - @trusted @system - Exception handling - a lot of runtime, questionable value - Versions - not redundant, but needs a better system (with AND/OR, possibility of de-versioning, the assignment op to set versions is kinda bad) I think I would find some more, but these are the ones I can recall now. As others have said, I think this is crazy. -- /Jacob Carlborg
Re: Does D have too many features?
On 2012-04-28 21:36, Andrej Mitrovic wrote: On 4/28/12, Walter Brightnewshou...@digitalmars.com wrote: What's your list? I don't mind extra features, just as long as they're properly documented and implemented. For example, I have absolutely no uses for anonymous classes right now, but I know DWT2 uses them and probably other people do use them. If a anonymous classes where remove from D, life would get even harder for DWT. Personally I find the hardest threads to to follow are the ones discussing in/out/inout/autoref. For one thing there are compiler bugs, but then there are misconceptions between what developers vs documentation vs core devs say about them. And then you mix in classes and templates into the story and it all becomes a large forest of information that is very hard to digest. Agree. Another feature I'm curious about is .dup/.idup. It's basically hardcoded for a couple of types, but why not instead use UFCS and implement .dup/.idup in std.array as a free function? Then you might even use it for user-types by requiring a type to implement .dup/.idup functions. Agree with this one as well. -- /Jacob Carlborg
Re: Does D have too many features?
On 2012-04-28 21:58, foobar wrote: D has a lot of ad-hock features which make the language needlessly large and complex. I'd strive to replace these with better general purpose mechanisms. My list: * I'd start with getting rid of foreach completely. (not just foreach_reverse). This is nothing more than a fancy function with a delegate parameter. I agree. * This is a big one: get rid of *all* current compile time special syntax. It should be replaced by a standard compilation API and the compiler should be able to use plugins/addons. This would reduce the size of the language to half of its current size, maybe even more. I agree with this one as well. At least if the compiler would be implemented like this. -- /Jacob Carlborg
Re: Does D have too many features?
On 2012-04-28 22:43, Timon Gehr wrote: On 04/28/2012 09:58 PM, foobar wrote: It should be replaced by a standard compilation API and the compiler should be able to use plugins/addons. Are you serious? Have a look at what Scala have done. They basically have the complete compiler available as a library. Then they used this library to implement runtime reflection and macros. Macros in Scala are functions that execute at compile time. -- /Jacob Carlborg
Re: Does D have too many features?
On 2012-04-28 23:42, Peter Alexander wrote: Here's my list: - Properties. They add no value and just start pointless discussions about what should and shouldn't be a property. - UFCS. It's just sugar, but adds complexity. - const/immutable/inout/shared/pure. These add massive complexity to the language for little (IMO) benefit. When I do multi-threading, I usually have to resort to casting. Maybe these will improve with time. - opDispatch. I think it just promotes sloppy, obfuscated code for minor syntactical benefit. Member access through pointers should require - like in C++ so that you can overload it for smart pointer/reference ADTs. That's all I can think of for now. I love all these features beside the attributes. -- /Jacob Carlborg
Re: Does D have too many features?
On 2012-04-29 00:02, deadalnix wrote: Off topic. I discussed several proposals, and I invest time ever since to come up with a good solution. Introducing a whole new paradigm in a language isn't something light. AST manipulation at compile time is the key. This would be awesome to have. -- /Jacob Carlborg
Re: Does D have too many features?
On Sunday, 29 April 2012 at 12:26:13 UTC, David Nadlinger wrote: - Anonymous nested classes: They might be useful in Java, particularly in older incarnations, but not so much in D – never used them. I never used these until very recently. A couple weeks ago, I wanted to do some kind of range adapter kinda like Phobos does with the anon structs... but I wanted it to work with runtime too. So, I made an interface with empty, front, popFront, and then pulled out the old return new class ByChunkRange for the first time. I never expected that I'd use it, but it was nice to have for that time when I did decide I wanted it. That's my biggest concern with saying we have too many features. We might not use them often, but it would suck to say that would be perfect just to find it was removed later.
Re: Does D have too many features?
On 29.04.2012 18:40, Jacob Carlborg wrote: 1 + 2 foo bar foo_bar Would be translated to: 1.+(2) foo.bar(foo_bar) That is a very general way to handle operators and let the user create new operators, not just overloading existing ones. warning(1): Smalltalk detected! [use -foop-only to ignore] Operator precedence would get real tricky (or stupid just like in Smalltalk). -- Dmitry Olshansky
Re: Does D have too many features?
On Sunday, 29 April 2012 at 14:40:38 UTC, Jacob Carlborg wrote:
foreach ([1, 2, 3, 4], (i) { writeln(i); });
The above already works today. If we can a bit syntax sugar for
delegates and inlinable delegates we could have this:
foreach ([1, 2, 3, 4] ; i) {
writeln(i);
}
We'd still need a solution for continue and break, though.
David
Re: Does D have too many features?
On Sun, Apr 29, 2012 at 02:35:07AM -0400, Nick Sabalausky wrote: Timon Gehr timon.g...@gmx.ch wrote in message news:jnhpvv$ih4$1...@digitalmars.com... [...] Implementing a compiler is probably harder for D, because of the interplay of forward references, CTFE and compile time introspection. Those make D more difficult to implement than many languages, but OTOH, AIUI, C++ has some real nightmarish details with templates and even just simply parsing. Probably some other bizarre cruft, too. IIRC, I think Walter's occasionally mentioned something about the...overload rules? [...] It has been said that C++ cannot be lexed before it's parsed. Before C++11, for example, this is invalid: std::vectorstd::vectorT nestedList; Instead, you have to write: std::vectorstd::vectorT nestedList; Fortunately they fixed this in C++11. But now you have another problem: std::vectormyTemplateT1 nestedList; Whether or not this is valid depends on whether T is a type name or a variable name (e.g., if myTemplate takes an int parameter). But how is the lexer even supposed to know whether the should be a right shift operator or two right angle brackets? It has to understand the _semantics_ of T before it can even lex the thing. I read somewhere that one of D's goals was to be able to lex the language without requiring semantic knowledge in the lexer. You have no idea how much such a seemingly-obvious concept can save hours, days, nay, months and years of frustration in compiler implementation. So you think D is hard to implement? We have barely even begun to delve into the insane convolutions of C++. You'll start to have some real hair-tearing sessions once you start getting into implicit conversion rules and template best-match algorithms. Be glad, be very glad that we have D instead of C++! T -- Designer clothes: how to cover less by paying more.
Re: Shared with no type in Druntime.
On 2012-04-29 05:03, Adam Wilson wrote: Ok, I can accept that. Explicit typing is lots of extra pointless typing when the compiler can just figure it out for me. But that leaves us with an interesting design question. Right now, DI gen is destructive, which means any changes I make to the DI file will get destroyed on the next build if I forget to remove the -H flags. Unfortunately that means that the DI generator is going to have to somewhat dictate coding style and we need to make sure that DI gen covers the broadest possible range of potential uses. Personally, I have no problem leaving in initializers for module level variables. Is that an acceptable solution to the community? No, I think it's way better that the DI generator outputs the actually type instead of just shared/auto and the assignment. In this case: shared stdin = _iob[0]; Should be generated as: shared File stdin; Anything to the right of the assignment operator is just an implementation detail. -- /Jacob Carlborg
Re: Does D have too many features?
On Sun, Apr 29, 2012 at 08:40:16AM +0200, Paulo Pinto wrote: [...] My employer does consulting for big projects. The type of entreprise projects that require multi-site development scattered across the globe, sometimes with 300+ developers. There is no way a dynamic language would work in such scenarios, without having a constant broken build on the CI system. [...] Yeah, at my work we have about 20-30 people working on a very large C/C++ codebase (one among many), and we already get broken builds every now and then, like bugs that completely break just about every feature in the system -- makes you wonder how any sane programmer could've checked in such a mess (and how said mess made it through the kangaroo code review process). Or blatant internal API breakages that make you wonder if anybody even *read* what they wrote. I cannot begin to imagine the horror of using a dynamic language in this setting. Static languages are already painful enough; throw in indeterminate typing at compile-time and it's a recipe for utter disaster, probably every single work day. And this is only 20-30 developers. The problem gets exponentially worse when that number goes up. At 300+ developers, the project would grind to a complete halt in less than a day (probably less than an hour). T -- Study gravitation, it's a field with a lot of potential.
Re: Does D have too many features?
On Sun, Apr 29, 2012 at 10:28:47AM +0200, SomeDude wrote: On Sunday, 29 April 2012 at 08:13:53 UTC, Nick Sabalausky wrote: There will still be sugar in the compiler so they appear to be builtins. When the switch happens, I'm sure it'll be transparent - average users probably won't even notice. It's just that behind the scenes their implementation will move from DMD to Druntime. Hmmm, sounds nice, but bolting the language with the standard library is very risky (and a rather bad idea imho). Unless there is a very lightweight minimalistic core for Phobos (something which I advocate), you bolt a heavyweight library to your language, and that's not good. [...] Please note that the AA implementation will be moving into druntime, NOT phobos. The compiler already depends on a bunch of stuff in druntime (the GC being a prime example, and the Object class being another). And every time you write 'typeid'? That's druntime code too. T -- It is widely believed that reinventing the wheel is a waste of time; but I disagree: without wheel reinventers, we would be still be stuck with wooden horse-cart wheels.
Re: Does D have too many features?
On 2012-04-29 04:32, Francois Chabot wrote:
- properties - another incredibly convenient feature. I think a more
sexy implementation of properties are in order, but the construct is
great. It would be nice to have properties as a language type, rather
than a attribute:
To me, properties are much more than a convenience. The important part
of it comes from its existence, not its usage. Quite simply, having
properties mean that using public member variables does not break
encapsulation (as long as having them part of the public interface is
intentional).
Without properties, you MUST write accessors for all of them on the off
chance that you might want to refactor/delegate them in the future. This
adds a huge amount of boilerplate code that ends up wasted time 98% of
the time.
In short, properties existing, even if not used, end up improving both
my efficiency and the legibility of my code.
In principle I agree with you. But in practice this doesn't always work.
Take this for example:
struct Point
{
int x;
int y;
}
class Widget
{
Point point;
}
void main()
{
auto w = new Widget;
writeln(w.point.x);
w.point.x++;
writeln(w.point.x);
}
Prints 0 and 1 as expected. If we now change point to a property
like this:
class Widget
{
//Point point;
Point point_;
@property Point point ()
{
return point_;
}
@property Point point (Point point)
{
return point_ = point;
}
}
It will now print 0 and 0. This is a silently breaking change. Sure
you can change point to return by reference:
class Widget
{
Point point_;
@property ref Point point ()
{
return point_;
}
@property ref Point point (Point point)
{
writeln(foo);
point_ = point;
return point_;
}
}
Which will print 0 and 1 again. But it won't print foo, meaning
you bypassed the getter. To solve this the compiler would need to
perform some kind of property rewriting. Translating:
w.point.x++;
To:
auto __p = w.point;
__p.x++;
w.point = __p;
Also you might need to just as well use properties from the beginning
because you need virtual properties. It would help if this was allowed:
class Widget
{
@property Point point;
}
Which would translate to:
@property Point point ()
{
return point_;
}
@property Point point (Point point)
{
return point_ = point;
}
--
/Jacob Carlborg
Re: Does D have too many features?
On Sunday, 29 April 2012 at 15:16:57 UTC, H. S. Teoh wrote: […] and template best-match algorithms. Be glad, be very glad that we have D instead of C++! To be fair, the template matching logic in D is quite complicated as well (at least I can recall several instances of stumbling over bugs in the implementation, would have to search Bugzilla for details) – the only thing is that we don't really have a formal spec for it yet… David
Re: Does D have too many features?
On 28.04.2012 20:47, Walter Bright wrote: Andrei and I had a fun discussion last night about this question. The idea was which features in D are redundant and/or do not add significant value? A couple already agreed upon ones are typedef and the cfloat, cdouble and creal types. What's your list? * The operator, which does nothing except introduce bugs (It does NOT perform an unsigned shift). * package. I have no idea how a failed Java experiment got incorporated into D. * the zoo of parameter passing options * Most of the __traits are useless and redundant.
Re: Does D have too many features?
Am 29.04.2012 17:27, schrieb H. S. Teoh: On Sun, Apr 29, 2012 at 08:40:16AM +0200, Paulo Pinto wrote: [...] At 300+ developers, the project would grind to a complete halt in less than a day (probably less than an hour). Suffice to say, that on that specific project we had weeks without any working build, that had to be saved with hard code free rules until it got green again. This type of projects is what made me change my mind about static vs dynamic. Static languages with automatic type inference, and some type of dynamic dispatch like D's variant type/opDispatch, fullfil most use cases a dynamic language is good for, without sacrificing tooling or large scale development. -- Paulo
Re: Does D have too many features?
On 2012-04-29 17:07, David Nadlinger wrote:
On Sunday, 29 April 2012 at 14:40:38 UTC, Jacob Carlborg wrote:
foreach ([1, 2, 3, 4], (i) { writeln(i); });
The above already works today. If we can a bit syntax sugar for
delegates and inlinable delegates we could have this:
foreach ([1, 2, 3, 4] ; i) {
writeln(i);
}
We'd still need a solution for continue and break, though.
David
This has already been solved when using opApply, although quite an ugly
solution.
--
/Jacob Carlborg
Re: Does D have too many features?
On 04/29/2012 04:53 PM, Jacob Carlborg wrote: On 2012-04-28 22:43, Timon Gehr wrote: On 04/28/2012 09:58 PM, foobar wrote: It should be replaced by a standard compilation API and the compiler should be able to use plugins/addons. Are you serious? Have a look at what Scala have done. They basically have the complete compiler available as a library. Then they used this library to implement runtime reflection and macros. Macros in Scala are functions that execute at compile time. It is not as powerful as what we have in D and it requires invoking the compiler multiple times.
Re: Does D have too many features?
On Sunday, 29 April 2012 at 16:10:40 UTC, Jacob Carlborg wrote:
On 2012-04-29 17:07, David Nadlinger wrote:
On Sunday, 29 April 2012 at 14:40:38 UTC, Jacob Carlborg wrote:
foreach ([1, 2, 3, 4] ; i) {
writeln(i);
}
We'd still need a solution for continue and break, though.
David
This has already been solved when using opApply, although quite
an ugly solution.
Yes, but that requires the compiler to generate the return value
»glue« code for continue/break inside an opApply foreach. If
foreach is a library function and you pass an ordinary delegate,
you have a problem in the current language since you can't know
that a »return« statement inside that delegate really should
return from the outer function.
David
Re: Does D have too many features?
On Sunday, 29 April 2012 at 15:50:54 UTC, Don wrote: * package. I have no idea how a failed Java experiment got incorporated into D. +1, forgot to mention that one. David
Re: Does D have too many features?
On Sunday, 29 April 2012 at 09:52:21 UTC, David Nadlinger wrote: On Saturday, 28 April 2012 at 21:12:39 UTC, SomeDude wrote: […] And this opinion doesn't come just out of thin air, I speak from my own professional experience. Regardless of the fact that I tend to agree with you on this one, isn't »my own professional experience« usually a synonym for »thin air«? ;) David Well yes and no. It's the difference between I think that, and I've experienced in real projects that. And well, discussing in another forum, I've had other similar echos and experiences. Basically, with Python and other dynamically typed languages, the time you gain writing code, you lose testing it and correcting bugs that a compiler would have found for you.
Re: Does D have too many features?
Don: * package. I have no idea how a failed Java experiment got incorporated into D. Weren't Java designers thinking about adding superpackages too to Java? * the zoo of parameter passing options Please explain, what do you mean? Bye, bearophile
Re: Does D have too many features?
On 04/29/2012 05:17 PM, H. S. Teoh wrote:
On Sun, Apr 29, 2012 at 02:35:07AM -0400, Nick Sabalausky wrote:
Timon Gehrtimon.g...@gmx.ch wrote in message
news:jnhpvv$ih4$1...@digitalmars.com...
[...]
Implementing a compiler is probably harder for D, because of the
interplay of forward references, CTFE and compile time
introspection.
Those make D more difficult to implement than many languages, but
OTOH, AIUI, C++ has some real nightmarish details with templates and
even just simply parsing. Probably some other bizarre cruft, too.
IIRC, I think Walter's occasionally mentioned something about
the...overload rules?
[...]
C++ implementation complexity is incidental.
It has been said that C++ cannot be lexed before it's parsed. Before
C++11, for example, this is invalid:
std::vectorstd::vectorT nestedList;
Instead, you have to write:
std::vectorstd::vectorTnestedList;
Fortunately they fixed this in C++11. But now you have another problem:
std::vectormyTemplateT1 nestedList;
Whether or not this is valid depends on whether T is a type name or a
variable name
I think it is never valid.
(e.g., if myTemplate takes an int parameter). But how is
the lexer even supposed to know whether the should be a right shift
operator or two right angle brackets? It has to understand the
_semantics_ of T before it can even lex the thing.
A D compiler has to semantically analyse the code without full
information about which symbols are declared, (getting the full set of
declared symbols is actually an ill-defined problem because conditional
compilation is Turing complete and can already depend on any declared
symbol or even on the fact that a certain symbol has _not_ been
declared). There might also be ambiguities or contradictions in the code
that a compiler should detect.
There is no mention of this issue or its (necessarily conservative and
somewhat arbitrary) solution in the language documentation. DMD does not
solve the problem, but just fails in funny ways when faced with a
non-trivial instance of it.
C++ does not have such issues at all because it disallows forward
references!
Don't get me wrong, I think this is rather awesome. But I predict it
will be somewhat of a roadblock for getting the language into a stable
state.
I read somewhere that one of D's goals was to be able to lex the
language without requiring semantic knowledge in the lexer.
This is required in order to have forward references.
You have no idea
I do.
how much such a seemingly-obvious concept can save hours, days,
nay, months and years of frustration in compiler implementation.
So you think D is hard to implement? We have barely even begun to delve
into the insane convolutions of C++. You'll start to have some real
hair-tearing sessions once you start getting into implicit conversion
rules
Well, again, DMD does not get those right. And there is some black magic
in that area, because the implicitly-converts-to-relation is from
expressions to types instead of from types to types. (which is awesome
of course, but it is complex to get right).
Try this (this *should* compile).
pragma(msg, typeof(1?[[]]:[[1]]));
pragma(msg, typeof(1?1?[[]]:[[]]:[[1]]));
pragma(msg, typeof([[[]],[[]],[[1]]]));
class C{}
static C[] c = [null];
pragma(msg, typeof([[null],[new C]]));
and template best-match algorithms. Be glad, be very glad that we
have D instead of C++!
static if(!is(typeof(foo))) enum bar = 1;
static if(!is(typeof(bar))) enum foo = 1;
In D, most of the complexity stems from its advanced features, while in
C++ a lot of the complexity is merely incidental.
Re: Does D have too many features?
On 29 April 2012 18:50, Don nos...@nospam.com wrote: On 28.04.2012 20:47, Walter Bright wrote: Andrei and I had a fun discussion last night about this question. The idea was which features in D are redundant and/or do not add significant value? A couple already agreed upon ones are typedef and the cfloat, cdouble and creal types. What's your list? * The operator, which does nothing except introduce bugs (It does NOT perform an unsigned shift). What does it do? I use this all over the place, I assumed it worked... maybe I have bugs? * package. I have no idea how a failed Java experiment got incorporated into D. package confuses me, it's poorly documented. What are the protections between packages, sub-packages. Can parent packages see sub-package contents? vice-versa? * Most of the __traits are useless and redundant. Which traits are useless and redundant? I'm actually finding the set is incomplete, and there are some missing (parameter list introspection, current scope/object identification, current module/package)
Re: Does D have too many features?
On 4/29/12, David Nadlinger s...@klickverbot.at wrote:
As for r, every time I
actually need WysiwigString, I use backticks, because such
strings often contain quotes anyway.
IIRC I think the reason for this might be that some keyboards don't
have the backtick key, or something like that.
Regarding TokenString(i.e.
q{}) .. The problem is that
can't just »interrupt« q{}s strings to do something like
»q{…} ~ identifierName ~ q{…}«,
I typically use format for these purposes, e.g.:
string x = format(q{
void %s() { }
}, foo);
Works fairly well for me.
- Concatenation of adjacent strings: Also an anti-feature, imho.
Absolutely!
- »Short« floating point literals like .4 instead of 0.4 and
4. instead of 4.0 – the saved characters are not worth the
syntax special cases, especially w.r.t. UFCS.
I think those are already deprecated? Or they're about to be anyway.
- shared: TLS by default is great, but only __gshared is really
usable right now.
Yep, and Phobos doesn't deal with shared all that well either. E.g.
format() doesn't work on shared variables
(http://d.puremagic.com/issues/show_bug.cgi?id=7036).
