Feature request: Allow functions of the form function-declaration statement;
Example: int test() return 5;

This would make the function syntax closer to the way if/else, while, for and similar
statements' blocks are handled now, potentially making parsing easier. It would
also help with internal consistency.
Also, it would allow methods like void test() synchronized(this) { }, which to me just
looks cleaner than using brackets to contain a single statement.
I couldn't immediately imagine a case where this syntax might lead to an ambiguity; if
there is, I'm sorry.

 -- awaiting feedback, downs

Downs wrote:
> Feature request: Allow functions of the form function-declaration statement;
> Example: int test() return 5;
> 
> This would make the function syntax closer to the way if/else, while, for and similar
> statements' blocks are handled now, potentially making parsing easier. It would
> also help with internal consistency.
> Also, it would allow methods like void test() synchronized(this) { }, which to me just
> looks cleaner than using brackets to contain a single statement.

I never thought of this, or needed this, but it makes sense though. let { } be used for grouping statements. Nice.

L.

Downs wrote:
> Feature request: Allow functions of the form function-declaration statement;
> Example: int test() return 5;
> 
> This would make the function syntax closer to the way if/else, while, for and similar
> statements' blocks are handled now, potentially making parsing easier. It would
> also help with internal consistency.
> Also, it would allow methods like void test() synchronized(this) { }, which to me just
> looks cleaner than using brackets to contain a single statement.
> I couldn't immediately imagine a case where this syntax might lead to an ambiguity; if
> there is, I'm sorry.
> 
>  -- awaiting feedback, downs

Ambiguity:
---
void foo()(T);
---
No-implementation declaration of a no-template-argument template function that takes a T, or no-argument function that evaluates "T"?

Of course, the practical use of a no-implementation template function declaration may be limited enough (is there any at all?) that banning it may not be much of a problem...

Frits van Bommel wrote:
> Downs wrote:
>> Feature request: Allow functions of the form function-declaration statement;
>> Example: int test() return 5;
>>
>> This would make the function syntax closer to the way if/else, while, for and similar
>> statements' blocks are handled now, potentially making parsing easier. It would
>> also help with internal consistency.
>> Also, it would allow methods like void test() synchronized(this) { }, which to me just
>> looks cleaner than using brackets to contain a single statement.
>> I couldn't immediately imagine a case where this syntax might lead to an ambiguity; if
>> there is, I'm sorry.
>>
>>  -- awaiting feedback, downs
> 
> Ambiguity:
> ---
> void foo()(T);
> ---
> No-implementation declaration of a no-template-argument template function that takes a T, or no-argument function that evaluates "T"?
> 
> Of course, the practical use of a no-implementation template function declaration may be limited enough (is there any at all?) that banning it may not be much of a problem...
Forgive my ignorance, but I don't get what you mean by "no-argument function
that evaluates T." Wouldn't that be foo()(T)? (without the void)
 -- slightly confused, downs

Downs wrote:
> Frits van Bommel wrote:
>> Downs wrote:
>>> Feature request: Allow functions of the form function-declaration statement;
>>> Example: int test() return 5;
>>>
>>> This would make the function syntax closer to the way if/else, while, for and similar
>>> statements' blocks are handled now, potentially making parsing easier. It would
>>> also help with internal consistency.
>>> Also, it would allow methods like void test() synchronized(this) { }, which to me just
>>> looks cleaner than using brackets to contain a single statement.
>>> I couldn't immediately imagine a case where this syntax might lead to an ambiguity; if
>>> there is, I'm sorry.
>>>
>>>  -- awaiting feedback, downs
>>
>> Ambiguity:
>> ---
>> void foo()(T);
>> ---
>> No-implementation declaration of a no-template-argument template function that takes a T, or no-argument function that evaluates "T"?
>>
>> Of course, the practical use of a no-implementation template function declaration may be limited enough (is there any at all?) that banning it may not be much of a problem...
> Forgive my ignorance, but I don't get what you mean by "no-argument function
> that evaluates T." Wouldn't that be foo()(T)? (without the void)
>  -- slightly confused, downs
Nevermind, got it. Sorry. Agreed.

