www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Declaration syntax

reply "deed" <none none.none> writes:
 From time to time I find the declaration syntax slightly awkward. 
The main
reason is that the identifiers come after the types, making it 
harder to
identify names and get an overview of the code. This bothered me 
enough to
start playing with alternatives.

My two questions are:

1. Are there technical reasons not to do it this way, like 
grammar/ambiguity,
    parsing time, etc.?
2. Have others been thinking in same direction playing with 
converters
    or alternative front ends?

NB! This is by no means any suggestion to change D-syntax.

Modifications:

1. Swap type and name. Like Go, but return type between function 
name and
    parameter list.
2. Names come first, all other annotations after. ALWAYS. Example:

       private const(int)[] foo(const(int)[] all, int newNum, int 
sum) {}

    becomes

       foo const(int)[](all const(int)[], newNum int, sum int) 
private {}

    At this point the readability and overview would be improved 
IMO.

3. Separate parameter names from their types.

       foo(all, newNum, sum) const(int)[](const(int)[], int, int) 
private {}


A couple of examples from phobos follow below:

//========================================
// From std.container
//========================================
// Current syntax

struct Range
{
     private Node * _first;
     private Node * _last;
     private this(Node* first, Node* last);
     private this(Node* n);
      property bool empty() const nothrow;
      property T front();
     void popFront();
      property Range save();
      property T back();
     void popBack();
}


// Modified syntax

Range struct
{
     _first Node* private;
     _last Node* private;
     this(first, last) (Node*, Node*) private;
     this(n) (Node*) private;
     empty bool()  property const nothrow;
     front T()  property;
     popFront void();
     save Range()  property ;
     back T()  property;
     popBack void();
}

//========================================
// From std.datetime
//========================================
// Current syntax

abstract class TimeZone
{
public:
      property string name() const nothrow;
      property string stdName() const nothrow;
      property string dstName() const nothrow;
      property abstract bool hasDST() const nothrow;
     abstract bool dstInEffect(long stdTime) const nothrow;
     abstract long utcToTZ(long stdTime) const nothrow;
     abstract long tzToUTC(long adjTime) const nothrow;
     Duration utcOffsetAt(long stdTime) const nothrow;
     static immutable(TimeZone) getTimeZone(string name);
     static string[] getInstalledTZNames(string subName = "");
private:
     this(string name, string stdName, string dstName) immutable 
pure;
     immutable string _name;
     immutable string _stdName;
     immutable string _dstName;
}


// Modified syntax

TimeZone class abstract
{
public:
     name() string()  property const nothrow;
     stdName() string()  property const nothrow;
     dstName() string()  property const nothrow;
     hasDST() bool()  property const nothrow abstract;
     dstInEffect(stdTime) bool(long) abstract const nothrow;
     utcToTZ(stdTime) long(long) abstract const nothrow;
     tzToUTC(adjTime) long(long) abstract const nothrow;
     utcOffsetAt(stdTime) Duration(long)  const nothrow;
     getTimeZone(name) static immutable TimeZone(string);
     getInstalledTZNames(subName = "") static string[] (string);
private:
     this(name, stdName, dstName) (string, string, string) 
immutable pure;
     _name immutable string;
     _stdName immutable string;
     _dstName immutable string;
}

// Alternative layout:

TimeZone class abstract
{
   public:
     name()                  string()     property const nothrow;
     stdName()               string()     property const nothrow;
     dstName()               string()     property const nothrow;
     hasDST()                bool()       property const nothrow 
abstract;
     dstInEffect( stdTime )  bool(long)  abstract const nothrow;
     utcToTZ( stdTime )      long(long)  abstract const nothrow;
     tzToUTC( adjTime )      long(long)  abstract const nothrow;
     utcOffsetAt( stdTime )  Duration(long)  const nothrow;
     getTimeZone( name )     static immutable TimeZone(string);
     getInstalledTZNames( subName = "")
                             static string[](string);
   private:
     this(name, stdName, dstName) (string, string, string) 
immutable pure;
     _name    immutable string;
     _stdName immutable string;
     _dstName immutable string;
}

//========================================
// From std.getopt
//========================================
// Current syntax

private void getoptImpl(T...)(ref string[] args, ref 
configuration cfg, T opts);

void handleOption(R)(string option, R receiver, ref string[] args,
         ref configuration cfg, bool incremental);

private bool optMatch(string arg, string optPattern, ref string 
value,
     configuration cfg);


// Modified syntax

getoptImpl(args, cfg, opts) private
     (T...) void (ref string[], ref configuration, T);

handleOption(option, receiver, args, cfg, incremental)
     (R) void (string, R, ref string[], ref configuration, bool);

optMatch(arg, optPattern, value, cfg) private
     bool (string, string, ref string, configuration);
Jan 07 2014
next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 8 January 2014 at 00:23:34 UTC, deed wrote:
 1. Are there technical reasons not to do it this way, like 
 grammar/ambiguity, parsing time, etc.?

I can't think of any, it is pretty simple to parse either way.
 2. Have others been thinking in same direction playing with 
 converters or alternative front ends?

I know there was one to make D look more like python a while ago that was recently discussed again on the forum but I can't remember what it was called right now.
    At this point the readability and overview would be improved 
 IMO.

I don't agree; I find that backwards and weird. Comes down to what you're used to probably. Another option might be to put tabs in there so you write void foo() int bar() and so on so the names are vertically aligned.
Jan 07 2014
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Jan 08, 2014 at 12:35:18AM +0000, Adam D. Ruppe wrote:
 On Wednesday, 8 January 2014 at 00:23:34 UTC, deed wrote:

   At this point the readability and overview would be improved
