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.

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.

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.

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

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

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.

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.

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.

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

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?