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 reply "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
next sibling parent reply "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
next sibling parent reply "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
parent reply "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
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 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:


 		// Variable declaration
 		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 "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 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 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 reply "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
parent reply "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
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 parent reply 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
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 "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 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 reply "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
parent reply "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
parent reply "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


rudimentary assembler, progress was made by being able to express, for
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
parent reply "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
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
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 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 reply "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
parent reply "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
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 parent reply "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
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 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