Discussion:
Dart and D: features that could be used in D, D->dart for web programming
(too old to reply)
Timothee Cour
2014-02-27 10:19:05 UTC
Permalink
A1)
Google's Dart (https://www.dartlang.org) looks like a very promising
replacement for javascript. It can compile to javascript to ensure
portability (but chromium runs it natively) but the language itself reminds
more of D to a surprising extent. Dart language has features such as:


static typing (but can also have dynamic typing, akin to std.variant, with
better support/syntax than D)
ahead of time compilation
unicode support
built in serialization/deserialization via json
annotations
mixins (used to emulate multiple inheritance)
generics
vector/AA litterals
alias (called typedef in dart), is, assert
try/catch/finally
operator overloading
properties (same parenthesis-less caller syntax as in D)
delegates (called closures)
nesting functions, 1st class functions, lambda => syntax
DDOC (called dartdoc)
D-like syntax and nesting comments,
introspection (runtime only AFAIK)

A2)
Also features that would be nice to have in D or were better designed than
in D:

* cascade operations: they perform a series of operations on the members of
a single object:
foo.bar(1)..baz(3)
equivalent to:
foo.bar(1)
foo.baz(3)

* better way to define default constructors:
class Point {
num x;
num y;
num z;
// Syntactic sugar for setting z and x before the constructor body runs.
Point(this.z, this.x){...}
}
This is more explicit and flexible than D's way for default struct
constructors, which can only allow to set all fields in order, without
skipping some, and doesn't allow to do anything else in the ctor.

* named constructors

* distinguish integer divide (~/) vs divide (/), so that 5/2=2, 5~/2=2

* shorthand function declaration with => (used not just for lambdas)

* for (var x in collection) //better syntax than foreach(var;collection)

* better syntax for optional positional arguments:
void fun(int x, [int y, int z=3]){...}
Thinking of which, this would actually solve a long standing problem in D,
that of specifying optional parameters AFTER a variadic template:
void fun(T...)(T args, [string file=__FILE__,int line=__LINE__]){...}

* export for libraries

* async/wait etc

* great IDE/debugger/package manager/static analyzer

also the following which I've previously proposed adding to D:

* string interpolation $variableName (or ${expression})
assert('foo. ${s.toUpperCase()} bar' == 'foo. STRING INTERPOLATION bar');

* optional named parameters arguments (with simplest possible syntax)

* import all except specified symbols:
import 'package:lib2/lib2.dart' hide foo; // Import all names EXCEPT foo.

A3)
And then some design decisions which wouldn't work for D: everything is an
object, no struct (just class), VM, etc.

A4)
there were may previous threads regarding using D on the web via compiling
to javascript. In light of this it would seem a lot easier to compile D to
dart.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140227/2f57a48b/attachment-0001.html>
Suliman
2014-02-27 10:46:24 UTC
Permalink
What needed to create language that can be run everywhere? I mean
would it be hard to add support of running D code in web-browser?

it's better to write all logic at one language, that on 2 or 3.
bearophile
2014-02-27 10:53:48 UTC
Permalink
Post by Timothee Cour
class Point {
num x;
num y;
num z;
// Syntactic sugar for setting z and x before the constructor
body runs.
Point(this.z, this.x){...}
}
This is more explicit and flexible than D's way for default
struct
constructors, which can only allow to set all fields in order,
without
skipping some, and doesn't allow to do anything else in the
ctor.
A variant of this idea was discussed, and I think it's a good
idea.
Post by Timothee Cour
* distinguish integer divide (~/) vs divide (/), so that 5/2=2,
5~/2=2
* shorthand function declaration with => (used not just for
lambdas)
Both good. But for the first you need a different syntax in D.
Post by Timothee Cour
* optional named parameters arguments (with simplest possible
syntax)
import 'package:lib2/lib2.dart' hide foo; // Import all names
EXCEPT foo.
Probably both good, if well designed.

