www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Adding Modules to C in 10 Lines of Code

reply Walter Bright <newshound2 digitalmars.com> writes:
https://nwcpp.org/

An online presentation.

Monday at 7PM PST.
Apr 17
next sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 4/17/22 13:12, Walter Bright wrote:
 https://nwcpp.org/
 
 An online presentation.
 
 Monday at 7PM PST.
(My earlier post disappeared.) April 20 is Wednesday. Ali
Apr 17
parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/17/2022 5:40 PM, Ali Çehreli wrote:
 On 4/17/22 13:12, Walter Bright wrote:
 https://nwcpp.org/

 An online presentation.

 Monday at 7PM PST.
(My earlier post disappeared.) April 20 is Wednesday. Ali
Gak! My bad. You're right.
Apr 17
prev sibling next sibling parent user1234 <user1234 12.de> writes:
On Sunday, 17 April 2022 at 20:12:38 UTC, Walter Bright wrote:
 https://nwcpp.org/

 An online presentation.

 Monday at 7PM PST.
I thought to that when you made this, a few weeks ago, for importC: "that's 10 lines because module system is already backed by D system of scopes, symbol lookups(, etc.)" For a pure C compiler, it would be more like 200 lines, right ?
Apr 19
prev sibling next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Sunday, 17 April 2022 at 20:12:38 UTC, Walter Bright wrote:
 https://nwcpp.org/

 An online presentation.

 Monday at 7PM PST.
Will there be a recording available?
Apr 19
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Tuesday, 19 April 2022 at 12:41:18 UTC, jmh530 wrote:
 On Sunday, 17 April 2022 at 20:12:38 UTC, Walter Bright wrote:
 https://nwcpp.org/

 An online presentation.

 Monday at 7PM PST.
Will there be a recording available?
Talks from past NWCPP meetups are on their YouTube channel here: https://www.youtube.com/user/NWCPP/videos I assume this one will be there, too.
Apr 19
parent jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 19 April 2022 at 12:46:16 UTC, Mike Parker wrote:
 [snip]

 Talks from past NWCPP meetups are on their YouTube channel here:

 https://www.youtube.com/user/NWCPP/videos

 I assume this one will be there, too.
Thanks.
Apr 19
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/19/2022 5:41 AM, jmh530 wrote:
 Will there be a recording available?
Yes. NWCPP routinely posts the video a few days later.
Apr 19
prev sibling parent ezneh <petitv.isat gmail.com> writes:
On Tuesday, 19 April 2022 at 12:41:18 UTC, jmh530 wrote:
 On Sunday, 17 April 2022 at 20:12:38 UTC, Walter Bright wrote:
 https://nwcpp.org/

 An online presentation.

 Monday at 7PM PST.
Will there be a recording available?
Here it is: https://www.youtube.com/watch?v=2ImfbGm0fls
Apr 22
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/17/2022 1:12 PM, Walter Bright wrote:
 https://nwcpp.org/
 
 An online presentation.
 
 Monday at 7PM PST.
Slides: https://nwcpp.org/talks/2022/modules_in_c.pdf Video: https://www.youtube.com/watch?v=2ImfbGm0fls
Apr 22
next sibling parent Matheus <matheus gmail.com> writes:
Invidious instances:

https://invidious.flokinet.to/watch?v=2ImfbGm0fls
https://invidious.namazso.eu/watch?v=2ImfbGm0fls
https://vid.puffyan.us/watch?v=2ImfbGm0fls
https://inv.riverside.rocks/watch?v=2ImfbGm0fls
https://invidious.weblibre.org/watch?v=2ImfbGm0fls
https://yt.artemislena.eu/watch?v=2ImfbGm0fls
https://invidious.osi.kr/watch?v=2ImfbGm0fls

And much more: https://redirect.invidious.io/watch?v=2ImfbGm0fls

Matheus.
Apr 22
prev sibling parent reply forkit <forkit gmail.com> writes:
On Friday, 22 April 2022 at 19:54:13 UTC, Walter Bright wrote:
 On 4/17/2022 1:12 PM, Walter Bright wrote:
 https://nwcpp.org/
 
 An online presentation.
 
 Monday at 7PM PST.
