Steve Yegge's rant on The Next Big Language

[Vassily Gavrilyak]

>Daniel Keep Wrote:
> See, the way I *think* DMD does it is that it goes from the inner-most
> expression out.  So at the very inner-most level, we've got the
> delegate.  It starts off by getting the type of the arguments, since we
> need to know these to make sense of the body.  All good.  We then have
> "return a>b".  Well, we know a and b, so the result of this is obviously
> a bool.  We go to check the return type and... it's missing.  Hmm, well,
> let's just fix it to bool.  Alright--delegate's done.
> 
> Now we come to the map call.  We're given an argument that's int[], so T
> is obviously int.  We're given a delegate of type bool
> delegate(int,int), so R is obviously bool.  Easy.
> 
> If we switch it around, it becomes messier: we need to do the type
> inference for the call to map BEFORE we work out what the type of the
> delegate is.  But we can't work out all the types, since we need to know
> the type of the delegate to get R.  So we end up with the types of map
> depending on the delegate, and the types on the delegate depending on
> map.  Where do you start?
> 
> The obvious answer to this is to make the whole AST lazily-evaluated,
> but I like Walter, and I think it's important for people to go outside
> once in a while :P
Nice explanation, thanks. That's the current state of features of D made me think 
that we almost there. 
We already have type inference almost everywhere but not in function arguments. 
It seems like one little step and we will have the full inference engine.
But it only "looks" so and the reality is probably classic 80/20 situation 
when the remaining 20% of features will take 80% of time. 
And it is probably better to just stick with 80%.


> I just wanted to point out that the syntax is wildly different from
> anything else in D.  The advantage of the current syntax, is that it
> *looks* like some kind of function... it's got the parenthesised
> argument list and the curly-brace body.
> 
> I see "=>" and immediately think of maps (er, the associative-array kind.)
PHP, Perl or Ruby? I think about maps when I see {hello:"world"} ;-)

Well, => is just one of possibilities for lambdas.

C# and Nemerle use it.
Haskell's  a -> a+a  almost the same.

C, C++ and Java don't have this at all, so we can't just still it from here.

Now Ruby and Smalltalk uses a| a+a. They are not from C family though.

Javascript will adopt  function(a) a+a, at least Brendan promised it here.
http://weblogs.mozillazine.org/roadmap/archives/2006/05/javascript_2_ecmascript_editio.html#comments 
This approach seems suitable for D too - no new keywords and also allows delegate(a) a+a and 
int(a,b) a+b
It's just looks a little long for me, but probably I'm the only one thinking so :-)


Taking some other syntax would be good too, but that's will be D's only syntax, foreign for 
for everybody. Probably it's better to mimic something people familiar with. 
> 
> Of course, the above syntax is also much shorter for single expressions.
> I know; I always preferred Nemerle, tho :P  You wanna talk about
> type-inference, go check that one out!

Of course I already checked it, and liked very much. I would use it, but have no place for it
in my projects. All my server and client side development is JS. 
And I choose D because for one task only because of native compilation and Linux support.
I need controlling hardware and my brains are so broken with JS that I practically can't
imagine to do something in C. 
If Nemerle could help me here then JS will too and I would choose JS :-)



> 
> > Actually they implemented comprehensions too, but with somewhat strange "SQL-like"
> > syntax. So my example with such syntax will look something like:
> > var res = FROM [1,2,3] AS x SELECT x+x WHERE x<2 ORDER BY x;
> > It's probably more readable but that's totally different language, no spirit of C here.
> 
> I think that they started developing LINQ because people wanted list
> comprehensions, but instead of taking their cues from Haskell or
> Python... they used SQL.  It's debatable as to whether that was a good
> idea or not; I'll just say that I prefer Haskell/Python style list
> comprehensions :)
Yes, I would prefer those too, but that's not so simple feature to get right and implement . 
JS already has it (Python way), and I still don't use it, it just seems foreign for me in C family. Also it is not very clear what should be used as collection types.
Python has lists and generators. JS has array and generators.
D has arrays, hashes and some kind of custom iterators (opApply). 
Should hashes be there?  Should iterators be there? What should be the result type for comprehension custom iterators?
E.g if comprehension will be allowed for arrays only - that will be too restrictive for me.
It's very complex issue.

> > To conclude - D needs parametrized lazy arguments and more aggressive type inference. 
> > It will cover most syntax sugar issues with array comprehensions and much more, 
> > because syntax will not be restricted.
> > Example I actually use often:
> > Given an array of people build an associative array with name as a key;
> > Person[char[]] peopleByName = people.hashBy((person)=>person.name);
> 
> With enough semantic analysis, I imagine you could get D to do anything.
>   I agree, it *would* be nice to have, and being able to write shorter
> lambda functions is always nice.  I wouldn't say it "needs" them,
> though: 
Well, that's probably my bad English :-)
I didn't mean that D needs it badly. Remember, we are discussing the array comprehensions.
And I said that probably they are NOT needed. We can have the same effect with little adoptions of current syntax and not big changes.

>I'd prefer to see more features that really honestly *can't* be
> done at the moment added (like compile-time function evaluation or
> better compile-time reflection) before incremental improvements like that.
Yes, me too, but I keep silent about 'hard' ones too. (well, closures is my top wanted feature).

> Anyway, that's just my opinion, for what that's worth :P
> I'll go now, I think I've started rambling again.

Well, you see, I agreed with you about type inference, it's complex and probably not needed.
Functions expressions (parametrized lazy's) seems like just syntax sugar that's already partially resolved with lazy expressions (only not parametrized). 

Done properly this will give one more feature in D's checklist that many other languages already have.
And also it will give some more consistense to current unparametrized 'lazy' expressions.
Probably even the keyword lazy can be deprecated at all, as unneccessary, delegates are good enough.
And removing some code is always nice :-)
> 
> 	-- Daniel
> 
> -- 
> Unlike Knuth, I have neither proven or tried the above; it may not even
> make sense.
> 
> v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D
> i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/

It was nice to talk with you, thanks

Vassily