Bye,
bearophile
w0rp
2014-02-27 12:38:07 UTC
Permalink
I don't like any of the syntax changes mentioned. I do like the
suggestions for better IDEs and similar tools. We can always do
more to improve these.
Asman01
2014-02-27 15:07:22 UTC
Permalink
On Thursday, 27 February 2014 at 10:27:41 UTC, Timothee Cour
Post by Timothee Cour
A1)
Google's Dart (https://www.dartlang.org) looks like a very
promising
replacement for javascript. It can compile to javascript to
ensure
portability (but chromium runs it natively) but the language
itself reminds
more of D to a surprising extent. Dart language has features
static typing (but can also have dynamic typing, akin to
std.variant, with
better support/syntax than D)
ahead of time compilation
unicode support
built in serialization/deserialization via json
annotations
mixins (used to emulate multiple inheritance)
generics
vector/AA litterals
alias (called typedef in dart), is, assert
try/catch/finally
operator overloading
properties (same parenthesis-less caller syntax as in D)
delegates (called closures)
nesting functions, 1st class functions, lambda => syntax
DDOC (called dartdoc)
D-like syntax and nesting comments,
introspection (runtime only AFAIK)
A2)
Also features that would be nice to have in D or were better
designed than
* cascade operations: they perform a series of operations on
the members of
foo.bar(1)..baz(3)
foo.bar(1)
foo.baz(3)
class Point {
num x;
num y;
num z;
// Syntactic sugar for setting z and x before the constructor
body runs.
Point(this.z, this.x){...}
}
This is more explicit and flexible than D's way for default
struct
constructors, which can only allow to set all fields in order,
without
skipping some, and doesn't allow to do anything else in the
ctor.
* named constructors
* distinguish integer divide (~/) vs divide (/), so that 5/2=2,
5~/2=2
* shorthand function declaration with => (used not just for
lambdas)
* for (var x in collection) //better syntax than
foreach(var;collection)
void fun(int x, [int y, int z=3]){...}
Thinking of which, this would actually solve a long standing
problem in D,
that of specifying optional parameters AFTER a variadic
void fun(T...)(T args, [string file=__FILE__,int
line=__LINE__]){...}
* export for libraries
* async/wait etc
* great IDE/debugger/package manager/static analyzer
* string interpolation $variableName (or ${expression})
assert('foo. ${s.toUpperCase()} bar' == 'foo. STRING
INTERPOLATION bar');
* optional named parameters arguments (with simplest possible
syntax)
import 'package:lib2/lib2.dart' hide foo; // Import all names
EXCEPT foo.
A3)
everything is an
object, no struct (just class), VM, etc.
A4)
there were may previous threads regarding using D on the web
via compiling
to javascript. In light of this it would seem a lot easier to
compile D to
dart.
I've hear that Microsoft's equivalent so-called TypeScript was
more successfully than Google's one, more people like much more
TypeScript syntax and features, like I do.
Ary Borenszweig
2014-02-27 16:48:21 UTC
Permalink
Post by Timothee Cour
And then some design decisions which wouldn't work for D: everything is
an object, no struct (just class), VM, etc.
In a programming language you can make everything look like an object
but implement it as a primitive type. So that could work in D (but I
think nobody would like it, although it can make the language much simpler).
Paulo Pinto
2014-02-27 17:16:56 UTC
Permalink
Post by Ary Borenszweig
Post by Timothee Cour
And then some design decisions which wouldn't work for D: everything is
an object, no struct (just class), VM, etc.
In a programming language you can make everything look like an object
but implement it as a primitive type. So that could work in D (but I
think nobody would like it, although it can make the language much simpler).
Yep, that is how for example .NET, Eiffel, Smalltalk, Lisp and many
other languages work.
Bienlein
2014-02-28 12:15:01 UTC
Permalink
Post by Paulo Pinto
Yep, that is how for example .NET, Eiffel, Smalltalk, Lisp and
many other languages work.
An object in Smalltalk is not a primitive type. Even ints,
floats, chars, etc. in Smalltalk are no primitive types but
objects. Not wanting to be a rogue. Just pointing out ;-).
Paulo Pinto
2014-02-28 16:02:11 UTC
Permalink
Post by Paulo Pinto
Yep, that is how for example .NET, Eiffel, Smalltalk, Lisp and many
other languages work.
An object in Smalltalk is not a primitive type. Even ints, floats,
chars, etc. in Smalltalk are no primitive types but objects. Not wanting
to be a rogue. Just pointing out ;-).
Yes they are, kind of, because the ones small enough to fit in
registers, like SmallInteger are converted to primitive types by the JIT.