Slides: https://nwcpp.org/talks/2022/modules_in_c.pdf Video: https://www.youtube.com/watch?v=2ImfbGm0fls
Here is the answer to the 2 questions you posed in your presentation: (1) why nobody has done this in 40 years? (2) what went on with C++ for 20 years? It's simple. Rational choice theory tell us, that the reward of the action must outweigh the costs incurred.
May 02
next sibling parent Jack <jckj33 gmail.com> writes:
On Tuesday, 3 May 2022 at 01:54:16 UTC, forkit wrote:
 On Friday, 22 April 2022 at 19:54:13 UTC, Walter Bright wrote:
 On 4/17/2022 1:12 PM, Walter Bright wrote:
 https://nwcpp.org/
 
 An online presentation.
 
 Monday at 7PM PST.
Slides: https://nwcpp.org/talks/2022/modules_in_c.pdf Video: https://www.youtube.com/watch?v=2ImfbGm0fls
Here is the answer to the 2 questions you posed in your presentation: (1) why nobody has done this in 40 years? (2) what went on with C++ for 20 years? It's simple. Rational choice theory tell us, that the reward of the action must outweigh the costs incurred.
I don't quite get it, did you mean the C import isn't worth the cost?
May 27
prev sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Tuesday, 3 May 2022 at 01:54:16 UTC, forkit wrote:
 On Friday, 22 April 2022 at 19:54:13 UTC, Walter Bright wrote:
 On 4/17/2022 1:12 PM, Walter Bright wrote:
 https://nwcpp.org/
 
 An online presentation.
 
 Monday at 7PM PST.
Slides: https://nwcpp.org/talks/2022/modules_in_c.pdf Video: https://www.youtube.com/watch?v=2ImfbGm0fls
Here is the answer to the 2 questions you posed in your presentation: (1) why nobody has done this in 40 years? (2) what went on with C++ for 20 years? It's simple. Rational choice theory tell us, that the reward of the action must outweigh the costs incurred.
Stepstone did it for Objective-C with #import, and Apple with module maps for C and Objective-C, the modules design that preceeded C++ modules on clang. Then we have those failed attempts at fixing C like SafeC. And if we count research work, Bjarne Stroustoup and Gabriel dos Reis, did it back when they were teaching in Texas university, here is the 2009 paper, "A Principled, Complete, and Efficient Representation of C++" https://www.stroustrup.com/gdr-bs-macis09.pdf Both Visual Age for C++ v0.4 and Lucid's Energize C++ did 40 years ago, by serializing C++ code into database representation, both failed due to high hardware requirements for late 80's/early 90's PCs. Lucid Energize Demo in 1993 https://www.youtube.com/watch?v=pQQTScuApWk Its database system, Cadillac, "Foundation for a C++ Programming Environment" https://dreamsongs.com/Files/Energize.pdf Visual Age for C++ v4, http://www.edm2.com/0704/vacpp4/vacpp4.html
 The build environment is totally different from traditional 
 compilers. The concept of header files and source code files is 
 obsolete. VAC++ utilizes a global approach to definitions and 
 implementations. That is, once a definition is processed it 
 stays in memory for the duration of the build. To maintain 
 compatibility, header files can still be #included. This new 
 approach to handling source code is disorienting at first and 
 will make migrating existing code to the compiler somewhat 
 difficult. Errors pertaining to objects being defined more than 
 once will likely occur while migrating. Often these errors are 
 incorrect. The work around is to remove the #include line in 
 the source file that contains the offending “redefinition”.
https://books.google.de/books?id=ZwHxz0UaB54C&pg=PA206&redir_esc=y#v=onepage&q&f=false Additionally the way pre-compiled headers work on C++ Builder and Visual C++, versus the UNIX way, meant that on Windows the reward of the action did not outweigh the costs incurred, and ironically Visual C++ is the one leading the C++ modules support anyway, thanks to Gabriel dos Reis being part of the team, and pinging back on those 2009 learnings.
May 29
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/29/2022 11:13 PM, Paulo Pinto wrote:
 Stepstone did it for Objective-C with #import,
Not the same as C doing the importing of C code.
 and Apple with module maps for C 
 and Objective-C, the modules design that preceeded C++ modules on clang.
 
 Then we have those failed attempts at fixing C like SafeC.
 
 And if we count research work, Bjarne Stroustoup and Gabriel dos Reis, did it 
 back when they were teaching in Texas university, here is the 2009 paper,
 
 "A Principled, Complete, and Efficient Representation of C++"
 
 https://www.stroustrup.com/gdr-bs-macis09.pdf