IMO.

I don't agree; I find that backwards and weird. Comes down to what you're used to probably. Another option might be to put tabs in there so you write void foo() int bar() and so on so the names are vertically aligned.

If we're going to redo syntax, we might as well adopt a much less ambiguous (and prettier!) function declaration syntax based on mathematical notation (which is also adopted by some functional languages): funcName : type1 arg1, type2 arg2, ... -> returnType For example: pow : real base, real exponent -> real { // Variable declaration tmp1 : real; // Variable declaration with initializer result : real = dotDotDotMagic(base, exponent, tmp1); // Statement as usual return result; } T -- IBM = I'll Buy Microsoft!
Jan 07 2014
prev sibling next sibling parent "Kapps" <opantm2+spam gmail.com> writes:
On Wednesday, 8 January 2014 at 00:35:19 UTC, Adam D. Ruppe wrote:
 I know there was one to make D look more like python a while 
 ago that was recently discussed again on the forum but I can't 
 remember what it was called right now.

Delight http://delight.sourceforge.net/
Jan 07 2014
prev sibling next sibling parent "Ross Hays" <accounts rosshays.net> writes:
 	pow : real base, real exponent -> real
 	{
 		// Variable declaration
 		tmp1 : real;

 		// Variable declaration with initializer
 		result : real = dotDotDotMagic(base, exponent, tmp1);

 		// Statement as usual
 		return result;
 	}


 T

I generally prefer the C style declarations that we already have in D, but that syntax is pretty nice too...
Jan 07 2014
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Jan 08, 2014 at 02:10:04AM +0000, Ross Hays wrote:
	pow : real base, real exponent -> real
	{
		// Variable declaration
		tmp1 : real;

		// Variable declaration with initializer
		result : real = dotDotDotMagic(base, exponent, tmp1);

		// Statement as usual
		return result;
	}


T

I generally prefer the C style declarations that we already have in D, but that syntax is pretty nice too...

I like C style declarations too, but as someone said, it's a matter of what you're accustomed to. The above was just my idea of the what-if scenario where we redesign D syntax (I doubt it's ever going to happen, definitely not happening in D2, and probably won't be in D3 either, if we ever get to that point). T -- Customer support: the art of getting your clients to pay for your own incompetence.
Jan 07 2014
prev sibling next sibling parent "simendsjo" <simendsjo gmail.com> writes:
On Wednesday, 8 January 2014 at 00:35:19 UTC, Adam D. Ruppe wrote:
 On Wednesday, 8 January 2014 at 00:23:34 UTC, deed wrote:
 1. Are there technical reasons not to do it this way, like 
 grammar/ambiguity, parsing time, etc.?

I can't think of any, it is pretty simple to parse either way.
 2. Have others been thinking in same direction playing with 
 converters or alternative front ends?

I know there was one to make D look more like python a while ago that was recently discussed again on the forum but I can't remember what it was called right now.
   At this point the readability and overview would be improved 
 IMO.

I don't agree; I find that backwards and weird. Comes down to what you're used to probably. Another option might be to put tabs in there so you write void foo() int bar() and so on so the names are vertically aligned.

+1 - I use spaces though. The problem is that reading the code becomes difficult if you don't have nice formatting either way. The identifier is difficult to read, or the type is difficult to read. Formatting the code is the only way to make it easy to read. If you're a vim user, look at vim-easy-align: https://github.com/junegunn/vim-easy-align Other editors might have similar formatting rules.
Jan 07 2014
prev sibling next sibling parent "Robert Nagel" <rcnagel gmail.com> writes:
 I like C style declarations too, but as someone said, it's a 
 matter of
 what you're accustomed to. The above was just my idea of the 
 what-if
 scenario where we redesign D syntax (I doubt it's ever going to 
 happen,
 definitely not happening in D2, and probably won't be in D3 
 either, if
 we ever get to that point).


 T

Yes that would definitely be a somewhat major change. Probably more of a possible syntax for another language built I still like that function declaration syntax (a bit weird for variables IMO but not even remotely important).
Jan 07 2014
prev sibling next sibling parent reply "Boyd" <gaboonviper gmx.net> writes:
If you're out for easier code readability, then I'd recommend not 
to bother with syntax too much. It'll only get you a slight 
readability increase at most, and you'll piss off anyone who 
doesn't agree with you, or doesn't want to refactor his code.

I've been experimenting with language design a bit and I found 
that a much bigger issue with coding, is that we still use files 
and plain text. An IDE where code is represented in a simple tree 
and saved in a database, for example, would improve things 
dramatically, and no language changes would be necessary.
Jan 08 2014
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2014-01-08 09:47, Boyd wrote:

 I've been experimenting with language design a bit and I found that a
 much bigger issue with coding, is that we still use files and plain
 text. An IDE where code is represented in a simple tree and saved in a
 database, for example, would improve things dramatically, and no
 language changes would be necessary.

I don't think that's necessary. It's all about how the IDE presents the code. Currently in most text editors and IDE's the lowest unit of text editing is a file. There's nothing stopping an IDE from providing different units of text editing. There are already some editors that are doing this or experiment with it: * http://www.andrewbragdon.com/codebubbles_site.asp * http://www.lighttable.com/ There's also the usual IDE's, like Eclipse, Xcode, VisualStudio and NetBeans, that provides class browsers and similar. -- /Jacob Carlborg
Jan 08 2014
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2014-01-08 11:13, Boyd wrote:

 I agree that you wouldn't want code to be precisely constraint to what's
 syntactically correct. Function bodies in particular benefit quite a bit
 from just manually typing text. But a tree structure of all modules,
 classes, functions, properties, etc..., would go a long way.

