www.digitalmars.com         C & C++   DMDScript  

D - Wider discussion

reply John Fletcher <J.P.Fletcher aston.ac.uk> writes:
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
Aug 14 2001
parent reply Mark Evans <mevans zyvex.com> writes:
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
Aug 14 2001
parent reply "Walter" <walter digitalmars.com> writes:
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
Aug 14 2001
next sibling parent reply "Erik Funkenbusch" <erikf seahorsesoftware.com> writes:
"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?
Aug 14 2001
parent reply "Walter" <walter digitalmars.com> writes:
"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?
Aug 15 2001
parent Charles Hixson <charleshixsn earthlink.net> writes:
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).
Aug 16 2001
prev sibling next sibling parent reply John Fletcher <J.P.Fletcher aston.ac.uk> writes:
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
Aug 16 2001
parent reply "Walter" <walter digitalmars.com> writes:
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.
Aug 17 2001
next sibling parent reply John Fletcher <J.P.Fletcher aston.ac.uk> writes:
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
Aug 17 2001
parent reply "Walter" <walter digitalmars.com> writes:
John Fletcher wrote in message <3B7D3B82.940D2C16 aston.ac.uk>...

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?


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.
Aug 17 2001
parent John Fletcher <J.P.Fletcher aston.ac.uk> writes:
Walter wrote:


 John Fletcher wrote in message <3B7D3B82.940D2C16 aston.ac.uk>...

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?

 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
Aug 20 2001
prev sibling parent "Sean L. Palmer" <spalmer iname.com> writes:
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




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.
Nov 04 2001
prev sibling next sibling parent Russell Bornschlegel <kaleja estarcion.com> writes:
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
Aug 16 2001
prev sibling parent John English <je brighton.ac.uk> writes:
Walter wrote:

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


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
-----------------------------------------------------------------
May 08 2002