🚀 go-pugleaf

In article <1991Apr19.163253.22253@kestrel.edu> gyro@kestrel.edu (Scott Layson Burson) writes:
>
>To see if we can get some discussion going on the matter, let me
>sketch a simple proposal.  Suppose we were to introduce a keyword
>"module" with a simple syntax:
>
>   module Foo {
>     // ... declarations
>   }
>
>The intent here is that the declarations within the braces have
>exactly the same form as those normally found at top level, so that
>one can write things like
>
>   module Foo {
>   #include "something.h"
>   }
>
>where the author of the header file need not have done anything
>special to make such usage possible.

Would it work just as well to say
class Foo {
#include "something.h"
}

since classes and everything else (?) can -- eventually -- be nested inside
classes.
>
>The only problem I can see with it concerns the issue of binary-only
>library distribution, which, it has already been noted, is problematic
>anyway.  It is not hard to imagine linker extensions that could fix
>this, but I gather that is considered an undesirable thing to do.
>

We already (pre-C++) have namespace problems in libraries.  Two functions
in different libraries can have the same name and the ambiguity is
resolved by the order in which the libraries are linked.  The same thing in
the C++ case will take care of all situations except where the programmer
actually uses a global name which is in both libraries but wants the one from
the library later in the compile command line.  This is likely to be much
more common in C++ than it was in C I think.  The linker extension to 
accommodate this would be straightforward.
	1) Be able to associate a scope identifier (e.g. MyLib:: ) with
	a library either in a program or on the command line.
	2) Have the linker defer any references beginning with such scope
	identifiers until the library associated with that scope id.
	3) Global names without scope ids associated with libraries would
	be resolved as before -- giving backwards compatibility.
Still perhaps more than anyone wants to do.  However if anyone ever changes
the linker for other reasons...

David R. Cok
Eastman Kodak Company -- Imaging Science Lab
cok@Kodak.COM

In article <1991Apr19.183922.1982@kodak.kodak.com> cok@islsun.Kodak.COM (David Cok) writes:
>In article <1991Apr19.163253.22253@kestrel.edu> gyro@kestrel.edu (Scott Layson Burson) writes:
>>
>>To see if we can get some discussion going on the matter, let me
>>sketch a simple proposal.  Suppose we were to introduce a keyword
>>"module" with a simple syntax:
>>
>>   module Foo {
>>     // ... declarations
>>   }
>>
...
>
>Would it work just as well to say
>class Foo {
>#include "something.h"
>}
>
>since classes and everything else (?) can -- eventually -- be nested inside
>classes.

Right.  That's just what I proposed awhile back.  However I think that Scott
wanted something slightly more than this (and so do I).

