Bill Baxter wrote:
> BCS wrote:
> 
>> Jarrett Billingsley wrote:
>>
>>
>> If I'm reading it right this does that, and nicely:
> 
> 
> Uh... no.  Sort of does it, yes.  Nicely? no.

Ok, maybe I overstated my case: It does it without making me want to puke.

> 
> And should at least allow bar to be implemented like:
> 
> SetT!(int,int) bar(int i, int j)
> {
>    return SetT(i,j);
> }
> 

I tried that by using static opCall but you can't overload both static and non static opCall. I assume that if you could than a little implicit instancing would get rid of the rest. If you use a class it might look better, sort of. But then you get an alloc.

Bill Baxter wrote:
>    http://steve.yegge.googlepages.com/scheming-is-believing

Interesting (but long!) article.  Thanks for posting it.

> But I didn't succeed in finding out who Mr. Yegge is other than a guy with a blog who knows how to program.  Is he famous for something besides his blog?

I didn't know who he was either, but some googling found this page:

http://steve-yegge.blogspot.com/2006/07/get-famous-by-not-programming.html

He describes himself as being famous for being a "loudmouth" blogger. He's worked at Amazon and now works at Google, so I guess that gives him a leg-up in the loudmouth blog arena :)

-Jeff

"BCS" <BCS@pathlink.com> wrote in message news:eqq7nq$2tut$1@digitalmars.com...

> Half?, more like one or two hard misses and a few more close calls.

Well let's see:

 1. Object-literal syntax for arrays and hashes

Arrays?  Yes.  Hashes?  no.

 2. Array slicing and other intelligent collection operators

Yes.

 3. Perl 5 compatible regular expression literals

No.  It did in a way at one point, but no one liked that.

 4. Destructuring bind (e.g. x, y = returnTwoValues())

No.

 5. Function literals and first-class, non-broken closures

Function literals, yes; non-broken closures, no.  How many posts have we had in the past month that had to do with people returning nested functions?  :S

 6. Standard OOP with classes, instances, interfaces, polymorphism, etc.

Yes.

 7. Visibility quantifiers (public/private/protected)

Yes.

 8. Iterators and generators

Not in the way I think he means.  There's opApply, but..

 9. List comprehensions

No.

10. Namespaces and packages

Package namespaces... yes.  ;)

11. Cross-platform GUI

No!

12. Operator overloading

Yes.

13. Keyword and rest parameters

No, but what does he mean by "rest"?  Vararg?  That's a yes, but..

14. First-class parser and AST support

If he means "code modifying other code" then no, certainly not first-class.

15. Static typing and duck typing

Yes.  (Unless some duck typing expert wants to correct me, I _think_ D has it)

16. Type expressions and statically checkable semantics

I won't lie, I don't know what this means.  But it doesn't sound like D has them since I've never heard of them.

17. Solid string and collection libraries

_Libraries_?  Noooo.

18. Strings and streams act like collections

Yes, if by "collection" you mean "you can iterate over them."


So counting the ones that are partially yes as 0.5, and the yeses as 1.0, I get 9.  9/18 = 0.5

"Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message news:eqr5o5$16us$1@digitalmars.com...
> "BCS" <BCS@pathlink.com> wrote in message news:eqq7nq$2tut$1@digitalmars.com...
>
>> Half?, more like one or two hard misses and a few more close calls.
>
> Well let's see:

And I just wanted to add that this is considering _language features_, not things that can be done with libraries (excluding those points which explicitly mention libraries).  So yes, you can do Perl-like regexps, multiple return values, iterators, generators, and list comprehensions with libraries.   I think it's awesome that D can pretty much provide these without much trouble, but these are not language features.

Reply to Jarrett,

> "BCS" <BCS@pathlink.com> wrote in message
> news:eqq7nq$2tut$1@digitalmars.com...
> 
>> Half?, more like one or two hard misses and a few more close calls.
>> 
> Well let's see:
> 
> 1. Object-literal syntax for arrays and hashes
> 
> Arrays?  Yes.  Hashes?  no.
> 

Hashes can be done +(1 + .5)/2

> 2. Array slicing and other intelligent collection operators
> 
> Yes.

+1

> 
> 3. Perl 5 compatible regular expression literals
> 
> No.  It did in a way at one point, but no one liked that.
> 

Regex is there but not as a native type. IIRC however these is a project to do compile time regex compilation.

+.5

> 4. Destructuring bind (e.g. x, y = returnTwoValues())
> 
> No.

Not as part of the language but, again it can be done:

Slightly better syntax than before:

