www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - No household is perfect

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
http://www.reddit.com/r/programming/comments/1rx8r2/go_binary_sizes_are_growing_out_of_control/

http://www.reddit.com/r/programming/comments/1rvltx/scala_1_would_not_program_again/#new


Andrei
Dec 02 2013
next sibling parent reply Shammah Chancellor <anonymous coward.com> writes:
On 2013-12-03 00:36:28 +0000, Andrei Alexandrescu said:


 http://www.reddit.com/r/programming/comments/1rx8r2/go_binary_sizes_are_gro
ing_out_of_control/ 
 
 
 http://www.reddit.com/r/programming/comments/1rvltx/scala_1_would_no
_program_again/#new 
 
 
 
 Andrei


I find this particularly interesting.   Where is the interest in Scala 
being generated compared to D?

https://www.ohloh.net/languages/compare?measure=commits&percent=true&l0=scala&l1=dmd&l2=haskell&l3=-1
l4=-1&commit=Update 


-Shammah
Dec 02 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/2/13 6:49 PM, Shammah Chancellor wrote:

 On 2013-12-03 00:36:28 +0000, Andrei Alexandrescu said:


 http://www.reddit.com/r/programming/comments/1rx8r2/go_binary_sizes_are_growing_out_of_control/


 http://www.reddit.com/r/programming/comments/1rvltx/scala_1_would_not_program_again/#new



 Andrei


 I find this particularly interesting.   Where is the interest in Scala
 being generated compared to D?

 https://www.ohloh.net/languages/compare?measure=commits&percent=true&l0=scala&l1=dmd&l2=haskell&l3=-1&l4=-1&commit=Update


 -Shammah


The graph confirms what I believed - Scala is much more popular than D.

Odersky's response and the subsequent thread are interesting, too: 
https://groups.google.com/forum/?fromgroups#!topic/scala-debate/153H3Ya4Nxk


Andrei
Dec 02 2013
next sibling parent reply Shammah Chancellor <anonymous coward.com> writes:
On 2013-12-03 03:01:12 +0000, Andrei Alexandrescu said:


 On 12/2/13 6:49 PM, Shammah Chancellor wrote:

 On 2013-12-03 00:36:28 +0000, Andrei Alexandrescu said:
 

 http://www.reddit.com/r/programming/comments/1rx8r2/go_binary_sizes_are_gro
ing_out_of_control/ 
 
 
 
 http://www.reddit.com/r/programming/comments/1rvltx/scala_1_would_no
_program_again/#new 
 
 
 
 
 Andrei


 
 I find this particularly interesting.   Where is the interest in Scala
 being generated compared to D?
 
 https://www.ohloh.net/languages/compare?measure=commits&percent=true&l0=scala&l1=dmd&l2=haskell&l3=-1
l4=-1&commit=Update 
 
 
 
 -Shammah


 
 The graph confirms what I believed - Scala is much more popular than D.
 
 Odersky's response and the subsequent thread are interesting, too: 
 https://groups.google.com/forum/?fromgroups#!topic/scala-debate/153H3Ya4Nxk 
 
 
 Andrei



I don't understand it at all though.  I've been using D (off and on) 
since around 0.47.   It's a fanastic language much better than Scala.   
 Props to Walter, and you.    There are some rough edges, but I argue 
about them on this forum, and for the most part many of the things that 
I dislike, or want, have been added or changed in an acceptable way 
over the last 10 years.       I want to see this language succeed.  I 
tell everyone I know about it.

I burned out on D for awhile ago, but I've always poked my head in here 
a couple times a year, and am now using it for a fairly large project.  
 The reason I kept having to abandon it in the past was due to blocking 
compiler bugs with templates & CTFE, but with the new bugzilla I find 
that the bugs I submit are generally noted and fixed in a reasonable 
amount of time now.   I like that the community is more open now.  
There are some beasts who fix bugs really quickly in the frontend.

rant/
With that said, I am finding though that a lot of the documentation on 
the website is not maintained well by the community.   There are a lot 
of references to deprecated features, or things that don't work.   E.G. 
 scope'd calls allocation

scope Foo bar = new Foo;  is all over the documentation.  I've come to 
find out this is deprecated?

Or this message from 2012: 
http://forum.dlang.org/thread/20120411014440.GA12737 quickfur.ath.cx