Going around the horn, really doing it the hard way. Besides, writing a paper is not the same thing as implementing a working system. There were many proposals about adding modules to C, they just all went nowhere.
 Both Visual Age for C++ v0.4 and Lucid's Energize C++ did 40 years ago, by 
 serializing C++ code into database representation, both failed due to high 
 hardware requirements for late 80's/early 90's PCs.
Yee gods, doing it with a database representation is certainly going around the horn. Note that neither D nor ImportC rely on some database or symbol table file.
 Lucid Energize Demo in 1993
 
 https://www.youtube.com/watch?v=pQQTScuApWk
 
 Its database system, Cadillac,
 
 "Foundation for a C++ Programming Environment"
 
 https://dreamsongs.com/Files/Energize.pdf
 
 Visual Age for C++ v4,
 
 http://www.edm2.com/0704/vacpp4/vacpp4.html
 
 The build environment is totally different from traditional compilers. The 
 concept of header files and source code files is obsolete. VAC++ utilizes a 
 global approach to definitions and implementations. That is, once a definition 
 is processed it stays in memory for the duration of the build. To maintain 
 compatibility, header files can still be #included. This new approach to 
 handling source code is disorienting at first and will make migrating existing 
 code to the compiler somewhat difficult. Errors pertaining to objects being 
 defined more than once will likely occur while migrating. Often these errors 
 are incorrect. The work around is to remove the #include line in the source 
 file that contains the offending “redefinition”.
https://books.google.de/books?id=ZwHxz0UaB54C&pg=PA206&redir_esc=y v=onepage&q&f=false Additionally the way pre-compiled headers work on C++ Builder and Visual C++, versus the UNIX way, meant that on Windows the reward of the action did not outweigh the costs incurred, and ironically Visual C++ is the one leading the C++ modules support anyway, thanks to Gabriel dos Reis being part of the team, and pinging back on those 2009 learnings.
Precompiled headers for C and C++ were certainly a module-like system (I know because I wrote one), but they are horrific kludges.
Jun 04
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Saturday, 4 June 2022 at 07:40:36 UTC, Walter Bright wrote:
 On 5/29/2022 11:13 PM, Paulo Pinto wrote:
 [...]
Not the same as C doing the importing of C code.
 [...]
Going around the horn, really doing it the hard way. Besides, writing a paper is not the same thing as implementing a working system. There were many proposals about adding modules to C, they just all went nowhere.
 [...]
Yee gods, doing it with a database representation is certainly going around the horn. Note that neither D nor ImportC rely on some database or symbol table file.
 [...]
Precompiled headers for C and C++ were certainly a module-like system (I know because I wrote one), but they are horrific kludges.
I guess going around the horn is a synonym for lets pretend there wasn't prior art and keep arguing D did it first, as usual.
Jun 04
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/4/2022 5:29 AM, Paulo Pinto wrote:
 I guess going around the horn is a synonym for lets pretend there wasn't prior 
 art and keep arguing D did it first, as usual.
Writing a paper is not doing it first.
Jun 04
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Saturday, 4 June 2022 at 19:26:27 UTC, Walter Bright wrote:
 On 6/4/2022 5:29 AM, Paulo Pinto wrote:
 I guess going around the horn is a synonym for lets pretend 
 there wasn't prior art and keep arguing D did it first, as 
 usual.
Writing a paper is not doing it first.
That paper had a real implementation to follow along, while Lucid and IBM products were real things one could buy.
Jun 04
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/4/2022 10:54 PM, Paulo Pinto wrote:
 That paper had a real implementation to follow along,
I didn't see it.
 while Lucid and IBM 
 products were real things one could buy.
That are *C* compilers doing imports for *C* code? What C compilers have imports: gcc - nope clang - nope VC - nope Digital Mars C - nope C Standard - nope ImportC - yes!
Jun 05
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Sunday, 5 June 2022 at 22:41:14 UTC, Walter Bright wrote:
 On 6/4/2022 10:54 PM, Paulo Pinto wrote:
 That paper had a real implementation to follow along,
I didn't see it.
 while Lucid and IBM products were real things one could buy.
