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.

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

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

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!

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?