April 29, 2012 Re: Does D have too many features? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Paulo Pinto | 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
|
April 29, 2012 Re: Does D have too many features? | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Nadlinger | 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. |
April 29, 2012 Re: Does D have too many features? | ||||
---|---|---|---|---|
| ||||
Posted in reply to foobar | 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? |
April 29, 2012 Re: Does D have too many features? | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Nadlinger | 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.
|
April 29, 2012 Re: Does D have too many features? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 |
April 29, 2012 Re: Does D have too many features? | ||||
---|---|---|---|---|
| ||||
Posted in reply to q66 | 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 |
April 29, 2012 Re: Does D have too many features? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrej Mitrovic | On 2012-04-28 21:36, Andrej Mitrovic wrote: > On 4/28/12, Walter Bright<newshound2@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 |
April 29, 2012 Re: Does D have too many features? | ||||
---|---|---|---|---|
| ||||
Posted in reply to foobar | 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 |
April 29, 2012 Re: Does D have too many features? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Peter Alexander | 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 |
April 29, 2012 Re: Does D have too many features? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | 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 |
Copyright © 1999-2021 by the D Language Foundation