That are *C* compilers doing imports for *C* code? What C compilers have imports: gcc - nope clang - nope VC - nope Digital Mars C - nope C Standard - nope ImportC - yes!
https://clang.llvm.org/docs/Modules.html And I am out of this thread.
Jun 05
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 6 June 2022 at 05:49:55 UTC, Paulo Pinto wrote:
 https://clang.llvm.org/docs/Modules.html

 And I am out of this thread.
Yes, Objective-C has added modules to C since forever… Just rename your .c file to .m I guess that would be the first.
Jun 06
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 6 June 2022 at 11:02:32 UTC, Ola Fosheim Grøstad wrote:
 Yes, Objective-C has added modules to C since forever… Just 
 rename your .c file to .m

 I guess that would be the first.
Or maybe not… you still use .h, so it depends on the implementation. Pointless discussion really.
Jun 06
prev sibling next sibling parent reply Daniel N <no public.email> writes:
On Monday, 6 June 2022 at 05:49:55 UTC, Paulo Pinto wrote:
 On Sunday, 5 June 2022 at 22:41:14 UTC, Walter Bright wrote:
 On 6/4/2022 10:54 PM, Paulo Pinto wrote:
 That paper had a real implementation to follow along,
I didn't see it.
 while Lucid and IBM products were real things one could buy.
That are *C* compilers doing imports for *C* code? What C compilers have imports: gcc - nope clang - nope VC - nope Digital Mars C - nope C Standard - nope ImportC - yes!
https://clang.llvm.org/docs/Modules.html And I am out of this thread.
https://clang.llvm.org/docs/Modules.html#objective-c-import-declaration "At present, there is no C or C++ syntax for import declarations. Clang will track the modules proposal in the C++ committee. See the section Includes as imports to see how modules get imported today." So Object-C can import C, but *C* cannot import *C*. Walter added __import support in *.c, clang could have done the same but they *didn't*, they were also probably just 10 lines away from the goal.
Jun 06
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 6 June 2022 at 11:23:44 UTC, Daniel N wrote:
 So Object-C can import C, but *C* cannot import *C*.
Objective-C is a proper superset of C AFAIK.
Jun 06
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/5/2022 10:49 PM, Paulo Pinto wrote:
 On Sunday, 5 June 2022 at 22:41:14 UTC, Walter Bright wrote:
 That are *C* compilers doing imports for *C* code?
https://clang.llvm.org/docs/Modules.html And I am out of this thread.
I had thought that was just for ObjectiveC. It seems it does work for C, though the user has to create "module map" files: "To actually see any benefits from modules, one first has to introduce module maps for the underlying C standard library and the libraries and headers on which it depends. The section Modularizing a Platform describes the steps one must take to write these module maps."
Jun 07
prev sibling parent reply mee6 <mee6 lookat.me> writes:
On Saturday, 4 June 2022 at 19:26:27 UTC, Walter Bright wrote:
 On 6/4/2022 5:29 AM, Paulo Pinto wrote:
 I guess going around the horn is a synonym for lets pretend 
 there wasn't prior art and keep arguing D did it first, as 
 usual.
Writing a paper is not doing it first.
Why do you care so much about being "first"? Would you not have implemented and made a presentation about it if you didn't think it was the first implementation?
Jun 05
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/5/2022 7:26 AM, mee6 wrote:
 On Saturday, 4 June 2022 at 19:26:27 UTC, Walter Bright wrote:
 On 6/4/2022 5:29 AM, Paulo Pinto wrote:
 I guess going around the horn is a synonym for lets pretend there wasn't 
 prior art and keep arguing D did it first, as usual.
Writing a paper is not doing it first.
Why do you care so much about being "first"? Would you not have implemented and made a presentation about it if you didn't think it was the first implementation?
Because it's fun to be first!
Jun 05
next sibling parent reply zjh <fqbqrr 163.com> writes:
On Sunday, 5 June 2022 at 22:41:41 UTC, Walter Bright wrote:

 Because it's fun to be first!
Yes, `'d'` is always independent. For example, `'d'` is the `first one` without `class encapsulation`.
Jun 05
next sibling parent reply zjh <fqbqrr 163.com> writes:
On Monday, 6 June 2022 at 00:19:16 UTC, zjh wrote:

 Because it's fun to be first!