The hash-map doc still makes reference to opHash 
(http://dlang.org/hash-map.html).  Which bit me when I copied and 
pasted.
/rant

I will try to do my part on updating these things.

-Shammah
Dec 02 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/2/2013 9:18 PM, Shammah Chancellor wrote:

 There are some beasts who fix bugs really quickly in the frontend.


Yup, we have a couple of really prodigious contributors to the complex bits of 
the front end.



 rant/
 With that said, I am finding though that a lot of the documentation on the
 website is not maintained well by the community.   There are a lot of
references
 to deprecated features, or things that don't work.   E.G. scope'd calls
allocation

 scope Foo bar = new Foo;  is all over the documentation.  I've come to find out
 this is deprecated?

 Or this message from 2012:
 http://forum.dlang.org/thread/20120411014440.GA12737 quickfur.ath.cx

 The hash-map doc still makes reference to opHash
 (http://dlang.org/hash-map.html).  Which bit me when I copied and pasted.
 /rant

 I will try to do my part on updating these things.


Thank you, we do need the help!
Dec 03 2013
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:


 Odersky's response and the subsequent thread are interesting, 
 too: 
 https://groups.google.com/forum/?fromgroups#!topic/scala-debate/153H3Ya4Nxk


An interesting idea:

Martin O.:

we should do something about operators. I like James Ward's idea 
to mandate an alphabetic alias for every operator - at least 
people would know how to pronounce them then.<


Bye,
bearophile
Dec 03 2013
next sibling parent reply "Tobias Pankrath" <tobias pankrath.net> writes:
On Tuesday, 3 December 2013 at 12:18:32 UTC, bearophile wrote:

 Andrei Alexandrescu:


 Odersky's response and the subsequent thread are interesting, 
 too: 
 https://groups.google.com/forum/?fromgroups#!topic/scala-debate/153H3Ya4Nxk


 An interesting idea:

 Martin O.:

we should do something about operators. I like James Ward's 
idea to mandate an alphabetic alias for every operator - at 
least people would know how to pronounce them then.<


 Bye,
 bearophile


Does scala have arbitrary operators like Haskell? Looks useless 
in D. If you have an operator '+' that should not be pronounced 
'plus' you are doing it wrong.
Dec 03 2013
parent reply Russel Winder <russel winder.org.uk> writes:
On Tue, 2013-12-03 at 13:29 +0100, Tobias Pankrath wrote:
[…]

 Does scala have arbitrary operators like Haskell? Looks useless 
 in D. If you have an operator '+' that should not be pronounced 
 'plus' you are doing it wrong.


Yes.

	a + b

could be set union, logic and, string concatenation. The + is just a
message to the LHS object, it determines what to do. This is the whole
basis for DSLs.

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Dec 03 2013
next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Tuesday, 3 December 2013 at 12:41:40 UTC, Russel Winder wrote:

 On Tue, 2013-12-03 at 13:29 +0100, Tobias Pankrath wrote:
 […]

 Does scala have arbitrary operators like Haskell? Looks 
 useless in D. If you have an operator '+' that should not be 
 pronounced 'plus' you are doing it wrong.


 Yes.

 	a + b

 could be set union, logic and, string concatenation. The + is 
 just a
 message to the LHS object, it determines what to do. This is 
 the whole
 basis for DSLs.


Fully agree, I still cannot understand why so many people have
problems seeing operators as function calls with different set of
letters, like so many languages allow.

Maybe I've spent too much time with math at the uni. :)

--
Paulo
Dec 03 2013
parent reply "eles" <eles eles.com> writes:
On Tuesday, 3 December 2013 at 14:25:50 UTC, Paulo Pinto wrote:

 On Tuesday, 3 December 2013 at 12:41:40 UTC, Russel Winder 
 wrote:

 On Tue, 2013-12-03 at 13:29 +0100, Tobias Pankrath wrote:





 Maybe I've spent too much time with math at the uni. :)


You mean std.uni? Seriously, let's change that name into 
std.unicode. std.uni it is just laughable (yes, flames, flames) 
and tells, well, nothing.
Dec 03 2013
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
eles:


 You mean std.uni? Seriously, let's change that name into 
 std.unicode.


I think he meant "Unicorn".

Bye,
bearophile
Dec 03 2013
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/3/2013 7:49 AM, eles wrote:

 You mean std.uni? Seriously, let's change that name into std.unicode.


"unicode" is trademarked and could cause us some problems. So, no.
Dec 03 2013
next sibling parent reply "Brad Anderson" <eco gnuk.net> writes:
On Tuesday, 3 December 2013 at 19:56:24 UTC, Walter Bright wrote:

 On 12/3/2013 7:49 AM, eles wrote:

 You mean std.uni? Seriously, let's change that name into 
 std.unicode.


 "unicode" is trademarked and could cause us some problems. So, 
 no.


Huh...sure enough:

The Unicode Consortium Name and Trademark Usage Policy: 
http://www.unicode.org/policies/logo_policy.html
Dec 03 2013
parent "eles" <eles eles.com> writes:
On Tuesday, 3 December 2013 at 21:12:36 UTC, Brad Anderson wrote:

 On Tuesday, 3 December 2013 at 19:56:24 UTC, Walter Bright 
 wrote:

 On 12/3/2013 7:49 AM, eles wrote:





 The Unicode Consortium Name and Trademark Usage Policy: 
 http://www.unicode.org/policies/logo_policy.html


Yeah, bad.

D allows unicode source, so you could name the module

std.Unicode®

;)

no, I was joking. but I am sad 'bout it
Dec 04 2013
prev sibling next sibling parent reply =?UTF-8?B?Ikx1w61z?= Marques" <luis luismarques.eu> writes:
On Tuesday, 3 December 2013 at 19:56:24 UTC, Walter Bright wrote:

 "unicode" is trademarked and could cause us some problems. So, 
 no.


That seems unlikely. Also, it's not that different from 
std.windows, std.linux, etc.
Dec 04 2013
next sibling parent "Parke" <parke.nexus gmail.com> writes:
On Wednesday, 4 December 2013 at 17:21:24 UTC, Luís Marques wrote:

 On Tuesday, 3 December 2013 at 19:56:24 UTC, Walter Bright 
 wrote:

 "unicode" is trademarked and could cause us some problems. So, 
 no.


 That seems unlikely. Also, it's not that different from 
 std.windows, std.linux, etc.


Also, "unicode" is a standard type in Python 2.7.
Dec 04 2013
prev sibling parent reply "Kapps" <opantm2+spam gmail.com> writes:
On Wednesday, 4 December 2013 at 17:21:24 UTC, Luís Marques wrote:

 On Tuesday, 3 December 2013 at 19:56:24 UTC, Walter Bright 
 wrote:

 "unicode" is trademarked and could cause us some problems. So, 
 no.


 That seems unlikely. Also, it's not that different from 
 std.windows, std.linux, etc.


 From http://www.unicode.org/policies/logo_policy.html :

You may use the Unicode Word Mark to refer to the Unicode® 
Standard, to other Unicode® specifications, tools and code, and 
to Unicode® seminars, tutorials, meetings, and events, so long as 
any such references (a) are truthful, fair, and not misleading, 
and (b) follow these Guidelines.

     Always use “Unicode” as an adjective followed by an 
appropriate noun. Do not use “Unicode” alone as a noun. Do not 
pluralize it or make it possessive, and do not alter its spelling.
     Use the ® symbol to indicate that the Unicode Mark is a 
registered trademark. The symbol should be used in all prominent 
references to the Unicode Mark, such as headlines, chapter 
titles, packaging, advertising, etc. The symbol should also be 
used in the first reference to the Unicode Mark in body copy, but 
may thereafter be omitted in body copy.
     Use the appropriate Trademark Legend (see below) in the 
footnotes or footers of any material making reference to the 
Unicode Mark.

Incorrect: Unicode
Correct: The Unicode® Standard


I was rather surprised by this.
Dec 04 2013
parent reply Marco Leise <Marco.Leise gmx.de> writes:
Am Thu, 05 Dec 2013 06:16:14 +0100
schrieb "Kapps" <opantm2+spam gmail.com>:


 On Wednesday, 4 December 2013 at 17:21:24 UTC, Lu=C3=ADs Marques wrote:

 On Tuesday, 3 December 2013 at 19:56:24 UTC, Walter Bright=20
 wrote:

 "unicode" is trademarked and could cause us some problems. So,=20
 no.


 That seems unlikely. Also, it's not that different from=20
 std.windows, std.linux, etc.


=20
  From http://www.unicode.org/policies/logo_policy.html :
=20
 You may use the Unicode Word Mark to refer to the Unicode=C2=AE=20
 Standard, to other Unicode=C2=AE specifications, tools and code, and=20
 to Unicode=C2=AE seminars, tutorials, meetings, and events, so long as=20
 any such references (a) are truthful, fair, and not misleading,=20
 and (b) follow these Guidelines.
=20
      Always use =E2=80=9CUnicode=E2=80=9D as an adjective followed by an=


=20

 appropriate noun. Do not use =E2=80=9CUnicode=E2=80=9D alone as a noun. D=


o not=20

 pluralize it or make it possessive, and do not alter its spelling.
      Use the =C2=AE symbol to indicate that the Unicode Mark is a=20
 registered trademark. The symbol should be used in all prominent=20
 references to the Unicode Mark, such as headlines, chapter=20
 titles, packaging, advertising, etc. The symbol should also be=20
 used in the first reference to the Unicode Mark in body copy, but=20
 may thereafter be omitted in body copy.
      Use the appropriate Trademark Legend (see below) in the=20
 footnotes or footers of any material making reference to the=20
 Unicode Mark.
=20
 Incorrect: Unicode
 Correct: The Unicode=C2=AE Standard
=20
=20
 I was rather surprised by this.


No word about naming a module or a keyword 'unicode'. I would
be surprised if someone asked if D could have a module named
std.unicode and they said "no". Our use would be "truthful,
fair and not misleading" and isn't a "prominent reference".
But the current module name is ok for me, too.

--=20
Marco
Dec 04 2013
parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Thursday, 5 December 2013 at 06:04:20 UTC, Marco Leise wrote:

 Am Thu, 05 Dec 2013 06:16:14 +0100
 schrieb "Kapps" <opantm2+spam gmail.com>:


 On Wednesday, 4 December 2013 at 17:21:24 UTC, Luís Marques 
 wrote:

 On Tuesday, 3 December 2013 at 19:56:24 UTC, Walter Bright 
 wrote:

 "unicode" is trademarked and could cause us some problems. 
 So, no.


 That seems unlikely. Also, it's not that different from 
 std.windows, std.linux, etc.


 
  From http://www.unicode.org/policies/logo_policy.html :
 
 You may use the Unicode Word Mark to refer to the Unicode® 
 Standard, to other Unicode® specifications, tools and code, 
 and to Unicode® seminars, tutorials, meetings, and events, so 
 long as any such references (a) are truthful, fair, and not 
 misleading, and (b) follow these Guidelines.
 
      Always use “Unicode” as an adjective followed by an 
 appropriate noun. Do not use “Unicode” alone as a noun. Do not 
 pluralize it or make it possessive, and do not alter its 
 spelling.
      Use the ® symbol to indicate that the Unicode Mark is a 
 registered trademark. The symbol should be used in all 
 prominent references to the Unicode Mark, such as headlines, 
 chapter titles, packaging, advertising, etc. The symbol should 
 also be used in the first reference to the Unicode Mark in 
 body copy, but may thereafter be omitted in body copy.
      Use the appropriate Trademark Legend (see below) in the 
 footnotes or footers of any material making reference to the 
 Unicode Mark.
 
 Incorrect: Unicode
 Correct: The Unicode® Standard
 
 
 I was rather surprised by this.


 No word about naming a module or a keyword 'unicode'. I would
 be surprised if someone asked if D could have a module named
 std.unicode and they said "no". Our use would be "truthful,
 fair and not misleading" and isn't a "prominent reference".
 But the current module name is ok for me, too.


Having read all that though, one could argue that having "uni" is 
*even worst* than "unicode", as it violates both:
a) Use the ® symbol to indicate that the Unicode Mark
b) Do not alter its spelling

