"Walter" <walter@digitalmars.com> wrote in message news:ak1k42$j5f$1@digitaldaemon.com...

> >    Still, using runtime interfaces for this sounds a little wrong to me.
>
> It's still compile time, just a bit extra work for the semantic pass.

   Hmmm... I guess...

> It doesn't matter if some functions are before and some after the use of
it,
> the compiler sees all of them when doing the semantic analysis.

   Ok... I figured that.

> >    I guess that with the non-need for function prototypes, this
particular
> > example is solvable in D. But I'm thinking especially of templates
defined
> > in one module and used in another.
>
> If func() is defined in a different module than template Tpl() and is not
> visible in the scope of template Tpl(), then you'll get a "func undefined"
> message when the instance Tpl(bool) is compiled regardless of whether
func()
> is visible at the scope of instance Tpl(bool) or not.

   So you can't really use templates taken from a library with user-defined
types unless those user defined types are already known to the library?

> This is fundamentally different than the way C++ works - C++ tries to do
it
> both ways, with some names getting resolved at template declaration scope, and some at template instantiation scope, depending on whether a name is "type-dependent" or not.

   Yes, and we agree that's bad. Still, unless you have a clever answer to
this, I can't see how your solution is good enough.

   I know you don't like forward declarations, but they might be warranted
in the case of templates:

template Tpl(T) {
  exists void func(T); // forward declaration...
  void anotherfunc(T t) {
    func(t);
  }
}

   This would allow you to eliminate all problems with dependent names.
It'll also allow the compiler to do even better error messages for invalid
instantiations. In a way, you can consider this as compile-time contracts
for templates.

Salutaciones,
                       JCAB

Walter wrote:
> "Russell Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message
> news:3D63D965.4040809@deming-os.org...
> 
>>>>What is the difference between
>>>>    template Bar(D, D : D[]) {...}
>>>>and
>>>>    template Bar(D : D{}) {...}
>>>>?
>>>
>>>The latter is illegal, as D{} is not a type.
>>
>>Oops, meant D[] on the latter one
> 
> 
> In that case, it serves to distinguish:
> 
>     instance Bar(int) x1;
> 
> from:
> 
>     instance Bar(int, int[]) x2;

And the difference between the two is?

Walter wrote:
> It occurs to me that this does fit in with the D template syntax:
> 
>     template Calculator(T : NUMERIC) { ... }
> 
> means that T can be either NUMERIC or a class derived from NUMERIC (if
> NUMERIC is a class or interface). Your case 3 would be:
> 
>     template Cage(B, D : B) {/*whatever*/}
> 
> which would constrain D to be the same as B or derived from B.
I could see somebody wanting to do something like this:

template List(X) {
    class List {...};
};
template Thingy(A, List(A).List) {...};

However, since we can't refer to template instances that way - we have to instantiate them explictly - I don't see any way to do this with the current template syntax.  Do you have any ideas how?

On Thu, 22 Aug 2002 12:58:44 -0700 "Juan Carlos Arevalo Baeza" <jcab@JCABs-Rumblings.com> wrote:

>    So you can't really use templates taken from a library with user-defined
> types unless those user defined types are already known to the library?

You can, as long as you pass those types as template parameters.

On Thu, 22 Aug 2002 14:02:13 -0700 Russell Lewis <spamhole-2001-07-16@deming-os.org> wrote:

>> In that case, it serves to distinguish:
>> 
>>     instance Bar(int) x1;
>> 
>> from:
>> 
>>     instance Bar(int, int[]) x2;
> 
> And the difference between the two is?

The first one gets one argument, the second gets two. =)

I've been thinking along the same lines.  I'd like to see what kind of language you'd come up with.  I really liked what I saw in Yoritz language, and NVIDIA Cg.  Something with simplified memory management and designed to be implemented using SIMD.  I have a lot of vague ideas and no time to solidify them.

I'm likely to completely ditch C compatibility if I make a language, though. Too much baggage.  I'd make it able to link with C but not syntactically compatible.

Sean