On Mon, 02 Apr 2007 14:25:27 +0400, Downs <default_357-line@yahoo.de> wrote:

> Feature request: Allow functions of the form function-declaration statement;
> Example: int test() return 5;
>
> This would make the function syntax closer to the way if/else, while, for and similar
> statements' blocks are handled now, potentially making parsing easier.

An interesting example of language syntax simplification can be seen from Scala language (http://www.scala-lang.org). In version 1.* Scala used semicolons as an expression terminator. That restruction had been removed in version 2.*. There is a quote from document 'Changes between Scala Version 1.0 and 2.0' (unfortunately this document is not available from Scala site now):

<quote>
2 Newlines as Statement Separators

Newlines can now be used as statement separators in place of semicolons. A newline is significant as a statement separator if the following three conditions are fulfilled:

1. The token immediately preceding the newline can terminate a statement.
2. The token immediately following the newline can begin a statement.
3. The token appears in a region where multiple statements are allowed.

Multiple statements are allowed for the program as a whole and between { ... } braces; they are disallowed between (...) parentheses and between [...] brackets.

For instance, a semicolon is now no longer necessary after the println call in the function below:

def square(x: int) = {
  println("square called")
  x * x
}

This new convention makes some previously allowed multi-line expressions illegal. An example is:

def inAllowedRange(x: int) =
  x >= loBound && // newline significant here!
  x <= hiBound

In these cases it suffices to enclose themulti-line expression in parentheses to suppress the generation of a newline token:

def inAllowedRange(x: int) = (
  x >= loBound && // no newline is inserted
  x <= hiBound
)
</quote>

This improvement has made Scala a very short-spoken language. In conjunction with other things (like: every expression has a value, type inference and optional {} in function body definition) Scala programs have less syntax noise than in С++/D or Java. For example, simple getter method can be written in Scala as:

def getX = x // return type is infered from expression 'x'.

IMHO, it will be great if D allows semicolons and 'return' keyword skipping. Like this:

int getX() { x }

instead of

int getX() { return x; }

-- 
Regards,
Yauheni Akhotnikau

eao197 wrote:
> An interesting example of language syntax simplification can be seen from Scala language (http://www.scala-lang.org).

I've recently read about Scala. It's a very promising language. Maybe a bit slow currently, but I've read they are working on it.

> This improvement has made Scala a very short-spoken language. In conjunction with other things (like: every expression has a value, type inference and optional {} in function body definition) Scala programs have less syntax noise than in С++/D or Java.

It has been interesting to observe the evolution of D. It seems that today many languages are evolving to the same direction. I've heard even Visual Basic is starting to implement ideas from the "higher level" languages. C# 3.0 incorporates features found in functional languages. Recently also D has got high level features that really boost the expressiveness. Scala has gained much interest in the academic world and is making big leaps in expressiveness (thanks to pattern matching, traits, being fully object oriented, doing multiple inheritance "right" etc.). And then there are Ocaml, F#, Spec#, Haskell and others. As far as I see it, this causes a lot of competition. :)

Now, after the AST macros and the new type system have be implemented, I think D will be in a difficult situation. Should it follow the route that results in implementing everything but kitchen sink while keeping the syntax similar to C/C++/Java or should it evolve into a relatively simple, powerful and orthogonal core language that allows implementing all higher level constructs without cluttering the common core. Of course this is not just black and white.

It's a shame that the academic world hasn't really put interest in D. It has a lot of potential while still remaining practical and useful for real world applications. I think there is unorthogonality in D that could be resolved much better with the help of academic expertise.

I personally would like to see the gap between static (compile time) and dynamic (runtime) worlds closing. There are so many similarities between templates and ordinary functions & lambdas. Also type inference could be more general. Of course I understand Walter has only limited time and everyone has their favorite feature request, but these things look important to me ATM. It just seems that there's no clear roadmap and the language is just wandering blindfolded there somewhere. What do you think?

Jari-Matti Mäkelä wrote:
> [...]
> I personally would like to see the gap between static (compile time) and
> dynamic (runtime) worlds closing. There are so many similarities between
> templates and ordinary functions & lambdas. Also type inference could be
> more general. Of course I understand Walter has only limited time and
> everyone has their favorite feature request, but these things look
> important to me ATM.

I assure you that you are not the only person who feels that way. ;)

> It just seems that there's no clear roadmap and the
> language is just wandering blindfolded there somewhere. What do you think?

I think that the most important industrial language today is C++, which was created by an engineer trying to solve real world problems with real-world constraints.  On the other hand, there is no end to academically designed "pure" languages (I don't mean 'pure' in the technical sense, but rather the aesthetic one), but few to none of them are commercial/industrial/popular successes.  So while languages built around "religious principles" (everything is an Object, everything is message-passing, everything is a function, etc.) may be elegant, they are often not entirely practical.

Somewhere in between Haskell and C is a set of compromises that result in an elegant type system that recognizes that memory is not infinite and processors take real clock cycles to get things done.  While D does not necessarily position itself ideally within this space, I think it offers some compelling features in a unique combination that is fairly rare in many of the newer languages.

I think the idea of a roadmap is alluringly misleading.  It presumes that there is a best way to design a language, in the way that there might be a best way to design an operating system or a car.  At the end of the day, a programming language is a tool to solve problems. Sometimes those problems are nicely solved by a set of features that fit together like a jigsaw puzzle, and other times problems require a pocketknife and some elbow grease.  Being able to maintain that balance is, I think, the key to producing a language that possesses both beauty and utility.

Personally, I find Don Clugston's metaprograms to be fairly exquisite, because they demonstrate a simplicity and power that similar programs in other languages stuggle for.  Of course, Lisp can pretty much do anything that any other language can, within reason, but at the expense of syntax.  Don's programs still look like programs.  Haskell can be even more elegant and concise, but odds are, you will never be able to drop down into inline assembly and hack some SSE instructions into an inner loop to squeeze that last bit of performance out of your program.  The fact that Walter gives you a screwdriver and lets you get at the bare metal is not something to be taken lightly, but it does require some sacrifices in the language (you could never give the kind of security guarantees that Java can, for instance).  You can't eat your cake and have it too.

So, although the development of D may seem 'haphazard' at times, that is the nature of all great art.  If you saw Michaelangelo's 'David' when it was half-complete, it would probably look a little haphazard as well.
Unfortunately, there is not enough science to design a language from start to finish with every feature you might want to add.  So you have to build it up by pieces and hope that what comes out in the end is something that you enjoy using.  And if you really want D to become more refined and elegant, then code, code code.  There's nothing like real-world use cases to motivate making a potentially painful change to clean things up.  Walter is very open-minded about his language, but he's also very practical.  He's not going to waste his time implementing something that he doesn't think anybody will use.

The more you expose the rough edges of the language with practical programs, the more motivation will exist to recast those features in a more refined mold.  It also doesn't hurt to air your feature wish-lists, either.  I mean, there's no guarantee that anything will get implemented, but it's human nature to oil the squeaky wheels.  Squeak loud enough, and you might get your black gold...

And if you *really* want to see the language succeed, lend a helping hand.  If you haven't noticed, there isn't exactly a Sun or IBM or Microsoft throwing its weight behind D...yet.  Most people would agree that the success of Java had as much to do with its rich library set as anything else.  There's a bajillion different D libraries you could write, and each one has the potential to make D more attractive to other programmers.  Not only that, but the front-end is completely Open Source, so you can even experiment with your own feature ideas without even bugging Walter.  Finally, keep in mind that tools really leverage the productivity available with a language.  Helping out with toolchains is probably the single biggest help you could offer, and there are plenty of projects that could use the manpower (or womanpower, as the case may be).

Dave

On Tue, 03 Apr 2007 03:00:36 +0400, Jari-Matti Mäkelä <jmjmak@utu.fi.invalid> wrote:

> eao197 wrote:
>> An interesting example of language syntax simplification can be seen
>> from Scala language (http://www.scala-lang.org).
>
> I've recently read about Scala. It's a very promising language. Maybe a
> bit slow currently, but I've read they are working on it.

<offtopic>
From my expirience Scala isn't slow. It seems to be slow because of use of JVM, but real application speed highly depends from the task and algorithms. Scala has a quick compiler. Expecially in form of fsc /fast scala compile/ when part of compiler resides in memory all the time (in such case speed of fsc on my laptop is comparable with speed of DMD). And on some microbenchmarks Scala outperforms C++. For example in simple message outperforms beetwen threads Scala shows throughput ~800K m/s, and C++ with ACE only ~600K m/s. I think it is because of great GC from JVM 1.5.
</offtopic>

> I personally would like to see the gap between static (compile time) and
> dynamic (runtime) worlds closing. There are so many similarities between
> templates and ordinary functions & lambdas. Also type inference could be
> more general. Of course I understand Walter has only limited time and
> everyone has their favorite feature request, but these things look
> important to me ATM. It just seems that there's no clear roadmap and the
> language is just wandering blindfolded there somewhere. What do you think?

Excuse me, but I haven't any global ideas of the way D may come in the future.

Last 2.5 years I wrote a lot on Ruby, sometimes I wrote (and write now) on Ruby much more then on C++ (and I'm C++ programmer now). And I had deep look into Scala as a very interesting and highly portable language (because of JVM). And breif look into Nemerle. However I decided to stop my search for my next big language on D, because it is very easy to me as a C++ programmer and, imho, much more expresive than C++/Java/C#.

But when I need to switch from Ruby or Scala to C++ or D I have a high degree of discomfort: after Ruby/Scala expirience usage of semicolons is very annoying (and, sometimes this is true for 'return' statement).

I understand that transforming IfStatement/SwitchStatement from a statement to an expression may be very hard. And optional ReturnStatement may be very hard to implement too. It would be great, but if not it won't be a tragedy. But I hope that optional semicolons is much easier to implement. And such trifle can make D much more expressive (the Scala history shows this).

-- 
Regards,
Yauheni Akhotnikau

David B. Held wrote:

> Personally, I find Don Clugston's metaprograms to be fairly exquisite,
> because they demonstrate a simplicity and power that similar programs in
> other languages stuggle for.  Of course, Lisp can pretty much do
> anything that any other language can, within reason, but at the expense
> of syntax.  Don's programs still look like programs.  Haskell can be
> even more elegant and concise, but odds are, you will never be able to
> drop down into inline assembly and hack some SSE instructions into an
> inner loop to squeeze that last bit of performance out of your program.
>  The fact that Walter gives you a screwdriver and lets you get at the
> bare metal is not something to be taken lightly, but it does require
> some sacrifices in the language (you could never give the kind of
> security guarantees that Java can, for instance).  You can't eat your
> cake and have it too.

Sorry, I was not trying to disparage Walter's or Don's work. Sorry if I sounded like that.

> And if you *really* want to see the language succeed, lend a helping hand.  If you haven't noticed, there isn't exactly a Sun or IBM or Microsoft throwing its weight behind D...yet.  Most people would agree that the success of Java had as much to do with its rich library set as anything else.  There's a bajillion different D libraries you could write, and each one has the potential to make D more attractive to other programmers.  Not only that, but the front-end is completely Open Source, so you can even experiment with your own feature ideas without even bugging Walter.  Finally, keep in mind that tools really leverage the productivity available with a language.  Helping out with toolchains is probably the single biggest help you could offer, and there are plenty of projects that could use the manpower (or womanpower, as the case may be).

Yes, I know and agree.