Consider the following:

/* ////////////////////////////////////////////////////////////////////////// */

module std.dtl.functions.categories;

interface IFunction
{}

    interface IPredicate
        : public IFunction
    {}


template Predicate(A) { class Predicate
    : public IPredicate
{
public:
    alias bool  return_type;
    alias A     argument_type;
}}

/* ////////////////////////////////////////////////////////////////////////// */



/* ////////////////////////////////////////////////////////////////////////// */

module std.dtl.functions.predicates;

template Not(F) { class Not
    : public Predicate!(argument_type_selector!(F).argument_type)
{
public:
    this(F f)
    {
        m_f = f;
    }
public:
    bool opCall(argument_type v)
    {
        return !m_f(v);
    }
private:
    F   m_f;
}}

/* ////////////////////////////////////////////////////////////////////////// */




/* ////////////////////////////////////////////////////////////////////////// */

class IsOdd
    : public Predicate!(int)
{
public:
    bool opCall(int i)
    {
        return 0 != (i % 2);
    }
};

/* ////////////////////////////////////////////////////////////////////////// */


I'm getting the error: "no property 'argument_type' for type 'IsOdd'"

I presume this is a bug. Is that so? If so, can it be fixed? If not, is there a reason that'd preclude a language change to facilitate this?

I modified your example, as your example was incomplete (missing import
statements):
-------------------------------------------

interface IFunction
{}

interface IPredicate : public IFunction
{}


template Predicate(A)
{ class Predicate
    : public IPredicate
{
public:
    alias bool  return_type;
    alias A     argument_type;
}
}

template Not(F) { class Not
    : public Predicate!(argument_type_selector!(F).argument_type)
{
public:
    this(F f)
    {
        m_f = f;
    }
public:
    bool opCall(argument_type v)
    {
        return !m_f(v);
    }
private:
    F   m_f;
}}

class IsOdd
    : public Predicate!(int)
{
public:
    bool opCall(int i)
    {
        return 0 != (i % 2);
    }
};
----------------------------------------------------

and it compiles successfully.

Bah! I thought that'd be the case. I guess I'm just stretching the complexity limits.

Want the full-zip to play with? ;)

"Walter" <newshound@digitalmars.com> wrote in message news:cdansf$15pg$1@digitaldaemon.com...
> I modified your example, as your example was incomplete (missing import
> statements):
> -------------------------------------------
>
> interface IFunction
> {}
>
> interface IPredicate : public IFunction
> {}
>
>
> template Predicate(A)
> { class Predicate
>     : public IPredicate
> {
> public:
>     alias bool  return_type;
>     alias A     argument_type;
> }
> }
>
> template Not(F) { class Not
>     : public Predicate!(argument_type_selector!(F).argument_type)
> {
> public:
>     this(F f)
>     {
>         m_f = f;
>     }
> public:
>     bool opCall(argument_type v)
>     {
>         return !m_f(v);
>     }
> private:
>     F   m_f;
> }}
>
> class IsOdd
>     : public Predicate!(int)
> {
> public:
>     bool opCall(int i)
>     {
>         return 0 != (i % 2);
>     }
> };
> ----------------------------------------------------
>
> and it compiles successfully.
>
>

"Matthew Wilson" <admin.hat@stlsoft.dot.org> wrote in message news:cdasb9$16vs$2@digitaldaemon.com...
> Bah! I thought that'd be the case.

Hence my robotic request for reproducible examples <g>.

> I guess I'm just stretching the
> complexity limits.

I sincerely doubt it. DMD doesn't have complexity limits (other than running
out of memory).

> Want the full-zip to play with? ;)

No, I'll just boringly repeat that 99% of problems can be reduced to 10 lines or less of code. Just copy it all to another directory, and then whack away at it. I've had people send me literally megabytes of source they assured me couldn't be reduced that whacked down to 10 lines (!).