There are IDE's already doing this, like Eclipse, Xcode, NetBeans and so on. -- /Jacob Carlborg
Jan 08 2014
prev sibling next sibling parent "Tobias Pankrath" <tobias pankrath.net> writes:
On Wednesday, 8 January 2014 at 08:47:23 UTC, Boyd wrote:
 If you're out for easier code readability, then I'd recommend 
 not to bother with syntax too much. It'll only get you a slight 
 readability increase at most, and you'll piss off anyone who 
 doesn't agree with you, or doesn't want to refactor his code.

 I've been experimenting with language design a bit and I found 
 that a much bigger issue with coding, is that we still use 
 files and plain text. An IDE where code is represented in a 
 simple tree and saved in a database, for example, would improve 
 things dramatically, and no language changes would be necessary.

It wouldn't. When I was working for a SAP consulting company, I wrote some parts of ABAP, which is stored in the database of the SAP system itself and only accessible via the build in "IDE". I would have killed for an decent IDE but there was no way to easy access the code directly. Programming text are nothing more than serialized tree data structures stored in a common format. Actually there was a EMACS plugin for "language-directed" coding, where the editor knew the code structure and you could only enter syntactically valid code. Like a "snippet plugin" on steroids. However the author of the plugin itself admitted that this was a wrong direction and is back to text editing.
Jan 08 2014
prev sibling next sibling parent "Boyd" <gaboonviper gmx.net> writes:
On Wednesday, 8 January 2014 at 09:46:23 UTC, Tobias Pankrath 
wrote:
 On Wednesday, 8 January 2014 at 08:47:23 UTC, Boyd wrote:
 If you're out for easier code readability, then I'd recommend 
 not to bother with syntax too much. It'll only get you a 
 slight readability increase at most, and you'll piss off 
 anyone who doesn't agree with you, or doesn't want to refactor 
 his code.

 I've been experimenting with language design a bit and I found 
 that a much bigger issue with coding, is that we still use 
 files and plain text. An IDE where code is represented in a 
 simple tree and saved in a database, for example, would 
 improve things dramatically, and no language changes would be 
 necessary.

It wouldn't. When I was working for a SAP consulting company, I wrote some parts of ABAP, which is stored in the database of the SAP system itself and only accessible via the build in "IDE". I would have killed for an decent IDE but there was no way to easy access the code directly. Programming text are nothing more than serialized tree data structures stored in a common format. Actually there was a EMACS plugin for "language-directed" coding, where the editor knew the code structure and you could only enter syntactically valid code. Like a "snippet plugin" on steroids. However the author of the plugin itself admitted that this was a wrong direction and is back to text editing.

I agree that you wouldn't want code to be precisely constraint to what's syntactically correct. Function bodies in particular benefit quite a bit from just manually typing text. But a tree structure of all modules, classes, functions, properties, etc..., would go a long way.
Jan 08 2014
prev sibling next sibling parent "Chris Cain" <clcain uncg.edu> writes:
On Wednesday, 8 January 2014 at 08:47:23 UTC, Boyd wrote:
 If you're out for easier code readability, then I'd recommend 
 not to bother with syntax too much. It'll only get you a slight 
 readability increase at most, and you'll piss off anyone who 
 doesn't agree with you, or doesn't want to refactor his code.

 I've been experimenting with language design a bit and I found 
 that a much bigger issue with coding, is that we still use 
 files and plain text. An IDE where code is represented in a 
 simple tree and saved in a database, for example, would improve 
 things dramatically, and no language changes would be necessary.

What you've described is almost exactly what I kind-of came up with on my own too. If I had time, I'd work on such a concept to see whether it actually works in practice, but I don't see any good reason why it wouldn't. The only issue is that it would require more of a time investment to get started (working on a compiler is hard enough... but requiring a custom IDE to go with it? Ouch). I've got a few more ideas but they're crazy enough that I wouldn't feel comfortable talking about them prior to actually testing the ideas out to see if it works well.
Jan 08 2014
prev sibling next sibling parent "Tobias Pankrath" <tobias pankrath.net> writes:
On Wednesday, 8 January 2014 at 10:13:57 UTC, Boyd wrote
 I agree that you wouldn't want code to be precisely constraint 
 to what's syntactically correct. Function bodies in particular 
 benefit quite a bit from just manually typing text. But a tree 
 structure of all modules, classes, functions, properties, 
 etc..., would go a long way.

