Walter

I (or you) could put a page on this onto wikiwiki, where computer languages are discussed. If you don't know it, it is a set of editable web pages.

See http://c2.com/cgi/wiki?CategoryLanguage

It might be better to wait until you release a compiler.

John

While I do not challenge Walter's skill as a compiler writer and language designer, it does seem that a wider discussion group is in order.  One of the sitting USENET groups might be a better starting point, even before -- in fact preferably before -- the first version is released.

One strategy that made Python a great success was its development model.  It was conceived by one person but with a large body of other developers and users.  To this day, Guido retains autocratic rule over Python development but is not a one-man show.  Python is open-source, too, and that always helps.  You can go the open-source route and still retain control of the development.

Lack of template support might be a mistake.  That is one of the better features of C++.  There were reasons why it came into being so late in the game and was adopted into the standard.

Take a look at blitz++ and the Matrix Template Library for some ideas.  I consider blitz++ the best numerics library out there.

For strings, I always loved the way the Icon language (formerly SNOBOL, later Unicon) handled them.  It has been a long-standing dream of mine to have Icon strings available in C.  Maybe D can do it.

Mark




On Tue, 14 Aug 2001 10:55:33 +0100, John Fletcher <J.P.Fletcher@aston.ac.uk> wrote:
> Walter
> 
> I (or you) could put a page on this onto wikiwiki, where computer languages are discussed. If you don't know it, it is a set of editable web pages.
> 
> See http://c2.com/cgi/wiki?CategoryLanguage
> 
> It might be better to wait until you release a compiler.
> 
> John
> 
> 

I held off for a long time posting the spec because the alpha compiler wasn't strong enough yet. Finally, I did decide to post just the spec here to test the waters first. Once I do have a decent compiler for it, then we can investigate a larger audience.

I can't make it open source, due to the licensing issues. The alpha compiler uses the optimizer and back end of the C compiler. What I'd like to try and do is release the front end as open source to someone who would hopefully graft it onto gcc <g>.

I know that templates likely will be a big issue. I intend to address it in version 2 of the language. The way C++ does it is simply too complicated for me, I am trying to find a simpler way, so much more thought needs to be expended there.

Does the D string design work for you? I don't know SNOBOL or Icon.

-Walter

Mark Evans wrote in message <1104_997793689@evans>...
>While I do not challenge Walter's skill as a compiler writer and language
designer, it does seem that a wider discussion group is in
>order.  One of the sitting USENET groups might be a better starting point,
even before -- in fact preferably before -- the first version is
>released.
>
>One strategy that made Python a great success was its development model.
It was conceived by one person but with a large body of
>other developers and users.  To this day, Guido retains autocratic rule
over Python development but is not a one-man show.  Python is
>open-source, too, and that always helps.  You can go the open-source route
and still retain control of the development.
>
>Lack of template support might be a mistake.  That is one of the better
features of C++.  There were reasons why it came into being so
>late in the game and was adopted into the standard.
>
>Take a look at blitz++ and the Matrix Template Library for some ideas.  I
consider blitz++ the best numerics library out there.
>
>For strings, I always loved the way the Icon language (formerly SNOBOL,
later Unicon) handled them.  It has been a long-standing
>dream of mine to have Icon strings available in C.  Maybe D can do it.
>
>Mark
>
>
>
>
>On Tue, 14 Aug 2001 10:55:33 +0100, John Fletcher
<J.P.Fletcher@aston.ac.uk> wrote:
>> Walter
>>
>> I (or you) could put a page on this onto wikiwiki, where computer languages are discussed. If you don't know it, it is a set of editable web pages.
>>
>> See http://c2.com/cgi/wiki?CategoryLanguage
>>
>> It might be better to wait until you release a compiler.
>>
>> John
>>
>>
>
>

"Walter" <walter@digitalmars.com> wrote in message news:9lbjnb$21i9
> I know that templates likely will be a big issue. I intend to address it
in
> version 2 of the language. The way C++ does it is simply too complicated
for
> me, I am trying to find a simpler way, so much more thought needs to be expended there.

Templates are a requirement for me in any general purpose language now. I'll put up with a language without them, but it will never be my "preferred" language without them.

Templates provide features that are simply not possible without them (or some other form of generics).  I don't think it's valid to argue against templates based on their improper use.  Otherwise we'd have to discount most features of most languages ;)

