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);

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.

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!

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/

> 	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...

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.

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.

> 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).

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.

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.