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

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

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.

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

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.

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.

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

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

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

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.