www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Feature request: one-statement functions without brackets

reply Downs <default_357-line yahoo.de> writes:
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
Apr 02 2007
next sibling parent reply Lionello Lunesu <lio lunesu.remove.com> writes:
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.
Apr 02 2007
parent mike <vertex gmx.at> writes:
Am 02.04.2007, 11:29 Uhr, schrieb Lionello Lunesu <lio lunesu.remove.com=
:
 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. le=
t =
 { } be used for grouping statements. Nice.

 L.
Nice indeed. -- = Erstellt mit Operas revolution=E4rem E-Mail-Modul: http://www.opera.com/= mail/
Apr 03 2007
prev sibling next sibling parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
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...
Apr 02 2007
parent reply Downs <default_357-line yahoo.de> writes:
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
Apr 02 2007
parent Downs <default_357-line yahoo.de> writes:
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.
Apr 02 2007
prev sibling next sibling parent reply eao197 <eao197 intervale.ru> writes:
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
Apr 02 2007
parent reply =?UTF-8?B?SmFyaS1NYXR0aSBNw6RrZWzDpA==?= <jmjmak utu.fi.invalid> writes:
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" 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" 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?
Apr 02 2007
next sibling parent reply "David B. Held" <dheld codelogicconsulting.com> writes:
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
Apr 02 2007
next sibling parent reply =?UTF-8?B?SmFyaS1NYXR0aSBNw6RrZWzDpA==?= <jmjmak utu.fi.invalid> writes:
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.
Apr 03 2007
parent "David B. Held" <dheld codelogicconsulting.com> writes:
Jari-Matti Mäkelä wrote:
 [...]
 Sorry, I was not trying to disparage Walter's or Don's work. Sorry if I
 sounded like that.
 [...]
I didn't take your post that way at all. I was just making a point. Dave
Apr 03 2007
prev sibling parent =?UTF-8?B?SmFyaS1NYXR0aSBNw6RrZWzDpA==?= <jmjmak utu.fi.invalid> writes:
David B. Held wrote:
 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.
I think you are underestimating the importance of language constructs with sound mathematical backing.
 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.
The languages I listed in the previous post have a strong community real world applications. In addition, they are very similar to D or what D seems to be becoming. The fact that most of them run on top of a VM doesn't make them inferior as a language.
 Unfortunately, there is not enough science to design a language from
 start to finish with every feature you might want to add.
 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.
Learning from practical problems is just one way to see things. I know Walter has been in contact with the C++ world, but D has also embraced the functional paradigm quite much. Knowledge of functional languages has existed for over 50 years. I'm sure they have made practical points too, not only academic daydreaming.
Apr 03 2007
prev sibling parent reply eao197 <eao197 intervale.ru> writes:
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 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
Apr 02 2007
parent Georg Wrede <georg nospam.org> writes:
eao197 wrote:
 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).
Well, you might want to give it a try. It shouldn't bee all too hard to write a "D++ to D" filter, that simply adds semicolons at the end of every line, except for a few situations, which could be found out using regular (probably multi-line) expressions. This first try at it would of course be limited, as taking care of every situation might be more work, but the result could already be informative. Quite another thing is, the semicolons bring redundancy to the code that _humans_ need more than the compiler. Readability, clarity of meaning, and the possbility to split an expression to several lines, they all bring time savings when reading and understanding the code at a glance. Also many people have to use C, C++ or Java, and the semicolon behaving in a familiar way does reduce the mental burden of switching between these languages. All that outweighs the drag of one more key press on most of the lines. Besides, the actual "time savings" when writing code aren't all that massive. For example object.d (my version is DMD 0.163, and I admit this is an arbitrary file, ;-) but still) contains 620 lines, and only 193 of them contain a semicolon. That's less than a third.
Apr 03 2007
prev sibling parent Dan <murpsoft hotmail.com> writes:
I most definitely am not *for* semicolon removal/insertion.  I've been working
on the JavaScript Engine, and I've used JavaScript for a long time.  I can tell
you that *sometimes* implementing it is worse than always doing so.  You become

them if you automatically type them in all the time like I do.

I *am* for allowing the removal of {} for for/function when there's only one
statement.

I *am* for expression jacking some things.  Yes, a switch expression is more
complicated than a statement.  It has been done before though, and it's not
that much worse.  Also, it gets handled by the compiler and won't affect
switches that aren't expressions.

Internally, and I'm writing this terribly sub-optimally, you're saying:

// let EDX = x, AL = table offset, ECX = instruction*;

mov ECX, AL[$]; // load up the jump table
and ECX, 0x12; // sanity mask
jmp [ECX]; // jump into the jump table
mov EDX, 4; // x = switch(y){ case 3: 4; case 5: 1; case ... case ...}
jmp _out;
mov EDX, 1;
jmp _out;
...

So you're just assigning things to a variable, and passing that variable out. 
Syntactic sugar for:

switch(y){
  case 3:  x = 4;
  case 5: x = 1;
 ..
}

Which can sort of be optimized to do some cool stuff later, and theoretically
you could use EFLAGS in interesting ways throughout.
Apr 03 2007