I don't care much about uni vs unicode, but I think siding with 
"uni" for copyright reasons is a fallacious argument.

Besides, I don't see where the problem with naming the 
file/module "std/unicode.d"/"std.unidoe" is, as long as the first 
paragraph reads: "This is the Unicode® module".
Dec 05 2013
parent =?UTF-8?B?Ikx1w61z?= Marques" <luis luismarques.eu> writes:
On Thursday, 5 December 2013 at 08:06:35 UTC, monarch_dodra wrote:

 Having read all that though, one could argue that having "uni" 
 is *even worst* than "unicode", as it violates both:
 a) Use the ® symbol to indicate that the Unicode Mark
 b) Do not alter its spelling

 I don't care much about uni vs unicode, but I think siding with 
 "uni" for copyright reasons is a fallacious argument.


(mind you, copyright is different from trademark!)

I didn't tell you this before, but I actually informally asked an 
IP lawyer about this situation and he told me that, in general, 
stating facts of the trademark is fine, as long as one is not 
implying it is authorized, etc.

I think this use is not a problem, both in terms of the letter of 
the law and my personal judgement of how likely it would be for 
the Unicode Consortium to complain. For instance, see:

"Nominative fair use. This is when a potential infringer (or 
defendant) uses the registered trademark to identify the 
trademark holder's product or service in conjunction with his or 
her own. To invoke this defense, the defendant must prove the 
following elements:
* the product or service cannot be readily identified without the 
mark
* he/she only uses as much of the mark as is necessary to 
identify the goods or services
* he/she does nothing with the mark to suggest that the trademark 
holder has given his approval to the defendant
"

The unicode module uses the word Unicode to refer to facts about 
the Unicode Standard. If you want to, in the docs, add a few ® 
symbols, use quotes around "Unicode" and "The Unicode Standard", 
add a notice that the word is a trademark, etc., I think that is 
fine. Stopping the use of the word Unicode in the language and 
documentation because it is a trademark seems to me to be 
overthinking it. This is a factual use, just don't imply that the 
consortium approves anything of the D module and documentation. 
The rights of a trademark owner are *not* absolute, and if 
anything I'd expect them to complain about the current use of 
"Unicode" in the docs (which can easily be fixed) than the use of 
"unicode" in the module name (where it is reasonable not to use 
the ® symbol due to technical and practical reasons). Really, 
just don't overthink it. It's not like this issue would be 
specific to D (Python uses "unicode", as someone said) or to 
Unicode (the docs use several other trademarks, without 
mentioning that they are trademarks...)
Dec 10 2013
prev sibling parent "eles" <eles eles.com> writes:
On Tuesday, 3 December 2013 at 19:56:24 UTC, Walter Bright wrote:

 On 12/3/2013 7:49 AM, eles wrote:

 You mean std.uni? Seriously, let's change that name into 
 std.unicode.


 "unicode" is trademarked and could cause us some problems. So, 
 no.


http://www.erlang.org/doc/man/unicode.html
Dec 05 2013
prev sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 03.12.2013 16:49, schrieb eles:

 On Tuesday, 3 December 2013 at 14:25:50 UTC, Paulo Pinto wrote:

 On Tuesday, 3 December 2013 at 12:41:40 UTC, Russel Winder wrote:

 On Tue, 2013-12-03 at 13:29 +0100, Tobias Pankrath wrote:





 Maybe I've spent too much time with math at the uni. :)


 You mean std.uni? Seriously, let's change that name into std.unicode.
 std.uni it is just laughable (yes, flames, flames) and tells, well,
 nothing.


It is my daily German creeping into my English, uni => University.

--
Paulo
Dec 03 2013
parent "eles" <eles eles.com> writes:
On Tuesday, 3 December 2013 at 20:42:01 UTC, Paulo Pinto wrote:

 Am 03.12.2013 16:49, schrieb eles:

 On Tuesday, 3 December 2013 at 14:25:50 UTC, Paulo Pinto wrote:

 On Tuesday, 3 December 2013 at 12:41:40 UTC, Russel Winder 
 wrote:

 On Tue, 2013-12-03 at 13:29 +0100, Tobias Pankrath wrote:









 It is my daily German creeping into my English, uni => 
 University.


it is my daily D rant, uni => unicode
Dec 04 2013
prev sibling next sibling parent "Tobias Pankrath" <tobias pankrath.net> writes:
On Tuesday, 3 December 2013 at 12:41:40 UTC, Russel Winder wrote:

 On Tue, 2013-12-03 at 13:29 +0100, Tobias Pankrath wrote:
 […]

 Does scala have arbitrary operators like Haskell? Looks 
 useless in D. If you have an operator '+' that should not be 
 pronounced 'plus' you are doing it wrong.


 Yes.

 	a + b

 could be set union, logic and, string concatenation. The + is 
 just a
 message to the LHS object, it determines what to do. This is 
 the whole
 basis for DSLs.



I really have no problem with operator overloading, but set union 
(∪), logic and (∧) and string concatenation (∘) do have well 
defined and commonly used symbols.

I would not argue against adding these to the language via a 
general mechanism and indeed then it might be useful to have a 
name for a user defined wtf-operator ?!?!. But if you overload an 
operator (+) it should be some kind of addition.
Dec 03 2013
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/3/13 4:41 AM, Russel Winder wrote:

 On Tue, 2013-12-03 at 13:29 +0100, Tobias Pankrath wrote:
 […]

 Does scala have arbitrary operators like Haskell? Looks useless
 in D. If you have an operator '+' that should not be pronounced
 'plus' you are doing it wrong.


 Yes.

 	a + b

 could be set union, logic and, string concatenation. The + is just a
 message to the LHS object


or RHS :o).


Andrei
Dec 03 2013
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 12/3/13 4:53 PM, Andrei Alexandrescu wrote:

 On 12/3/13 4:41 AM, Russel Winder wrote:

 On Tue, 2013-12-03 at 13:29 +0100, Tobias Pankrath wrote:
 […]

 Does scala have arbitrary operators like Haskell? Looks useless
 in D. If you have an operator '+' that should not be pronounced
 'plus' you are doing it wrong.


 Yes.

     a + b

 could be set union, logic and, string concatenation. The + is just a
 message to the LHS object


 or RHS :o).


How come?
Dec 03 2013
parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Tuesday, 3 December 2013 at 20:09:52 UTC, Ary Borenszweig 
wrote:

 On 12/3/13 4:53 PM, Andrei Alexandrescu wrote:

 On 12/3/13 4:41 AM, Russel Winder wrote:

 On Tue, 2013-12-03 at 13:29 +0100, Tobias Pankrath wrote:
 […]

 Does scala have arbitrary operators like Haskell? Looks 
 useless
 in D. If you have an operator '+' that should not be 
 pronounced
 'plus' you are doing it wrong.


 Yes.

    a + b

 could be set union, logic and, string concatenation. The + is 
 just a
 message to the LHS object


 or RHS :o).


 How come?


"opBinaryRight":
http://dlang.org/operatoroverloading.html

It's a "neat" feature that allows operators being member 
functions, yet still resolve to the right hand side if needed. 
For example:
auto result = 1 + complex(1, 1);

