www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - Aliases not passed down to child classes

reply "Matthew Wilson" <admin.hat stlsoft.dot.org> writes:
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?
Jul 16 2004
parent reply "Walter" <newshound digitalmars.com> writes:
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.
Jul 17 2004
parent reply "Matthew Wilson" <admin.hat stlsoft.dot.org> writes:
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.

Jul 17 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"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 (!).
Jul 17 2004
parent reply "Matthew Wilson" <admin.hat stlsoft.dot.org> writes:
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

 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

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

Jul 18 2004
parent reply "Walter" <newshound digitalmars.com> writes:
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?
Jul 19 2004
next sibling parent Sean Kelly <sean f4.ca> writes:
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
Jul 19 2004
prev sibling next sibling parent reply J C Calvarese <jcc7 cox.net> writes:
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/
Jul 19 2004
next sibling parent reply J C Calvarese <jcc7 cox.net> writes:
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/
Jul 19 2004
next sibling parent John Reimer <brk_6502 NO_SPA_M.yahoo.com> writes:
 
 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...
 

What about runnons that would be bad!
Jul 19 2004
prev sibling parent "Walter" <newshound digitalmars.com> writes:
"J C Calvarese" <jcc7 cox.net> wrote in message
news:cdi2tj$10io$1 digitaldaemon.com...
 Well, as threatened:
 http://www.prowiki.org/wiki4d/wiki.cgi?D__Tutorial/BugReports

I put a link to it on www.digitalmars.com/bugs.html. Thanks!
Jul 20 2004
prev sibling parent "Walter" <newshound digitalmars.com> writes:
"J C Calvarese" <jcc7 cox.net> wrote in message
news:cdhm8t$sen$1 digitaldaemon.com...
 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.)

100 lines isn't bad, but I get a lot of "I'll ship you my whole 5 mb of source", and that's a tough slog since I have no idea what the code is and what it's supposed to be doing.
 I really doubt it's lack of ability though. I think it's lack of time.

But also everyone wants their particular bug addressed. And I want to get to them all. But to be frank, the ones that are reduced to the minimum move to the front of the queue, the ones that are 5 Mb of source fall to the back. Also, reducing the code to the minimum usually suggests a workaround, and that'll keep your project moving.
 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. :)

If it's good, I'll put it up on the web site. Anyone want to see consistently top drawer bug reports, just check out Christof's work in the digitalmars C++ group.
Jul 20 2004
prev sibling next sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"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.
Jul 19 2004
parent "Walter" <newshound digitalmars.com> writes:
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:cdhn59$so6$1 digitaldaemon.com...
 I think it's part skill - and no surprise that you're the most skilled -

 other things. For me, those "other things" are generally a combination of

 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

 more.

Part of boiling it down is turning off one's brain about what might be wrong, and simply whacking away at it. (And there's just no way I understand complex template code, I just whack away at it.) Get rid of aliases, replace complex types with 'int', delete statements with wild abandon, remove every unused declaration, delete the function bodies, etc. Part of it is to create a simple cc.bat file to compile it, then the 'whack-compile-whack-compile' loop is pretty quick. I also use a text editor that automatically creates backup files, so if a whack removed the failure, then I just copy back the backup and whack off something else.
Jul 20 2004
prev sibling next sibling parent Roberto Mariottini <Roberto_member pathlink.com> writes:
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 speak out of my own experience: I've finally found a bug in the embedded OS we are using that was bugging me for months. Not that I worked full time to the bug discovering task, but I've dedicated many days to it. It was a nightmare: every test case I put up was perfectly working, while the full app was not. Obviously, I was searching the bug where it wasn't. One day, to do some unrelated testing, I completely excluded the part of the program that (I thougth) contained the bug, and the bug was still there! Now it was easy to track it down, looking where I never looked before. I think the main problem was the little I knew of the underlying OS internals, that made me look in the wrong places (enlarging the size of a buffer made the bug appear less than 1/100 than before, but the bug was elsewhere). Apart from lazyness and short time, IMHO the main reason for the difficulty to find a short test case resides in the little knowing of the language syntax and the compiler internals. So for me it's not surprising that you, knowing better than anyone else the language and the compiler, are the bes test case maker. Ciao
Jul 21 2004
prev sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
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 believe the lack of this skill in most cases turns out to be lazyness. Lars Ivar Igesund
Jul 22 2004