The programmer cannot see it, because it is considered an implementation
detail, likewise in the other environments I mentioned.

--
Paulo
thedeemon
2014-02-27 17:29:43 UTC
Permalink
On Thursday, 27 February 2014 at 10:27:41 UTC, Timothee Cour
Post by Timothee Cour
A1)
Google's Dart (https://www.dartlang.org) looks like a very
promising
replacement for javascript. It can compile to javascript to
ensure
portability (but chromium runs it natively)
No, neither Chromium nor even Chrome run it natively. Only
Dartium which is a separate browser.
Post by Timothee Cour
* cascade operations: they perform a series of operations on
foo.bar(1)..baz(3)
foo.bar(1)
foo.baz(3)
In D we can use
with(foo) { bar(1); bar(3); }
Pretty close.

Dart looks like a very nice language for front-end web
development indeed. If I was doing web-dev I would choose vibe.d
+ Dart combo.

Some features like its constructors and short form of methods I
would love to see in D too.

As for compiling D to Dart I'm not sure that's feasible. You'll
have to chop off lower half of it.
Paulo Pinto
2014-02-27 18:20:22 UTC
Permalink
Post by Timothee Cour
A1)
Google's Dart (https://www.dartlang.org) looks like a very promising
replacement for javascript. It can compile to javascript to ensure
portability (but chromium runs it natively)
No, neither Chromium nor even Chrome run it natively. Only Dartium which
is a separate browser.
From what I understood on Dart talks last Google IO, work was planned
to have V8 and Dart VM play together inside Chrome.

Personally, I think unless Google pushes the language fro ChromeOS or
Android, it will hardly get any real market size.

Like it or not, JavaScript is good enough.

On my field of work, it doesn't matter how many cool languages I know,
we are usually bound by what the whole team is comfortable using, what
the boss allows for and the technologies that are requested by the
customers themselves.

--
Paulo
Craig Dillabaugh
2014-02-27 18:37:49 UTC
Permalink
On Thursday, 27 February 2014 at 18:20:20 UTC, Paulo Pinto wrote:
clip
Post by Paulo Pinto
Like it or not, JavaScript is good enough.
Really? I've been stuck for the past week or so trying to put
together a browser based UI using JavaScript + HTML for a work
related project. It has been a painful experience. In fairness
to JavaScript, I didn't know the language very well coming in,
but still I've found working in this setting rather frustrating.

If the future of applications is really client-server based
applications, where the client is basically a VM (if we consider
the browser a VM of sorts) surely there is room for a better
development model than this HTML + Javascript mongrel.
w0rp
2014-02-27 19:54:03 UTC
Permalink
On Thursday, 27 February 2014 at 18:37:51 UTC, Craig Dillabaugh
Post by Craig Dillabaugh
On Thursday, 27 February 2014 at 18:20:20 UTC, Paulo Pinto
clip
Post by Paulo Pinto
Like it or not, JavaScript is good enough.
Really? I've been stuck for the past week or so trying to put
together a browser based UI using JavaScript + HTML for a work
related project. It has been a painful experience. In fairness
to JavaScript, I didn't know the language very well coming in,
but still I've found working in this setting rather frustrating.
If the future of applications is really client-server based
applications, where the client is basically a VM (if we
consider the browser a VM of sorts) surely there is room for a
better development model than this HTML + Javascript mongrel.
I developed 99% of the JavaScript part of an application for a
year, and I have extensive JavaScript knowledge. After all that,
I wrote this. https://w0rp.com/blog/post/javascript-sucks/
Craig Dillabaugh
2014-02-27 20:13:50 UTC
Permalink
Post by w0rp
On Thursday, 27 February 2014 at 18:37:51 UTC, Craig Dillabaugh
Post by Craig Dillabaugh
On Thursday, 27 February 2014 at 18:20:20 UTC, Paulo Pinto
clip
Post by Paulo Pinto
Like it or not, JavaScript is good enough.
Really? I've been stuck for the past week or so trying to put
together a browser based UI using JavaScript + HTML for a work
related project. It has been a painful experience. In
fairness to JavaScript, I didn't know the language very well
coming in, but still I've found working in this setting rather
frustrating.
If the future of applications is really client-server based
applications, where the client is basically a VM (if we
consider the browser a VM of sorts) surely there is room for a
better development model than this HTML + Javascript mongrel.
I developed 99% of the JavaScript part of an application for a
year, and I have extensive JavaScript knowledge. After all
that, I wrote this. https://w0rp.com/blog/post/javascript-sucks/
Great. Now I have something to go an read for laughs whenever I
feel my blood-pressure exceeding safe limits :o)
Martin Drasar
2014-02-27 20:23:14 UTC
Permalink
I developed 99% of the JavaScript part of an application for a year, and
I have extensive JavaScript knowledge. After all that, I wrote this.
https://w0rp.com/blog/post/javascript-sucks/
I think it was someone on Slashdot who posted this wonderful comment:

"JavaScript is a crap language that can't be fixed. If they ever add an
honest garbage collector to the base language then most programs will
delete themselves upon execution."
Chris
2014-02-28 11:21:50 UTC
Permalink
Post by w0rp
On Thursday, 27 February 2014 at 18:37:51 UTC, Craig Dillabaugh
Post by Craig Dillabaugh
On Thursday, 27 February 2014 at 18:20:20 UTC, Paulo Pinto
clip
Post by Paulo Pinto
Like it or not, JavaScript is good enough.
Really? I've been stuck for the past week or so trying to put
together a browser based UI using JavaScript + HTML for a work
related project. It has been a painful experience. In
fairness to JavaScript, I didn't know the language very well
coming in, but still I've found working in this setting rather
frustrating.
If the future of applications is really client-server based
applications, where the client is basically a VM (if we
consider the browser a VM of sorts) surely there is room for a
better development model than this HTML + Javascript mongrel.
I developed 99% of the JavaScript part of an application for a
year, and I have extensive JavaScript knowledge. After all
that, I wrote this. https://w0rp.com/blog/post/javascript-sucks/
@Craig&w0rp

I really do understand yeez. Really. At the moment I'm working
with JS (again). Nightmare. Disaster. The server side is
programmed in D, the user (client) side needs JS, ain't no other
way. I have made a real, real, real, reeeeel effort, I've tried
to replicate, mimic, emulate, imitate ... (running out of words
here) every good programming pattern ever invented. But to no
avail. JS is madness and I seriously don't understand why it has
survived the way it is, why people just didn't abandon it years
ago. It is madness. Frustration. Alienation.
Every time I write something in JS, I feel like a complete
programming novice, with the only difference that I know exactly
what I want and how I would do it in any other programming
language. But not so in JS. It defies reason and common human
logic. JS degrades programmers. Years of experience are naught,
you have to beg and cajole, you're at the mercy of a psychopathic
tyrant.
Whenever I program in JS I become highly irritable. When I
program in D, I'm calm, I know what I want, and I know I will get
it.
I don't understand why we haven't got over JS yet. The
Internet is so important and we still have to program things in
JS. I don't get it. Now don't mention PHP with me ...
Chris
2014-02-28 11:45:37 UTC
Permalink
Post by Chris
Post by w0rp
On Thursday, 27 February 2014 at 18:37:51 UTC, Craig
Post by Craig Dillabaugh
On Thursday, 27 February 2014 at 18:20:20 UTC, Paulo Pinto
clip
Post by Paulo Pinto
Like it or not, JavaScript is good enough.
Really? I've been stuck for the past week or so trying to put
together a browser based UI using JavaScript + HTML for a
work related project. It has been a painful experience. In
fairness to JavaScript, I didn't know the language very well
coming in, but still I've found working in this setting
rather frustrating.
If the future of applications is really client-server based
applications, where the client is basically a VM (if we
consider the browser a VM of sorts) surely there is room for
a better development model than this HTML + Javascript
mongrel.
I developed 99% of the JavaScript part of an application for a
year, and I have extensive JavaScript knowledge. After all
that, I wrote this.
https://w0rp.com/blog/post/javascript-sucks/
@Craig&w0rp
I really do understand yeez. Really. At the moment I'm working
with JS (again). Nightmare. Disaster. The server side is
programmed in D, the user (client) side needs JS, ain't no
other way. I have made a real, real, real, reeeeel effort, I've
tried to replicate, mimic, emulate, imitate ... (running out of
words here) every good programming pattern ever invented. But
to no avail. JS is madness and I seriously don't understand why
it has survived the way it is, why people just didn't abandon
it years ago. It is madness. Frustration. Alienation.
Every time I write something in JS, I feel like a complete
programming novice, with the only difference that I know
exactly what I want and how I would do it in any other
programming language. But not so in JS. It defies reason and
common human logic. JS degrades programmers. Years of
experience are naught, you have to beg and cajole, you're at
the mercy of a psychopathic tyrant.
Whenever I program in JS I become highly irritable. When I
program in D, I'm calm, I know what I want, and I know I will
get it.
I don't understand why we haven't got over JS yet. The
Internet is so important and we still have to program things in
JS. I don't get it. Now don't mention PHP with me ...
"There is another option here. Use another programming language."