Will compile, and be re-written as:
auto result = complex(1, 1).opBinaryRight!"+"(1);

In contrast, C++ has to resort to non-member friend operators to 
make this work.
Dec 03 2013
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 12/3/13 7:23 PM, monarch_dodra wrote:

 On Tuesday, 3 December 2013 at 20:09:52 UTC, Ary Borenszweig wrote:

 On 12/3/13 4:53 PM, Andrei Alexandrescu wrote:

 On 12/3/13 4:41 AM, Russel Winder wrote:

 On Tue, 2013-12-03 at 13:29 +0100, Tobias Pankrath wrote:
 […]

 Does scala have arbitrary operators like Haskell? Looks useless
 in D. If you have an operator '+' that should not be pronounced
 'plus' you are doing it wrong.


 Yes.

    a + b

 could be set union, logic and, string concatenation. The + is just a
 message to the LHS object


 or RHS :o).


 How come?


 "opBinaryRight":
 http://dlang.org/operatoroverloading.html

 It's a "neat" feature that allows operators being member functions, yet
 still resolve to the right hand side if needed. For example:
 auto result = 1 + complex(1, 1);

 Will compile, and be re-written as:
 auto result = complex(1, 1).opBinaryRight!"+"(1);

 In contrast, C++ has to resort to non-member friend operators to make
 this work.


That's nice.

Of course, it's not needed if you overload "+" for the int type to 
receive a complex.
Dec 04 2013
parent reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Wednesday, 4 December 2013 at 13:39:32 UTC, Ary Borenszweig 
wrote:

 That's nice.

 Of course, it's not needed if you overload "+" for the int type 
 to receive a complex.


The point is that D does not have operator overloading for 
in-built types. The unnecessary one is the global operator 
overload you suggest, as it is more intrusive than 
`opBinaryRight`.
Dec 04 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/4/2013 5:50 AM, Jakob Ovrum wrote:

 The point is that D does not have operator overloading for in-built types. The
 unnecessary one is the global operator overload you suggest, as it is more
 intrusive than `opBinaryRight`.


The bad thing about the global operator overloading is that it:

1. follows different scoping and lookup rules

2. was the motivation for ADL (aka "Koenig Lookup")

There was no way I was going to put ADL into D :-)
Dec 04 2013
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 12/04/2013 06:11 PM, Walter Bright wrote:

 On 12/4/2013 5:50 AM, Jakob Ovrum wrote:

 The point is that D does not have operator overloading for in-built
 types. The
 unnecessary one is the global operator overload you suggest, as it is
 more
 intrusive than `opBinaryRight`.


 The bad thing about the global operator overloading is that it:

 1. follows different scoping and lookup rules

 2. was the motivation for ADL (aka "Koenig Lookup")

 There was no way I was going to put ADL into D :-)


Makes sense, but I'd argue that whenever a.opBinaryRight!"+"(b) is 
valid, then a + b should be valid. (Also, the converse. Built-in types 
do not need to behave specially.)
Dec 04 2013
prev sibling parent "Tobias Pankrath" <tobias pankrath.net> writes:
On Wednesday, 4 December 2013 at 17:11:07 UTC, Walter Bright 
wrote:

 2. was the motivation for ADL (aka "Koenig Lookup")

 There was no way I was going to put ADL into D :-)


---
// lib.d
struct Struct {}
// more.d
import lib.d
int front(Struct s) {}
void popFront(ref Struct s) {}
// main.d
import lib;
import more;

import std.range;

pragma(msg, isInputRange!(Struct)); // outputs 'false'
void main() {}
---

Any plans/ways to make external methods work here?
Dec 11 2013
prev sibling parent Marco Leise <Marco.Leise gmx.de> writes:
Am Tue, 03 Dec 2013 23:23:07 +0100
schrieb "monarch_dodra" <monarchdodra gmail.com>:


 On Tuesday, 3 December 2013 at 20:09:52 UTC, Ary Borenszweig=20
 wrote:

 On 12/3/13 4:53 PM, Andrei Alexandrescu wrote:

 On 12/3/13 4:41 AM, Russel Winder wrote:

 On Tue, 2013-12-03 at 13:29 +0100, Tobias Pankrath wrote:
 [=E2=80=A6]

 Does scala have arbitrary operators like Haskell? Looks=20
 useless
 in D. If you have an operator '+' that should not be=20
 pronounced
 'plus' you are doing it wrong.


 Yes.

    a + b

 could be set union, logic and, string concatenation. The + is=20
 just a
 message to the LHS object


 or RHS :o).


 How come?


=20
 "opBinaryRight":
 http://dlang.org/operatoroverloading.html
=20
 It's a "neat" feature that allows operators being member=20
 functions, yet still resolve to the right hand side if needed.=20
 For example:
 auto result =3D 1 + complex(1, 1);
=20
 Will compile, and be re-written as:
 auto result =3D complex(1, 1).opBinaryRight!"+"(1);
=20
 In contrast, C++ has to resort to non-member friend operators to=20
 make this work.


In this case I agree, but when porting some vector/matrix
code from C++ I found it hard to reproduce everything in D.
I can't quite remember the details, but I think it had to do
with mutual opOpAssign of classes in separate modules.

--=20
Marco
Dec 04 2013
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/3/2013 4:41 AM, Russel Winder wrote:

 Yes.

 	a + b

 could be set union, logic and, string concatenation. The + is just a
 message to the LHS object, it determines what to do. This is the whole
 basis for DSLs.


Using operator overloading to create a DSL is just wrong. Part of the design of 
operator overloading in D is to deliberately frustrate such attempts.

+ should mean addition, not union, concatenation, etc. Overloading is there to 
support addition on user defined types, not to invent new meanings for it.

Embedded DSLs should be visually distinct, and D provides the ability for that 
with string mixins and CTFE.


Part of my opinion for this comes from C++ regexes done using expression 
templates. It's cute and clever, but it's madness. For one, any sort of errors 
coming out of it if a mistake is made are awesomely incomprehensible. For 
another, there's no clue in the source code when one has slipped into DSL-land, 
and suddenly * doesn't mean pointer dereference, it means "0 or more".

Utter madness.
Dec 03 2013
next sibling parent reply "Brad Anderson" <eco gnuk.net> writes:
On Tuesday, 3 December 2013 at 20:06:49 UTC, Walter Bright wrote:

 On 12/3/2013 4:41 AM, Russel Winder wrote:

 Yes.

 	a + b

 could be set union, logic and, string concatenation. The + is 
 just a
 message to the LHS object, it determines what to do. This is 
 the whole
 basis for DSLs.


 Using operator overloading to create a DSL is just wrong. Part 
 of the design of operator overloading in D is to deliberately 
 frustrate such attempts.

 + should mean addition, not union, concatenation, etc. 
 Overloading is there to support addition on user defined types, 
 not to invent new meanings for it.

 Embedded DSLs should be visually distinct, and D provides the 
 ability for that with string mixins and CTFE.


 Part of my opinion for this comes from C++ regexes done using 
 expression templates. It's cute and clever, but it's madness. 
 For one, any sort of errors coming out of it if a mistake is 
 made are awesomely incomprehensible. For another, there's no 
 clue in the source code when one has slipped into DSL-land, and 
 suddenly * doesn't mean pointer dereference, it means "0 or 
 more".

 Utter madness.


Indeed. I had a regex bottleneck in a C++ program so I figured 
I'd just convert it to Boost Xpressive as an easy solution. It 
took me half a day to convert the regular expression into the 
convoluted single line of code with dozens of operators it 
became. It did run faster (phew!) so it was worth it but the code 
is unrecognizable as a regular expression and I have to keep a 
comment with the original regular expression in the code because 
nobody (myself included) should have to spend an ungodly amount 
of time trying to decipher the cryptic source code it became.

