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.

-- 
Marco

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

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.

-- 
Marco

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

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

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

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.

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

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

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

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.