On Tuesday, 9 September 2014 at 00:22:49 UTC, Marco Leise wrote:
> Am Mon, 08 Sep 2014 23:31:47 +0000
> schrieb "Dicebot" <public@dicebot.lv>:
>
>> […] fuck […] off-topic flamewar […] quite intentional.
>> […] won't let you do that easily […] off-topic bullshit
>> […] shooting people […] don't buy this […] attention whore
>> […] troll […] retard […] You are crossing the line
>> […] screw this language […] demagogue rhetorics
>> […] face the reaction
>
> *gulp*

I have never pretended to be a nice person to deal with.

On 9/8/14, 4:31 PM, Dicebot wrote:
> On Monday, 8 September 2014 at 15:22:05 UTC, Ola Fosheim Grøstad wrote:
>> On Monday, 8 September 2014 at 15:09:27 UTC, Dicebot wrote:
>>> It is not about D community but about yourself. Do _you_ want to be
>>> viewed as a valuable member of community? Do _you_ want to receive on
>>> topic responses to your threads?
>>
>> I only want to receive a response on this thread from community
>> members who are willing to share their patches! Your contribution to
>> this thread is counter productive.
>
> And I don't give a

Shall we keep it civil please. Thanks. -- Andrei

Am Mon, 08 Sep 2014 19:12:22 +0200
schrieb Timon Gehr <timon.gehr@gmx.ch>:

> On 09/08/2014 07:00 PM, Marco Leise wrote:
> > Am Mon, 8 Sep 2014 18:34:10 +0300
> > schrieb ketmar via Digitalmars-d <digitalmars-d@puremagic.com>:
> >
> >> On Mon, 08 Sep 2014 17:25:07 +0200
> >> Timon Gehr via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> >>
> >>> int square(int x)=>x*x;
> >> noted.
> >
> > To clarify:
> 
> The above is not valid D 2.066 syntax.
> Your apparent confusion supports a point I made in favour of it some
> time ago though. My post was about function declaration syntax, not
> squaring numbers. I assume Ola will still want to support x² though. :o)

I have to say, that was clever. I really didn't notice the wrong syntax until now. It doesn't get my vote though to keep some uniformness in function/method definitions. One time fire and forget lambdas are something different. They appear in the middle of expressions etc.

> > There is x^^2, but the implementation uses pow(x,2)
> 
> Is this really still true?
> 
> > and presumably yields a "real" result
> 
> No, both pow(x,2) and x^^2 yield an 'int' result.

Ok, memorized.

-- 
Marco

On Tue, 9 Sep 2014 02:41:25 +0200
Marco Leise via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> I have to say, that was clever. I really didn't notice the wrong syntax until now. It doesn't get my vote though to keep some uniformness in function/method definitions. One time fire and forget lambdas are something different. They appear in the middle of expressions etc.
this is nice syntax for simple getters, for example. not really necessary, but still nice.

On Tuesday, 9 September 2014 at 00:24:18 UTC, ketmar via Digitalmars-d wrote:
> let me stress it: this it NOT ABOUT FORKING AT ALL. this is about "hey,
> people, tell me about things your playing with in your free time!" and
> now you telling us that we should stop playing with *free* *and* *open*
> *code*. or at least be ashamed of what we are doing.

If actually using any of those patches (or recommending to do it) was never your intention, I apologize. However you have earlier made several comment about maintaing own set of patches for things that don't seem to be accepted upstream and that has been the deciding factor in the most negative interpretation of the thread. Probably it was more of a sarcasm thing but you can never be sure on the internet.

Actually I got more angry of Ola "license > people" attitude than any of your experiments. In general I respect any kind of personal preferences unless those get spoken out loud in "this is the right thing to do" style

> and we have no NG to ask such questions. this NGs is the main point of
> connection for D users. where he should ask his question if not here?

This NG is appropriate place for asking such questions but exact wording used was most confusing and didn't resemble any sort of learning / experimental topic. Sorry for misunderstanding your intention but being more precise about intentions can help to avoid it.

> please, don't turn such people off. 'cause your posts make me think
> that making my own independend D fork is not such a bad idea after all.

It can be both a good and a bad idea for reasons I have already mentioned. Most likely impractical because of plain amount of effort involved but it is clearly better than sticking to private patches (almost) no one else uses.

On Tue, 09 Sep 2014 00:44:30 +0000
Dicebot via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> However you have earlier made several comment about maintaing own set of patches for things that don't seem to be accepted upstream
i'm still doing this, 'cause i found some things inconsistent and worth fixing even if this breaks compatibility with some old code. but this new features are used in my private libraries that i'm not intending to make public (albeit some of them are accessible on repo.or.cz).

while i'm still sure that some changes should be accepted to mainline, i don't want to fight for this.

by the way: i'm not topicstarter. ;-)