If my program were written in D I would have just replaced 
"regex(" with "ctRegex!(" and moved on with my day.
Dec 03 2013
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Dec 03, 2013 at 09:19:34PM +0100, Brad Anderson wrote:

 On Tuesday, 3 December 2013 at 20:06:49 UTC, Walter Bright wrote:

On 12/3/2013 4:41 AM, Russel Winder wrote:

Yes.

	a + b

could be set union, logic and, string concatenation. The + is just a
message to the LHS object, it determines what to do. This is the
whole basis for DSLs.






Ugh. Ugh, ugh, ugh. This beckons to that horrid decision in C++'s
<iostream> of overloading << to mean "output" and >> to mean "input".
The only redeeming quality about this is that << and >> are relatively
rarely used in their original sense (bitwise shifts), so it doesn't
cause as much of a cognitive dissonance as it otherwise might. But
still. Ugh. There are just so many things wrong with this choice, not
the least of which is the fact that the operator precedence of << and >>
makes no sense when used as I/O operators -- because said operators were
never intended to be I/O in the first place!! This leads to such fun as:

	int a, b;
	cout << a < b;	// what does this do?
			// (hint: it does NOT output the value of a < b)

Ugh!



Using operator overloading to create a DSL is just wrong. Part of
the design of operator overloading in D is to deliberately
frustrate such attempts.




+1.



+ should mean addition, not union, concatenation, etc. Overloading
is there to support addition on user defined types, not to invent
new meanings for it.




There's a C++ library that overloads the *comma operator* (!!) to allow
you to do things like this:

	// Creates a 3x4 matrix (!)
	A = 1, 2,  3, 4,
	    5, 6,  7, 8,
	    9, 10, 11, 12;

Now, this particular example looks rather cute, but let's say we want to
compute matrix elements as we construct it:

	// Creates a 3x4 matrix (what, really?!)
	A = x++, y++, z++, f(x+y),
	    y+2*x-z, 4*y, 5*(z-y*x),
	    f(x)-f(y), f(z), g(x), 0;

Seriously?? Anyone who understands what a comma operator is (which is
itself already a Bad Idea) might imagine this is but a needlessly
obscure way of setting A to 0 while performing a whole bunch of
side-effects, in a way fitting for an IOCCC entry.

(And just in case you wonder: the dimensions of the matrix are
determined beforehand. So technically, you *could* create a 3x4 matrix
using this code:

	// Yes this is still a 3x4 matrix... and yes the first row
	// contains 1, 2, 3, 4, and the second row starts with 5.
	// Obvious, isn't it?
	A = 1,  2,  3,
	    4,  5,  6,
	    7,  8,  9,
	    10, 11, 12;

Or, indeed, this:

	// This is a 3x4 matrix too, even though it sure doesn't look
	// anything like it!!
	A = 1, 2, 3, 4,  5,  6,
	    7, 8, 9, 10, 11, 12;

Please, somebody tell me how this can even remotely be construed to be a
good thing.)

Not to mention, the meaning of such code depends entirely up the type of
A. What if I have another custom type that also overloads the comma
operator, in a slightly different way? Then the semantics of the above
snippets would be *completely* different yet again.

Now tell me again, why is C++ code so hard to maintain? Hmmm...



Embedded DSLs should be visually distinct, and D provides the
ability for that with string mixins and CTFE.




String mixins + CTFE = teh r0ckz when it comes to DSLs.

After having experienced C++ for a decade or two, I've come to decide
that operator overloading is a Bad Idea(tm), except when it applies
strictly to custom numerical types that are intended to behave like
built-in numerical types. All other uses of operator overloading are,
strictly speaking, abusive, and lead to unmaintainable code. Yes, it's
cute and clever, and lets you write things not supported by the language
"directly", but the next person to inherit your code will curse your
name when they spend 5 hours trying to figure out exactly why x+y didn't
do what they thought it did. And that's just with *one* library that
overloads operators in an unusual way. Now add a second, third, fourth
library, each of which overloads the operators in an unusual way, and
you might as well be submitting your code as IOCCC entries (except that
they don't take C++ entries).

OTOH, I completely understand the desire for infix notation for
operators on custom types. If you're writing a set library, it sucks to
have to write a.union(b.intersection(c)) when what you *really* want is
to write: a ∪ (b ∩ c). Here is where D does it right: use a compile-time
string argument to a CTFE function that transforms this string into
code. Then you can write:

	Set a, b, c;
	auto d = mixin(SetExpr!"a ∪ (b ∩ c)");
		// The above line gets turned into:
		// auto d = a.union(b.intersection(c));
		// at compile-time.

So you can write your set expressions the "natural" way, *and* a new
reader of your code will know to look for SetExpr's documentation to
understand what the string argument does (not to mention it being amply
clear that a DSL is involved here, rather than code that looks like
normal numerical expressions but actually does something else).

This has even more benefits than fixing C++'s wrong approach, though:

For one thing, overloaded operators can't easily generate optimal code,
because they just get translated into nested function calls. In order to
be able to optimize, say, a ∪ a ∪ a into a no-op, in C++'s approach
you'd have to resort to arcane black magic like expression templates to
coax the compiler to do what you want. In D, you are parsing the
expression as a *string*, which means you get to define how the string
is parsed, and how it is to be transformed into code, *directly*. You
can run the expression tree through an expression simplifier algorithm,
for example, factor common subexpressions, reduce it using known
identities, etc.. All of which, granted, can be done by expression
templates, except with many more times the pain, proneness to bugs, and
unmaintainability.

These string DSLs also let you define your own operators (like I did
above) without needing to abuse existing operators like + and *, define
your own operator precedence rules, define custom syntax without needing
to twist and warp it to conform to host language syntax (like that C++
regex library, which honestly makes me cringe every time I look at its
contorted syntax).



Part of my opinion for this comes from C++ regexes done using
expression templates. It's cute and clever, but it's madness. For
one, any sort of errors coming out of it if a mistake is made are
awesomely incomprehensible. For another, there's no clue in the
source code when one has slipped into DSL-land, and suddenly *
doesn't mean pointer dereference, it means "0 or more".

Utter madness.




Yeah, that library, while admittedly very clever, is total madness. It
looks *nothing* like what regexen normally look like, does something
completely unlike what its surface syntax might suggest, and is in
pretty much every way very difficult to understand, and therefore hard
to maintain and prone to bugs. In today's software development world,
where there's too much code to comprehend and too little time to
comprehend it, dissociating syntax from its usual meaning is just asking
for maintenance nightmares.



 Indeed. I had a regex bottleneck in a C++ program so I figured I'd
 just convert it to Boost Xpressive as an easy solution. It took me
 half a day to convert the regular expression into the convoluted
 single line of code with dozens of operators it became. It did run
 faster (phew!) so it was worth it but the code is unrecognizable as
 a regular expression and I have to keep a comment with the original
 regular expression in the code because nobody (myself included)
 should have to spend an ungodly amount of time trying to decipher
 the cryptic source code it became.
 
 If my program were written in D I would have just replaced "regex("
 with "ctRegex!(" and moved on with my day.


Yeah!! Props to std.regex!


T

-- 
Why can't you just be a nonconformist like everyone else? -- YHL
Dec 03 2013
parent reply "Joshua Niehus" <jm.niehus gmail.com> writes:
On Tuesday, 3 December 2013 at 22:28:26 UTC, H. S. Teoh wrote:

[snip] Then you can write:

 	Set a, b, c;
 	auto d = mixin(SetExpr!"a ∪ (b ∩ c)");
 		// The above line gets turned into:
 		// auto d = a.union(b.intersection(c));
 		// at compile-time.

 So you can write your set expressions the "natural" way, *and* 
 [snip]


This would make for a good blog post/wiki article.  Does one 
already exist?
Dec 03 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Joshua Niehus:


 This would make for a good blog post/wiki article.  Does one 
 already exist?


If you have a AST macros like in Julia language, I think you can 
write something like:

 setExpr(a ∪ (b ∩ c));

The main difference is that the compiler gives you a tree in the 
macro to work on, instead of a string to parse and munge.

Bye,
bearophile
Dec 03 2013
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Dec 04, 2013 at 04:23:59AM +0100, bearophile wrote:

 Joshua Niehus:
 

This would make for a good blog post/wiki article.  Does one
already exist?


 
 If you have a AST macros like in Julia language, I think you can
 write something like:
 
  setExpr(a ∪ (b ∩ c));
 
 The main difference is that the compiler gives you a tree in the
 macro to work on, instead of a string to parse and munge.


[...]

The problem with having the compiler parse it is that it has to be in a
syntax understood by the compiler. If your DSL needs a radically
different syntax, it won't work (e.g., regex: how is the compiler to
know '+' is a postfix operator instead of an infix one?).