At a bare minimum, I require a form of generics which seamlessly handle type-safe arbitrary parameters.  One way to do this would be to implement a form of intrinsic polymorphism, with compile-time constraints.  Languages like smalltalk don't need templates because everything gets handled at runtime, and all objects are derived from the same place.  But I think everyone agrees that compile-time type safety is better than run-time for a general purpose language.

For instance, suppose the following syntax:

(Note, syntax is arbitrarily chosen with no regard to parsing complexity)

void func(generic obj)
{

}

The problem here is that you have no way of knowing what type obj is in the function, thus you can't declare new objects of the same type as obj.  So perhaps we have this:

typeof(obj) newobj = obj;

this would neatly create a way to genericly define such types.  It wouldn't allow you to pass types to the function that were not passed as arguments though.

generic func(generic obj) : generic x
{
    // do calculations in a more precise format
    x temp = obj;

    return typeof(return)(x);
}

int main()
{
    float d = func(1.1f) : double;
    int i = func(1) : long;
    long l = func(1L) : int; // error, cannot assin obj to temp, truncation
}

Now, the real problem is how to instantiate a generic when the module is compiled seperately.  You would have to build syntax into the import statement  to generate "generic modules", which would help to eliminate code bloat caused by templates.  If the module doesn't exist, it creates it, if it already does, it automatically imports it when you reference a generic class or function.

import func;  // imports func and/or func.gl

int main()
{
    float d = func(1.1f) : double;  // generates float-float-double-func in
func.gl
}

func.gl is essentially a static library, which contains various template instantiations for func.

Am I making any sense here?  Or am I just stating the obvious?  Or am I stating the ludicrous?

"Why D doesn't have templates" is definitely going to be a hot issue. I am going to have to try to organize my thoughts on it better in the main spec than I have done so far by dismissing it with a one liner <g>.

Yes, you are making sense.

A thought: the separately compiled template module issue should not be a problem. Just write out the templates, and then import the module. The compiler should handle the rest. If it doesn't, then back to the drawing board to fix it.

-Walter

"Erik Funkenbusch" <erikf@seahorsesoftware.com> wrote in message news:9ld075$2u5t$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:9lbjnb$21i9
> > I know that templates likely will be a big issue. I intend to address it
> in
> > version 2 of the language. The way C++ does it is simply too complicated
> for
> > me, I am trying to find a simpler way, so much more thought needs to be expended there.
>
> Templates are a requirement for me in any general purpose language now. I'll put up with a language without them, but it will never be my "preferred" language without them.
>
> Templates provide features that are simply not possible without them (or some other form of generics).  I don't think it's valid to argue against templates based on their improper use.  Otherwise we'd have to discount
most
> features of most languages ;)
>
> At a bare minimum, I require a form of generics which seamlessly handle type-safe arbitrary parameters.  One way to do this would be to implement
a
> form of intrinsic polymorphism, with compile-time constraints.  Languages like smalltalk don't need templates because everything gets handled at runtime, and all objects are derived from the same place.  But I think everyone agrees that compile-time type safety is better than run-time for
a
> general purpose language.
>
> For instance, suppose the following syntax:
>
> (Note, syntax is arbitrarily chosen with no regard to parsing complexity)
>
> void func(generic obj)
> {
>
> }
>
> The problem here is that you have no way of knowing what type obj is in
the
> function, thus you can't declare new objects of the same type as obj.  So perhaps we have this:
>
> typeof(obj) newobj = obj;
>
> this would neatly create a way to genericly define such types.  It
wouldn't
> allow you to pass types to the function that were not passed as arguments though.
>
> generic func(generic obj) : generic x
> {
>     // do calculations in a more precise format
>     x temp = obj;
>
>     return typeof(return)(x);
> }
>
> int main()
> {
>     float d = func(1.1f) : double;
>     int i = func(1) : long;
>     long l = func(1L) : int; // error, cannot assin obj to temp,
truncation
> }
>
> Now, the real problem is how to instantiate a generic when the module is compiled seperately.  You would have to build syntax into the import statement  to generate "generic modules", which would help to eliminate
code
> bloat caused by templates.  If the module doesn't exist, it creates it, if it already does, it automatically imports it when you reference a generic class or function.
>
> import func;  // imports func and/or func.gl
>
> int main()
> {
>     float d = func(1.1f) : double;  // generates float-float-double-func
in
> func.gl
> }
>
> func.gl is essentially a static library, which contains various template instantiations for func.
>
> Am I making any sense here?  Or am I just stating the obvious?  Or am I stating the ludicrous?
>
>
>