See for example http://pauillac.inria.fr/~lang/papers/trondheim86/usefulness-syntax-directed-editors-19860616-18.pdf This paper states that a structured editor indeed offers benefits, however they concede that they do not come from tree operation on source (tree cut and paste etc.) but from refactoring* tools that benefit from the tree structure. However as many modern IDEs prove it does not matter (for refactoring) whether you pretty print (serialize) the source code for the user or parse (deserialize) it into a tree for the refactoring tools.
Jan 08 2014
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Wednesday, 8 January 2014 at 00:23:34 UTC, deed wrote:
 From time to time I find the declaration syntax slightly 
 awkward. The main
 reason is that the identifiers come after the types, making it 
 harder to
 identify names and get an overview of the code. This bothered 
 me enough to
 start playing with alternatives.

 My two questions are:

 1. Are there technical reasons not to do it this way, like 
 grammar/ambiguity,
    parsing time, etc.?
 2. Have others been thinking in same direction playing with 
 converters
    or alternative front ends?

 NB! This is by no means any suggestion to change D-syntax.

 Modifications:

 1. Swap type and name. Like Go, but return type between 
 function name and
    parameter list.
 2. Names come first, all other annotations after. ALWAYS. 
 Example:

       private const(int)[] foo(const(int)[] all, int newNum, 
 int sum) {}

    becomes

       foo const(int)[](all const(int)[], newNum int, sum int) 
 private {}

    At this point the readability and overview would be improved 
 IMO.

 3. Separate parameter names from their types.

       foo(all, newNum, sum) const(int)[](const(int)[], int, 
 int) private {}


 A couple of examples from phobos follow below:

 //========================================
 // From std.container
 //========================================
 // Current syntax

 struct Range
 {
     private Node * _first;
     private Node * _last;
     private this(Node* first, Node* last);
     private this(Node* n);
      property bool empty() const nothrow;
      property T front();
     void popFront();
      property Range save();
      property T back();
     void popBack();
 }


 // Modified syntax

 Range struct
 {
     _first Node* private;
     _last Node* private;
     this(first, last) (Node*, Node*) private;
     this(n) (Node*) private;
     empty bool()  property const nothrow;
     front T()  property;
     popFront void();
     save Range()  property ;
     back T()  property;
     popBack void();
 }

 //========================================
 // From std.datetime
 //========================================
 // Current syntax

 abstract class TimeZone
 {
 public:
      property string name() const nothrow;
      property string stdName() const nothrow;
      property string dstName() const nothrow;
      property abstract bool hasDST() const nothrow;
     abstract bool dstInEffect(long stdTime) const nothrow;
     abstract long utcToTZ(long stdTime) const nothrow;
     abstract long tzToUTC(long adjTime) const nothrow;
     Duration utcOffsetAt(long stdTime) const nothrow;
     static immutable(TimeZone) getTimeZone(string name);
     static string[] getInstalledTZNames(string subName = "");
 private:
     this(string name, string stdName, string dstName) immutable 
 pure;
     immutable string _name;
     immutable string _stdName;
     immutable string _dstName;
 }


 // Modified syntax

 TimeZone class abstract
 {
 public:
     name() string()  property const nothrow;
     stdName() string()  property const nothrow;
     dstName() string()  property const nothrow;
     hasDST() bool()  property const nothrow abstract;
     dstInEffect(stdTime) bool(long) abstract const nothrow;
     utcToTZ(stdTime) long(long) abstract const nothrow;
     tzToUTC(adjTime) long(long) abstract const nothrow;
     utcOffsetAt(stdTime) Duration(long)  const nothrow;
     getTimeZone(name) static immutable TimeZone(string);
     getInstalledTZNames(subName = "") static string[] (string);
 private:
     this(name, stdName, dstName) (string, string, string) 
 immutable pure;
     _name immutable string;
     _stdName immutable string;
     _dstName immutable string;
 }

 // Alternative layout:

 TimeZone class abstract
 {
   public:
     name()                  string()     property const nothrow;
     stdName()               string()     property const nothrow;
     dstName()               string()     property const nothrow;
     hasDST()                bool()       property const nothrow 
 abstract;
     dstInEffect( stdTime )  bool(long)  abstract const nothrow;
     utcToTZ( stdTime )      long(long)  abstract const nothrow;
     tzToUTC( adjTime )      long(long)  abstract const nothrow;
     utcOffsetAt( stdTime )  Duration(long)  const nothrow;
     getTimeZone( name )     static immutable TimeZone(string);
     getInstalledTZNames( subName = "")
                             static string[](string);
   private:
     this(name, stdName, dstName) (string, string, string) 
 immutable pure;
     _name    immutable string;
     _stdName immutable string;
     _dstName immutable string;
 }

 //========================================
 // From std.getopt
 //========================================
 // Current syntax

 private void getoptImpl(T...)(ref string[] args, ref 
 configuration cfg, T opts);

 void handleOption(R)(string option, R receiver, ref string[] 
 args,
         ref configuration cfg, bool incremental);

 private bool optMatch(string arg, string optPattern, ref string 
 value,
     configuration cfg);


 // Modified syntax

 getoptImpl(args, cfg, opts) private
     (T...) void (ref string[], ref configuration, T);

 handleOption(option, receiver, args, cfg, incremental)
     (R) void (string, R, ref string[], ref configuration, bool);

 optMatch(arg, optPattern, value, cfg) private
     bool (string, string, ref string, configuration);

It's really a matter of opinion which is best, which in my opinion is trumped by the familiarity of C-style syntax. I'm sure I could work with either way.
Jan 08 2014
prev sibling next sibling parent "eles" <eles eles.com> writes:
On Wednesday, 8 January 2014 at 01:26:12 UTC, H. S. Teoh wrote:
 On Wed, Jan 08, 2014 at 12:35:18AM +0000, Adam D. Ruppe wrote:
 On Wednesday, 8 January 2014 at 00:23:34 UTC, deed wrote:

tmp1 : real;

If there is one thing that I would bring from Pascal to C would be exactly the declaration syntax, that is: var tmp1: real; and the like. I think this also makes the parsing faster (especially if the "var" becomes required) and, IIRC, it was cited among the reasons for Go declaration syntax.
Jan 08 2014
prev sibling next sibling parent "Boyd" <gaboonviper gmx.net> writes:
On Wednesday, 8 January 2014 at 10:26:06 UTC, Jacob Carlborg 
wrote:
 On 2014-01-08 11:13, Boyd wrote:

 I agree that you wouldn't want code to be precisely constraint 
 to what's
 syntactically correct. Function bodies in particular benefit 
 quite a bit
 from just manually typing text. But a tree structure of all 
 modules,
 classes, functions, properties, etc..., would go a long way.