By having a compile-time string as input, you have maximum flexibility.
It's essentially writing a mini-compiler embedded in D, because it runs
in CTFE.


T

-- 
You are only young once, but you can stay immature indefinitely. -- azephrahel
Dec 04 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/4/13 7:06 AM, H. S. Teoh wrote:

 On Wed, Dec 04, 2013 at 04:23:59AM +0100, bearophile wrote:

 Joshua Niehus:


 This would make for a good blog post/wiki article.  Does one
 already exist?


 If you have a AST macros like in Julia language, I think you can
 write something like:

  setExpr(a ∪ (b ∩ c));

 The main difference is that the compiler gives you a tree in the
 macro to work on, instead of a string to parse and munge.


 [...]

 The problem with having the compiler parse it is that it has to be in a
 syntax understood by the compiler. If your DSL needs a radically
 different syntax, it won't work (e.g., regex: how is the compiler to
 know '+' is a postfix operator instead of an infix one?).

 By having a compile-time string as input, you have maximum flexibility.
 It's essentially writing a mini-compiler embedded in D, because it runs
 in CTFE.


Yah, my thoughts exactly. Looks like we're in a sweet spot there.

Andrei
Dec 04 2013
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
04-Dec-2013 20:22, Andrei Alexandrescu пишет:

 On 12/4/13 7:06 AM, H. S. Teoh wrote:

 On Wed, Dec 04, 2013 at 04:23:59AM +0100, bearophile wrote:

 Joshua Niehus:


 This would make for a good blog post/wiki article.  Does one
 already exist?


 If you have a AST macros like in Julia language, I think you can
 write something like:

  setExpr(a ∪ (b ∩ c));

 The main difference is that the compiler gives you a tree in the
 macro to work on, instead of a string to parse and munge.


 [...]

 The problem with having the compiler parse it is that it has to be in a
 syntax understood by the compiler. If your DSL needs a radically
 different syntax, it won't work (e.g., regex: how is the compiler to
 know '+' is a postfix operator instead of an infix one?).

 By having a compile-time string as input, you have maximum flexibility.
 It's essentially writing a mini-compiler embedded in D, because it runs
 in CTFE.


 Yah, my thoughts exactly. Looks like we're in a sweet spot there.


I'll just add a bit of my experience on this.

The coolest side of things is that you get to code a mini-compiler that 
has a very nice backend - D code. More then that you get optimizer and 
such for free. Then you only do the fun stuff - your frontend, and if it 
wasn't for CTFE speed/stability the experience is _very_ pleasant.

Compare that with writing a fully fledged JIT compiler for say, regex 
patterns. Don't forget to account that you'd need to port it to X 
architectures times Y OS ABIs and generate code of at least moderate 
quality.

JIT would have the benefit of being usable for patterns not known ahead 
of time though.

-- 
Dmitry Olshansky
Dec 04 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-12-04 19:55, Dmitry Olshansky wrote:


 I'll just add a bit of my experience on this.

 The coolest side of things is that you get to code a mini-compiler that
 has a very nice backend - D code. More then that you get optimizer and
 such for free. Then you only do the fun stuff - your frontend, and if it
 wasn't for CTFE speed/stability the experience is _very_ pleasant.


With AST macros it would be the same thing, just that you don't need to 
code the mini-compiler. It's already done for you.


 Compare that with writing a fully fledged JIT compiler for say, regex
 patterns. Don't forget to account that you'd need to port it to X
 architectures times Y OS ABIs and generate code of at least moderate
 quality.

 JIT would have the benefit of being usable for patterns not known ahead
 of time though.


AST macros would generate a new AST, no need to create a JIT compiler. 
The advantage of AST macros is that the compiler doesn't need to re-lex 
and re-parse the result.

-- 
/Jacob Carlborg
Dec 05 2013
parent reply "Don" <x nospam.com> writes:
On Thursday, 5 December 2013 at 08:17:01 UTC, Jacob Carlborg 
wrote:

 On 2013-12-04 19:55, Dmitry Olshansky wrote:


 I'll just add a bit of my experience on this.

 The coolest side of things is that you get to code a 
 mini-compiler that
 has a very nice backend - D code. More then that you get 
 optimizer and
 such for free. Then you only do the fun stuff - your frontend, 
 and if it
 wasn't for CTFE speed/stability the experience is _very_ 
 pleasant.


 With AST macros it would be the same thing, just that you don't 
 need to code the mini-compiler. It's already done for you.


 Compare that with writing a fully fledged JIT compiler for 
 say, regex
 patterns. Don't forget to account that you'd need to port it 
 to X
 architectures times Y OS ABIs and generate code of at least 
 moderate
 quality.

 JIT would have the benefit of being usable for patterns not 
 known ahead
 of time though.


 AST macros would generate a new AST, no need to create a JIT 
 compiler. The advantage of AST macros is that the compiler 
 doesn't need to re-lex and re-parse the result.


I think that is of negligible benefit. There's not a whole of 
difference between manipulating an AST, vs manipulating text, and 
I'm confident that the time taken to do that is always going to 
be far more than the time required to lex and parse text.

What AST macros could provide is syntax sugar.
But IMHO there's a lot more to be gained from improvements to 
compile time reflection.
Dec 05 2013
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 12/05/2013 10:25 AM, Don wrote:

 But IMHO there's a lot more to be gained from improvements to compile
 time reflection.


In particular, improvements to the specification of its semantics. :)
Dec 05 2013
prev sibling parent reply "Chris Cain" <clcain uncg.edu> writes:
On Thursday, 5 December 2013 at 09:25:30 UTC, Don wrote:

 I think that is of negligible benefit. There's not a whole of 
 difference between manipulating an AST, vs manipulating text, 
 and I'm confident that the time taken to do that is always 
 going to be far more than the time required to lex and parse 
 text.

 What AST macros could provide is syntax sugar.
 But IMHO there's a lot more to be gained from improvements to 
 compile time reflection.