struct SetT(V...)
{
 V args_m;
 void opCall(inout V args)
 {
   foreach (i, arg; args_m) args[i] = arg;
 }
}

SetT!(V) Set(V...)(V args)
{
 SetT!(V) ret;
 foreach (i, arg; args) ret.args_m[i] = arg;  return ret;
}

SetT!(int,int) bar(int i, int j){ return Set(i,j); }

void main()
{
 int i=1,j=2,k=0,l=0;
 bar(i,j)(k,l);
 writef("[k,l]=[%d,%d]\n", k,l);
}

+.5

> 
> 5. Function literals and first-class, non-broken closures
> 
> Function literals, yes; non-broken closures, no.  How many posts have
> we had in the past month that had to do with people returning nested
> functions?  :S
> 

that's broken usage, not a broken feature, they work if you do them right, just as pointers do.

+1

> 6. Standard OOP with classes, instances, interfaces, polymorphism,
> etc.
> 
> Yes.
> 

+1

> 7. Visibility quantifiers (public/private/protected)
> 
> Yes.
>

+1

> 8. Iterators and generators
> 
> Not in the way I think he means.  There's opApply, but..
> 

foreach will take delegate, and with only a little work the delegate can carry context from one foreach to the next

auto it = WalkList("hello world");

foreach(char c; it)
 if(c == ' ')
   break;
 else
   writef(c);

writef(\n);

foreach(char c; it)
 writef(c);

other options include:

Nested iteration

foreach(rec; DB.WithName("bob").ageOver(65).Male.iter)

Joined iteration of AA's

int[char[]] foo, bar;
foreach(char[] k, int v; Inter(foo, bar))

I could be wrong but I don't see what that doesn't cover.

+1

> 9. List comprehensions
> 
> No.

Ok, I'll bite, What is it?

+??

> 
> 10. Namespaces and packages
> 
> Package namespaces... yes.  ;)
> 

+1

> 11. Cross-platform GUI
> 
> No!
> 

Hard miss.

+0

> 12. Operator overloading
> 
> Yes.

+1

> 
> 13. Keyword and rest parameters
> 
> No, but what does he mean by "rest"?  Vararg?  That's a yes, but..
> 

I'm not sure what this is
+??


> 14. First-class parser and AST support
> 
> If he means "code modifying other code" then no, certainly not
> first-class.
> 

Hard miss. Unless you count mixin or template code

+0

> 15. Static typing and duck typing
> 
> Yes.  (Unless some duck typing expert wants to correct me, I _think_ D
> has it)

+1

> 
> 16. Type expressions and statically checkable semantics
> 
> I won't lie, I don't know what this means.  But it doesn't sound like
> D has them since I've never heard of them.
> 

I'd count template's that construct types under this, as well as the ability to statically check operator restrictions

somewhere Oskar Linde has a Unit checking template that at compile time checks for errors like adding meters to Newtons

+1

> 17. Solid string and collection libraries
> 
> _Libraries_?  Noooo.
> 

We don't need them, D's AA's and dynamic arrays cover most of it and IIRC there are about a dozen libs for playing with them when you need more, clean them up a little and you've got it.

+1

> 18. Strings and streams act like collections
> 
> Yes, if by "collection" you mean "you can iterate over them."
> 

+1

> So counting the ones that are partially yes as 0.5, and the yeses as
> 1.0, I get 9.  9/18 = 0.5
> 

I get 12.75 of 18 with only 2 hard misses and two that I don't known what they are.

However that's just my counting, based on my assumptions:

breakable features count [see #5] (everything is breakable if you try hard enough)
available with libs gets part credit [#1, 3, 4]
a feature is as good as a lib [#17]

Reply to Jarrett,

> "Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message
> news:eqr5o5$16us$1@digitalmars.com...
> 
>> "BCS" <BCS@pathlink.com> wrote in message
>> news:eqq7nq$2tut$1@digitalmars.com...
>> 
>>> Half?, more like one or two hard misses and a few more close calls.
>>> 
>> Well let's see:
>> 
> And I just wanted to add that this is considering _language features_,
> not things that can be done with libraries (excluding those points
> which explicitly mention libraries).  So yes, you can do Perl-like
> regexps, multiple return values, iterators, generators, and list
> comprehensions with libraries.   I think it's awesome that D can
> pretty much provide these without much trouble, but these are not
> language features.
> 

To pick at a few:
Does any language do interators for user type as language features? You have to write them your self in every language I know of. In D, all the types you can get without a lib can be iterated over without a lib.

And I'll admit that the mult return is a bit of a stretch.

But *I* don't care if things come from a lib or from a feature, just how well they get the job done. And I would never use a language that doesn't need libs. It would be WAY to big.

But that's all just my opinion. Really my point is that for the most part D, in one form or another, has most of the things mentioned .

Reply to Bill,

> And should at least allow bar to be implemented like:
> 
> SetT!(int,int) bar(int i, int j)
> {
> return SetT(i,j);
> }

struct SetT(V...)
{

V args_m;

void opCall(inout V args)
{
foreach (i, arg; args_m) args[i] = arg;
}

}

SetT!(V) Set(V...)(V args)
{
SetT!(V) ret;
foreach (i, arg; args) ret.args_m[i] = arg; return ret;
}


SetT!(int,int) bar(int i, int j)
{
return Set(i,j);
}

It still has that odd left to right assignment.

"BCS" <ao@pathlink.com> wrote in message news:ce0a334373a38c91d108e764264@news.digitalmars.com...
>>
>> 5. Function literals and first-class, non-broken closures
>>
>
> that's broken usage, not a broken feature, they work if you do them right, just as pointers do.

I'd consider the current incarnation of closures "broken."  Are they useful as they are now?  Hell yes.  But can you do everything with them that you can in languages that have true closures?  No.  Functions are *almost* first class types in D ;)  Being able to return closures without having to manually create the context would be.. amazing.

>> 9. List comprehensions
>
> Ok, I'll bite, What is it?

Basically it's a way of really easily applying functions and such over a list.  They're kind of like array operations (a[] = b[] + c[]), which D doesn't have yet, but more flexible.  You can do stuff like (using very python-like syntax):

int[] numbers = [1, 2, 3, 4, 5, 6, 7, 8];

// This loops through numbers, seeing if the condition holds true,
// and if it does, adds it to a new list, which is eventually assigned
// to evens.
int[] evens = [x for x in numbers if !(x & 1)];

// Square the list
int[] squares = [x * x for x in numbers];

>> 13. Keyword and rest parameters
>
> I'm not sure what this is

Keyword parameters are another thing found in python.  They allow you to call functions with named parameters:

foo(x = 5, y = 10);

In python, the keyword parameters are interpreted as a hashtable, but since D is statically typed, it could probably just map the parameters right to the parameters defined in the function.  I'd really like to see this.

>> 16. Type expressions and statically checkable semantics
>
> I'd count template's that construct types under this, as well as the ability to statically check operator restrictions
>
> somewhere Oskar Linde has a Unit checking template that at compile time checks for errors like adding meters to Newtons

Oh, alright then.  That's cool.

>> 17. Solid string and collection libraries
>>
>> _Libraries_?  Noooo.
>>
>
> We don't need them, D's AA's and dynamic arrays cover most of it and IIRC there are about a dozen libs for playing with them when you need more, clean them up a little and you've got it.

I'll agree with you mostly for collections (I haven't missed STL a bit), but std.string is kind of an embarassment.  It only really has support for char[] (major shortfall in a language that supposedly handles UTF-16 and UTF-32) and doesn't provide any in-place functions (which would be great when you're writing a program that doesn't want to make any heap allocations).

"BCS" <ao@pathlink.com> wrote in message news:ce0a334373d08c91d138f82c904@news.digitalmars.com...
> To pick at a few:
> Does any language do interators for user type as language features? You
> have to write them your self in every language I know of.

...well if you don't write the iterator for your user type, how is the language going to know how to iterate over it?  When Steve said "iterators and generators" as a 'thing to have', I think he meant that they are first-class primitives in the language.  Having to write a custom iterator for a class wouldn't change that fact.

> But *I* don't care if things come from a lib or from a feature, just how well they get the job done.

I don't either.  But then you have languages like C++, where you are practically crippled without a library.  It's nice to have a basic set of powerful functionality without having to resort to the standard library to do the most common tasks.  D does that very well right now, but that doesn't mean it's perfect.

Jarrett Billingsley schrieb am 2007-02-13:
> "BCS" <BCS@pathlink.com> wrote in message news:eqq7nq$2tut$1@digitalmars.com...
>
>> Half?, more like one or two hard misses and a few more close calls.
>
> Well let's see:

[snip]

> 15. Static typing and duck typing
>
> Yes.  (Unless some duck typing expert wants to correct me, I _think_ D has it)

Shouldn't the code below be legal if D supported duck typing?
#
# class Cat{
#    void grow(){}
# }
#
# class Tree{
#    void grow(){}
# }
#
# void main(){
#    Tree t = new Cat();
#    t.grow();
# }

Thomas