There are IDE's already doing this, like Eclipse, Xcode, NetBeans and so on.

True, but we still need one for D. And I have to say that most implementations, that I've seen, are pretty weak and clumsy.
Jan 08 2014
prev sibling next sibling parent reply "dajones" <dajones hotmail.com> writes:
"deed" <none none.none> wrote in message 
news:unsbvdjdsxtsqgfdetby forum.dlang.org...
 Modifications:

 1. Swap type and name. Like Go, but return type between function name and 
 parameter list.
 2. Names come first, all other annotations after. ALWAYS. Example:

       private const(int)[] foo(const(int)[] all, int newNum, int sum) {}

    becomes

       foo const(int)[](all const(int)[], newNum int, sum int) private {}

Why have a function declaration take a different form than an expression? h = sqrt(x*x+y*y) s = sin(theta) There's thousands of years of math behind that, we are taught that form before we ever get near programming a computer. result = do_somthing_with(parameters)
Jan 08 2014
next sibling parent "dajones" <dajones hotmail.com> writes:
"Tobias Pankrath" <tobias pankrath.net> wrote in message 
news:ointgouwuqyhuoowhzej forum.dlang.org...
 On Wednesday, 8 January 2014 at 14:13:16 UTC, dajones wrote:
 "deed" <none none.none> wrote in message
 news:unsbvdjdsxtsqgfdetby forum.dlang.org...
 Modifications:

 1. Swap type and name. Like Go, but return type between function name 
 and parameter list.
 2. Names come first, all other annotations after. ALWAYS. Example:

       private const(int)[] foo(const(int)[] all, int newNum, int sum) {}

    becomes

       foo const(int)[](all const(int)[], newNum int, sum int) private {}

Why have a function declaration take a different form than an expression? h = sqrt(x*x+y*y) s = sin(theta) There's thousands of years of math behind that, we are taught that form before we ever get near programming a computer. result = do_somthing_with(parameters)

x : Int = 4 h = sqrt(x * x) Is 'h' a function or is it 2? Should h change if I change x?

if you showed the line h = sqrt(x*x) to 100 people, either programmers or people familiar with algebra, how many do you think would say that 'h' is a variable and how many do you think would say 'h' is a function? And FWIW the square root of 4*4 is 4 not 2.
Jan 08 2014
prev sibling parent "dajones" <dajones hotmail.com> writes:
"deed" <none none.none> wrote in message 
news:lludycbhnhjzyypowtci forum.dlang.org...
 Why have a function declaration take a different form than an expression?

 h = sqrt(x*x+y*y)
 s = sin(theta)

 There's thousands of years of math behind that, we are taught that form
 before we ever get near programming a computer.

 result = do_somthing_with(parameters)

Your example seems to show how the functions are used, not how they are declared. I'm only considering declarations and prototyping.

My point was that the form should be the same for declaration and use. It's more consitent / intuative that way. I can see your point that the names would be more visable at the front of the declaration, but I cant honestly think that it's ever been a problem for me. That's what syntax highlighting and formating is for. Eg... struct { pure double sin(double x) nothrow immutable double pi double sqrt(double x) nothrow safe const(int)[] foo(const(int)[] all, int newNum, int sum) } is better than... struct { sqrt(x) double(double) nothrow pi immutable double sin(x) double(double) foo(all, newNum, sum) const(int)[] (const(int)[], int, int) } imo at least, and if the names are all highlighted in luminous green it's all moot then anyway.
Jan 08 2014
prev sibling next sibling parent "Tobias Pankrath" <tobias pankrath.net> writes:
On Wednesday, 8 January 2014 at 14:13:16 UTC, dajones wrote:
 "deed" <none none.none> wrote in message
 news:unsbvdjdsxtsqgfdetby forum.dlang.org...
 Modifications:

 1. Swap type and name. Like Go, but return type between 
 function name and parameter list.
 2. Names come first, all other annotations after. ALWAYS. 
 Example:

       private const(int)[] foo(const(int)[] all, int newNum, 
 int sum) {}

    becomes

       foo const(int)[](all const(int)[], newNum int, sum int) 
 private {}

Why have a function declaration take a different form than an expression? h = sqrt(x*x+y*y) s = sin(theta) There's thousands of years of math behind that, we are taught that form before we ever get near programming a computer. result = do_somthing_with(parameters)

x : Int = 4 h = sqrt(x * x) Is 'h' a function or is it 2? Should h change if I change x?
Jan 08 2014
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Jan 08, 2014 at 08:47:21AM +0000, Boyd wrote:
[...]
 I've been experimenting with language design a bit and I found that
 a much bigger issue with coding, is that we still use files and
 plain text. An IDE where code is represented in a simple tree and
 saved in a database, for example, would improve things dramatically,
 and no language changes would be necessary.