Yes, `'d'` is always independent.
[C++'s moudle](https://www.oschina.net/news/198583/c-plus-plus-23-to-introduce-module-support) `D`, hurry up and get nervous.
Jun 05
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 6 June 2022 at 01:05:38 UTC, zjh wrote:
 On Monday, 6 June 2022 at 00:19:16 UTC, zjh wrote:

 Because it's fun to be first!
Yes, `'d'` is always independent.
[C++'s moudle](https://www.oschina.net/news/198583/c-plus-plus-23-to-introduce-module-support) `D`, hurry up and get nervous.
C++ has had modules for a while, but only Microsoft has a fully compliant implementation: https://en.cppreference.com/w/cpp/language/modules https://en.cppreference.com/w/cpp/compiler_support/20 Give it a year to be fully usable across compilers.
Jun 06
prev sibling parent reply forkit <forkit gmail.com> writes:
On Monday, 6 June 2022 at 00:19:16 UTC, zjh wrote:
 On Sunday, 5 June 2022 at 22:41:41 UTC, Walter Bright wrote:

 Because it's fun to be first!
Yes, `'d'` is always independent. For example, `'d'` is the `first one` without `class encapsulation`.
To be fair, the encapsulation of a class can be encapsulated within a module, but not in a class (as one might reasonably expect, if they come from any other main stream language that uses a class type). This implies (to me at least) that D does not consider a class to be a real type, like other main stream languages do. Some new languages have even gone out of there way to get rid of the class type completely! At least D hasn't gone that far.. yet. I suspect there are many in the D community that would welcome that ;-) Even an int type gets better recognition 'as a type', in D. But yes, as far as i know, D is the first to do this - i.e. turn the class into a pseudo type, that cannot have encapsulation unless it is put into a super type (the module), all by its self (with no friends). private could change that. D could be the first indeed, for turning a pseudo class type, back into an first class type. C'mon D. Be the first!
Jun 05
next sibling parent reply zjh <fqbqrr 163.com> writes:
On Monday, 6 June 2022 at 03:17:34 UTC, forkit wrote:

 Some new languages have even gone out of there way to get rid 
 of the class type completely! At least D hasn't gone that far.. 
 yet. I suspect there are many in the D community that would 
 welcome that ;-)
I don't know many other languages,I am not used to them. `Rust` seems no class. These people are too radical.
Jun 05
next sibling parent zjh <fqbqrr 163.com> writes:
On Monday, 6 June 2022 at 03:28:07 UTC, zjh wrote:

 `Rust` seems no class. These people are too radical.
It is easy to `make mistakes` if you take big `changes`.
Jun 05
prev sibling parent reply forkit <forkit gmail.com> writes:
On Monday, 6 June 2022 at 03:28:07 UTC, zjh wrote:
 On Monday, 6 June 2022 at 03:17:34 UTC, forkit wrote:

 Some new languages have even gone out of there way to get rid 
 of the class type completely! At least D hasn't gone that 
 far.. yet. I suspect there are many in the D community that 
 would welcome that ;-)
I don't know many other languages,I am not used to them. `Rust` seems no class. These people are too radical.
Rust did not set out to be a multi-paradigm language. For Rust, I suspect they got of rid of the class, because they were setting out to be a high-performace, systems-level, programming language, and so decided that the class abstraction had to go. Ok. Fair enough. D likes to think of itself as a high-performace, systems-level, programming language, as well, but it also claims to be a multi-paradigm language. I have no doubt that many in the D community would also love to remove the class abstraction from the langauge, completely, and then they could force people into thinking 'the D way'. I guess they want us to be grateful, that they have provided us with a pseudo class type. How nice of them. The addidtion of a little character, , to word private, could change this: private // Compiler says: oh. so you really want private to mean private? ok. I'll do it for you. no problem. But I think even that is asking too much of the D community ;-)
Jun 05
next sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 6/5/22 22:01, forkit wrote:

 I have no doubt that many in the D community would also love to remove
 the class abstraction from the langauge, completely, and then they could
 force people into thinking 'the D way'.
I must accept that "you have no doubt" but that claim is baseless.
 I guess they want us to be grateful, that they have provided us with a
 pseudo class type. How nice of them.
Now, that is trolling. Ali
Jun 05
next sibling parent forkit <forkit gmail.com> writes:
On Monday, 6 June 2022 at 05:48:14 UTC, Ali Çehreli wrote:
 Now, that is trolling.

 Ali