Thanks for this blog. Whenever I program in JS everything feels
rather 'undefined'. I would love to see the day when JS becomes
obsolete.
bearophile
2014-02-28 12:12:37 UTC
Permalink
Post by Chris
Every time I write something in JS, I feel like a complete
programming novice,
Probably that's part of the problem. More experience in a
language helps.

I suggest to use TypeScript (http://www.typescriptlang.org/ ), it
has static types, more Java-style classes, better modules, and
more; that give a more tidy and ordered kind of coding. If
JavaScript gains integers too, programming in TypeScript probably
becomes bearable even for die hard D programmers :-)

Bye,
bearophile
Chris
2014-02-28 12:58:06 UTC
Permalink
Post by bearophile
Post by Chris
Every time I write something in JS, I feel like a complete
programming novice,
Probably that's part of the problem. More experience in a
language helps.
Unfortunately, you cannot get experienced in JS, there's always a
new pitfall and the more you know it the more you hate it. If you
don't hate it, you don't know it. On the bright side of things,
JS teaches you how _not_ to do things and it makes you appreciate
other languages, real programming languages.

Programming is like this:

Abstract concept of what you wanna do > find out how to do it in
C/Java/D/C#/Python ...

JS Programming is like this:

Abstract concept of what you wanna do > find out how ... > wait,
why the f***k is it not > stackoverflow > ah, you cannot do this
in JS > ah, you can, but you have to reinvent the wheel > now! >
wait, now, why the f***k > loop through the above ...
Post by bearophile
I suggest to use TypeScript (http://www.typescriptlang.org/ ),
it has static types, more Java-style classes, better modules,
and more; that give a more tidy and ordered kind of coding. If
JavaScript gains integers too, programming in TypeScript
probably becomes bearable even for die hard D programmers :-)
Thanks a million, I'll check it out.
Post by bearophile
Bye,
bearophile
Chris
2014-02-28 15:00:52 UTC
Permalink
Post by bearophile
Post by Chris
Every time I write something in JS, I feel like a complete
programming novice,
Probably that's part of the problem. More experience in a
language helps.
I suggest to use TypeScript (http://www.typescriptlang.org/ ),
Ah, no, it's MS. So is Silverlight. Don't like proprietary stuff.
If Ceylon is real open source, great.

I'm still dreaming of a language that will replace JS, not just
compile to JS.
Asman01
2014-03-01 16:37:35 UTC
Permalink
Post by bearophile
Post by Chris
Every time I write something in JS, I feel like a complete
programming novice,
Probably that's part of the problem. More experience in a
language helps.
I suggest to use TypeScript (http://www.typescriptlang.org/ ),
it has static types, more Java-style classes, better modules,
and more; that give a more tidy and ordered kind of coding. If
JavaScript gains integers too, programming in TypeScript
probably becomes bearable even for die hard D programmers :-)
Bye,
bearophile
And now with full(native, i.e., not using a plug-in) support in
Visual Studio 2013 check out
http://blogs.msdn.com/b/mvpawardprogram/archive/2013/11/13/typescript-support-in-visual-studio-2013.aspx
;)
Craig Dillabaugh
2014-03-01 18:57:01 UTC
Permalink
Post by Asman01
Post by bearophile
Post by Chris
Every time I write something in JS, I feel like a complete
programming novice,
Probably that's part of the problem. More experience in a
language helps.
I suggest to use TypeScript (http://www.typescriptlang.org/ ),
it has static types, more Java-style classes, better modules,
and more; that give a more tidy and ordered kind of coding. If
JavaScript gains integers too, programming in TypeScript
probably becomes bearable even for die hard D programmers :-)
Bye,
bearophile
And now with full(native, i.e., not using a plug-in) support in
Visual Studio 2013 check out
http://blogs.msdn.com/b/mvpawardprogram/archive/2013/11/13/typescript-support-in-visual-studio-2013.aspx
;)
As soon as Microsoft releases a Linux version I will be sure to
try it out :o)
Asman01
2014-03-01 19:19:43 UTC
Permalink
Post by Craig Dillabaugh
Post by Asman01
Post by bearophile
Post by Chris
Every time I write something in JS, I feel like a complete
programming novice,
Probably that's part of the problem. More experience in a
language helps.
I suggest to use TypeScript (http://www.typescriptlang.org/
), it has static types, more Java-style classes, better
modules, and more; that give a more tidy and ordered kind of
coding. If JavaScript gains integers too, programming in
TypeScript probably becomes bearable even for die hard D
programmers :-)
Bye,
bearophile
And now with full(native, i.e., not using a plug-in) support
in Visual Studio 2013 check out
http://blogs.msdn.com/b/mvpawardprogram/archive/2013/11/13/typescript-support-in-visual-studio-2013.aspx
;)
As soon as Microsoft releases a Linux version I will be sure to
try it out :o)
Well, you will need to wait a while. :P

