Difference between revisions of "Beyond D2"
Timotheecour (talk | contribs) |
Timotheecour (talk | contribs) |
||
Line 1: | Line 1: | ||
== Motivation == | == Motivation == | ||
− | This | + | This can be used as a centralized place to discuss parts of D2's design that are controversial or suboptimal in retrospect. |
− | Also discussed here are features that would be worthy of consideration in a hypothetical successor for D2 ( | + | Also discussed here are features that would be worthy of consideration in a hypothetical successor for D2, let's call it D3 (or E!). |
This page came up from email thread http://forum.dlang.org/post/ygmtislwwhfftiqrujan@forum.dlang.org. | This page came up from email thread http://forum.dlang.org/post/ygmtislwwhfftiqrujan@forum.dlang.org. | ||
− | + | Desirable properties: | |
+ | * move features & special syntax from language to library whenever possible | ||
+ | * increase syntax & feature orthogonality (no special case for strings, prefer explicit to implicit) | ||
+ | * increase DRY-ness of code | ||
+ | * design grammar to be easy to parse and provide reference compiler as a library | ||
+ | * feature AST macros to simplify a number of constructs | ||
+ | * prefer automatic attribute inference over manual annotation | ||
− | + | Staying as close as possible to D2's syntax is not necessarily a goal, as automatic translation tools can easily take care of this: clarity of target language is a more important role. | |
== Features to drop == | == Features to drop == | ||
− | * | + | * remove language builtins (sort / reverse / foreach_reverse / complex numbers), see http://dlang.org/deprecate.html |
* get rid of opSlice/opSliceAssign etc: | * get rid of opSlice/opSliceAssign etc: | ||
** a..b is instead syntax sugar for a Slice object: | ** a..b is instead syntax sugar for a Slice object: | ||
− | ** rationale for opSlice, opSliceAssign, vs a..b being syntax | + | ** rationale for opSlice, opSliceAssign, vs a..b being syntax sugar for a Slice struct? http://forum.dlang.org/post/mailman.551.1365290408.4724.digitalmars-d-learn@puremagic.com |
+ | |||
+ | * get rid of C-style expression lists in parenthesis; these would be reserved for tuples | ||
* strings: stop conflating range of code points with range of code units: | * strings: stop conflating range of code points with range of code units: | ||
Line 28: | Line 36: | ||
** http://forum.dlang.org/post/op.wx7lqwvx54xghj@puck.auriga.bhead.co.uk + code | ** http://forum.dlang.org/post/op.wx7lqwvx54xghj@puck.auriga.bhead.co.uk + code | ||
− | * | + | * get rid of @property |
+ | |||
+ | * get rid of /**/ since we have nesting /++/ | ||
+ | |||
+ | * pragma(msg,) shouldn't insert "\n" (easy to add, impossible to remove) | ||
+ | |||
+ | * remove 'version(foo)' in favor of: static if(versions.foo), which would be more orthogonal. versions is an implicitly imported module that contains (for example): | ||
+ | version.osx=true | ||
+ | version.posix=true | ||
+ | version.windows=false | ||
+ | //plus other versions defined on command line | ||
+ | => no new syntax | ||
+ | |||
+ | == Safety == | ||
+ | * default is @safe/@pure ; attributes are automatically inferred and exported in di interface files | ||
+ | |||
+ | == Separate Compilation == | ||
+ | |||
+ | * is virtual by default a good idea with separate compilation model? | ||
== Features to add == | == Features to add == | ||
Line 61: | Line 87: | ||
* proposal: lazy compilation model for compiling binaries: http://forum.dlang.org/post/mailman.1357.1371876331.13711.digitalmars-d@puremagic.com | * proposal: lazy compilation model for compiling binaries: http://forum.dlang.org/post/mailman.1357.1371876331.13711.digitalmars-d@puremagic.com | ||
− | * allow JIT | + | * allow JIT code, to allow runtime eval statements (for REPL etc). |
* Compiler as a library (eg llvm/clang toolchain) | * Compiler as a library (eg llvm/clang toolchain) | ||
Line 68: | Line 94: | ||
== Tooling == | == Tooling == | ||
+ | * Incremental compilation support in rdmd: http://d.puremagic.com/issues/show_bug.cgi?id=9673 | ||
* improved dmd/rdmd command line: http://wiki.dlang.org/DIP41 | * improved dmd/rdmd command line: http://wiki.dlang.org/DIP41 | ||
− | |||
== Syntax changes == | == Syntax changes == | ||
− | * | + | * full UFCS support: foo.mixin, foo.assert, foo.stringof, foo.typeof |
− | * Go style a := b meaning auto a = b | + | |
− | * semi-column optional | + | * More lightweight syntax: |
− | * Go style lightweight if/while/etc expressions that don't require () around the if statement: | + | ** Go style a := b meaning auto a = b |
+ | |||
+ | ** semi-column optional | ||
+ | |||
+ | ** Go style lightweight if/while/etc expressions that don't require () around the if statement: | ||
<syntaxhighlight lang="d"> | <syntaxhighlight lang="d"> | ||
while x>=0 {...} | while x>=0 {...} | ||
</syntaxhighlight> | </syntaxhighlight> | ||
− | |||
+ | == Language interop == | ||
+ | * Allow transparently including C headers in code as in Go; could use swig behind the scenes | ||
== More controversial features to add == | == More controversial features to add == | ||
Line 88: | Line 119: | ||
** More future proof and eases refactoring | ** More future proof and eases refactoring | ||
− | |||
---- | ---- | ||
Page originally created by Timothee Cour on 11/09/2013; copyright: public domain. | Page originally created by Timothee Cour on 11/09/2013; copyright: public domain. | ||
TODO: add discussion/DIP/webpage links to each item | TODO: add discussion/DIP/webpage links to each item |
Revision as of 04:38, 10 November 2013
Contents
Motivation
This can be used as a centralized place to discuss parts of D2's design that are controversial or suboptimal in retrospect. Also discussed here are features that would be worthy of consideration in a hypothetical successor for D2, let's call it D3 (or E!). This page came up from email thread http://forum.dlang.org/post/ygmtislwwhfftiqrujan@forum.dlang.org.
Desirable properties:
- move features & special syntax from language to library whenever possible
- increase syntax & feature orthogonality (no special case for strings, prefer explicit to implicit)
- increase DRY-ness of code
- design grammar to be easy to parse and provide reference compiler as a library
- feature AST macros to simplify a number of constructs
- prefer automatic attribute inference over manual annotation
Staying as close as possible to D2's syntax is not necessarily a goal, as automatic translation tools can easily take care of this: clarity of target language is a more important role.
Features to drop
- remove language builtins (sort / reverse / foreach_reverse / complex numbers), see http://dlang.org/deprecate.html
- get rid of opSlice/opSliceAssign etc:
- a..b is instead syntax sugar for a Slice object:
- rationale for opSlice, opSliceAssign, vs a..b being syntax sugar for a Slice struct? http://forum.dlang.org/post/mailman.551.1365290408.4724.digitalmars-d-learn@puremagic.com
- get rid of C-style expression lists in parenthesis; these would be reserved for tuples
- strings: stop conflating range of code points with range of code units:
- "foo" represents a range of code points
- "foo".rep represents a range of code units, eg: immutable(char)[]
- This would remove a *lot* of special case code in phobos and make it easier to write generic code, eg, would remove need for distinguishing ElementType vs ForeachType
- I've discussed this in email:"iteration over a string"
- Andrei mentioned it here as well: http://forum.dlang.org/post/l3h49k$b6$1@digitalmars.com
"It is my opinion that a better solution exists (in the form of making representation accessible only through a property .rep)"
- stop conflating paths with strings; would make a lot of code safer and cross platform; would still allow implicit conversion via alias this.
- get rid of @property
- get rid of /**/ since we have nesting /++/
- pragma(msg,) shouldn't insert "\n" (easy to add, impossible to remove)
- remove 'version(foo)' in favor of: static if(versions.foo), which would be more orthogonal. versions is an implicitly imported module that contains (for example):
version.osx=true version.posix=true version.windows=false //plus other versions defined on command line => no new syntax
Safety
- default is @safe/@pure ; attributes are automatically inferred and exported in di interface files
Separate Compilation
- is virtual by default a good idea with separate compilation model?
Features to add
- AST macros
- proposal: https://dl.dropboxusercontent.com/u/18386187/ast_macros.html#scroll_to_here
- would enable many features; eg:
- supersedes: "proposal: a new string litteral to embed variables in a string" http://forum.dlang.org/post/mailman.94.1383254681.9546.digitalmars-d@puremagic.com
- supersedes: "feature request: __ARGS__ for logging (cf __FILE__, __LINE__, __FUNC___)" http://forum.dlang.org/post/godmqvdatmjvkyjybkoa@forum.dlang.org
- python style named parameter arguments
- Yield return
- R-value references
- Safe references
- language syntax for tuples; unify syntax for compile time tuples with runtime tuples
- could follow DIP32 but use (a,b) syntax instead; we would get rid of C-style expression lists to enable this
Arrays and Ranges
- multidimensional indexing and slicing:
- builtin slices with begin..end:step or begin..end..step
Compilation
- proposal: lazy compilation model for compiling binaries: http://forum.dlang.org/post/mailman.1357.1371876331.13711.digitalmars-d@puremagic.com
- allow JIT code, to allow runtime eval statements (for REPL etc).
- Compiler as a library (eg llvm/clang toolchain)
- Compiler written in D2, and then bootstrapped from their as done in rust and many other languages
Tooling
- Incremental compilation support in rdmd: http://d.puremagic.com/issues/show_bug.cgi?id=9673
- improved dmd/rdmd command line: http://wiki.dlang.org/DIP41
Syntax changes
- full UFCS support: foo.mixin, foo.assert, foo.stringof, foo.typeof
- More lightweight syntax:
- Go style a := b meaning auto a = b
- semi-column optional
- Go style lightweight if/while/etc expressions that don't require () around the if statement:
while x>=0 {...}
Language interop
- Allow transparently including C headers in code as in Go; could use swig behind the scenes
More controversial features to add
- store code as AST,
- The 1st idea is to get rid of styleguides completely and allow people to read/write code with their preferred style. Codes gets stored and exchanged as AST; clients read the AST and converts it on the fly as source code in the user's preferred formatting.
- speeds up compilation: only currently modified code needs to get translation from source to AST
- More future proof and eases refactoring
Page originally created by Timothee Cour on 11/09/2013; copyright: public domain. TODO: add discussion/DIP/webpage links to each item