It is (or will be in future) reasonably easy to package up all of the things
that we now put into include files and give them all their own little
namespaces by wrapping them in `class <identifier> { ... }'.  (Note that
you will have to declare all data member and function member as "static"
if you want the effect of a "module" however.)

The problem is *not* one of establishing new "modules" or new "namespaces"
(which class declarations can do quite well, thank you).  No.  The problem
is that if you do this, it becomes quite cumbersome to *reference* the
things whose declarations you have now nested within class declarations.
Specifically, it is quite irritating to have to write out the extra
CLASSNAME:: qualification all over the place.

How can this problem (i.e. the *real* problem) be solved?

Recently, I proposed the introduction of a Pascal style `with' statement.
Thinking more about it, I now realize that it would probably be better to
have something more like an Ada `use' statement to solve this problem.
An Ada `use' statement looks just like `use <module>;' (where <module>
is just an identifier for some module).  You put such a statement into
any scope where you want to be able to refer to the members of <module>
*without* the qualification.  (The `use' statement only applies within
the scope which contains it.)  If you `use' two or more modules within
the same scope, and if those modules contain identically named declarations
for different things, then in order to refer (unambigously) to any of the
things with the (conflicting) name, you must use the full and explicit
qualification.

The big problem with a Pascal-style `with' statement is that it is treated
as a form of an executable statement (rather like a `while' statement).
Thus, you can't place them at `file-scope' in C++.

But Ada's `use' statement is treated like a declarative statement.  Thus,
if we had such a beast in C++, we could make it legal to write `use'
statements at the file-scope level.  That could be most helpful.

I think that if we had a `use' statement in C++, the problem of namespaces
would be mostly solved.  Of course there would still be that irritating
need to declare data and function members as `static'.  That's where having
a `module <identifier> { ... }' construct would come in handy.  We could
define a `module' to be just like a class except that its data members and
function members would all be *implicitly* static.  Still, I'm sure that
we're all against introducing new keywords if it could be avoided, so how
about just using `class <identifier> static { ... }' rather than requiring
`module <identifier>'.

-- 

// Ron ("Loose Cannon") Guilmette
// Internet: rfg@ncd.com      uucp: ...uunet!lupine!rfg
// New motto:  If it ain't broke, try using a bigger hammer.

In article <5143@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes:
>The problem is *not* one of establishing new "modules" or new "namespaces"
>(which class declarations can do quite well, thank you).

Except that as you point out later on in your message, there is
currently no way to wrap a class declaration around a group of
top-level declarations and have them be treated as static members by
default.  So it seems to me that until some syntax is defined for that
purpose, this is still the primary problem, since as things stand
there's no way to resolve name conflicts at all (without editing the
source, which is exactly what I'm trying to avoid).

>							   No.  The problem
>is that if you do this, it becomes quite cumbersome to *reference* the
>things whose declarations you have now nested within class declarations.
>Specifically, it is quite irritating to have to write out the extra
>CLASSNAME:: qualification all over the place.
>
>How can this problem (i.e. the *real* problem) be solved?

Though I'm not opposed to an attempt to solve this problem in some
such way as you suggest, I think you overrate it.  I've worked on a
number of projects where the qualifiers were part of the names (i.e.
the language in use had no namespace facility at all), and therefore
they *always* had to be included, even in references from *inside* the
module.  Even so, it didn't particularly bother me, I guess partly
because the qualifiers made it easy to know what source file to look
in to find a definition.

>Recently, I proposed the introduction of a Pascal style `with' statement.
>Thinking more about it, I now realize that it would probably be better to
>have something more like an Ada `use' statement to solve this problem.

I agree that this would be handy.

>I think that if we had a `use' statement in C++, the problem of namespaces
>would be mostly solved.  Of course there would still be that irritating
>need to declare data and function members as `static'.  That's where having
>a `module <identifier> { ... }' construct would come in handy.  We could
>define a `module' to be just like a class except that its data members and
>function members would all be *implicitly* static.  Still, I'm sure that
>we're all against introducing new keywords if it could be avoided, so how
>about just using `class <identifier> static { ... }' rather than requiring
>`module <identifier>'.

Except it would presumably be `struct <identifier> static { ... }',
since it wouldn't do you much good if all the members were private!

Personally, I would prefer the introduction of a keyword in this case,
because it seems awfully strange to be using `struct' when I'm really
not declaring a structure.  Also, if there were also some sort of
`use' declaration, I think I would really want it to work only on
modules; otherwise its definition has to be that it makes the names of
only static members visible, because it wouldn't make sense to make
the names of normal (nonstatic) members visible, and I think that
would be weird.

-- Scott

rfg@NCD.COM (Ron Guilmette) writes:

:In article <1991Apr19.183922.1982@kodak.kodak.com> cok@islsun.Kodak.COM (David Cok) writes:
:>In article <1991Apr19.163253.22253@kestrel.edu> gyro@kestrel.edu (Scott Layson Burson) writes:
:>>
:>>To see if we can get some discussion going on the matter, let me
:>>sketch a simple proposal.  Suppose we were to introduce a keyword
:>>"module" with a simple syntax:
:>>
:>>   module Foo {
:>>     // ... declarations
:>>   }
:>>
:...
:>
:>Would it work just as well to say
:>class Foo {
:>#include "something.h"
:>}
:>
:>since classes and everything else (?) can -- eventually -- be nested inside
:>classes.

:Right.  That's just what I proposed awhile back.  However I think that Scott
:wanted something slightly more than this (and so do I).

:It is (or will be in future) reasonably easy to package up all of the things
:that we now put into include files and give them all their own little
:namespaces by wrapping them in `class <identifier> { ... }'.  (Note that
:you will have to declare all data member and function member as "static"
:if you want the effect of a "module" however.)

:The problem is *not* one of establishing new "modules" or new "namespaces"
:(which class declarations can do quite well, thank you).  No.  The problem
:is that if you do this, it becomes quite cumbersome to *reference* the
:things whose declarations you have now nested within class declarations.
:Specifically, it is quite irritating to have to write out the extra
:CLASSNAME:: qualification all over the place.

:How can this problem (i.e. the *real* problem) be solved?

:Recently, I proposed the introduction of a Pascal style `with' statement.
:Thinking more about it, I now realize that it would probably be better to
:have something more like an Ada `use' statement to solve this problem.
:An Ada `use' statement looks just like `use <module>;' (where <module>
:is just an identifier for some module).  You put such a statement into
:any scope where you want to be able to refer to the members of <module>
:*without* the qualification.  (The `use' statement only applies within
:the scope which contains it.)  If you `use' two or more modules within
:the same scope, and if those modules contain identically named declarations
:for different things, then in order to refer (unambigously) to any of the
:things with the (conflicting) name, you must use the full and explicit
:qualification.

:The big problem with a Pascal-style `with' statement is that it is treated
:as a form of an executable statement (rather like a `while' statement).
:Thus, you can't place them at `file-scope' in C++.

:But Ada's `use' statement is treated like a declarative statement.  Thus,
:if we had such a beast in C++, we could make it legal to write `use'
:statements at the file-scope level.  That could be most helpful.

:I think that if we had a `use' statement in C++, the problem of namespaces
:would be mostly solved.  Of course there would still be that irritating
:need to declare data and function members as `static'.  That's where having
:a `module <identifier> { ... }' construct would come in handy.  We could
:define a `module' to be just like a class except that its data members and
:function members would all be *implicitly* static.  Still, I'm sure that
:we're all against introducing new keywords if it could be avoided, so how
:about just using `class <identifier> static { ... }' rather than requiring
:`module <identifier>'.

I've thought about this, and come to the same conclusions as Ron.
Well, how should the "use" syntax look like?  How about:

default class CLASSNAME-LIST {
  // code goes here;
}

This way, we won't need to introduce new keywords.  Possibly the
"class" keyword could be left out but I think it makes the code
more readable.  The effect of such a statement would be to push
the scopes of the specified classes, much like the effect of
entering the scope of a class who publicly inherits from those
classes.  The last point made is relevant to compiler implementors
who could reuse the scope-handling in these cases.  Would anybody
care to comment on this?  Should we (the net) try to write a proposal
to the ANSI commitee before their june meeting in Lund, Sweden (at
least I think that's the case, some of the members will speak at
some seminars there, which I'll try to attend).

				Niklas

-- 
Niklas Hallqvist	Phone: +46-(0)31-40 75 00
Applitron Datasystem	Fax:   +46-(0)31-83 39 50
Molndalsvagen 95	Email: niklas@appli.se
S-412 63  GOTEBORG, Sweden     mcsun!sunic!chalmers!appli!niklas

In article <1991Apr19.163253.22253@kestrel.edu> gyro@kestrel.edu (Scott Layson Burson) writes:
>
>To see if we can get some discussion going on the matter, let me
>sketch a simple proposal.  Suppose we were to introduce a keyword
>"module" with a simple syntax:
>
>   module Foo {
>     // ... declarations
>   }
>
>The intent here is that the declarations within the braces have
>exactly the same form as those normally found at top level, so that
>one can write things like
>
>   module Foo {
>   #include "something.h"
>   }
>
>where the author of the header file need not have done anything
>special to make such usage possible.
>
Let me refer to this as the "standard proposal" for no better reason than
that I have proposed the exact same syntax elsewhere. 

One could embellish this to give the module private and public parts,
overcoming the wretched "static/extern" syntax. 

But there are some significant problems with name space control. While you
now can disambiguate a name conflict in the source file

	module A { ... int f() ... }
	module B { ... int f() ... }

on the link level, there are still two global functions f() which cannot
be distinguished. Sure, the implementation of the f()'s could also be
contained in module A { ... } and module B { ... } wrappers, but that
rather negates the module A { #include "..." } trick. And it doesn't
protect against the problem of two module designers assigning the same
module name. 

Also, one may well argue that 

	module A { /* global data and functions */ }

is no different from 

	class A { /* the same data and functions */ }
	main() { A anInstance; /* ... */ }

so the feature is unnecessary. 

Does anyone have any idea how to overcome the problem of two classes/
global functions having the same name using a renaming syntax like in
Eiffel? I can see how this works in the compilation stage, but I still
don't understand how one can do the link step with a standard linker. 

Cay

In article <5143@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes:
>The problem is *not* one of establishing new "modules" or new "namespaces"
>(which class declarations can do quite well, thank you).  No.  The problem
>is that if you do this, it becomes quite cumbersome to *reference* the
>things whose declarations you have now nested within class declarations.
>Specifically, it is quite irritating to have to write out the extra
>CLASSNAME:: qualification all over the place.

Wouldn't this be a case were multiple inheritance could be used?

	struct Modulename {
		static ....;
		static ....;
	};

	class Foo : private Modulename {
		....
	};

I think it would solve the problem of "getting into" the module for code
packaged in classes.  Name conflicts only arise when an ambiguous name
is _used_, if I remember correctly, and can be solved with explicit
qualification.

Another property I like in Modula-2 is to be able to selectively
import names from a module, i.e.,

	IMPORT fission FROM Atomic;

I do not see how this very useful feature could be provided with the
class-as-module-and-no-new-keywords-please approach.

		-- Dag Bruck

In article <5143@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes:
>It is (or will be in future) reasonably easy to package up all of the things
>that we now put into include files and give them all their own little
>namespaces by wrapping them in `class <identifier> { ... }'.  (Note that
>you will have to declare all data member and function member as "static"
>if you want the effect of a "module" however.)
>
>The problem is *not* one of establishing new "modules" or new "namespaces"
>(which class declarations can do quite well, thank you).  No.  The problem
>is that if you do this, it becomes quite cumbersome to *reference* the
>things whose declarations you have now nested within class declarations.
>Specifically, it is quite irritating to have to write out the extra
>CLASSNAME:: qualification all over the place.
>
> [proposed 'use' clause to get around this naming problem]

No need to invent new language structures -- use private inheritance.

For example, your class wants to use several libraries.  Each of these
libraries is packaged into a big class, with nested classes for the
real functionality, and maybe a couple of static functions, etc.
I.e., instead of

CARSTUFF.H:
    const int NumTires = 4; 
    class Tire {...};
    class Axle {...};
    class Manifold {...};

You do CARSTUFF.H:
    struct CARSTUFF {
      static const int NumTires;
      class Tire {...};
      class Axle {...};
      class Manifold {...};
    }; 

Now consider what would have been a problem before: you want to
use both the CARSTUFF library, and the TOPOLOGY library, both of which
define (different) Manifold classes.  But you don't want to qualify
the non-conflicting names, like Axle and MetricSpace.
No problem:

class MyClass: private CARSTUFF, private TOPOLOGY
{
    CARSTUFF::Manifold my_auto_manifold;
    TOPOLOGY::Manifold my_topological_manifold;
    HausdorffSpace space;
    Axle axles[2];
};


Peter Golde
petergo%microsoft@uunet.uu.net

In article <5143@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes:
|The problem is *not* one of establishing new "modules" or new "namespaces"
|(which class declarations can do quite well, thank you).  No.  The problem
|is that if you do this, it becomes quite cumbersome to *reference* the
|things whose declarations you have now nested within class declarations.
|Specifically, it is quite irritating to have to write out the extra
|CLASSNAME:: qualification all over the place.
|
|How can this problem (i.e. the *real* problem) be solved?

C++ already has several "solutions" to these kinds of problems:

1) Within a member function "this->" is the default
2) Within a class inherited classnames are the default
3) Using references you can use shorthand names
....