Paulo Pinto
2014-02-27 20:39:53 UTC
Permalink
clip
Post by Paulo Pinto
Like it or not, JavaScript is good enough.
Really? I've been stuck for the past week or so trying to put together a
browser based UI using JavaScript + HTML for a work related project. It
has been a painful experience. In fairness to JavaScript, I didn't know
the language very well coming in, but still I've found working in this
setting rather frustrating.
If the future of applications is really client-server based
applications, where the client is basically a VM (if we consider the
browser a VM of sorts) surely there is room for a better development
model than this HTML + Javascript mongrel.
I didn't say I like it that much, just that it is good enough for what
enterprise applications, my field of work, are about.

So unless the browser vendors start supporting other languages, our
customers will only ask for JavaScript, because it is easier to find
guys when doing maintenance support.

They don't care about Dart, TypeScript, CoffeScript, or whatever might
be the flavour of the month, because it increases their problems to
find people and their internal teams usually don't know those languages
anyway.

The same to any other language out there. Usually when I get to work on
a cool language at the enterprise level, it is no longer cool, or it was
brought in because some startup belonging to someone close to the CTO
managed to sneak it in.

The is of course my enterprise world, yours may vary.

--
Paulo
Russel Winder
2014-02-28 07:12:25 UTC
Permalink
On Thu, 2014-02-27 at 19:20 +0100, Paulo Pinto wrote:
[?]
Post by Paulo Pinto
From what I understood on Dart talks last Google IO, work was planned
to have V8 and Dart VM play together inside Chrome.
Dartium is a build of Chromium with both, so this is very much the
direction that is possible.
Post by Paulo Pinto
Personally, I think unless Google pushes the language fro ChromeOS or
Android, it will hardly get any real market size.
Like it or not, JavaScript is good enough.
On my field of work, it doesn't matter how many cool languages I know,
we are usually bound by what the whole team is comfortable using, what
the boss allows for and the technologies that are requested by the
customers themselves.
Dart has a JavaScript translation back end, so could have a role very
much like CoffeeScript ? which arguably hasn't been that successful
given jQuery, Backbone, Ember, Angular, etc.

Ceylon has both JVM and JavaScript back ends and is targetted at
end-to-end single language working: Ceylon in the browser, Ceylon on the
server. If some of the FUD and prejudice that is being put about by
innovation haters in the Javaverse can be overcome, I think Ceylon
could be a big player in the game of Web applications and services.
--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder at ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: russel at winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Walter Bright
2014-02-27 20:43:08 UTC
Permalink
Post by Timothee Cour
* optional named parameters arguments (with simplest possible syntax)
This comes up now and then. The problem with it is it makes function overloading
a near impossibility to untangle.
Jacob Carlborg
2014-03-01 15:19:29 UTC
Permalink
Post by Walter Bright
This comes up now and then. The problem with it is it makes function
overloading a near impossibility to untangle.
We could quite easy add support for named parameters but still require
using the same position of the arguments. I don't know if those wanting
named parameters would be satisfied with this though.
--
/Jacob Carlborg
bearophile
2014-03-01 15:31:39 UTC
Permalink
Post by Jacob Carlborg
We could quite easy add support for named parameters but still
require using the same position of the arguments. I don't know
if those wanting named parameters would be satisfied with this
though.
I think requiring the same position of the arguments goes against
one of the main points of having named arguments.

