Re: I have a feature request: "Named enum scope inference"
2012/9/29 Tommi :
> On Saturday, 29 September 2012 at 04:26:01 UTC, Alex Rønne Petersen wrote:
>>
>>
>> It's an awful lot of magic (it's not as easy in the implementation as it
>> sounds like) for questionable gain when we have the with statement IMO.
>
>
> "it's not as easy in the implementation as it sounds like"
> --
> If this argument means: "It's going to increase the compilation time too
> much", then it's obviously a good reason not to do it. But if it means:
> "It's a lot of work to modify the compiler source code", then that's
> completely an unacceptable argument. The question of how much work it is to
> implement, has nothing to do with whether it's a good feature to have or
> not. And that's what we're discussing.
>
>
> "questionable gain"
> ---
> Well, if you never use enum flags to control the specifics of your types and
> functions, then the gain is zero. That is parallel to: if you never create
> any variables, then the gain of the keyword 'auto' is zero. If you do
> however do these things constantly, then the gain is: less typing and
> cleaner syntax. Comparison:
>
> enum Size{ small, medium, big }
> enum Fitness { thin, strong, weak, fat }
> enum Goal{ love, build, heal, kill }
>
> class Character(Size s, Fitness f, Motivation m)
> {
> ...
> }
>
> auto c1 = new Character!(Size.big, Fitness.fat, Goal.kill);
> auto c2 = new Character!(big, fat, kill);
>
No, compiler implementation is not a problem.
In past, I've thought about such feature, but there is some
difficulties to determine an obvious semantic.
1. If the enum member name is same as local variable.
enum E { foo ,bar }
void test(E e) {}
void main() {
auto bar = E.foo;
test(bar);
// 1a) test receives E.bar, or
// 1b) E.foo from local variable 'var'?
}
If you select 1a, existing code will break.
But, 1b will introduce more worse case. See next.
2. The semantics based on 'whether is undefined name or not' is fragile.
First, you might write code such as the following.
enum E { foo ,bar }
void test(E e) {}
void main() {
test(foo); // in here, the name 'bar' is undefined, so test can
receive E.foo
}
After a while, you may add a global variable in module scope.
enum E { foo ,bar }
int foo = 10;
void test(E e) {}
void main() {
test(foo); // foo is defined, and look up module scope foo.
// Then, now the code is broken implicitly!
}
This is a hijacking of local scope, and it is awful.
P.S.
It seems to me the root problem is that using a raw-identifier for the
start of the inference.
If there is a symbol literal, the problem may be solved.
test('bar); // bar is a symbol, so it does not refer any normal declarations
Kenji Hara
Re: Rust and D
On Saturday, 29 September 2012 at 06:11:30 UTC, Nick Sabalausky wrote: (Had to look up that name) Ahh, I see. That explains the dismissal of metaprogramming and generics, and the dismissal Go's objectors via a roundabout strawman (Ie by complaining about the act of complaining, and by categorizing of Go's complaints as merely programmers loving to complain for the sake of complaining). (And yea, I see the "[generics] are a fine thing", but he's still overall very dismissive of their importance.) He's not dismissive of their importance. The point was that if you can dismiss a language based solely on its lack of generics then you are essentially admitting that you have very little imagination as a programmer. You are admitting that the only way you can do productive, meaningful work is if you have generics. It's worth pointing out that a large fraction of (most?) programming languages do not have generics, yet people seem to be able to do meaningful work in them. I imagine that the less imaginative hardcore Go programmers will look at D and say things like "wow, how can D programmers work without channels?", and maybe the Lisp programmers say "wow, how can D programmers work without homoiconic representation", and maybe the Haskell programmers say "wow, how can D programmers work with only crappy local type inference?" As you can see, no matter what you think of these features, the arguments are pointless because it is very clear that you can do meaningful work without them. We get by without channels, homoiconicity, and full program type inference; just as the Go programmers get by without generics.
Re: I have a feature request: "Named enum scope inference"
On 29 September 2012 04:12, Andrej Mitrovic wrote:
> On 9/29/12, Jonathan M Davis wrote:
>> you could simply use with to solve the problem:
>>
>> with(MyFruit)
>> {
>> switch(fruit)
>> {
>> case apple: break;
>> case orange: break;
>> case banana: break;
>> }
>> }
>>
>
> It's even simpler:
> switch(fruit) with (MyFruit)
> {
> case apple: break;
> case orange: break;
> case banana: break;
> }
This. :-)
--
Iain Buclaw
*(p < e ? p++ : p) = (c & 0x0f) + '0';
Re: Rust and D
On Sat, 29 Sep 2012 10:08:29 +0200 "Peter Alexander" wrote: > > He's not dismissive of their importance. The point was that if > you can dismiss a language based solely on its lack of generics Goes back to my other original point: --- 2. [He's dismissing] The impracticality of judging the myriad of languages out there these days by going hands-on with all of them, and not having some way to narrow things down to a realistic level first. --- If he were talking about some minor insignificant feature, then I agree it'd be goofy to reject a language solely because of that. But that's not what's happening. Generics are a major thing. Many people *do* find them to make a big difference. So there's three possibilities: A. As I said, he's dismissing the impracticality of judging the myriad of languages without having some way to narrow things down to a realistic level. Or he acknowledges that impracticality and: B. He considers generics fairly unimportant/insignificant (ie, to the point of feeling it's not worth using to narrow down language choices), in which case *many* people clearly disagree with him. But instead of addressing *that*, or even acknowledging it at all, he's pulling a strawman with "They all just hatin' 'cause they like ta hate!" C. He agrees that generics are a major thing that make a big difference, in which case...what's he even complaining about? Just being sore that his language isn't up to snuff? Or sore that everyone doesn't have time to try out his "wonderful except for the lack of generics" language? So any way you take it, he's still not making much sense. > then you are essentially admitting that you have very little > imagination as a programmer. You are admitting that the only way > you can do productive, meaningful work is if you have generics. > Ok, yes, he is saying that too, but it's a ridiculous point and a faulty argument. (See below.) > It's worth pointing out that a large fraction of (most?) > programming languages do not have generics, yet people seem to be > able to do meaningful work in them. > Still a pointless argument. Name *any* feature X of a programming language and remove it: As long as it doesn't render the language non-turing-complete or eliminate the possibility of doing any I/O, then I can do useful things with the language, and so can just about any other decent programmer. So sure, that's true, he's right about that much. Problem is, that's irrelevant: The important point he's missing is "If feature X is helpful, then why should I *bother* going without, when there are plenty of other languages (such as the one I'm already using) that *do* provide me with that benefit?" He fails to even *try* to answer that and instead just complains about complaining. So unless he's trying to say "You should try Go because it's not worse than some languages", then his argument is a strawman. Frankly, I'm getting the feeling he's frustrated at discovering that a feature-light language and initial "Wow, a Google/Pike language!" attention aren't enough to sell huge crowds of people on Go. And at the realization that to get a large following, and better PR, he needs to compete better on features.
Re: Rust and D
On Saturday, 29 September 2012 at 10:27:26 UTC, Nick Sabalausky wrote: If he were talking about some minor insignificant feature, then I agree it'd be goofy to reject a language solely because of that. But that's not what's happening. Generics are a major thing. Many people *do* find them to make a big difference. So, with this in mind, do you think these hypothetical people are all justified? (a) [Go programmer]: D is rubbish because it doesn't have channels. (b) [Lisp programmer]: D is rubbish because it doesn't have homoiconicity. (c) [Haskell programmer]: D is rubbish because it doesn't have full type inference. All of those things are considered "a major thing" by their users, and many people do find them to "make a big difference." My question to you: Is it okay to reject D solely with these arguments? If not, how is this any different from rejecting Go solely from its lack of generics?
Re: Rust and D
On Saturday, 29 September 2012 at 10:27:26 UTC, Nick Sabalausky wrote: Problem is, that's irrelevant: The important point he's missing is "If feature X is helpful, then why should I *bother* going without, when there are plenty of other languages (such as the one I'm already using) that *do* provide me with that benefit?" He fails to even *try* to answer that and instead just complains about complaining. The answer to that question is obvious: you should bother going without because other languages provide other things that your pet language does not (e.g. channels + simplicity in this case). Searching for a better language is a search like any other. Hill-climbing is a poor search heuristic. Sometimes you have to be willing to lose features to find the higher peaks.
Re: Rust and D
On Saturday, 29 September 2012 at 10:53:57 UTC, Peter Alexander wrote: On Saturday, 29 September 2012 at 10:27:26 UTC, Nick Sabalausky wrote: If he were talking about some minor insignificant feature, then I agree it'd be goofy to reject a language solely because of that. But that's not what's happening. Generics are a major thing. Many people *do* find them to make a big difference. So, with this in mind, do you think these hypothetical people are all justified? (a) [Go programmer]: D is rubbish because it doesn't have channels. (b) [Lisp programmer]: D is rubbish because it doesn't have homoiconicity. (c) [Haskell programmer]: D is rubbish because it doesn't have full type inference. All of those things are considered "a major thing" by their users, and many people do find them to "make a big difference." My question to you: Is it okay to reject D solely with these arguments? If not, how is this any different from rejecting Go solely from its lack of generics? Because except for Go, all static languages developed after 1990, which managed to gain mainstream use, have some form of generics. Just to name a few out of my mind: - Ada - Modula-3 - Eiffel - C++ - D - Java - VB.NET - Object Pascal/Delphi - Ocaml - F# - Haskell - Scala For those like myself that use C++ since the 'C with classes' time, Go's lack of generics feels like time travel into a time where generics were some strange stuff in compiler design papers. The days when C++ compiler vendors used to offer C macro processor hacks, or external tools to enable the use of fake generics in C++ code. Borland was one of them, for example. Funny enough, this type of tooling seems to start appearing in the Go community, proving that regardless of what they say, the need is there. -- Paulo
Re: I have a feature request: "Named enum scope inference"
Yeah, to respond to the larger topic, the with statement is more than enough here. I'm not convinced that complicating lookup rules further is worth it.
Re: Rust and D
On Saturday, 29 September 2012 at 11:18:40 UTC, Paulo Pinto wrote: On Saturday, 29 September 2012 at 10:53:57 UTC, Peter Alexander My question to you: Is it okay to reject D solely with these arguments? If not, how is this any different from rejecting Go solely from its lack of generics? Because except for Go, all static languages developed after 1990, which managed to gain mainstream use, have some form of generics. There's two ways to interpret this sentence: 1. You claim it is okay to reject Go because it differs from other statically typed languages, or 2. You claim that all statically typed languages must have generics to be worth using. I hope it is not 1, and if it is 2 then again, I find this incredibly unimaginative. Interestingly, Rob Pike comments on this world view: http://commandcenter.blogspot.co.uk/2012/06/less-is-exponentially-more.html "Early in the rollout of Go I was told by someone that he could not imagine working in a language without generic types. As I have reported elsewhere, I found that an odd remark. To be fair he was probably saying in his own way that he really liked what the STL does for him in C++. For the purpose of argument, though, let's take his claim at face value. What it says is that he finds writing containers like lists of ints and maps of strings an unbearable burden. I find that an odd claim. I spend very little of my programming time struggling with those issues, even in languages without generic types. But more important, what it says is that types are the way to lift that burden. Types. Not polymorphic functions or language primitives or helpers of other kinds, but types. That's the detail that sticks with me."
Re: Rust and D
On Saturday, 29 September 2012 at 10:53:57 UTC, Peter Alexander wrote: So, with this in mind, do you think these hypothetical people are all justified? (a) [Go programmer]: D is rubbish because it doesn't have channels. (b) [Lisp programmer]: D is rubbish because it doesn't have homoiconicity. (c) [Haskell programmer]: D is rubbish because it doesn't have full type inference. Would you agree D would be better if it had those features? How about we rephrase to something less inflammatory: [Go programmer]: I prefer not to use D because it doesn't have channels. [Lisp programmer]: I prefer not to use D because it doesn't have homoiconicity. [Haskell programer]: I prefer not to use D because it doesn't have full type inference. Suddenly they all seem like perfectly acceptable arguments. If a person really likes/needs a certain language feature, then surely that is a good reason to reject a language that does not have this feature? Many people like generics. Go doesn't have them. So why get angry if these people reject Go?
Re: Rust and D
On 9/28/12 5:54 PM, Peter Alexander wrote: On Friday, 28 September 2012 at 17:42:07 UTC, Froglegs wrote: The Rust website says this: Generic types yes, only simple, non-turing-complete substitution After seeing that I just assumed the language was worthless and ignored it.. is there something more to this? Relevant: http://commandcenter.blogspot.co.uk/2011/12/esmereldas-imagination.html I remember the entry, it's caused some criticism on reddit or HN a while ago. Particularly the closing paragraph has grated many people, but heck, who hasn't had a bad blogging day? We've experienced some similar criticism about D, which was quite clearly (in my opinion) a rationalization of a foregone disposition rather than a valid concern. One example that comes to mind is an email exchange with a C++ expert who latched onto D not supporting structs with internal pointers as an essential feature for many designs, which that person found unthinkable to adjust. (I don't see how the parallel with the actress anecdote holds, as the punchline there is that an actor has to imagine being in other lines of work as the very part of acting.) Anyhow, I've recently decided to acquire some fluency in Go and look into alternative ways to accomplish things I'd want to accomplish. Andrei
Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples
On 2012-09-28 19:09, deadalnix wrote: It is ambiguous with the comma declaration syntax. I could live without it. -- /Jacob Carlborg
Re: dynamic library building and loading
On 2012-09-28 20:25, Maxim Fomin wrote: I tried to check how TLS, EX, etc. (mostly exposed to dll issue) are working and here is some kind of test: https://github.com/mxfm/sharedtest. Unfortunately scope(exit) isn't executed when it is situated in a shared library and which calls some throwing function from another shared library. Unittests aren't working either. Regarding other parts - they seem to work. That's a fairly uninteresting test. You are linking to the dynamic library. What's interesting is loading a dynamic library using dlopen, or similar. What's the point of using dynamic libraries if you're linking with them? -- /Jacob Carlborg
Re: dynamic library building and loading
On 2012-09-28 19:54, Rob T wrote: I suppose the answer is very complicated, but why can't the runtime execute as a shared lib? Is it a design limitation of the runtime model? This sort of problem should have been dealt with from the ground up, not now. What can be done to fix it, or is it a major redesign + re-write effort? See one of my other posts: http://forum.dlang.org/thread/k3vfm9$1tq$1...@digitalmars.com?page=3#post-k4219f:24uft:241:40digitalmars.com -- /Jacob Carlborg
Re: Rust and D
On Saturday, 29 September 2012 at 12:09:35 UTC, Thiez wrote: Would you agree D would be better if it had those features? Maybe. Maybe not. It's irrelevant. How about we rephrase to something less inflammatory: [Go programmer]: I prefer not to use D because it doesn't have channels. [Lisp programmer]: I prefer not to use D because it doesn't have homoiconicity. [Haskell programer]: I prefer not to use D because it doesn't have full type inference. Suddenly they all seem like perfectly acceptable arguments. If a person really likes/needs a certain language feature, then surely that is a good reason to reject a language that does not have this feature? If the person has not even tried the language then no, I still do not think those are valid reasons to reject a language. Many people like generics. Go doesn't have them. So why get angry if these people reject Go? I like ice cream. Vegetables don't contain ice cream. So why get angry if I don't try vegetables? Ok, so there's no reason to get angry, but I'd be an idiot to follow that logic. The parallel is that I would consider it unhealthy to dismiss a language without trying it just because it lacks a feature that you happen to like. It may have something else that you like even more, or you may even find that the *lack* of a feature actually makes the language simpler and more expressive in ways you couldn't imagine (e.g. D's lack on inner struct pointers makes things significantly simpler).
Re: Rust and D
On Sat, 29 Sep 2012 08:15:56 -0400 Andrei Alexandrescu wrote: > > (I don't see how the parallel with the actress anecdote holds, as the > punchline there is that an actor has to imagine being in other lines > of work as the very part of acting.) > I'd been thinking the same thing. It was very amusing in the actress context, but brining it into programming just didn't seem to fit.
Re: Rust and D
On Sat, 29 Sep 2012 13:06:33 +0200 "Peter Alexander" wrote: > > The answer to that question is obvious: you should bother going > without because other languages provide other things that your > pet language does not (e.g. channels + simplicity in this case). > > Searching for a better language is a search like any other. > Hill-climbing is a poor search heuristic. Sometimes you have to > be willing to lose features to find the higher peaks. > And sometimes I need to get work done instead of trying out all of the 100's of languages out there in some altruistic quest to be fair to everybody.
Re: Rust and D
On Saturday, 29 September 2012 at 12:04:50 UTC, Peter Alexander wrote: On Saturday, 29 September 2012 at 11:18:40 UTC, Paulo Pinto wrote: On Saturday, 29 September 2012 at 10:53:57 UTC, Peter Alexander My question to you: Is it okay to reject D solely with these arguments? If not, how is this any different from rejecting Go solely from its lack of generics? Because except for Go, all static languages developed after 1990, which managed to gain mainstream use, have some form of generics. There's two ways to interpret this sentence: 1. You claim it is okay to reject Go because it differs from other statically typed languages, or 2. You claim that all statically typed languages must have generics to be worth using. I hope it is not 1, and if it is 2 then again, I find this incredibly unimaginative. It is 2. And before you say that it is due to lack of experience with Go. I have tried. You will find lots of posts made by me about generics and doing systems programming with GC enabled languages in gonuts. Actually, you may even find some early code reviews made to my early attempts to create the Windows version of the os.user package. Which was latter on picked up by the Go team. Or the early attempts to support some form of UI in Windows. So I don't dismiss Go without language experience. Interestingly, Rob Pike comments on this world view: http://commandcenter.blogspot.co.uk/2012/06/less-is-exponentially-more.html I belong to the C++ category he describes there. Actually his blog entry was discussed to great lengths at Lambda the Ultimate. Personally I think they are throwing the baby with the water in terms of language design. Go would have been a great language before Generic Programming, Meta-programming and functional programming became mainstream in the IT corporations. Nowadays it feels like a step backwards. While using Go I travelled back in time to my university days when I thought Oberon or Component Pascal would become mainstream. Languages which share the same design philosophy. But that was back in 1994. -- Paulo
Re: Rust and D
On Saturday, 29 September 2012 at 14:03:52 UTC, Nick Sabalausky wrote: And sometimes I need to get work done instead of trying out all of the 100's of languages out there in some altruistic quest to be fair to everybody. Nothing wrong with that, but rejecting a language because you don't have time to try it out is much different for rejecting it because it lacks a single feature.
Re: I have a feature request: "Named enum scope inference"
On Saturday, 29 September 2012 at 05:47:59 UTC, Bernard Helyer
wrote:
Except a theoretical feature doesn't exist, so someone has
to write the code. So no, it's not an 'unacceptable
argument'.
I'll explain my way of seeing this in the form we all understand:
code.
bool tryImplement(Feature x)
{
bool is_a_nice_feature_to_have = discussFeature(x);
if (is_a_nice_feature_to_have)
{
bool do_we_implement_it = discussImplementation(x);
if (do_we_implement_it)
{
implement(x);
return true;
}
std.pause(10.years);
bool does_someone_else_implement_it_in_2022 =
discussImplementation(x);
if (does_someone_else_implement_it_in_2022)
{
implement(x);
return true;
}
std.pause(10.years);
// ... and so on
}
return false;
}
And I think we're currently inside the function call
'discussFeature(x)'. There's no point in calling
'discussImplementation(x)' until we're in the scope of the if
clause 'if (is_a_nice_feature_to_have)'.
Re: Rust and D
On Sat, 29 Sep 2012 12:54:26 +0200 "Peter Alexander" wrote: > On Saturday, 29 September 2012 at 10:27:26 UTC, Nick Sabalausky > wrote: > > If he were talking about some minor insignificant feature, then > > I agree > > it'd be goofy to reject a language solely because of that. But > > that's > > not what's happening. Generics are a major thing. Many people > > *do* find > > them to make a big difference. > > So, with this in mind, do you think these hypothetical people are > all justified? > > (a) [Go programmer]: D is rubbish because it doesn't have > channels. > (b) [Lisp programmer]: D is rubbish because it doesn't have > homoiconicity. > (c) [Haskell programmer]: D is rubbish because it doesn't have > full type inference. > > All of those things are considered "a major thing" by their > users, and many people do find them to "make a big difference." > If they find those things to be as important to them as I find metaprogramming to be, then yes, of course. Personally, I think it's a stretch to compare those to "having generics". But that's just me...and, apparently, a hell of a lot of other people too, to Pike's dismay. > My question to you: Is it okay to reject D solely with these > arguments? If it's in-line with their needs, then yes. It'd be both selfish and absurd for us to demand that everyone tries out and becomes proficient with our language and our language's way of doing things before deciding whether or not our language is right for them and worth their time. And in addition to all that, I doubt very much that most people who say things to the effect of "I won't use Go because it lacks generics" are *truly* basing it *purely* on the lack of generics, so the whole question is academic anyway. Hell, I'm sure *I've* at some point probably given the impression that generics are the only reason I'm not into Go. But the reality is that there are also other reasons, and "generics" is merely one of the biggest and most convenient to point out. Just as an example, I'm sure a *lot* of the "No generics, not interested" crowd would also find this applicable, too: "I'm happy enough with my current language and don't have time to try another out unless there's already something about it that really stands out to me as being likely worth the investment."
Re: Rust and D
On Sat, 29 Sep 2012 14:05:19 +0200 "Peter Alexander" wrote: > > Interestingly, Rob Pike comments on this world view: > > http://commandcenter.blogspot.co.uk/2012/06/less-is-exponentially-more.html > > "Early in the rollout of Go I was told by someone that he could > not imagine working in a language without generic types. As I > have reported elsewhere, I found that an odd remark. > > To be fair he was probably saying in his own way that he really > liked what the STL does for him in C++. For the purpose of > argument, though, let's take his claim at face value. > > What it says is that he finds writing containers like lists of > ints and maps of strings an unbearable burden. I find that an odd > claim. I spend very little of my programming time struggling with > those issues, even in languages without generic types. > > But more important, what it says is that types are the way to > lift that burden. Types. Not polymorphic functions or language > primitives or helpers of other kinds, but types. > > That's the detail that sticks with me." > Sounds like Pike is either implying that all approaches are created equal, or that "types" are inferior. On the contrary, I think there's good reason to prefer the type-based solution. But maybe I'm wrong. Maybe I don't understand the other approaches well enough. Maybe Pike would actually convince more people if he spent more time explaining *how* Go sufficiently addresses the issue and less time using meta-arguments to rehash "Why can't people just start liking Go?" It's unfortunate, because the more I read these quotes of his, the more I have to wonder whether his emperor even has any clothes at all.
Re: I have a feature request: "Named enum scope inference"
On 29/09/2012 04:11, Andrej Mitrovic wrote:
On 9/29/12, David Piepgrass wrote:
I like the spirit of this feature, but as Alex pointed out,
ambiguity is possible (which could theoretically cause errors in
existing code)
It could also cause subtle problems because enum values are implicitly
convertible to the enum's base type. Take this for example:
void test(bool state) { }
enum Foo { no, yes }
class Class
{
enum Bar { yes, no }
void test() { .test(no); } // pass Foo.no (true) or Bar.no (false) ?
}
This isn't an issue with this proposal. There is no enum type available
to use for inference, so 'no' simply doesn't resolve there.
If you're ever working in Java using Eclipse, you'll notice that Eclipse
has this very feature in its autocomplete engine. For example, if you write:
if (myEnumValue ==
and then press Ctrl+Space, then it'll list the enum constants. When you
select one, it'll generate the qualified name because it has to.
The point is to use what we know about the type that is *likely* to
occur here (by considering assignment LHS, comparison LHS, parameters to
possibly matching methods, method return type in argument to 'return',
etc.) to infer which enum type's members to consider (if any).
Hope that clarifies :)
Re: Rust and D
On Sat, 29 Sep 2012 16:15:51 +0200 "Peter Alexander" wrote: > On Saturday, 29 September 2012 at 14:03:52 UTC, Nick Sabalausky > wrote: > > And sometimes I need to get work done instead of trying out all > > of the > > 100's of languages out there in some altruistic quest to be > > fair to > > everybody. > > Nothing wrong with that, but rejecting a language because you > don't have time to try it out is much different for rejecting it > because it lacks a single feature. It's not as different as it may seem. People have limited time. Some have more, some have less (hell, probably most have less), but *nobody* can go trying out all the languages out there, so we all have to have some some "filter" for picking the ones we feel most likely to pay off, narrowed down to whatever our schedule will even allow. Usually this is all implicit and maybe even sub-conscious, but it's always there. So when someone is "rejecting a language because it lacks a single feature" without even trying it, then no, I don't believe that they actually *are* rejecting it *just* because it lacks one feature, at least not in most cases. Because there's always still an implicit "I don't have time to pursue a language that I feel may not be likely enough to pay off."
Re: I have a feature request: "Named enum scope inference"
On Saturday, 29 September 2012 at 07:04:19 UTC, kenji hara wrote:
After a while, you may add a global variable in module scope.
enum E { foo ,bar }
int foo = 10;
void test(E e) {}
void main() {
test(foo); // foo is defined, and look up module scope foo.
// Then, now the code is broken implicitly!
}
This is a hijacking of local scope, and it is awful.
That code doesn't compile anyway, because the global foo is an
int. But you're right, my suggestion doesn't work. Or, there's no
way to implement it without breaking existing code. Here's the
reason again for completeness sake:
enum E { foo, bar };
void test(E e) {}
int intValue = -1;
void main()
{
int intValue = 42; // Hides the global intValue.
E foo = E.bar; // This is fine. A local variable foo hides
// E.foo from 'implicit global visibility'.
// It's effectively same as hiding a global.
test(foo); // Calls test(E.bar)
}
-
enum E { foo, bar };
void test(E e) {}
void main()
{
test(foo); // Calls test(E.bar)
}
E foo = E.bar; // This is very bad. A global variable foo hides
// E.foo from being implicitly globally visible
// (where applicaple)
On Saturday, 29 September 2012 at 07:04:19 UTC, kenji hara wrote:
It seems to me the root problem is that using a raw-identifier
for the start of the inference.
If there is a symbol literal, the problem may be solved.
test('bar); // bar is a symbol, so it does not refer any
normal declarations
That would work. I'd be fine with this kind of wild-card enum
literal.
Getting started with D - Phobos documentation sucks
Hi guys. I was browsing the book "Programming in D" by Ali Çehreli. It was pretty much clear, and then I stumbled upon this on page 89: 20.9 Exercises 1. Browse the documentations of the std.string, std.array, std.algorithm, and std.range modules. OK, let's open the D website and browse the documentation of std.string: http://dlang.org/phobos/std_string.html What do we see? A bunch of links that look like SEO tags of a spam website, followed by a mess of anything - structs, classes, functions, and what not. Do you really think somebody who learns programming can understand anything here? Compare this with, e.g., an msdn reference: http://msdn.microsoft.com/en-us/library/windows/desktop/ms684852(v=vs.85).aspx A clear division of enums, functions, macros, structs, ... http://msdn.microsoft.com/en-us/library/windows/desktop/ms684847(v=vs.85).aspx The functions are divided by usage, with a short explanation next to each function. I think documentation is really important, and something has to be done about it. How can a newcomer get started with D when he doesn't have a readable documentation of Phobos?
Re: Getting started with D - Phobos documentation sucks
On 09/29/2012 05:30 PM, Mr. Anonymous wrote: Hi guys. I was browsing the book "Programming in D" by Ali Çehreli. It was pretty much clear, and then I stumbled upon this on page 89: 20.9 Exercises 1. Browse the documentations of the std.string, std.array, std.algorithm, and std.range modules. OK, let's open the D website and browse the documentation of std.string: http://dlang.org/phobos/std_string.html What do we see? A bunch of links that look like SEO tags of a spam website, followed by a mess of anything - structs, classes, functions, and what not. Do you really think somebody who learns programming can understand anything here? Compare this with, e.g., an msdn reference: http://msdn.microsoft.com/en-us/library/windows/desktop/ms684852(v=vs.85).aspx A clear division of enums, functions, macros, structs, ... http://msdn.microsoft.com/en-us/library/windows/desktop/ms684847(v=vs.85).aspx The functions are divided by usage, with a short explanation next to each function. I think documentation is really important, and something has to be done about it. How can a newcomer get started with D when he doesn't have a readable documentation of Phobos? https://github.com/D-Programming-Language/d-programming-language.org
Re: dynamic library building and loading
On Saturday, 29 September 2012 at 13:19:01 UTC, Jacob Carlborg wrote: That's a fairly uninteresting test. I am not a D developer which means I have no incentive in blindly portraying D as a language having shared libraries support when in fact it has some issues. I am a D user which has incentive to gladly report which part of D does work (or seems to work) and which doesn't when making shared libraries. You are linking to the dynamic library. What's interesting is loading a dynamic library using dlopen, or similar. What's the point of using dynamic libraries if you're linking with them? I was not taking about dynamic loading, but about dynamic linking. If I understand topic right, the issue is the former, not the latter. BTW, in majority cases dynamic loading gives no advantages over dynamic linking (just the opposite: doing unnecessary job which can be done by linker and loader). In most cases, when an app is being written, it is known which functional from which third-party libraries would be used. The only exceptions I can name are pluggin support and hacker's binary ELF/PE tools. I can count few apps in windows and linux which are used often, which dynamically load something, and if they do, they likely load pluggins. This was made for cases when app developers by definition cannot know beforehand full list of used shared libraries. So, the question is just opposite: "What's the point of using dynamic loading if you know beforehand which libraries you use, which happens almost in all cases?". But I certainly agree that dynamic loading is essential for some applications, if not irreplaceable, and support of it also needed to be inspected and improved.
Re: Getting started with D - Phobos documentation sucks
On Saturday, 29 September 2012 at 15:29:46 UTC, Mr. Anonymous wrote: 1. Browse the documentations of the std.string, std.array, std.algorithm, and std.range modules. OK, let's open the D website and browse the documentation of std.string: http://dlang.org/phobos/std_string.html What do we see? A bunch of links that look like SEO tags of a spam website, followed by a mess of anything - structs, classes, functions, and what not. Compare this with, e.g., an msdn reference. Just remembering that most of the things that you see here is made by the community itself and the most important, it's free. But well this is not an excuse, but anyway, Microsoft come doing this since long time ago and was not always as you see today.
Re: Getting started with D - Phobos documentation sucks
On Saturday, 29 September 2012 at 15:46:36 UTC, MattCoder wrote: On Saturday, 29 September 2012 at 15:29:46 UTC, Mr. Anonymous wrote: 1. Browse the documentations of the std.string, std.array, std.algorithm, and std.range modules. OK, let's open the D website and browse the documentation of std.string: http://dlang.org/phobos/std_string.html What do we see? A bunch of links that look like SEO tags of a spam website, followed by a mess of anything - structs, classes, functions, and what not. Compare this with, e.g., an msdn reference. Just remembering that most of the things that you see here is made by the community itself and the most important, it's free. But well this is not an excuse, but anyway, Microsoft come doing this since long time ago and was not always as you see today. Don't get me wrong, I'm not saying somebody owes me something. I love D and appreciate the effort the community puts in it, otherwise I probably wouldn't write this post. I'm just saying that, in my opinion, it's a high priority and it has to be addressed, so that newcomers would be able to get started with D.
Re: Getting started with D - Phobos documentation sucks
On Saturday, 29 September 2012 at 15:29:46 UTC, Mr. Anonymous wrote: Hi guys. I was browsing the book "Programming in D" by Ali Çehreli. It was pretty much clear, and then I stumbled upon this on page 89: 20.9 Exercises 1. Browse the documentations of the std.string, std.array, std.algorithm, and std.range modules. OK, let's open the D website and browse the documentation of std.string: http://dlang.org/phobos/std_string.html What do we see? A bunch of links that look like SEO tags of a spam website, followed by a mess of anything - structs, classes, functions, and what not. Do you really think somebody who learns programming can understand anything here? Compare this with, e.g., an msdn reference: http://msdn.microsoft.com/en-us/library/windows/desktop/ms684852(v=vs.85).aspx A clear division of enums, functions, macros, structs, ... http://msdn.microsoft.com/en-us/library/windows/desktop/ms684847(v=vs.85).aspx The functions are divided by usage, with a short explanation next to each function. I think documentation is really important, and something has to be done about it. How can a newcomer get started with D when he doesn't have a readable documentation of Phobos? You should really read first "The D Programming Language", or TDPL. http://www.amazon.com/The-Programming-Language-Andrei-Alexandrescu/dp/0321635361 It's a great read, entertaining, informative. But notice that it doesn't cover everything, like template specializations (signature constraints are not the same thing). Then read the strictly less entertaining language reference pages starting from: http://dlang.org/lex.html But notice that it doesn't cover everything either. For example it fails to mention that pointers to structs and classes are implicitly dereferenced when you use the member access operator with them, like ptrToStruct.callMethod().
Re: dynamic library building and loading
On 2012-09-29 17:40, Maxim Fomin wrote: I was not taking about dynamic loading, but about dynamic linking. If I understand topic right, the issue is the former, not the latter. The title of the thread says "... and loading". BTW, in majority cases dynamic loading gives no advantages over dynamic linking (just the opposite: doing unnecessary job which can be done by linker and loader). In most cases, when an app is being written, it is known which functional from which third-party libraries would be used. I agree, in these cases their no point in using dynamic loading. The only exceptions I can name are pluggin support and hacker's binary ELF/PE tools. I can count few apps in windows and linux which are used often, which dynamically load something, and if they do, they likely load pluggins. This was made for cases when app developers by definition cannot know beforehand full list of used shared libraries. Exactly, pluggins are one of the main reasons for using dynamic loading. An other reason is license issues. There's a D library called Derelict which uses dynamic loading to load C libraries (OpenGL, SDL, OpenAL and others). One of the many reason for Derelict using dynamic loading is due to license issues/complications with these libraries. http://dsource.org/projects/derelict/ So, the question is just opposite: "What's the point of using dynamic loading if you know beforehand which libraries you use, which happens almost in all cases?". There's no point in doing that. But what I'm saying is if you know beforehand the libraries you will use you can get quite far with static libraries. -- /Jacob Carlborg
Re: Getting started with D - Phobos documentation sucks
On Saturday, 29 September 2012 at 15:53:17 UTC, Mr. Anonymous wrote: Don't get me wrong, I'm not saying somebody owes me something. I love D and appreciate the effort the community puts in it, otherwise I probably wouldn't write this post. I'm just saying that, in my opinion, it's a high priority and it has to be addressed, so that newcomers would be able to get started with D. No problem fellow and be sure that I don't wanted to surpress your feelings, because I had the same feelings in the first time that I saw the doc's. But be sure the guys behind D knows that, but you know this is a hard job which demands some time.
Re: Getting started with D - Phobos documentation sucks
And there's also the D Templates Tutorial at: https://github.com/PhilippeSigaud/D-templates-tutorial/blob/master/dtemplates.pdf (click "View Raw" on that page)
Re: Getting started with D - Phobos documentation sucks
On 9/29/12 11:30 AM, Mr. Anonymous wrote: I think documentation is really important, and something has to be done about it. How can a newcomer get started with D when he doesn't have a readable documentation of Phobos? Agree. It's high time we replace the silly litany of names at the top with a more sensible index (or, indeed, nothing at all!) Andrei
Re: Rust and D
On Saturday, 29 September 2012 at 14:27:03 UTC, Nick Sabalausky wrote: My question to you: Is it okay to reject D solely with these arguments? If it's in-line with their needs, then yes. It'd be both selfish and absurd for us to demand that everyone tries out and becomes proficient with our language and our language's way of doing things before deciding whether or not our language is right for them and worth their time. Again, no one is making any demands. I'm asking for one of two things from people: either try the language then form an educated opinion, or don't try it and say nothing. The problem is that people are reading "no generics", not trying the language, and then shouting out that it is rubbish. And in addition to all that, I doubt very much that most people who say things to the effect of "I won't use Go because it lacks generics" are *truly* basing it *purely* on the lack of generics, so the whole question is academic anyway. See post 4 in this thread. That's what got me started. http://forum.dlang.org/thread/tpwsxxjghbpsheexy...@forum.dlang.org#post-hqhkcxyqtbrbasuknmdt:40forum.dlang.org Yes, you said "most", and one post is not most, but I see this attitude a lot. Evidently Rob Pike does as well. I'm sure most people here have seen similar arguments against D.
Re: Getting started with D - Phobos documentation sucks
On Saturday, 29 September 2012 at 16:34:41 UTC, Andrei Alexandrescu wrote: On 9/29/12 11:30 AM, Mr. Anonymous wrote: I think documentation is really important, and something has to be done about it. How can a newcomer get started with D when he doesn't have a readable documentation of Phobos? Agree. It's high time we replace the silly litany of names at the top with a more sensible index (or, indeed, nothing at all!) Andrei Well, they *are* better than nothing at all. Sure, in the best of worlds, we'd have lovingly hand written indexes and documentation, such as for std_algorithm. However, for those modules that *don't* have that hand written doc, it is better than nothing. IMO, however, anything "nested" should NOT appear in the top index though, just the module's global functions and classes/structs. Anything else is clutter: std_container is a blatant example of the clutter I'm talking about: There is everything in there from "front" to "opIndexOpAssign"... Either that, or reorganized, as in: Array (front, back, ... opIndexOpAssiggn) Rather than the current free for all.
Re: Getting started with D - Phobos documentation sucks
On Saturday, 29 September 2012 at 17:03:26 UTC, monarch_dodra wrote: Well, they *are* better than nothing at all. Sure, in the best of worlds, we'd have lovingly hand written indexes and documentation, such as for std_algorithm. However, for those modules that *don't* have that hand written doc, it is better than nothing. It is possible to do something like that automatically: http://arsdnet.net/d-web-site/std_stdio.html http://arsdnet.net/d-web-site/std_datetime.html
Re: Getting started with D - Phobos documentation sucks
Le 29/09/2012 19:09, Adam D. Ruppe a écrit : On Saturday, 29 September 2012 at 17:03:26 UTC, monarch_dodra wrote: Well, they *are* better than nothing at all. Sure, in the best of worlds, we'd have lovingly hand written indexes and documentation, such as for std_algorithm. However, for those modules that *don't* have that hand written doc, it is better than nothing. It is possible to do something like that automatically: http://arsdnet.net/d-web-site/std_stdio.html http://arsdnet.net/d-web-site/std_datetime.html That is much better than what we currently have.
Re: Getting started with D - Phobos documentation sucks
On 29-Sep-12 21:13, deadalnix wrote: Le 29/09/2012 19:09, Adam D. Ruppe a écrit : On Saturday, 29 September 2012 at 17:03:26 UTC, monarch_dodra wrote: Well, they *are* better than nothing at all. Sure, in the best of worlds, we'd have lovingly hand written indexes and documentation, such as for std_algorithm. However, for those modules that *don't* have that hand written doc, it is better than nothing. It is possible to do something like that automatically: http://arsdnet.net/d-web-site/std_stdio.html http://arsdnet.net/d-web-site/std_datetime.html That is much better than what we currently have. Agreed. What's needed to make it a reality ? -- Dmitry Olshansky
Re: Rust and D
On Sat, 29 Sep 2012 19:04:01 +0200 "Peter Alexander" wrote: > On Saturday, 29 September 2012 at 14:27:03 UTC, Nick Sabalausky > wrote: > >> My question to you: Is it okay to reject D solely with these > >> arguments? > > > > If it's in-line with their needs, then yes. It'd be both > > selfish and > > absurd for us to demand that everyone tries out and becomes > > proficient > > with our language and our language's way of doing things before > > deciding whether or not our language is right for them and > > worth their > > time. > > Again, no one is making any demands. I'm asking for one of two > things from people: either try the language then form an educated > opinion, or don't try it and say nothing. The problem is that > people are reading "no generics", not trying the language, and > then shouting out that it is rubbish. > > > > And in addition to all that, I doubt very much that most people > > who > > say things to the effect of "I won't use Go because it lacks > > generics" > > are *truly* basing it *purely* on the lack of generics, so the > > whole question is academic anyway. > > See post 4 in this thread. That's what got me started. > > http://forum.dlang.org/thread/tpwsxxjghbpsheexy...@forum.dlang.org#post-hqhkcxyqtbrbasuknmdt:40forum.dlang.org > > Yes, you said "most", and one post is not most, but I see this > attitude a lot. Evidently Rob Pike does as well. I'm sure most > people here have seen similar arguments against D. Yea, I still don't see the problem. First of all, he wasn't "shouting out that it is rubbish" - only stated that he had assumed it to be *and* even asked if "is there something more to it". Second, obviously he's one of the many, many programmers who do highly value generics, so it's not unreasonable for him to dismiss it without trying it. How many people have so much free time they can go trying out all the languages that sound wrong for them? If Pike sees this sort of thing a lot and is bothered by it, then he needs to either reevaluate Go's stance on generics or provide direct explanation why Go doesn't need them without dancing around the issue with things like "Less is More" vagueness and "They're just complaining" hand-waving. Otherwise he can't expect people's apprehensions about it to magically go away. We had a big PR problem with the whole two-incompatible-standard-libs thing. What did we do? We fixed the damn problem and then communicated whenever necessary about how and why it wasn't an issue. What we didn't do was hop on our blogs to whine that people loved to complain and weren't being fair to D.
Re: I have a feature request: "Named enum scope inference"
But, if we were allowed to make a breaking change, then this is
how I think it should work:
// in a module scope...
enum E { foo, bar };
-
// These cause a compile error "foo is ambiguous":
1) E foo = E.bar;
2) E foo = E.foo;
3) enum foo = E.bar;
4) immutable foo = E.bar;
5) immutable foo = initFoo(); // if we can't CTFE initFoo()
// These are fine:
1) enum foo = E.foo;
2) immutable foo = E.foo;
3) int foo = 42; // int isn't implicitly convertible to E
4) E Foo = E.bar;
-
struct Convertible
{
E _value;
alias _value this;
}
Convertible foo; // Compile error: foo is ambiguous
-
struct MyStruct(T)
{
T foo = 123; // Fine, hides E.foo inside MyStruct scope
void fun()
{
T foo = 42 // Fine, hides both MyStruct.foo and
// E.foo inside this function scope
}
}
Here's the logic of it:
---
An enumeration of type E should be visible (like it was a module
scope variable) if, and only if, it occurs in one of these
"hot-spots" where a value of type E is expected (e.g. it could be
in a template parameter list, function argument list, or in a
case expression of a switch).
Inside these "hot-spots" the enumeration fights over visibility
against variables. It loses that fight against function local and
class/struct local variables which have the same name (and
whatever type). But it wins the battle over visibility against
module scope variables which have the same name but are not
implicitly convertible to type E. Against global variables which
are of type E or are implicitly convertible to type E, the battle
over visibility ends in a tie, and that's a compile-time
ambiguity error.
Re: I have a feature request: "Named enum scope inference"
On 9/29/12 2:44 PM, Tommi wrote: But, if we were allowed to make a breaking change I stopped reading here :o). Andrei
Re: Rust and D
On 9/29/2012 1:08 AM, Peter Alexander wrote: As you can see, no matter what you think of these features, the arguments are pointless because it is very clear that you can do meaningful work without them. We get by without channels, homoiconicity, and full program type inference; just as the Go programmers get by without generics. I think that argument is making the claims that: 1. all features are equally valuable 2. if one can get by without a feature, then that feature is not needed Both of those are invalid.
Re: Rust and D
On 9/29/2012 3:54 AM, Peter Alexander wrote: So, with this in mind, do you think these hypothetical people are all justified? (a) [Go programmer]: D is rubbish because it doesn't have channels. (b) [Lisp programmer]: D is rubbish because it doesn't have homoiconicity. (c) [Haskell programmer]: D is rubbish because it doesn't have full type inference. All of those things are considered "a major thing" by their users, and many people do find them to "make a big difference." People can and do make those arguments and justifications. The question is, really, how large of a class of programming problems does each of those features address?
Re: Rust and D
On 9/29/2012 5:05 AM, Peter Alexander wrote: There's two ways to interpret this sentence: 1. You claim it is okay to reject Go because it differs from other statically typed languages, or 2. You claim that all statically typed languages must have generics to be worth using. I hope it is not 1, and if it is 2 then again, I find this incredibly unimaginative. Is it really? For example, all modern cars use fuel injection. That doesn't make carbureted cars unusable, I've driven them just fine for decades, but I sure do prefer fuel injection. Most people prefer it so much that you can buy fuel injection kits to replace the carburetors on most older cars. I would not buy a new car with a carburetor. Same goes for electronic ignition. Man, is that better than the old points/dwell system.
Re: Rust and D
On Saturday, 29 September 2012 at 17:03:33 UTC, Peter Alexander wrote: I'm sure most people here have seen similar arguments against D. The complaint I've seen in a similar vain have been, "D is too complex" "it has everything and the kitchen sink" "if someone asks for it, it gets added" And all but the last one is true. These are valid concerns and should not be dismissed as "people complaining to complain." Attempts to explain that to simplify the language introduces complexity to the code may fail. But the concern is not any less valid. What is more annoying is that the level of understanding the complexity is usually attributed to that of C++. I grasp meta programming to a fairly decent degree, but I fail to read and understand that demonstrated in C++. I have very limited experience with C++ and almost no familiarity with templates (outside of the overlap with D). The syntax makes a huge difference! And with such clean syntax I guess our semantics is cleaner too. A similar parallel I may have identified is Go return values. These are compared to those used in C. But if I picked up on this correctly, errors codes must be explicitly ignored. In which case I think of checked exceptions, except now every call is made with a try. As you can see I am trying to apply experience I have with other languages to conform an understanding of the experience I'd get from Go. It doesn't mean it will be exactly correct, but this is how we efficiently eventuate things. If I have only ridden roller coasters that go upside-down, if asked whether I would enjoy one that doesn't go upside-down, I can apply my knowledge of the time spent not being upside down for those that do and make a best guess if I would find it fun/scary.
Re: Rust and D
On Saturday, 29 September 2012 at 19:09:46 UTC, Walter Bright wrote: On 9/29/2012 1:08 AM, Peter Alexander wrote: As you can see, no matter what you think of these features, the arguments are pointless because it is very clear that you can do meaningful work without them. We get by without channels, homoiconicity, and full program type inference; just as the Go programmers get by without generics. I think that argument is making the claims that: 1. all features are equally valuable 2. if one can get by without a feature, then that feature is not needed Both of those are invalid. Exactly my thoughts. Templates enable abstraction. Go channels enable ... channels. Comparing both on the same level is ridiculous. Go has a vey low level of abstraction. I feel it is even worse than C. In C, void* can be a powerful abstraction tool, but in Go pointers are almost banned and made difficult to use. Empty interfaces do not cut it because they involve boxing and unboxing and they give you nothing that void * could not give you and easier. Interfaces in general? You cannot even sensibly define interfaces with methods that have that same interfaces as their return types (just try it). I cannot see Go being used beyond utf-8 text processing (web servers and the like). Numeric calculations? Without some serious abstraction tools nobody is going to waste their time. Other uses? Wherever you go abstraction (read generics and the like) rules. Not using abstraction means usually wasting your programming effort and redoing things multiple times. When people refuse to use programming languages without abstraction mechanisms it is exactly immagination that they use.
Re: Rust and D
On Saturday, 29 September 2012 at 19:09:46 UTC, Walter Bright wrote: On 9/29/2012 1:08 AM, Peter Alexander wrote: As you can see, no matter what you think of these features, the arguments are pointless because it is very clear that you can do meaningful work without them. We get by without channels, homoiconicity, and full program type inference; just as the Go programmers get by without generics. I think that argument is making the claims that: 1. all features are equally valuable 2. if one can get by without a feature, then that feature is not needed Both of those are invalid. I'm not making claim 1, and claim 2 is true by definition.
Re: I have a feature request: "Named enum scope inference"
Scratch my previous post. It had a weird rule where the types of
identifiers had a say in whether or not there's ambiguity in the
name lookup. That's just silly. It should always be an ambiguity
error if the names are identical.
This new rule is easier to conceptualize too. Basically you just
think that there are these "hot-spots" (they're red, I think) in
your code wherever named enum values are expected. Inside each
"hot-spot", the name lookup is allowed to think that all the
enumerations (the enumerated identifiers) of that particular
named enum type are in module scope. And that's it.
So, again... if we were allowed to make a breaking change, this
is how I think it should work:
// in a module scope...
enum Char { a, b, c, d, e }
Char a = Char.c; // OK
auto b = a; // OK: .b == Char.c
Char c = Char.a; // OK: .c == Char.a
Char d = a; // ERROR: 'a' could be either 'Char.a' or '.a'
// because now 'a' is in a "hot-spot", where a
// value convertible to type Char is expected,
// and thus all Char enumerations can be seen
// as if they were in module scope
int e = 42; // OK
void test(Char ch) {}
struct MyStruct
{
int a = 1; // OK: hides '.a'
void fun()
{
Char a = Char.e; // OK: hides 'MyStruct.a' and '.a'
test(a); // OK: calls 'test(Char.e)' although the test
// argument 'a' is now in a "hot-spot" where
// all the enumerations of Char (a, b, c, d, e)
// are considered to be in module scope. But
// the function local 'a' hides anything that
// might be in module scope, so the name lookup
// doesn't even bother looking at module scope.
test(e); // ERROR: 'e' could be either 'Char.e' or '.e'
// because now the name lookup has to look at
// the module scope, where we have also Char.e
// visible due to the fact that argument 'e'
// is in a "hot-spot". It doesn't matter from
// our name-lookup's point of view that test
// is not callable with an int value.
}
}
Re: Rust and D
On 09/29/2012 09:12 PM, Walter Bright wrote: On 9/29/2012 3:54 AM, Peter Alexander wrote: So, with this in mind, do you think these hypothetical people are all justified? (a) [Go programmer]: D is rubbish because it doesn't have channels. (b) [Lisp programmer]: D is rubbish because it doesn't have homoiconicity. (c) [Haskell programmer]: D is rubbish because it doesn't have full type inference. All of those things are considered "a major thing" by their users, and many people do find them to "make a big difference." People can and do make those arguments and justifications. The question is, really, how large of a class of programming problems does each of those features address? a) can be done in a library. (eg. in D, but not in Go) Therefore, claiming that D does not have channels is moot anyway. b), c) enable more powerful abstractions. They help all programs if the programmer knows how to leverage them.
Re: Rust and D
On Sun, 30 Sep 2012 00:12:33 +0200 "Peter Alexander" wrote: > On Saturday, 29 September 2012 at 19:09:46 UTC, Walter Bright > wrote: > > > > I think that argument is making the claims that: > > > > 1. all features are equally valuable > > > > 2. if one can get by without a feature, then that feature is > > not needed > > > > Both of those are invalid. > > I'm not making claim 1, and claim 2 is true by definition. > Such a feature may not be *strictly* needed to accomplish a given task within a given language. However, it may very well still be needed in order to make said language actually worth switching to. I can get by with conditional jumps instead of if/else blocks (ex: Assembly, or old-school BASIC). And I even did for several years. But I sure as hell won't anymore if I don't have to. I, and many other people, find metaprogramming to be similarly "One you try it, you don't want to leave it". Not only does Go not have metaprogramming, but it doesn't even have the limited form of metaprogramming, generics, that's already common in many other languages. Therefore, the onus is on Go (or any other language that lacks generics), to show that there's something about the langauge that makes that sacrifice either worthwhile or at least somehow irrelevent.
Re: Rust and D
1. all features are equally valuable 2. if one can get by without a feature, then that feature is not needed Both of those are invalid. I'm not making claim 1, and claim 2 is true by definition. Brainfuck has all the needed language features by that definition.
Re: I have a feature request: "Named enum scope inference"
Although it's not very obvious what is a "hot-spot" and what is
not.
enum Char { a, b, c, d }
Char a = c; // OK: 'c' is in a "hot-spot"
Char b = c + 1; // ERROR: 'c' is undefined, because it's not in
// a "hot-spot" and therefore Char enumerations
// aren't visible. The expression c + 1 is
// expected to return Char but there's no reason
// to expect the arguments of that expression to
// be of type Char. (Another error would be that
// c + 1 doesn't even return Char, but we never
// get that far because the name lookup fails)
int c = 42;
void test(Char ch) {}
void test(int val) {}
void main()
{
test(c); // OK: calls test(.c) because arg 'c' is not in a
// "hot-spot". Function 'test' isn't expecting a
// Char variable as an argument, it's expecting a
// type chosen from set of types (among which Char
// just so happens to be). But, if you remove the
// test(int) specialization, this function call
// fails, and the one on the next line succeeds.
test(d); // ERROR: 'd' is undefined, because it's not in a
// "hot-spot" for the reason specified above, and
// therefore enumerations of Char are not brought
// into the module scope.
}
It is quite a mess. I think I'm ready to admit that this is not a
feature we'd like to have in this language (probably not in any
language for that matter).
Re: I have a feature request: "Named enum scope inference"
On Saturday, 29 September 2012 at 02:57:42 UTC, David Piepgrass
wrote:
I have a feature request: "Named enum scope inference"
The idea is, that whenever a named enum value is expected, you
don't need to explicitly specify the scope of the enum value.
This would reduce redundancy in typing, just like automatic
type inference does.
Examples:
-
enum MyDirection { forward, reverse }
struct MyIterator(MyDirection dir)
{
...
}
int forward = 42; // Doesn't interfere with the next line...
auto itr = MyIterator!forward(); // Infers MyDirection.forward
I like the spirit of this feature, but as Alex pointed out,
ambiguity is possible (which could theoretically cause errors
in existing code) and while I'm not familiar with how the
compiler is implemented, my spidey-sense thinks that what
you're asking for could be tricky to implement (in a language
that already has a very large amount of rules and features.)
Plus, I don't like the fact that when you see something like
"MyIterator!forward" by itself in code, there is no obvious
clue that forward is an enum value and not a class name or a
variable. So there is a sort of decrease in clarity of the
entire language by increasing the total number of possible
meanings that an identifier can have.
So I think this feature would need a more clear syntax,
something to indicate that the value is an enum value. I don't
currently have a really good counterproposal though
+1
Re: I have a feature request: "Named enum scope inference"
On Saturday, 29 September 2012 at 23:49:47 UTC, Tommi wrote: It is quite a mess. I think I'm ready to admit that this is not a feature we'd like to have in this language (probably not in any language for that matter). Using "with" should do the trick just fine for the few situations where there's too much redundant typing. I think adding new features needs to take a distant back seat to the far FAR more important issues in need of repair. For example, I cannot run D reliably from C/C++, yet that is one of the advertised features that compelled me to seriously consider D as a viable alternative to C/C++. What about dynamic linking? Nope, not yet. This is basic stuff! Should anyone really care about reducing the amount of typing you have to do when they can barely even use the language as it currently stands? There are however seemingly trivial items that probably should be added to D, but not as a convenience, instead to make it truely practical in a production environment. Now having said the above, the last thing D should become is stagnant for sake of preserving backwards compatibility. D2 is not D1, and D3 should not have to be D2. Personally, I'm in favor of the idea of breaking existing code so that past mistakes can be repaired and significant improvements can be implemented, but that should mean moving on to the next major version. --rt
Re: Getting started with D - Phobos documentation sucks
On Saturday, 29 September 2012 at 17:20:48 UTC, Dmitry Olshansky wrote: Agreed. What's needed to make it a reality ? Need to integrate my helper program into the website build process. Program here: http://arsdnet.net/d-web-site/improveddoc.d libs needed https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff dom.d and characterencodings.d When I tried this earlier, I couldn't even get the basic website to build on my box from github. I think it needs github phobos too but meh, I moved on to something else and never got back to it. But if the website makefile built and ran that program across the html it generates, it should be set.
Re: Getting started with D - Phobos documentation sucks
On Sunday, September 30, 2012 04:17:59 Adam D. Ruppe wrote: > When I tried this earlier, I couldn't even get the basic website > to build on my box from github. I think it needs github phobos > too but meh, I moved on to something else and never got back to > it. Unless something's changed recently, to build the website docs, you need both druntime and Phobos to be the latest from github (just like d-programming- language.org) and to have them all in the same directory. Otherwise, it doesn't work. And personally, I'm always having to change the makefile so that it doesn't try and build previous versions of Phobos or it doesn't work. It's far too dependent on having a very specific setup on your box and probably should be fixed as part of the initiatize to better automize the release process. It's far too fragile as it is. - Jonathan M Davis
Re: Rust and D
Go looks like a horrible combination of C and Lua, lacking the speed of C and the power of Lua(and I'd bet LuaJIT beats Go for performance). Not all features are equal, for me, meta programming is such a useful thing that a language better have something damn impressive to replace it(especially a systems programming language). I scanned through the Rust docs and did not see anything that appeared capable of doing so.
Re: Rust and D
Looking at Rust's concurrency model, it does have some great ideas. I wonder what would happen if D used thread-local heaps... As far as syntax goes, the "shared" keyword could be used to distinguish between the heap types. I'm not sure how all this would work with "new", but I'm sure someone can think of a clean syntax. In all, it's an intriguing idea, and it could fit with D's current concurrency model extremely well. I can definitely see this breaking code, but not much more than the switch to TLS globals did. It might be something to consider eventually.
Re: dynamic library building and loading
On Saturday, 29 September 2012 at 16:09:14 UTC, Jacob Carlborg wrote: There's no point in doing that. But what I'm saying is if you know beforehand the libraries you will use you can get quite far with static libraries. There are plenty of cases where you have to use a dynamically loaded lib even if you know before hand what will be loaded. I think you understand this if I read your posts correctly. In my case I have a pre-existing C++ app that is designed to load user defined C++ plugins. I wanted to interface D to one of my own C++ plugins, but I apparently cannot do it reliably because of initialization issues with the GC and possibly some other obscure items. If I can figure out what needs to be done to resolve the problem in enough detail, then maybe I can hack the runtime source and roll out a solution. The GC always seems to pop up as a source of problems. For long term solution, the GC should be made 100% optional (in practice as opposed to in theory), the standard library ought to be made to work with or wothout a GC (or simply without), and the GC itself should be easily replaceable with alternate versions. I think this idea has already been discussed elsewhere, and is on the TODO list (I hope!). --rt