Ok, I'm trying to boil down the compiler-crash / recursion problem. I've not got that yet, but here's an example of the alias/property problem. To suppress it, swap the commented line over.

    template HackSelector(T)
    {
        alias T     selected_type;
    }

    interface NotionalRangeTag
    {}

    template NotionalRange(V) { interface NotionalRange
        : public NotionalRangeTag
    {
    public:
        alias   V                   value_type;
        alias   NotionalRangeTag    range_category;

    public:
        bool        is_open();
        value_type  current();
        void        advance();
    }}

    template MatchedNotionalRange(R, F) { class MatchedNotionalRange
        : public NotionalRange!(R.value_type)
    //  : public
NotionalRange!(HackSelector!(typeof(R.value_type)).selected_type)
    {

    public:
        bool        is_open()
        {
            return false;
        }
        value_type  current()
        {
            return value_type.init;
        }
        void        advance()
        {
        }

    public:
        template select(F) { .MatchedNotionalRange!(R, F) select(F f = new
F())
        {
            return null;
        }}
    }}

    template List(V) { class List
    {
    public:
        alias   V   value_type;

    public:
        class Range
        {
        public:
            alias   V   value_type;
        }

        template select(F) { MatchedNotionalRange!(Range, F) select(F f =
new F())
        {
            return null;
        }}
    }}



    class SomeFunc1
    {
    public:
        bool opCall(int i)
        {
            return 0 != i;
        }
    }

    class SomeFunc2
    {
    public:
        bool opCall(int i)
        {
            return 0 == (i % 3);
        }
    }

    int main()
    {
        alias List!(int)        int_list_t;

        int_list_t  l   =   new int_list_t();

        l.select!(SomeFunc1)().select!(SomeFunc2)();

        return 0;
    }


"Walter" <newshound@digitalmars.com> wrote in message news:cdbpg8$1g7n$1@digitaldaemon.com...
>
> "Matthew Wilson" <admin.hat@stlsoft.dot.org> wrote in message news:cdasb9$16vs$2@digitaldaemon.com...
> > Bah! I thought that'd be the case.
>
> Hence my robotic request for reproducible examples <g>.
>
> > I guess I'm just stretching the
> > complexity limits.
>
> I sincerely doubt it. DMD doesn't have complexity limits (other than
running
> out of memory).
>
> > Want the full-zip to play with? ;)
>
> No, I'll just boringly repeat that 99% of problems can be reduced to 10 lines or less of code. Just copy it all to another directory, and then
whack
> away at it. I've had people send me literally megabytes of source they assured me couldn't be reduced that whacked down to 10 lines (!).
>
>

Thanks. I boiled it down much further:

------------------------------------------------
interface NotionalRange(V)
{
}

class MatchedNotionalRange(R)
    : NotionalRange!(R.value_type)
{
}

class Range
{
 alias   int   value_type;
}

class List
{
    MatchedNotionalRange!(Range) x;
}

-----------------------------------------------------------

I'm a bit befuddled, though. While I believe it is straightforward to boil these problems down to their essentials, almost nobody else (besides Christof Meerwald) seems to be able to do it. Am I sadly mistaken in thinking this is straightforward, or is it an unusual skill? Can it be taught?

In article <cdhf4o$pur$1@digitaldaemon.com>, Walter says...
>
>I'm a bit befuddled, though. While I believe it is straightforward to boil these problems down to their essentials, almost nobody else (besides Christof Meerwald) seems to be able to do it. Am I sadly mistaken in thinking this is straightforward, or is it an unusual skill? Can it be taught?

I think if a problem can be defined then it can be simplified.  The problem in many cases is that people encounter an odd bug and don't know what's causing it. Another factor may be laziness.  It's easier to post broken code then spend the time to investigate what's going on and try to create a minimal repro.  I've personally posted a few screw-ups mostly because the fault seemed simple and I didn't spend the time to double-check that it really existed.  Some part of this may be that bug reports are filed in a forum rather than through some more structured method.  It may be a fault of the interface that people feel they can open a dialog here to narrow down a problem rather than doing the work themselves and posting something more detailed.

Either way, I believe the skill can certainly be taught, as it is a lot like debugging.  Assuming there are people that really can't do this (and at the risk of straying from the topic a bit) I think part of the problem may be with how programming is taught these days.  In attempting to make it easy to learn I think too many details are being glossed over and the focus is mostly on producing code that will compile, with little thought to maintenance or to how the machine does what you've told it to.  Assuming this is a real issue, maybe a Q&A forum would be a good place for new folks to ask questions and such.  The main D forum serves that purpose now, but it's intermingled with noise from feature requests and other stuff.