Well, I could argue, correctly, that trolling is when someone picks only part of your argument, and uses only that part to support their own agenda - which is to destroy your argument by making it out to be something it is not.
Jun 05
prev sibling parent forkit <forkit gmail.com> writes:
On Monday, 6 June 2022 at 05:48:14 UTC, Ali Çehreli wrote:
 Now, that is trolling.

 Ali
juvenalian satire, perhaps. I'd accept that. But trolling? Really?
Jun 05
prev sibling parent zjh <fqbqrr 163.com> writes:
On Monday, 6 June 2022 at 05:01:27 UTC, forkit wrote:

 The addidtion of a little character,  , to word private, could 
 change this:

  private // Compiler says: oh. so you really want private to 
 mean private? ok. I'll do it for you. no problem.
You need a `DIP`.
Jun 05
prev sibling next sibling parent claptrap <clap trap.com> writes:
On Monday, 6 June 2022 at 03:17:34 UTC, forkit wrote:
 On Monday, 6 June 2022 at 00:19:16 UTC, zjh wrote:
 On Sunday, 5 June 2022 at 22:41:41 UTC, Walter Bright wrote:
But yes, as far as i know, D is the first to do this - i.e. turn the class into a pseudo type, that cannot have encapsulation unless it is put into a super type (the module), all by its self (with no friends).
Delphi / Object Pascal had the same visibility as D, private only meant private to the module.
Jun 06
prev sibling parent Dom Disc <dominikus scherkl.de> writes:
On Monday, 6 June 2022 at 03:17:34 UTC, forkit wrote:
 cannot have encapsulation unless it is put into a super type
 (the module), all by its self (with no friends).
It can have friends - they just need to be in the same file (module). And a class without its friend is really only half a type - that's why it is better to think of the module as the new type - which contains both the interface and all interna (friends and sub-classes and system parts that should not be visible from the outside). That's what a file is for in general: to collect things that belong together and should be seen as a single object. It makes no sense to put other unrelated classes or functions into the same file. Especially not in a large project (which is the only case where encapsulation makes sense at all).
Jun 06
prev sibling parent mee6 <mee6 lookat.me> writes:
On Sunday, 5 June 2022 at 22:41:41 UTC, Walter Bright wrote:
 On 6/5/2022 7:26 AM, mee6 wrote:
 On Saturday, 4 June 2022 at 19:26:27 UTC, Walter Bright wrote:
 On 6/4/2022 5:29 AM, Paulo Pinto wrote:
 I guess going around the horn is a synonym for lets pretend 
 there wasn't prior art and keep arguing D did it first, as 
 usual.
Writing a paper is not doing it first.
Why do you care so much about being "first"? Would you not have implemented and made a presentation about it if you didn't think it was the first implementation?
Because it's fun to be first!
How's it fun to be first? Why is it that what other people are doing, with no connection to you, reduces the 'fun' you have? Are you having fun trying to dismiss every implementation of modules in C so you can be "first"?
Jun 08
prev sibling parent reply claptrap <clap trap.com> writes:
On Saturday, 4 June 2022 at 12:29:59 UTC, Paulo Pinto wrote:
 On Saturday, 4 June 2022 at 07:40:36 UTC, Walter Bright wrote:
 On 5/29/2022 11:13 PM, Paulo Pinto wrote:


 Precompiled headers for C and C++ were certainly a module-like 
 system (I know because I wrote one), but they are horrific 
 kludges.
I guess going around the horn is a synonym for lets pretend there wasn't prior art and keep arguing D did it first, as usual.
Yikes whats up with you man? You need a hug?
Jun 04
parent Paulo Pinto <pjmlp progtools.org> writes:
On Sunday, 5 June 2022 at 04:42:44 UTC, claptrap wrote:
 On Saturday, 4 June 2022 at 12:29:59 UTC, Paulo Pinto wrote:
 On Saturday, 4 June 2022 at 07:40:36 UTC, Walter Bright wrote:
 On 5/29/2022 11:13 PM, Paulo Pinto wrote:


 Precompiled headers for C and C++ were certainly a 
 module-like system (I know because I wrote one), but they are 
 horrific kludges.
I guess going around the horn is a synonym for lets pretend there wasn't prior art and keep arguing D did it first, as usual.
Yikes whats up with you man? You need a hug?
Nah, fed up with "D did it first, other languages keep copying us" meme. Don't worry, I refrain myself in the future.
Jun 04