I disagree with that direction. The advantage of a text format is that it can represent *anything* (suitably serialized, of course), and that when things go wrong with your tools (IDE corrupts the file, or doesn't support certain operations, or, for that matter, you're working in an environment where no IDE is available and all you have is a bare-bones text editor), you have a way of reaching into the data and fixing it yourself. Having a custom binary representation of the code makes it impossible to manipulate outside of the IDE, which makes data recovery very time-consuming or impossible. That's not to say that plain text is the best representation for code, of course. But I have yet to find an alternative that doesn't suck, and that offers advantages that plain text can't offer. This isn't the first time this idea came up. I've heard of many attempts to replace text representation for code, and all of them sucked. If you think you have a superior representation, please convince me otherwise. T -- Elegant or ugly code as well as fine or rude sentences have something in common: they don't depend on the language. -- Luca De Vitis
Jan 08 2014
prev sibling next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 8 January 2014 at 00:23:34 UTC, deed wrote:
 1. Swap type and name. Like Go, but return type between 
 function name and
    parameter list.

I find the Go swap to be less clear like "functionname(x,y,z int)", but the swap with ":" is ok. However, then you might as well create a separate type name space starting with colon so that all types start with ":" and have a single colon mean auto (kinda like Go): x :int; // int x; y := 2; // auto y = 2; I think the basic advantage with the swap is to have the return value after the the function parameter list: add(x:int,y:int) :int {} sub(x:int,y:int) :int {} It is also more consistent with subclassing, an instance being a special case of a type. define :subclass:superclass{} // class subclass : superclass{} anonclass_instance:superclass{...}(...) etc. This is particularly useful in a language like Beta where you can inject code into the middle of the superclass: define :dbaccess { db :=dbopen(); INNER; db.close(); } define :dbtransaction:dbaccess{ db.begin(); INNER; db.end(); } define :updatedb:dbtransaction{ db.get(...); db.put(...); db.put(...); INNER; db.consistencycheck(); } :updatedb{ db.put(...morestuff...) }
 2. Names come first, all other annotations after. ALWAYS.

Yep, or rather: more specific identifiers come first.
Jan 08 2014
prev sibling next sibling parent "Boyd" <gaboonviper gmx.net> writes:
On Wednesday, 8 January 2014 at 16:31:06 UTC, H. S. Teoh wrote:
 On Wed, Jan 08, 2014 at 08:47:21AM +0000, Boyd wrote:
 [...]
 I've been experimenting with language design a bit and I found 
 that
 a much bigger issue with coding, is that we still use files and
 plain text. An IDE where code is represented in a simple tree 
 and
 saved in a database, for example, would improve things 
 dramatically,
 and no language changes would be necessary.

I disagree with that direction. The advantage of a text format is that it can represent *anything* (suitably serialized, of course), and that when things go wrong with your tools (IDE corrupts the file, or doesn't support certain operations, or, for that matter, you're working in an environment where no IDE is available and all you have is a bare-bones text editor), you have a way of reaching into the data and fixing it yourself. Having a custom binary representation of the code makes it impossible to manipulate outside of the IDE, which makes data recovery very time-consuming or impossible. That's not to say that plain text is the best representation for code, of course. But I have yet to find an alternative that doesn't suck, and that offers advantages that plain text can't offer. This isn't the first time this idea came up. I've heard of many attempts to replace text representation for code, and all of them sucked. If you think you have a superior representation, please convince me otherwise. T

I'm not suggesting getting rid of all plain text, but I'm definitely for replacing most of the text we need to define structural information. Furthermore, a custom binary implementation wouldn't be a problem as long as there is a well defined exchange format that all IDE's would share. This could simply be the code files we use now. I agree that current alternatives are less than stellar. I think that's mostly because any attempts either go too far (visual programming), or not nearly far enough (just listing the available objects). Unfortunately I don't have anything concrete. Only ideas, that I will eventually try to work out, when I have the time. (Don't hold your breath) I do wish that programmers would be more open to such ideas. There is too much pointless bickering about miniscule syntactic changes, yet no one seems to be interested in fixing the archaic use of plain text files.
Jan 08 2014
prev sibling next sibling parent "deed" <none none.none> writes:
 Why have a function declaration take a different form than an 
 expression?

 h = sqrt(x*x+y*y)
 s = sin(theta)

 There's thousands of years of math behind that, we are taught 
 that form
 before we ever get near programming a computer.

 result = do_somthing_with(parameters)

Your example seems to show how the functions are used, not how they are declared. I'm only considering declarations and prototyping. After point 2 they would be declared like this, assuming double as parameter and return type for sqrt and sin: sqrt double(x double) {} sin double(x double) {} foo const(int)[] (all const(int)[], newNum int, sum int) {} And after point 3, the declaration would be: sqrt(x) double(double) {} sin(x) double(double) {} foo(all, newNum, sum) const(int)[] (const(int)[], int, int) {} Currently we have: double sqrt(double x) double sin(double x) const(int)[] foo(const(int)[] all, int newNum, int sum) {} With 20 of these methods inside a struct or class, heavily annotated, and the code folded to get an overview, one have to search in the middle of all the declarations to identify them. And you need to identify said methods, otherwise the information value is quite limited. Consider struct { private Data[] property const nothrow bool property Data void } struct { _data empty() front() popFront() } I believe the last part provides more overall information by itself than the first. Also, the information in the first part is of limited value alone; we want to know that empty is the method that can be used as a property, returns bool, won't change our struct and doesn't throw more than that the struct contains that annotation or that that annotation happens to be named empty. And if the last part is changed to struct { _veryImportantData isDiskFull() lastAdded() deleteAll() } more overall information is provided than struct { private VeryImportantData[] property const nothrow bool property VeryImportantData void } Therefore it feels natural to compose this as struct { _data VeryImportantData[] private isDiskFull() bool() property const nothrow lastChanged() VeryImportantData() property deleteAll() void() } rather than struct { private VeryImportantData[] _data property bool isDiskFull() const nothrow property VeryImportantData lastChanged() void() deleteAll } or instead of struct { pure double sin(double x) nothrow immutable double pi double sqrt(double x) nothrow safe const(int)[] foo(const(int)[] all, int newNum, int sum) } have struct { sqrt(x) double(double) nothrow pi immutable double sin(x) double(double) foo(all, newNum, sum) const(int)[] (const(int)[], int, int) } Anyway, I'm not trying to push this, I was just curious about the two questions in my initial post.
Jan 08 2014
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Jan 08, 2014 at 05:19:59PM +0000, Boyd wrote:
 On Wednesday, 8 January 2014 at 16:31:06 UTC, H. S. Teoh wrote:
On Wed, Jan 08, 2014 at 08:47:21AM +0000, Boyd wrote:
[...]
I've been experimenting with language design a bit and I found that
a much bigger issue with coding, is that we still use files and
plain text. An IDE where code is represented in a simple tree and
saved in a database, for example, would improve things dramatically,
and no language changes would be necessary.

I disagree with that direction. The advantage of a text format is that it can represent *anything* (suitably serialized, of course), and that when things go wrong with your tools (IDE corrupts the file, or doesn't support certain operations, or, for that matter, you're working in an environment where no IDE is available and all you have is a bare-bones text editor), you have a way of reaching into the data and fixing it yourself. Having a custom binary representation of the code makes it impossible to manipulate outside of the IDE, which makes data recovery very time-consuming or impossible. That's not to say that plain text is the best representation for code, of course. But I have yet to find an alternative that doesn't suck, and that offers advantages that plain text can't offer. This isn't the first time this idea came up. I've heard of many attempts to replace text representation for code, and all of them sucked. If you think you have a superior representation, please convince me otherwise. T

I'm not suggesting getting rid of all plain text, but I'm definitely for replacing most of the text we need to define structural information. Furthermore, a custom binary implementation wouldn't be a problem as long as there is a well defined exchange format that all IDE's would share. This could simply be the code files we use now.

I suppose it depends on the way you're used to working. Me, I don't even use GUI's (well, my "GUI" is so bare bones that my manager doesn't even understand how I can even begin to use it), much less IDE's, and I generally prefer formats that can be processed by generic tools that aren't necessarily catered for manipulating code.
 I agree that current alternatives are less than stellar. I think
 that's mostly because any attempts either go too far (visual
 programming), or not nearly far enough (just listing the
 available objects).