A (temporarily?) solution to Walter's problem (has someone shown
examples of the problem?) is to just not allow the use of named
arguments for overloaded functions. This is not a large problem
because when you have named arguments, you have less need for
function overloading.

Bye,
bearophile
Michel Fortin
2014-03-01 16:19:07 UTC
Permalink
Post by Jacob Carlborg
Post by Walter Bright
This comes up now and then. The problem with it is it makes function
overloading a near impossibility to untangle.
We could quite easy add support for named parameters but still require
using the same position of the arguments. I don't know if those wanting
named parameters would be satisfied with this though.
I did implement something like that in DMD a while ago as an
experiment. See the comments below that commit:

https://github.com/michelf/dmd/commit/673bae4982ff18a3d216bc1578f50d40f4d26d7a

Walter pointed out that it should work for template arguments. I
agreed, devised a plan to restructure the whole thing to be less of a
hack and make it works for templates, then I had no more time to put on
this. :-(

This planned restructuring did lead to a transition to type-checked
arrays within DMD though, so the effort wasn't completely wasted.
--
Michel Fortin
michel.fortin at michelf.ca
http://michelf.ca
Jacob Carlborg
2014-03-01 17:18:17 UTC
Permalink
I did implement something like that in DMD a while ago as an experiment.
https://github.com/michelf/dmd/commit/673bae4982ff18a3d216bc1578f50d40f4d26d7a
I based the "quite easy" on the few changes needed in your implementation.
Walter pointed out that it should work for template arguments. I agreed,
devised a plan to restructure the whole thing to be less of a hack and
make it works for templates, then I had no more time to put on this. :-(
That happens too often :(
This planned restructuring did lead to a transition to type-checked
arrays within DMD though, so the effort wasn't completely wasted.
Nice :)
--
/Jacob Carlborg
Walter Bright
2014-02-27 20:46:32 UTC
Permalink
Post by Timothee Cour
import 'package:lib2/lib2.dart' hide foo; // Import all names EXCEPT foo.
As a general rule, negation features are frequently misunderstood, our brains
tend to just not see the negation. One should positively import names, not
negatively not import some.

And there's the maintenance problem - what did the importer mean to do when the
imported module adds a 'bar' name?
Walter Bright
2014-02-27 20:56:50 UTC
Permalink
* cascade operations: they perform a series of operations on the members of a
foo.bar(1)..baz(3)
foo.bar(1)
foo.baz(3)
D has ranges and algorithms to conveniently chain operations.
class Point {
num x;
num y;
num z;
// Syntactic sugar for setting z and x before the constructor body runs.
Point(this.z, this.x){...}
}
This is more explicit and flexible than D's way for default struct constructors,
which can only allow to set all fields in order, without skipping some, and
doesn't allow to do anything else in the ctor.
D doesn't allow non-trivial default struct constructors for some good reasons,
which are a long discussion we've had many times. These reasons don't apply to
javascript.
* named constructors
I don't see the point of such over using the factory method idiom.
* distinguish integer divide (~/) vs divide (/), so that 5/2=2, 5~/2=2
Such are needed so rarely - in C they are done with the modf function, and I've
never seen modf used in the wild.
* shorthand function declaration with => (used not just for lambdas)
tomayto, tomahto :-)
* for (var x in collection) //better syntax than foreach(var;collection)
tomayto, tomahto
void fun(int x, [int y, int z=3]){...}
Thinking of which, this would actually solve a long standing problem in D, that
void fun(T...)(T args, [string file=__FILE__,int line=__LINE__]){...}
Not sure what that is.
* export for libraries
What does that mean?
* async/wait etc
Those are a great idea, and we need to do them at some point.
bearophile
2014-02-27 22:40:12 UTC
Permalink
Post by Walter Bright
Post by Timothee Cour
* optional named parameters arguments (with simplest possible
syntax)
This comes up now and then. The problem with it is it makes
function overloading a near impossibility to untangle.
Do you have an example of the problem?
Post by Walter Bright
Post by Timothee Cour
class Point {
num x;
num y;
num z;
// Syntactic sugar for setting z and x before the
constructor body runs.
Point(this.z, this.x){...}
}
This is more explicit and flexible than D's way for default
struct constructors,
which can only allow to set all fields in order, without
skipping some, and
doesn't allow to do anything else in the ctor.
D doesn't allow non-trivial default struct constructors for
some good reasons, which are a long discussion we've had many
times. These reasons don't apply to javascript.
The idea of having some syntax like this is nice, it reduces the
poilerplace code, making the code less noisy and reducing the
probability of the currenty common bugs caused by having fields
and arguments with equal or similar names:

class Foo {
int x;
this(this.x) {}
void inc(int x) { this.x += x; }
}
Post by Walter Bright
Post by Timothee Cour
* shorthand function declaration with => (used not just for
lambdas)
tomayto, tomahto :-)
There is an enhancement request on this in Bugzilla.
A shorter syntax for simple functions is handy, because one-line
functions have become very common in D.