"Juan Carlos Arevalo Baeza" <jcab@JCABs-Rumblings.com> wrote in message news:ak3ami$286g$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:ak1p2n$1ben$1@digitaldaemon.com...
>
> > Even if you don't use D, I've found your comments about it to be very valuable.
>
>    Thanx.
>
> > Are you sure that all the other neat stuff in D doesn't tempt you?
>
>    Yes, it does. But not enough to use it. It does tempt me to try and
make
> my own language, thoguh ;-)
>
> Salutaciones,
>                        JCAB

"Mac Reiter" <Mac_member@pathlink.com> wrote in message news:ak3agl$27qt$1@digitaldaemon.com...
> I know that 'counted' would increase the complexity of the compiler, which
you
> have been trying to avoid, but I think it could be done without too much additional effort.  (I am not, however, familiar with writing compilers,
so my
> assumptions could be vastly incorrect)  It would certainly take less
effort to
> get it right (ignoring issues of "completely optimized" for the time
being)
> inside the compiler than it does outside.

The complexity comes from decrementing the counts of objects going out of scope, in the presence of exceptions. It did occur to me that if this was supported, it would also implicitly support the people who want deterministic destruction.

"Pavel Minayev" <evilone@omen.ru> wrote in message news:CFN374913480596065@news.digitalmars.com...
> On Thu, 22 Aug 2002 14:02:13 -0700 Russell Lewis <spamhole-2001-07-16@deming-os.org> wrote:
> >> In that case, it serves to distinguish:
> >>     instance Bar(int) x1;
> >> from:
> >>     instance Bar(int, int[]) x2;
> > And the difference between the two is?
> The first one gets one argument, the second gets two. =)

Yes, that's all it is. Think of it like function overloading.

"Pavel Minayev" <evilone@omen.ru> wrote in message news:CFN374913474843634@news.digitalmars.com...

> >    So you can't really use templates taken from a library with
user-defined
> > types unless those user defined types are already known to the library?
>
> You can, as long as you pass those types as template parameters.

   But not unless those types were visible at the point where the template
was declared. So:

--- mylibrary.d
template Tpl(T) { ... }
---

--- myprogram.d
using mylibrary;

class MyClass { ... }

instance Tpl(MyClass) TplMyClass; // Fails!!!
---

   That's what Walter seems to be saying. That the instantiation fails
because MyClass is not visible in mylibrary.d. And that's what I have a
problem with.

Salutaciones,
                       JCAB

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:ak5pq2$210p$1@digitaldaemon.com...

> I've been thinking along the same lines.  I'd like to see what kind of language you'd come up with.  I really liked what I saw in Yoritz
language,
> and NVIDIA Cg.  Something with simplified memory management and designed
to
> be implemented using SIMD.  I have a lot of vague ideas and no time to solidify them.

   :-) Yes, I know the feeling. And I would really like to compare ideas,
too. Hmmm... You know what? I think I'm going to start a little discussion
list of my own on my server, to discuss this kind of thing. I'm taking the
liberty of subscribing you, Sean. Anyone else interested, go here (hope this
works) or drop me email:

http://lists.jcabs-rumblings.com/listinfo.cgi/npl-jcabs-rumblings.com

   For short, the language I have in mind is:

- Small C-style run-time model and language kernel. This means bit & byte manipulation, basic memory address algebra, variables & functions... With room for platform-specific additions, of course, like I/O port access, etc.

- Extremely simple parser (much simpler than even D). This is, I believe, my most outrageous idea. If it works, that is.

- Configurable semantics for high extensibility. Ability to create language primitives and sub-languages by programming the mapping of them into the kernel.

- Compile-time execution model.

- Standard library including higher-level stuff like GC, which would be optional to use.

> I'm likely to completely ditch C compatibility if I make a language,
though.
> Too much baggage.  I'd make it able to link with C but not syntactically compatible.

   I'm completely ready to ditch compatibility. I'm also working on a C/C++
parser to ease converting source code.

Salutaciones,
                       JCAB