No, I think the issue is that nobody has truly tackled the real problem yet. Visual programming is just a misguided attempt at modelling computation with physical metaphors, which don't work because they utterly fall flat in capturing the sheer, immense complexity of computation. Most people don't even understand rudimentary complexity / computational theory (and through no fault of theirs: the nature of the subject is extremely complex, no pun intended), much less have any sort of useful visualization of it that is generically applicable. Listing available objects to me is like printing a catalogue of telescopes when the task at hand is to study astronomy. Until we shift our attention from the toys of syntax and representation to truly capture the nature of computation, the current state of things will continue to hold.
 Unfortunately I don't have anything concrete. Only ideas, that I
 will eventually try to work out, when I have the time. (Don't
 hold your breath)
 
 I do wish that programmers would be more open to such ideas.
 There is too much pointless bickering about miniscule syntactic
 changes, yet no one seems to be interested in fixing the archaic
 use of plain text files.

https://en.wikipedia.org/wiki/Parkinson's_law_of_triviality :-) We like to bicker about syntax because everybody understands it and has direct experience of it. Semantics -- we know we need it, and we've dabbled in it some, but nobody really understands it in its entirety, so as long as it's Turing-complete (whatever *that* means... :P), that's good enough for us. Leave us the time to argue over syntax and how to make the "right" coffee. On a more serious note, though, I classify the use of plain text files vs. whatever alternative representation format to be equally trivial as bikeshedding over syntax. The important issues at hand are the *semantics* of programming -- how to capture the sheer complexity of computation in a way that can make extremely complex computations tractable to our limited mental capacity. The history of the progress of programming is keyed on exactly this issue.
From the days of fiddling directly with binary bits to the first

example, addition, without needing to specify how exactly the bits are to be flipped. Then from assembly language to the first human-comprehensible languages, progress was made by being able to express a computation as a mathematical expression (more or less), without needing to specify exactly how each machine register is to be assigned to various intermediate quantities in order to produce the desired result. Then from the first (rather low-level) languages to (slightly) higher-level languages like C, progress was made by being able to encapsulate complex computations in functional units that can be reused without needing to rewrite a custom adaptation thereof for every occasion the same (or similar) computation is needed. At every stage, progress was made by building more powerful and far-reaching abstractions that can span greater scopes of computation. Whether said abstractions are represented by one syntax or another, in one medium (plain text) or another (binary), is ultimately mere clerical work. Whether you represent the number 8 as the glyph "8", as the word "eight", or as the Roman numeral VIII, doesn't matter as far as the ability to express that mathematical quantity is concerned. It's rather telling that today's mathematics, which has developed far beyond anyone's ability to fully comprehend in its entirety and scope, is still represented as mere symbols on paper (or some equivalent digital medium). There's a lot to be said about symbolic representations of abstract concepts: so far, no one has found any superior method of representing and manipulating abstract concepts. The crux of the issue is how to define a symbol -> semantics mapping that is maximally expressive and amenable to easy use. How these symbols are to be represented and stored, that's mere clerical work. Necessary, but by no means an issue more important than syntax. T -- Political correctness: socially-sanctioned hypocrisy.
Jan 08 2014
prev sibling next sibling parent "Tobias Pankrath" <tobias pankrath.net> writes:
 x : Int = 4
 h = sqrt(x * x)

 Is 'h' a function or is it 2? Should h change if I change x?

