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