> > that making my own independend D fork is not such a bad idea after all.
> It can be both a good and a bad idea for reasons I have already mentioned. Most likely impractical because of plain amount of effort involved but it is clearly better than sticking to private patches (almost) no one else uses.
what is the difference between "fork" and "building HEAD dmd with private patches applied"? i already forked dmd, just don't feel that i have to make it public.

btw: Lua has officially-blessed page "Lua power patches" in it's wiki. i can't see why D can't.

On Monday, 8 September 2014 at 23:48:54 UTC, Dicebot wrote:
> On Monday, 8 September 2014 at 23:39:17 UTC, Dicebot wrote:
>> Because original post had no learning context at all. I would gladly support initiative to provide more example-based tutorials for DMD contribution. Or any call for feedback based on existing patches. But it has nothing like that, instead focusing on "here is what I like to change in D so I keep local patches it" side of things. And this is really bad.

There may not yet be a learning context for the overall community, but there is for the small group of people who want to experiment with the different syntax that they've come up with.  They may find that their syntax changes don't work as well as they thought and abandon them.  A bunch of them may find one particular syntax change or addition to be very useful and push for it to be included in the mainline frontend.  We won't know any of this till they experiment and talk to each other.

>> Nothing is perfect and freedoms of open source come with their own drawbacks. I still find the benefits worth it but that doesn't mean that does mean that drawbacks are to be liked. Sometimes social aspect can be used as a counter-measure of technical flaw.
>
> To stress this point a bit more - constant bikeshedding is already one the major problems with D development culture. Everyone has his own opinion about the best syntax sugar or key features missing. One thing I respect established DMD contributors for is that they are capable of prioritizing the bigger picture over own preferences, despite the fact there is no one actually defining that bigger picture. If anything, I'd much more appreciate a real full-blown fork with a different vision (there are actually few already present) than encouraging a fragmentation over trivialities.

But not everyone wants a full fork, they just want to tweak the syntax to best suit their preferences.  One of the things I like about D is how it uses the old C-style syntax, so I don't have to rewire the C-style parser in my head every time I read D code.  Others have different parsers in their heads however. ;)

I've been thinking for some time that the solution to avoid source code formatting arguments is to have a formatter only show you source in the format you prefer, whether tabs over spaces or egyptian braces.  Perhaps the same is possible for syntax to a large extent, ie you download D source and your editor automatically runs it through a syntax translator so that you see the syntax you prefer.  This doesn't have to be part of the compiler, it can be done by other tools, though perhaps such translation tools would likely be built on the DDMD frontend.

Perhaps this is a first step in experimenting with such syntax translation, or maybe it doesn't go anywhere.  Let's not worry about fragmentation because of some small experiments.

On Tue, 09 Sep 2014 10:04:46 +0000
Joakim via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> Perhaps the same is possible for syntax to a large extent, ie you download D source and your editor automatically runs it through a syntax translator so that you see the syntax you prefer.
i'm planning to write such tool using Dparser (if it can power DCD and Dscanner, i'm sure it can power this tool too). this way i can use "my own shiny D dialect" to write my code and simply convert it to "mainline D" before sending to anyone else.

and in the end i can found that i'm not using my synactic sugar that much, for example. ;-)

btw: i'll investigate hdrgen feature soon. i believe that it can be used as a base to build full-blown pretty-printer, maybe even with simple configs.

On Monday, 8 September 2014 at 08:51:10 UTC, Ola Fosheim Grøstad wrote:
> I've started to make some minor mods to the DMD parser to tailor it to my own taste, but there is no reason to do double work, even if experimental. So I wonder which patches are available or in the works by others?
>
> I'm currently working on the following mods (not thoroughly tested yet):
>
> in : templatename‹params›
> out: templatename!(params)

Why dou want to turn it into C++'s style? it will slow down the compiler time because we need to look at symbol table the type of templatename because it might be a comparasion using < operator like this: a<b

> in : templatename«params»
> out: templatename!"params"

Why quote a paramter as string?

> in : a := expr
> out: auto a = expr

is this declaration? following (fortran?) rules: variable used in assignment without a previously declaration has implicit type? this isn't very good.

> in : a :== expr
> out: immutable a = expr
>
> And plan to continue with:
>
> in :  √x+y
> out:  sqrt(x) + y
>
> in :  a•b
> out:  a.opInner(b) // dot product, maybe some other name?
>
> in :  #arr;
> out:  arr.length //or perhaps something more generic?
>
> What are you working on and what patches do you have?

I didn't find this one so bad but these symbols are hard to type on usual keyboard...

On Tue, 09 Sep 2014 13:15:55 +0000
AsmMan via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> > in : templatename‹params›
> > out: templatename!(params)
> Why dou want to turn it into C++'s style?
look carefully: it's not "<", it's completely different unicode char.

> > in : templatename«params»
> > out: templatename!"params"
> Why quote a paramter as string?
it looks prettier.