if you showed the line h = sqrt(x*x) to 100 people, either programmers or people familiar with algebra, how many do you think would say that 'h' is a variable and how many do you think would say 'h' is a function? And FWIW the square root of 4*4 is 4 not 2.

Value, all of them. I know any calculus/syntax where it would be different. The only difference I am aware of is whether a change of x propagates to h.
Jan 08 2014
prev sibling next sibling parent "Boyd" <gaboonviper gmx.net> writes:
On Wednesday, 8 January 2014 at 20:12:03 UTC, H. S. Teoh wrote:
 I'm not suggesting getting rid of all plain text, but I'm
 definitely for replacing most of the text we need to define
 structural information.
 
 Furthermore, a custom binary implementation wouldn't be a 
 problem
 as long as there is a well defined exchange format that all 
 IDE's
 would share. This could simply be the code files we use now.

I suppose it depends on the way you're used to working. Me, I don't even use GUI's (well, my "GUI" is so bare bones that my manager doesn't even understand how I can even begin to use it), much less IDE's, and I generally prefer formats that can be processed by generic tools that aren't necessarily catered for manipulating code.

Well I mostly learned programming using Borland Delphi, so I'm kinda spoiled with GUI goodness.
 I agree that current alternatives are less than stellar. I 
 think
 that's mostly because any attempts either go too far (visual
 programming), or not nearly far enough (just listing the
 available objects).

No, I think the issue is that nobody has truly tackled the real problem yet. Visual programming is just a misguided attempt at modelling computation with physical metaphors, which don't work because they utterly fall flat in capturing the sheer, immense complexity of computation. Most people don't even understand rudimentary complexity / computational theory (and through no fault of theirs: the nature of the subject is extremely complex, no pun intended), much less have any sort of useful visualization of it that is generically applicable. Listing available objects to me is like printing a catalogue of telescopes when the task at hand is to study astronomy. Until we shift our attention from the toys of syntax and representation to truly capture the nature of computation, the current state of things will continue to hold.

Yeah, the whole software engineering field still seems to be in its infancy.
 Unfortunately I don't have anything concrete. Only ideas, that 
 I
 will eventually try to work out, when I have the time. (Don't
 hold your breath)
 
 I do wish that programmers would be more open to such ideas.
 There is too much pointless bickering about miniscule syntactic
 changes, yet no one seems to be interested in fixing the 
 archaic
 use of plain text files.

https://en.wikipedia.org/wiki/Parkinson's_law_of_triviality :-) We like to bicker about syntax because everybody understands it and has direct experience of it. Semantics -- we know we need it, and we've dabbled in it some, but nobody really understands it in its entirety, so as long as it's Turing-complete (whatever *that* means... :P), that's good enough for us. Leave us the time to argue over syntax and how to make the "right" coffee.

Oh feel free too keep bickering, I'll even join you:) I was just being a bit dramatic, and maybe hoping to find someone with similar ideas.
 On a more serious note, though, I classify the use of plain 
 text files
 vs. whatever alternative representation format to be equally 
 trivial as
 bikeshedding over syntax.  The important issues at hand are the
 *semantics* of programming -- how to capture the sheer 
 complexity of
 computation in a way that can make extremely complex 
 computations
 tractable to our limited mental capacity.  The history of the 
 progress
 of programming is keyed on exactly this issue.

It's not exactly the representation format I'm worried about, but rather the organization of code.
Jan 08 2014
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Jan 08, 2014 at 09:18:16PM +0000, Boyd wrote:
 On Wednesday, 8 January 2014 at 20:12:03 UTC, H. S. Teoh wrote:

I do wish that programmers would be more open to such ideas.  There
is too much pointless bickering about miniscule syntactic changes,
yet no one seems to be interested in fixing the archaic use of plain
text files.

https://en.wikipedia.org/wiki/Parkinson's_law_of_triviality :-) We like to bicker about syntax because everybody understands it and has direct experience of it. Semantics -- we know we need it, and we've dabbled in it some, but nobody really understands it in its entirety, so as long as it's Turing-complete (whatever *that* means... :P), that's good enough for us. Leave us the time to argue over syntax and how to make the "right" coffee.

Oh feel free too keep bickering, I'll even join you:) I was just being a bit dramatic, and maybe hoping to find someone with similar ideas.

No problem, let's just call the $1 billion D compiler nuclear reactor project a done deal, and get back to the bickering over the syntactic bikeshed. :-)
On a more serious note, though, I classify the use of plain text
files vs. whatever alternative representation format to be equally
trivial as bikeshedding over syntax.  The important issues at hand
are the *semantics* of programming -- how to capture the sheer
complexity of computation in a way that can make extremely complex
computations tractable to our limited mental capacity.  The history
of the progress of programming is keyed on exactly this issue.

It's not exactly the representation format I'm worried about, but rather the organization of code.

Well, how *should* code be organized? So far, the best we've come up with in the industry is to break it up into functions at the low levels, and classes and modules at the mid-level, and libraries and packages at the high-level. I'm not sure this hierarchical arrangement is the best there is, though it seems sufficient for what it does. Unfortunately, I don't have a better solution either. Nothing on the level of ground-breaking ideas that change the way we think about code, anyway. T -- Public parking: euphemism for paid parking. -- Flora
Jan 08 2014