Negligible? AST macros write the front-end of a D compiler for a 
string mixin for you. That's not negligible. Even if the D 
frontend was static and didn't change it would be difficult to 
reach parity. The best that can be done now is a language that 
reminds you of D (or a D subset that, at best, will confuse users 
since it's not going to support nearly everything).

Of course, I know we're not going to get AST macros, but at least 
don't say things like it's "negligible". The only reason we 
aren't getting AST macros is because it's the opposite of 
negligible; it's _too powerful_.
Dec 05 2013
parent reply "Don" <x nospam.com> writes:
On Thursday, 5 December 2013 at 14:18:46 UTC, Chris Cain wrote:

 On Thursday, 5 December 2013 at 09:25:30 UTC, Don wrote:

 I think that is of negligible benefit. There's not a whole of 
 difference between manipulating an AST, vs manipulating text, 
 and I'm confident that the time taken to do that is always 
 going to be far more than the time required to lex and parse 
 text.

 What AST macros could provide is syntax sugar.
 But IMHO there's a lot more to be gained from improvements to 
 compile time reflection.


 Negligible? AST macros write the front-end of a D compiler for 
 a string mixin for you. That's not negligible.


What I said was negligible was:

 "The advantage of AST macros is that the compiler doesn't need 
 to re-lex and re-parse the result."




It's a negligible benefit because most of the time is spent in 
the semantic pass (which can take unbounded time), not in the 
lexing and parsing steps (which always take time O(n), where n is 
the length of the source code).


 Even if the D frontend was static and didn't change it would be 
 difficult to reach parity. The best that can be done now is a 
 language that reminds you of D (or a D subset that, at best, 
 will confuse users since it's not going to support nearly 
 everything).


Actually everything can be done in a library. Especially when we 
switch to the frontend written in D, the library and compiler 
source can be the same.
But I don't see the point of it being identical to D.


 Of course, I know we're not going to get AST macros, but at 
 least don't say things like it's "negligible". The only reason 
 we aren't getting AST macros is because it's the opposite of 
 negligible; it's _too powerful_.


Remember that it would have to be "more powerful" than an 
arbitrary chunk of source code text. I don't see how that could 
possibly be true.
Dec 05 2013
parent "Chris Cain" <clcain uncg.edu> writes:
On Thursday, 5 December 2013 at 15:59:08 UTC, Don wrote:

 What I said was negligible was:

 "The advantage of AST macros is that the compiler doesn't 
 need to re-lex and re-parse the result."




 It's a negligible benefit because most of the time is spent in 
 the semantic pass (which can take unbounded time), not in the 
 lexing and parsing steps (which always take time O(n), where n 
 is the length of the source code).


I see. I thought you were saying the concept of not having to 
rewrite the D compiler was negligible. Which, of course, is 
false. The speed advantage is but that's really just a minor 
thing ultimately.


 Actually everything can be done in a library. Especially when 
 we switch to the frontend written in D, the library and 
 compiler source can be the same.


Hopefully it'll get us to where we need to go.


 But I don't see the point of it being identical to D.


It doesn't _need_ to be, strictly speaking. But having a program 
written in C, some C++, D, SQL, and some CompileTimeScripting 
Language is inherently more difficult to deal with than something 
that limits it to C, C++, and mostly D (that generates necessary 
SQL and fulfills the requirements needed by the CTS-L). 
Considering the CTS-L would be unique to D (and possibly even to 
your project), that's quite an advantage.


 Remember that it would have to be "more powerful" than an 
 arbitrary chunk of source code text. I don't see how that could 
 possibly be true.


Why would it have to be? Don't conflate this with the concept of 
"equivalent to a turing machine". We're not getting it because 
it'd be possible to change the meaning of 1+1 to 3. If it were 
more limited ("less powerful") then it would be something that 
wouldn't have been rejected but, potentially, far less useful.
Dec 05 2013
prev sibling parent reply Shammah Chancellor <anonymous coward.com> writes:
On 2013-12-04 03:23:59 +0000, bearophile said:


 Joshua Niehus:
 

 This would make for a good blog post/wiki article.  Does one already exist?


 
 If you have a AST macros like in Julia language, I think you can write 
 something like:
 
  setExpr(a ∪ (b ∩ c));
 
 The main difference is that the compiler gives you a tree in the macro 
 to work on, instead of a string to parse and munge.
 
 Bye,
 bearophile


Can't you define

template setExpr(string expr)
{
	PeggedStuff...

	mixin(PeggedStuff());
}

setExpr!(q{a ∪ (b ∩ c)}); ?

-Shammah
Dec 04 2013
parent =?UTF-8?B?U2ltZW4gS2rDpnLDpXM=?= <simen.kjaras gmail.com> writes:
On 2013-12-05 05:09, Shammah Chancellor wrote:

 On 2013-12-04 03:23:59 +0000, bearophile said:

 Joshua Niehus:

 This would make for a good blog post/wiki article.Does one already exist?

 If you have a AST macros like in Julia language, I think you can write
 something like:

  setExpr(a ∪ (b ∩ c));

 The main difference is that the compiler gives you a tree in the macro
 to work on, instead of a string to parse and munge.

 Bye,

 bearophile

 Can't you define

 template setExpr(string expr)
 {
     PeggedStuff...

     mixin(PeggedStuff());
 }


 setExpr!(q{a ∪ (b ∩ c)});?



It'd have to be:

     template setExpr(string expr)
     {
         PeggedStuff...
         enum setExpr = PeggedStuff();
     }

     mixin(setExpr!q{a ∪ (b ∩ c)});

for it to have access to the names a, b and c.

Apart from that, absolutely.


One of the problems would be the lack of type information. If it turns 
out that a is string, not a Set!int,

--
   Simen
Dec 05 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-12-03 21:06, Walter Bright wrote:


 Embedded DSLs should be visually distinct, and D provides the ability
 for that with string mixins and CTFE.


The point of DSL's are to make a languages that work optimal and look 
appropriate for the given domain. Not necessarily make it distinct from 
standard D.

-- 
/Jacob Carlborg
Dec 03 2013
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Dec 04, 2013 at 08:44:17AM +0100, Jacob Carlborg wrote:

 On 2013-12-03 21:06, Walter Bright wrote:
 

Embedded DSLs should be visually distinct, and D provides the ability
for that with string mixins and CTFE.


 
 The point of DSL's are to make a languages that work optimal and
 look appropriate for the given domain. Not necessarily make it
 distinct from standard D.


[...]

Of course, it's not the *point* of DSLs to be distinct from the host
language, but it's a good idea for it to be. Operator overloading that
turns + and * into something completely unlike their usual meanings
violates the principle of least surprise. A CTFE-string containing + and
* interpreted differently is better, because the syntax itself reminds
you that something unlike normal D syntax is happening.

	// (D) It's clear * and + means something different:
	auto m = input.match(ctRegex!`^a+b*c`);

	// (C++) What on earth might this mean?!
	sregex r = (s1= +_w) >> ' ' >> (s2= +_w) >> '!';


T

-- 
Computers aren't intelligent; they only think they are.
Dec 04 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/4/2013 7:27 AM, H. S. Teoh wrote:

 Of course, it's not the *point* of DSLs to be distinct from the host
 language, but it's a good idea for it to be. Operator overloading that
 turns + and * into something completely unlike their usual meanings
 violates the principle of least surprise. A CTFE-string containing + and
 * interpreted differently is better, because the syntax itself reminds
 you that something unlike normal D syntax is happening.

 	// (D) It's clear * and + means something different:
 	auto m = input.match(ctRegex!`^a+b*c`);

 	// (C++) What on earth might this mean?!
 	sregex r = (s1= +_w) >> ' ' >> (s2= +_w) >> '!';


Looks like we're on the same wavelength here.
Dec 04 2013
prev sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Tue, 2013-12-03 at 12:06 -0800, Walter Bright wrote:
[…]

I have been waiting to answer this as I wanted to do some experiment
first. However circumstances mean that this playing will have to wait
till the Christmas break. I thought I should put a place holder message
in though to mark that a reply is coming.


 Using operator overloading to create a DSL is just wrong. Part of the design
of 
 operator overloading in D is to deliberately frustrate such attempts.
 
 + should mean addition, not union, concatenation, etc. Overloading is there to 
 support addition on user defined types, not to invent new meanings for it.
 
 Embedded DSLs should be visually distinct, and D provides the ability for that 
 with string mixins and CTFE.


I think this position is too restrictive and just wrong. If D is really
aiming to stop internal DSLs using operators then D is missing the whole
point of abstraction. But as noted I want code not just waffle to
further this discussion.

[…]

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Dec 10 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/10/2013 4:28 AM, Russel Winder wrote:

 I think this position is too restrictive and just wrong. If D is really
 aiming to stop internal DSLs using operators then D is missing the whole
 point of abstraction. But as noted I want code not just waffle to
 further this discussion.


Looking forward to it!
Dec 10 2013
prev sibling parent "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
On Tuesday, 3 December 2013 at 12:18:32 UTC, bearophile wrote:

 Martin O.:

we should do something about operators. I like James Ward's 
idea to mandate an alphabetic alias for every operator - at 
least people would know how to pronounce them then.<


 Bye,
 bearophile


This is what was basically done with D1, all the operator 
overloading was name based so people know they were overloading 
'add' and not 'concatenate.' Using the symbol wasn't legal. I 
don't think it will prevent people from doing what they want 
though so I don't see it necessary.
Dec 03 2013
prev sibling parent reply =?UTF-8?B?Ikx1w61z?= Marques" <luis luismarques.eu> writes:
On Tuesday, 3 December 2013 at 00:36:32 UTC, Andrei Alexandrescu 
wrote:

 http://www.reddit.com/r/programming/comments/1rvltx/scala_1_would_not_program_again/#new


I think he might not have liked D either:


 This leads to ridiculous decisions such as using ~ to glue 
 handlers together in the flexible DSL offered by spray


;-)
Dec 02 2013
parent reply "Meta" <jared771 gmail.com> writes:
On Tuesday, 3 December 2013 at 03:06:20 UTC, Luís Marques wrote:

 On Tuesday, 3 December 2013 at 00:36:32 UTC, Andrei 
 Alexandrescu wrote:

 http://www.reddit.com/r/programming/comments/1rvltx/scala_1_would_not_program_again/#new


 I think he might not have liked D either:


 This leads to ridiculous decisions such as using ~ to glue 
 handlers together in the flexible DSL offered by spray


 ;-)