Walter wrote:

> I held off for a long time posting the spec because the alpha compiler wasn't strong enough yet. Finally, I did decide to post just the spec here to test the waters first. Once I do have a decent compiler for it, then we can investigate a larger audience.
>
> I can't make it open source, due to the licensing issues. The alpha compiler uses the optimizer and back end of the C compiler. What I'd like to try and do is release the front end as open source to someone who would hopefully graft it onto gcc <g>.
>

Walter

If the front end was open source, would it be possible to add new internal types to it which were compounds of existing types, e.g. quaternion?

John

Walter wrote:
> "Why D doesn't have templates" is definitely going to be a hot issue. I am
> going to have to try to organize my thoughts on it better in the main spec
> than I have done so far by dismissing it with a one liner <g>.
> 
> Yes, you are making sense.
> 
> A thought: the separately compiled template module issue should not be a
> problem. Just write out the templates, and then import the module. The
> compiler should handle the rest. If it doesn't, then back to the drawing
> board to fix it.
> 
> -Walter
> 
> "Erik Funkenbusch" <erikf@seahorsesoftware.com> wrote in message
> news:9ld075$2u5t$1@digitaldaemon.com...

FWIW, Eiffel gets along quite handily without templates.  Of course, it does use "restricted generics", another concept that fills the same need.  I don't know C++ very well, but templates have always given me a lot of trouble (even in "Hello, World!" equivalent tests), and Eiffel's generics never have.  This is a user rather than a designer perspective, however.
If it matters, the C++ compiler I was using was gcc 2.96 (2.97? -- the Red Hat 7.1 version, anyway).

Walter wrote:
> 
> I held off for a long time posting the spec because the alpha compiler wasn't strong enough yet. Finally, I did decide to post just the spec here to test the waters first. Once I do have a decent compiler for it, then we can investigate a larger audience.

Yes, don't try to discuss this on the wider Usenet until you've got 1.0 out the door. Don't even listen to the crowds of slashdotters who are going to be descending on this newsgroup in the near future (like me). :)

-Russell B

John Fletcher wrote in message <3B7BC551.E9907C61@aston.ac.uk>...
>Walter wrote:
>> I held off for a long time posting the spec because the alpha compiler wasn't strong enough yet. Finally, I did decide to post just the spec
here
>> to test the waters first. Once I do have a decent compiler for it, then
we
>> can investigate a larger audience.
>> I can't make it open source, due to the licensing issues. The alpha
compiler
>> uses the optimizer and back end of the C compiler. What I'd like to try
and
>> do is release the front end as open source to someone who would hopefully graft it onto gcc <g>.
>If the front end was open source, would it be possible to add new internal
types
>to it which were compounds of existing types, e.g. quaternion?


Yes. The way it is laid out internally is meant to make it easy to add new built-in types. The difficulty is getting the *back* end to support them. In order to make complex types work, I had to get them to work in the back end; quite a bit of work there.

Walter wrote:

> John Fletcher wrote in message <3B7BC551.E9907C61@aston.ac.uk>...
> >Walter wrote:
> >> I held off for a long time posting the spec because the alpha compiler wasn't strong enough yet. Finally, I did decide to post just the spec
> here
> >> to test the waters first. Once I do have a decent compiler for it, then
> we
> >> can investigate a larger audience.
> >> I can't make it open source, due to the licensing issues. The alpha
> compiler
> >> uses the optimizer and back end of the C compiler. What I'd like to try
> and
> >> do is release the front end as open source to someone who would hopefully graft it onto gcc <g>.
> >If the front end was open source, would it be possible to add new internal
> types
> >to it which were compounds of existing types, e.g. quaternion?
>
> Yes. The way it is laid out internally is meant to make it easy to add new built-in types. The difficulty is getting the *back* end to support them. In order to make complex types work, I had to get them to work in the back end; quite a bit of work there.

Sorry, I don't understand. If the front end could specify all its components in terms of existing types, would this difficult apply?  I guess so, since a complex is just two reals.  Could the back end have hooks to make it easier?

John