Bye,
bearophile
Timothee Cour
2014-02-28 00:49:37 UTC
Permalink
Post by Timothee Cour
* optional named parameters arguments (with simplest possible syntax)
Post by Walter Bright
This comes up now and then. The problem with it is it makes function
overloading a near impossibility to untangle.
Do you have an example of the problem?
Not sure what the problem would be. We could apply the same rules as for
template overloading, ie error when there's a potential ambiguity (or even
disable overloading for functions with named parameter until details are
ironed out). Many languages have this, for good reason (discussed, again,
many times).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140227/c58d635b/attachment.html>
Adam D. Ruppe
2014-02-28 01:02:16 UTC
Permalink
We could kinda do named parameters today like this:

ParameterTypeTuple!foo args;
args.named_param = 3;
foo(args);

It would be nice if we could declare a variable inside a
with(auto x = foo) like we can in if() too.
Timothee Cour
2014-02-28 00:29:12 UTC
Permalink
On Thu, Feb 27, 2014 at 12:56 PM, Walter Bright
Post by Walter Bright
* cascade operations: they perform a series of operations on the members of a
foo.bar(1)..baz(3)
foo.bar(1)
foo.baz(3)
D has ranges and algorithms to conveniently chain operations.
cascade != chaining:

cascade:
a.f1..f2..f3
<=>
a.f1
a.f2
a.f3

chaining:
a.f1.f2.f3
<=>
((a.f1).f2).f3)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140227/bb26efd7/attachment.html>
Timothee Cour
2014-02-28 00:42:03 UTC
Permalink
Post by Walter Bright
Post by Timothee Cour
void fun(int x, [int y, int z=3]){...}
Thinking of which, this would actually solve a long standing problem in D, that
void fun(T...)(T args, [string file=__FILE__,int line=__LINE__]){...}
Not sure what that is.
http://d.puremagic.com/issues/show_bug.cgi?id=8687 : Variadic templates do
not work properly with default arguments
Post by Walter Bright
* export for libraries
What does that mean?
http://wiki.dlang.org/DIP45
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140227/bdf66772/attachment.html>
Timothee Cour
2014-02-28 01:05:21 UTC
Permalink
Post by Walter Bright
Post by Timothee Cour
class Point {
num x;
num y;
num z;
// Syntactic sugar for setting z and x before the constructor body runs.
Point(this.z, this.x){...}
}
This is more explicit and flexible than D's way for default struct constructors,
which can only allow to set all fields in order, without skipping some, and
doesn't allow to do anything else in the ctor.
D doesn't allow non-trivial default struct constructors for some good
reasons, which are a long discussion we've had many times. These reasons
don't apply to javascript.
I don't recall this syntax 'Point(this.z, this.x){...}' ever being
discussed; can you please provide a link?

* it avoids the following common bug:

struct Point{int x;int y;}
auto a=Point(1,2,3);
//later on we add a field: struct Point{int x; int a; int y; }
//woops!

* less boilerplate / more DRY / more explicit:

struct Point{
Foo x=32;
Bar y;
Baz z;
this(this.y, this.z){} //instead of this(Bar y, Baz z){this.y=y;this.z=z;}
}


This is arguably a preferable syntax.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140227/6874b24a/attachment.html>
Loading...