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

order. One of the sitting USENET groups might be a better starting point,

released.
One strategy that made Python a great success was its development model.

other developers and users. To this day, Guido retains autocratic rule

open-source, too, and that always helps. You can go the open-source route

Lack of template support might be a mistake. That is one of the better

late in the game and was adopted into the standard.
Take a look at blitz++ and the Matrix Template Library for some ideas. I

For strings, I always loved the way the Icon language (formerly SNOBOL,

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

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 know that templates likely will be a big issue. I intend to address it

version 2 of the language. The way C++ does it is simply too complicated

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

version 2 of the language. The way C++ does it is simply too complicated

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

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

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

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

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

}
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

"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).

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

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

to test the waters first. Once I do have a decent compiler for it, then

can investigate a larger audience.
I can't make it open source, due to the licensing issues. The alpha

uses the optimizer and back end of the C compiler. What I'd like to try

do is release the front end as open source to someone who would hopefully
graft it onto gcc <g>.

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.

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

to test the waters first. Once I do have a decent compiler for it, then

can investigate a larger audience.
I can't make it open source, due to the licensing issues. The alpha

uses the optimizer and back end of the C compiler. What I'd like to try

do is release the front end as open source to someone who would hopefully
graft it onto gcc <g>.

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

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

The back end had the concept of only one real at a time. With complex
numbers, it had to start dealing with pairs. Also, complex numbers are
returned in (ST1,ST0). It wasn't that hard, there were just a lot of
permutations, since operands could be any combination of real, imaginary, or
complex, all with slightly different semantics. Multiply and divide are
implemented with helper functions rather than directly. Etc. Just a lot of
details.

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

The back end had the concept of only one real at a time. With complex
numbers, it had to start dealing with pairs. Also, complex numbers are
returned in (ST1,ST0). It wasn't that hard, there were just a lot of
permutations, since operands could be any combination of real, imaginary, or
complex, all with slightly different semantics. Multiply and divide are
implemented with helper functions rather than directly. Etc. Just a lot of
details.

I see. I have the same sort of special cases, only I am handling them at a
higher level in the template code. So it would not be that easy to have
something which had more than two, because of the register allocations.
John

This would be so cool. So I go onto some cool new machine, that exposes a
64 register stack with 8 doubles each and is just built for doing matrix
math, I could take the open source front end and add in some add-on support
module code to manipulate (do operations on) some type. Provide operators
and argument types, how to cast it or otherwise construct it from other
types, and tell the main compiler what assembly sequences have to be
generated to do each operation requested of it. The code generator could
maintain internal state to remember what it had done recently (such as which
registers or pseudo-registers it has allocated at that point in execution,
what's on the stack where) so it could optimize the code as it goes.
Quite interesting. BTW a non-optimizing backend is easy... what's hard is
writing an optimizing backend. If you're not worried about the speed of the
generated code you can avoid a lot of work. May be ok for the first D
compiler to only generate debug-quality code.
Sean
"Walter" <walter digitalmars.com> wrote in message
news:9lih2t$10ca$1 digitaldaemon.com...

John Fletcher wrote in message <3B7BC551.E9907C61 aston.ac.uk>...

If the front end was open source, would it be possible to add new

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.

order to make complex types work, I had to get them to work in the back

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

Icon uses array slice notation to get at substrings:
x[2:10] -- 9 chars selected from x
x[:10] -- from the start to position 10
x[10:] -- from position 10 to the end
Negative subscripts are treated as offsets from the end of the array,
so x[-1] is the last character of x (or thereabouts; I can't remember
if subscripts are 0-based or 1-based. If 1-based, then x[0] is the
last character and x[-1] the penultimate one).
So (assuming 1-based subscripts) you can get all but the first and
last chars of x using x[2:-1].
-----------------------------------------------------------------
John English | mailto:je brighton.ac.uk
Senior Lecturer | http://www.it.bton.ac.uk/staff/je
Dept. of Computing | ** NON-PROFIT CD FOR CS STUDENTS **
University of Brighton | -- see http://burks.bton.ac.uk
-----------------------------------------------------------------