I don't think this author is used to working with strongly-typed 
languages or languages with lower-level features:

"And while I’m on the topic, thanks for making me care about the 
difference between long and int, again. It’s been far too long 
since I wrote C."

I think he might've had a lot of the same criticisms for D as he 
did for Scala (save the build times. D's a real winner there).
Dec 02 2013
next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Tuesday, 3 December 2013 at 05:54:22 UTC, Meta wrote:

 On Tuesday, 3 December 2013 at 03:06:20 UTC, Luís Marques wrote:

 On Tuesday, 3 December 2013 at 00:36:32 UTC, Andrei 
 Alexandrescu wrote:

 http://www.reddit.com/r/programming/comments/1rvltx/scala_1_would_not_program_again/#new


 I think he might not have liked D either:


 This leads to ridiculous decisions such as using ~ to glue 
 handlers together in the flexible DSL offered by spray


 ;-)


 I don't think this author is used to working with 
 strongly-typed languages or languages with lower-level features:

 "And while I’m on the topic, thanks for making me care about 
 the difference between long and int, again. It’s been far too 
 long since I wrote C."


The main issue is that many seem to think very simple languages 
are the way to go, until they need to tackle complex problems and 
end up modeling manuly what other languages offer for free.

Like code generation tools in Go to overcome templates, or crazy 
macros in C to support OOP.



 I think he might've had a lot of the same criticisms for D as 
 he did for Scala (save the build times. D's a real winner 
 there).


Most languages with module support should provide pretty good 
compile times, C and C++ compilers are good example on how not to 
do it.

Just look at the compiler improvements in Objective-C, now with 
initial module support as of Maverick.

Sadly plain C and C++ compilers are what most young developers 
know as AOT compilers, hence the spread of slow compilation 
message.

--
Paulo
Dec 03 2013
next sibling parent "Atila Neves" <atila.neves gmail.com> writes:
 The main issue is that many seem to think very simple languages 
 are the way to go, until they need to tackle complex problems 
 and end up modeling manuly what other languages offer for free.

 Like code generation tools in Go to overcome templates, or 
 crazy macros in C to support OOP.


This can't be repeated enough. The complexity doesn't go away, it 
just moves into the implementation of the current application. 
Which brings to mind:

"Any sufficiently complicated C or Fortran program contains an ad 
hoc, informally-specified, bug-ridden, slow implementation of 
half of Common Lisp."

Replace Common Lisp with any other language that lets you get 
work done, and there you go.

Atila
Dec 03 2013
prev sibling parent reply "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
On Tuesday, 3 December 2013 at 09:46:27 UTC, Paulo Pinto wrote:

 Sadly plain C and C++ compilers are what most young developers 
 know as AOT compilers, hence the spread of slow compilation 
 message.

 --
 Paulo


I don't think that is limited to young developers. The only 
difference is that older developers are already comfortable 
programming in C/C++.
Dec 03 2013
parent Paulo Pinto <pjmlp progtools.org> writes:
Am 03.12.2013 16:36, schrieb Jesse Phillips:

 On Tuesday, 3 December 2013 at 09:46:27 UTC, Paulo Pinto wrote:

 Sadly plain C and C++ compilers are what most young developers know as
 AOT compilers, hence the spread of slow compilation message.

 --
 Paulo


 I don't think that is limited to young developers. The only difference
 is that older developers are already comfortable programming in C/C++.


Every time I code in C++ instead of JVM/.NET/D/Go, I remember of Turbo 
Pascal/Delphi/Oberon/Modula-2 compile times with nostalgia.

--
Paulo
Dec 03 2013
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/2/13 9:54 PM, Meta wrote:

 On Tuesday, 3 December 2013 at 03:06:20 UTC, Luís Marques wrote:

 On Tuesday, 3 December 2013 at 00:36:32 UTC, Andrei Alexandrescu wrote:

 http://www.reddit.com/r/programming/comments/1rvltx/scala_1_would_not_program_again/#new


 I think he might not have liked D either:


 This leads to ridiculous decisions such as using ~ to glue handlers
 together in the flexible DSL offered by spray


 ;-)


 I don't think this author is used to working with strongly-typed
 languages or languages with lower-level features:

 "And while I’m on the topic, thanks for making me care about the
 difference between long and int, again. It’s been far too long since I
 wrote C."

 I think he might've had a lot of the same criticisms for D as he did for
 Scala (save the build times. D's a real winner there).


He would at least to the extent a motivated and talented programmer 
could put together a rant against every language out there.

On the other hand Walter has been adamantly against configurable syntax 
(and talked me into that stance as well), so D is immune from quite a 
few issues pointed by that rant. D code is readable at least at surface 
level without needing context.

Also, the way D types work is quite a bit simpler so quite a few of the 
odd cases don't appear by design. I have this thought that D has 
offloaded to CTFE and Boolean logic a bunch of tasks that people achieve 
with complicated type-based proofs in Haskell or Scala. I think that's 
the real winner but time will tell.


Andrei
Dec 03 2013
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/3/2013 11:41 AM, Andrei Alexandrescu wrote:

 On the other hand Walter has been adamantly against configurable syntax (and
 talked me into that stance as well), so D is immune from quite a few issues
 pointed by that rant. D code is readable at least at surface level without
 needing context.

 Also, the way D types work is quite a bit simpler so quite a few of the odd
 cases don't appear by design. I have this thought that D has offloaded to CTFE
 and Boolean logic a bunch of tasks that people achieve with complicated
 type-based proofs in Haskell or Scala. I think that's the real winner but time
 will tell.


I also think it's abundantly clear that we hit a home run by making compile 
speed a priority since the beginning.
Dec 03 2013
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 3 December 2013 at 19:41:46 UTC, Andrei Alexandrescu 
wrote:

 On the other hand Walter has been adamantly against 
 configurable syntax (and talked me into that stance as well), 
 so D is immune from quite a few issues pointed by that rant. D 
 code is readable at least at surface level without needing 
 context.


Arguably, optional () and the mess involved around fall into the 
category of opaque and unclear syntax.
Dec 03 2013
parent "eles" <eles eles.com> writes:
On Tuesday, 3 December 2013 at 20:20:40 UTC, deadalnix wrote:

 On Tuesday, 3 December 2013 at 19:41:46 UTC, Andrei 
 Alexandrescu wrote:



 Arguably, optional () and the mess involved around fall into 
 the category of opaque and unclear syntax.


yes, that was a trap
Dec 04 2013