September 05, 2011 Re: RFC: StaticFilter, PApply, Compose, template predicates | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Nadlinger | Shin Fujishiro's std.meta has the features. https://github.com/sinfu/phobos-sandbox I think that module has been almost completed, but the contact with him has been interrupted. (I want to merge it, and it is licensed under the Boost License, but I doubt I will do it without his reply.) Kenji Hara 2011/9/4 David Nadlinger <see@klickverbot.at>: > As we currently aren't reviewing anything (We still need a review manager for David's RegionAllocator or whatever we decide to receive next? Do you want to get things going Jonathan? Should I do it again? Anybody else?), I thought I would take the opportunity to ask for comments on a few little template metaprogramming helpers: > > https://gist.github.com/1191885 > > Besides a few helpers for manipulating/combining template predicates, the above link contains three main: > > StaticFilter – like std.algorithm.filter, but for type tuples using template > predicates. > PApply – like the unluckily named std.functional.curry, but for template > parameters > Compose - alias Compose!(A, B, C) Comp; // Comp!D is now A!(B!(C!D)). > > I had originally whipped these up on the fly while working on some metaprogramming-heavy code, but they have proven useful in other projects as well. What do you think? Would some of these be worthy additions to Phobos? Do you have similar stuff lying around in your own code? > > Thanks, > David > |
September 05, 2011 Re: RFC: StaticFilter, PApply, Compose, template predicates | ||||
---|---|---|---|---|
| ||||
Posted in reply to kenji hara | On 09/05/2011 02:14 AM, kenji hara wrote:
> Shin Fujishiro's std.meta has the features.
>
> https://github.com/sinfu/phobos-sandbox
>
> I think that module has been almost completed, but the contact with
> him has been interrupted.
> (I want to merge it, and it is licensed under the Boost License, but I
> doubt I will do it without his reply.)
>
> Kenji Hara
And this will have to be fixed:
"All members in this module are defined in the $(D meta) namespace and cannot be used without the $(D meta) qualifier:"
Users can do the renamed import themselves if they wish to, the module should not enforce it.
|
September 05, 2011 Re: RFC: StaticFilter, PApply, Compose, template predicates | ||||
---|---|---|---|---|
| ||||
Posted in reply to kenji hara | On 9/5/11 2:14 AM, kenji hara wrote:
> Shin Fujishiro's std.meta has the features.
>
> https://github.com/sinfu/phobos-sandbox
Oh, wow, so now (largely) the same functionality has been implemented at least three times, in Shin Fujishiro's std.meta, in Philippe Sigaud's dranges, and by myself – I guess we should really do something about this to avoid reinventing the wheel over and over again.
Luckily, all the code is Boost-licensed, so I think I will just throw the best ideas from each implementation into a big bowl (for example, I really like Shin's approach to emulating template literals with strings) and cook up a module fit for submission to the Phobos review process.
Thus, it would be great if you could let me know what you would like to see as far as metaprogramming is concerned, besides common higher-order templates like Map/Reduce/Filter, general helpers like Compose/PApply/Switch/Iota and the low-level helpers for working around quirks in the language (think checking identity for arbitrary symbols/types/ct values, being able to alias both types and values, …).
High on my list of not yet implemented ideas is wrapping __traits: templates obviously won't be able to handle some of the strange semantics e.g. of the isArithmetic family of traits, but the »raw« __traits interface suffers from impedance mismatch with higher-order templates.
David
|
September 05, 2011 Re: RFC: StaticFilter, PApply, Compose, template predicates | ||||
---|---|---|---|---|
| ||||
Posted in reply to dsimcha | On Sun, 04 Sep 2011 19:46:45 -0400, dsimcha <dsimcha@yahoo.com> wrote:
> == Quote from Simen Kjaeraas (simen.kjaras@gmail.com)'s article
>> StaticFilter definitely should be in Phobos. StaticReduce too, but you
>> don't seem to have it on your list. I also often use StaticIota.
>> For more handy templates I feel should be in Phobos, see
>> Philippe Sigaud's dranges:
>> http://www.dsource.org/projects/dranges
>> -- =
>> Simen
>
> Seconded. StaticIota is extremely useful for loop unrolling optimizations, e.g.:
vote++
|
September 05, 2011 Re: RFC: StaticFilter, PApply, Compose, template predicates | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Nadlinger | On 09/05/2011 03:31 AM, David Nadlinger wrote: > On 9/5/11 2:14 AM, kenji hara wrote: >> Shin Fujishiro's std.meta has the features. >> >> https://github.com/sinfu/phobos-sandbox > > Oh, wow, so now (largely) the same functionality has been implemented at > least three times, in Shin Fujishiro's std.meta, in Philippe Sigaud's > dranges, and by myself – I guess we should really do something about > this to avoid reinventing the wheel over and over again. > > Luckily, all the code is Boost-licensed, so I think I will just throw > the best ideas from each implementation into a big bowl (for example, I > really like Shin's approach to emulating template literals with strings) > and cook up a module fit for submission to the Phobos review process. > > Thus, it would be great if you could let me know what you would like to > see as far as metaprogramming is concerned, besides common higher-order > templates like Map/Reduce/Filter, general helpers like > Compose/PApply/Switch/Iota and the low-level helpers for working around > quirks in the language (think checking identity for arbitrary > symbols/types/ct values, being able to alias both types and values, …). Is that the correct level for addressing quirks in the language? > > High on my list of not yet implemented ideas is wrapping __traits: > templates obviously won't be able to handle some of the strange > semantics e.g. of the isArithmetic family of traits, but the »raw« > __traits interface suffers from impedance mismatch with higher-order > templates. > > David |
September 05, 2011 Re: RFC: StaticFilter, PApply, Compose, template predicates | ||||
---|---|---|---|---|
| ||||
Posted in reply to Robert Jacques | Robert Jacques: > > Seconded. StaticIota is extremely useful for loop unrolling optimizations, e.g.: > > vote++ vote-- StaticIota is not the good solution. I have explained why elsewhere: http://d.puremagic.com/issues/show_bug.cgi?id=4085 Bye, bearophile |
September 05, 2011 Re: RFC: StaticFilter, PApply, Compose, template predicates | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | On Mon, 05 Sep 2011 13:05:23 +0200, bearophile <bearophileHUGS@lycos.com> wrote: > Robert Jacques: > >> > Seconded. StaticIota is extremely useful for loop unrolling >> optimizations, e.g.: >> >> vote++ > > vote-- > > StaticIota is not the good solution. I have explained why elsewhere: > http://d.puremagic.com/issues/show_bug.cgi?id=4085 Certainly we could sit in a corner and pray to almighty Walter that this be implemented, when he's done with the things he wants to do with D. Oooor - we could add StaticIota to Phobos, bypass the problem, and live happily ever after. Yes, static foreach would be nice, but the means to do what it would do, are easily implemented in the language as is. -- Simen |
September 05, 2011 Re: RFC: StaticFilter, PApply, Compose, template predicates | ||||
---|---|---|---|---|
| ||||
Posted in reply to Simen Kjaeraas | On 09/05/2011 07:31 PM, Simen Kjaeraas wrote:
> On Mon, 05 Sep 2011 13:05:23 +0200, bearophile
> <bearophileHUGS@lycos.com> wrote:
>
>> Robert Jacques:
>>
>>> > Seconded. StaticIota is extremely useful for loop unrolling
>>> optimizations, e.g.:
>>>
>>> vote++
>>
>> vote--
>>
>> StaticIota is not the good solution. I have explained why elsewhere:
>> http://d.puremagic.com/issues/show_bug.cgi?id=4085
>
> Certainly we could sit in a corner and pray to almighty Walter that this be
> implemented, when he's done with the things he wants to do with D. Oooor
> - we
> could add StaticIota to Phobos, bypass the problem, and live happily
> ever after.
>
> Yes, static foreach would be nice, but the means to do what it would do,
> are
> easily implemented in the language as is.
>
That is some heavy C++ design style reasoning.
|
September 05, 2011 Re: RFC: StaticFilter, PApply, Compose, template predicates | ||||
---|---|---|---|---|
| ||||
Posted in reply to Simen Kjaeraas | 2011/9/6 Simen Kjaeraas <simen.kjaras@gmail.com>:
> On Mon, 05 Sep 2011 13:05:23 +0200, bearophile <bearophileHUGS@lycos.com> wrote:
>
>> Robert Jacques:
>>
>>> > Seconded. StaticIota is extremely useful for loop unrolling optimizations, e.g.:
>>>
>>> vote++
>>
>> vote--
>>
>> StaticIota is not the good solution. I have explained why elsewhere: http://d.puremagic.com/issues/show_bug.cgi?id=4085
>
> Certainly we could sit in a corner and pray to almighty Walter that this be
> implemented, when he's done with the things he wants to do with D. Oooor -
> we
> could add StaticIota to Phobos, bypass the problem, and live happily ever
> after.
>
> Yes, static foreach would be nice, but the means to do what it would do, are easily implemented in the language as is.
Agreed to Simen. The foreach statement already has loop unrolling feature. To use it, we can pass a compile-time sequence (like TypeTuple) as its aggregator.
I think it is clear language design, and not need more. Then we need staticIota.
Kenji Hara
|
September 05, 2011 Re: RFC: StaticFilter, PApply, Compose, template predicates | ||||
---|---|---|---|---|
| ||||
Posted in reply to Simen Kjaeraas | Simen Kjaeraas:
> Yes, static foreach would be nice, but the means to do what it would do, are easily implemented in the language as is.
Notes:
- I am not asking for a real static foreach. The main point of bug 4085 is that that even half static foreach is better than the current situation.
- "static foreach" is also a way to better document what the code is doing. I sometimes add /*static*/ before foreach to increase readability.
- Some purposes/use cases of static foreach are not covered by a staticIota.
Bye,
bearophile
|
Copyright © 1999-2021 by the D Language Foundation