Substituting "module" for "class" in the above list leads to many ideas.
Here's some examples:

// the following silly #defines are introduced just to help show what 
// I'm talking about:
#define MODULE class
#define USE :

MODULE XYZCorpClasses
{
public:
	static int intThing;	
	class Object { public: void doSomething(); };
	// ....
};

MODULE ABCCorpClasses
{
public:
	class Object { public: void doSomething(); };
	// ....
};

MODULE MyClasses USE public XYZCorpClasses
{
public:
	class Derived : public Object 
	{ public: void doSomething(); };

	static void main()
	{
		// let's try using some XYZ stuff by default:

		Object object; object.doSomething();
		Derived dirv; dirv.doSomething();

		// now let's use some non-default ABC stuff instead:

		ABCCorpClasses::Object abcOb; abcOb.doSomething();

		// or explicitly use XYZ stuff if we like:

		XYZCorpClasses::Object xyzOb; xyzOb.doSomething();
	}
};


void main() { MyClasses::main(); }

In article <5143@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes:

   Recently, I proposed the introduction of a Pascal style `with' statement.
   Thinking more about it, I now realize that it would probably be better to
   have something more like an Ada `use' statement to solve this problem.
   An Ada `use' statement looks just like `use <module>;' (where <module>
   is just an identifier for some module). ... If you `use' two or
   more modules within
   the same scope, and if those modules contain identically named declarations
   for different things, then in order to refer (unambigously) to any of the
   things with the (conflicting) name, you must use the full and explicit
   qualification.

The Common Lisp package system has a similar scheme; in fact, there
is a function called USE-PACKAGE which does (effectively) what ADA use
does, except that the CL package system is really something that works
at READ (parse) time on symbols, not at compile time on semantic
units.

I'm not sure if ``overloading'' class is a good way to introduce such
a feature; adding new keywords would be justified in this case.

Scott Layson Burson <gyro@kestrel.edu> writes:
|Suppose we were to introduce a keyword "module" with a simple syntax:
|   module Foo {
|     // ... declarations
|   }

Ron Guilmette <rfg@NCD.COM> writes:
|how about just using `class <identifier> static { ... }' rather than
|requiring `module <identifier>'?

Niklas Hallqvist <niklas@appli.se> writes:
|How about:
|
|default class CLASSNAME-LIST {
|  // code goes here;
|}

I'd like something similar to Ron's idea, but the other way around:

static class <identifier> {
	// ...
}

Did you know that the above currently passes cfront without a peep?
The "static" doesn't actually *do* anything, but nothing complains.
This could be more generally defined as any storage-specifier
preceding a class definition becomes the default storage-specification
for the scope of the class?  Should it include [previously[ automatic
variables inside [non-inline] method definitions?  Hrm.  Perhaps only
limited to the scope of the class definition..

					Reid
--
Reid Ellis     1 Trefan Street Apt. E, Toronto ON, M5A 3A9
rae@utcs.toronto.edu        ||               rae@alias.com
CDA0610@applelink.apple.com ||      +1 416 362 9181 [work]

In article <1991Apr25.060721.12694@alias.com> rae@alias.com (Reid Ellis) writes:

   Scott Layson Burson <gyro@kestrel.edu> writes:
   |Suppose we were to introduce a keyword "module" with a simple syntax:
   |   module Foo {
   |     // ... declarations
   |   }

   Ron Guilmette <rfg@NCD.COM> writes:
   |how about just using `class <identifier> static { ... }' rather than
   |requiring `module <identifier>'?

   Niklas Hallqvist <niklas@appli.se> writes:
   |How about:
   |
   |default class CLASSNAME-LIST {
   |  // code goes here;
   |}

   I'd like something similar to Ron's idea, but the other way around:

   static class <identifier> {
	   // ...
   }

   Did you know that the above currently passes cfront without a peep?
   The "static" doesn't actually *do* anything, but nothing complains.

This is probably because
	static class X { ... } x;
would be a valid declaration.  It wouldn't be unreasonable for the
translator to complain about storage-class specifiers used in empty
declarations, but I wouldn't expect it.

   This could be more generally defined as any storage-specifier
   preceding a class definition becomes the default storage-specification
   for the scope of the class?

You could only do it for otherwise-empty declarations, and then the
result depends on whether an identifier name follows the class body.
Bletch.

Ron's suggestion works best of those above, in my opinion, because the
construct (specifically the placement of "static") bears little
resemblance to existing constructs.  The one Niklas proposes, if (as
he suggested) the "class" keyword becomes optional, might confuse a
compiler trying to do error recovery (e.g., from a missing ":" after
"default").

I haven't thought about it enough to know which suggestions I like as
a user of the language.  I've spent plenty of time recently dealing
with the g++ grammar, though.

rae@alias.com (Reid Ellis) writes:

>Scott Layson Burson <gyro@kestrel.edu> writes:
>|Suppose we were to introduce a keyword "module" with a simple syntax:
>|   module Foo {
>|     // ... declarations
>|   }

>Ron Guilmette <rfg@NCD.COM> writes:
>|how about just using `class <identifier> static { ... }' rather than
>|requiring `module <identifier>'?

>Niklas Hallqvist <niklas@appli.se> writes:
>|How about:
>|
>|default class CLASSNAME-LIST {
>|  // code goes here;
>|}

>I'd like something similar to Ron's idea, but the other way around:

>static class <identifier> {
>	// ...
>}

Aha, you misunderstood me...
My syntax wasn't invented for the declaration of a "module",
but rather as a replacement for the Ada "use"-statement.  I like
Ron's original syntax for the declaration, your syntax has the problem
of misunderstanding the definition:

static class X {
  // ...
} foo;

which defines "foo" to be a static instance of X with file scope.  In your proposal X would be an instance of a "module" X with global scope.  Please,
look at this example to understand my thoughts:

class PersistantObjectSystem static {
  class Storable {
    // ...
  }
  Storable* fetch():
}

void foo()
{
  default class PersistantObjectSystem {
    Storable *x = fetch(); // Means:
    // PersistantObjectSystem::Storable *x = Persistant::fetch();

  }
}
void foo (@x());
-- 
Niklas Hallqvist	Phone: +46-(0)31-40 75 00
Applitron Datasystem	Fax:   +46-(0)31-83 39 50
Molndalsvagen 95	Email: niklas@appli.se
S-412 63  GOTEBORG, Sweden     mcsun!sunic!chalmers!appli!niklas

Reid Ellis <rae@alias.com> [that's me] writes:
>I'd like something similar to Ron's idea, but the other way around:
>
>static class <identifier> {
>	// ...
>}

As several people pointed out in email, this is used for declarations
like

static class foo { ... } varname;

to declare 'varname' as a static variable.

Never mind... :)
							Reid
--
Reid Ellis     1 Trefan Street Apt. E, Toronto ON, M5A 3A9
rae@utcs.toronto.edu        ||               rae@alias.com
CDA0610@applelink.apple.com ||      +1 416 362 9181 [work]

Why don't we simply use a syntax which already evokes this concept --
using "extern"?

I don't know if another keyword after the extern is necessary, or
simply the name of the enclosing scope.  Something like the following?

extern NIH {
#include <NIHCL.h>
};
					Reid
						-- still red from not seeing
						-- the "static class {} var;"
						-- option. :)
--
Reid Ellis     1 Trefan Street Apt. E, Toronto ON, M5A 3A9
rae@utcs.toronto.edu        ||               rae@alias.com
CDA0610@applelink.apple.com ||      +1 416 362 9181 [work]

In article <1358@appli.se> niklas@appli.se (Niklas Hallqvist) writes:
>I've thought about this, and come to the same conclusions as Ron.
>Well, how should the "use" syntax look like?  How about:

Again, some simple alternatives to "use" blocks is for programmers to use
references as a short named alternative:

	WRAPPERCLASSNAME::doThis();
	WRAPPERCLASSNAME::doThat();
	WRAPPERCLASSNAME::doTheNextThing();

becomes:

	WRAPPERCLASSNAME const x& = ....;
	x.doThis();
	x.doThat();
	x.doTheNextThing();

which is hardly more onerous than:

	use WRAPPERCLASSNAME
	{
		doThis();
		doThat();
		doTheNextThing();
	}

Another alternative is:

class X : public WRAPPERCLASSNAME
{
public:
	static void doABunchOfStuff()
	{
		doThis();
		doThat();
		doTheNextThing();
	}
}

So, I'd rather see implementors spending their time and effort to make
existing features of the language more efficient, and thereby more
widely used, rather than adding new syntax in order to perform occasional
spot optimizations.