Date: Fri, 4 Feb 2022 16:35:00 +0000
[Steve]
* It would be a huge step forward if we can figure out how to do it.
I have faith in us 😊
* Loosely coupled systems require compromises and conventions for interoperability. Giving you my modular code to use outside my build system, compiler, and environment needs some implicit communication channel, and we don't have much besides the filesystem to start the bootstrap process.
Agreed, we need communication and some implicit assumptions to make things out. We also need some way to use the filesystem. However, my contention is that the degree of assumptions does not need to be as deeply and inflexible as it is through the current suggestion of filesystem layout.
* Also, note that we're over here in SG15. We're setting minimal baselines
Fully aware of that 😊
* I think what we're looking for is what would be an `install` or `export` step from the build.
We also need to add a step that allows for ‘design time’ build+use – something not as prevalent in conventional C world but not completely alien to it either. That additional step is a productivity opportunity and we shouldn’t squander it.
-- Gaby
From: Steve Downey <sdowney_at_[hidden]>
Sent: Thursday, February 3, 2022 5:41 PM
To: Gabriel Dos Reis <gdr_at_[hidden]>
Cc: sg15_at_[hidden]
Subject: Re: [SG15] Meeting on February 4th at 9AM Pacific
On Thu, Feb 3, 2022 at 8:07 PM Gabriel Dos Reis <gdr_at_[hidden]<mailto:gdr_at_[hidden]>> wrote:
[Steve]
* We've had deep concerns about tooling for modules forever.
Correct. But the suggestion of encoding into the filesystem is more of productivity opportunity inhibitor than a solution, which is why it was rejected back then. It is a huge step back.
-- Gaby
It would be a huge step forward if we can figure out how to do it. On the other hand, the one compiler I'm aware of that didn't distribute headers as files, Visual Age C++, stopped existing more than a decade ago.
Loosely coupled systems require compromises and conventions for interoperability. Giving you my modular code to use outside my build system, compiler, and environment needs some implicit communication channel, and we don't have much besides the filesystem to start the bootstrap process.
The argument that `class Xyzzy;` can be in any file is compelling, however the language systems that I know that have an `import class Xyzzy;` have filesystemlike requirements so that the class can be deterministically found.
Also, note that we're over here in SG15. We're setting minimal baselines. I wouldn't expect a Visual Studio project to ship this information to itself via this mechanism. That would be painful and wasteful, and require the build system to forget things it fullwell knows. I think what we're looking for is what would be an `install` or `export` step from the build.
* It would be a huge step forward if we can figure out how to do it.
I have faith in us 😊
* Loosely coupled systems require compromises and conventions for interoperability. Giving you my modular code to use outside my build system, compiler, and environment needs some implicit communication channel, and we don't have much besides the filesystem to start the bootstrap process.
Agreed, we need communication and some implicit assumptions to make things out. We also need some way to use the filesystem. However, my contention is that the degree of assumptions does not need to be as deeply and inflexible as it is through the current suggestion of filesystem layout.
* Also, note that we're over here in SG15. We're setting minimal baselines
Fully aware of that 😊
* I think what we're looking for is what would be an `install` or `export` step from the build.
We also need to add a step that allows for ‘design time’ build+use – something not as prevalent in conventional C world but not completely alien to it either. That additional step is a productivity opportunity and we shouldn’t squander it.
-- Gaby
From: Steve Downey <sdowney_at_[hidden]>
Sent: Thursday, February 3, 2022 5:41 PM
To: Gabriel Dos Reis <gdr_at_[hidden]>
Cc: sg15_at_[hidden]
Subject: Re: [SG15] Meeting on February 4th at 9AM Pacific
On Thu, Feb 3, 2022 at 8:07 PM Gabriel Dos Reis <gdr_at_[hidden]<mailto:gdr_at_[hidden]>> wrote:
[Steve]
* We've had deep concerns about tooling for modules forever.
Correct. But the suggestion of encoding into the filesystem is more of productivity opportunity inhibitor than a solution, which is why it was rejected back then. It is a huge step back.
-- Gaby
It would be a huge step forward if we can figure out how to do it. On the other hand, the one compiler I'm aware of that didn't distribute headers as files, Visual Age C++, stopped existing more than a decade ago.
Loosely coupled systems require compromises and conventions for interoperability. Giving you my modular code to use outside my build system, compiler, and environment needs some implicit communication channel, and we don't have much besides the filesystem to start the bootstrap process.
The argument that `class Xyzzy;` can be in any file is compelling, however the language systems that I know that have an `import class Xyzzy;` have filesystemlike requirements so that the class can be deterministically found.
Also, note that we're over here in SG15. We're setting minimal baselines. I wouldn't expect a Visual Studio project to ship this information to itself via this mechanism. That would be painful and wasteful, and require the build system to forget things it fullwell knows. I think what we're looking for is what would be an `install` or `export` step from the build.
Received on 2022-02-04 16:35:03