It would also be nice to have greater cohesion between documentation and feature changes.  The bug reports are useful and I've noticed you update the online docs pretty well, but there are still language features with little or no documentation which can cause confusion about whether something is a bug or not. However, this would obviously take away from development time so I'm hesitant to really push for it.  Perhaps there are some willing volunteers who would ask around and fill in these sections?


Sean

Walter wrote:
> Thanks. I boiled it down much further:
> 
> ------------------------------------------------
> interface NotionalRange(V)
> {
> }
> 
> class MatchedNotionalRange(R)
>     : NotionalRange!(R.value_type)
> {
> }
> 
> class Range
> {
>  alias   int   value_type;
> }
> 
> class List
> {
>     MatchedNotionalRange!(Range) x;
> }
> 
> -----------------------------------------------------------
> 
> I'm a bit befuddled, though. While I believe it is straightforward to boil
> these problems down to their essentials, almost nobody else (besides
> Christof Meerwald) seems to be able to do it. Am I sadly mistaken in
> thinking this is straightforward, or is it an unusual skill? Can it be
> taught?

I'm more inclined to think it's one or both of these reasons:

1. You're just much, much, more intelligent that any of the rest of us (except Mr. Meerwald).

2. Perhaps after spending 5 hours condensing it from 50,000 lines to 100 lines, we decide we're tired and it's small enough for you to work with. (And yes, the TV was on the entire time, and I'm sure it wouldn't have taken so long to do if I turned it off.)

I really doubt it's lack of ability though. I think it's lack of time.


By the way, I've thought about writing up some hints for how to condense down bug reports, but I suspect I'm the only one who would read it. :)

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/

"Walter" <newshound@digitalmars.com> wrote in message news:cdhf4o$pur$1@digitaldaemon.com...
> Thanks. I boiled it down much further:
>
> ------------------------------------------------
> interface NotionalRange(V)
> {
> }
>
> class MatchedNotionalRange(R)
>     : NotionalRange!(R.value_type)
> {
> }
>
> class Range
> {
>  alias   int   value_type;
> }
>
> class List
> {
>     MatchedNotionalRange!(Range) x;
> }
>
> -----------------------------------------------------------
>
> I'm a bit befuddled, though. While I believe it is straightforward to boil these problems down to their essentials, almost nobody else (besides Christof Meerwald) seems to be able to do it. Am I sadly mistaken in thinking this is straightforward, or is it an unusual skill? Can it be taught?

I think it's part skill - and no surprise that you're the most skilled - and part other things. For me, those "other things" are generally a combination of time pressure and a genuine confusion as to where the error may lie due to the complexity and unfamiliarity with D; if it were C++ I could boil things down more.

J C Calvarese wrote:
> Walter wrote:
> 
...
>>
>> I'm a bit befuddled, though. While I believe it is straightforward to boil
>> these problems down to their essentials, almost nobody else (besides
>> Christof Meerwald) seems to be able to do it. Am I sadly mistaken in
>> thinking this is straightforward, or is it an unusual skill? Can it be
>> taught?
>  I'm more inclined to think it's one or both of these reasons:
> 
> 1. You're just much, much, more intelligent that any of the rest of us (except Mr. Meerwald).
> 
> 2. Perhaps after spending 5 hours condensing it from 50,000 lines to 100 lines, we decide we're tired and it's small enough for you to work with. (And yes, the TV was on the entire time, and I'm sure it wouldn't have taken so long to do if I turned it off.)
> 
> I really doubt it's lack of ability though. I think it's lack of time.
> 
> 
> By the way, I've thought about writing up some hints for how to condense down bug reports, but I suspect I'm the only one who would read it. :)

Well, as threatened:
http://www.prowiki.org/wiki4d/wiki.cgi?D__Tutorial/BugReports

Hopefully, it makes a little sense. I'm crossing my fingers that I didn't end every sentence with a preposition. and used some good Capitalization. And no sentence fragments...

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/