| |
| Posted by FeepingCreature in reply to zjh | PermalinkReply |
|
FeepingCreature
| On Friday, 9 December 2022 at 02:10:01 UTC, zjh wrote:
> On Thursday, 8 December 2022 at 17:47:42 UTC, Walter Bright wrote:
> Here's a good thought provoking article:
https://viralinstruction.com/posts/goodjulia/
A couple of things stood out for me:
- https://viralinstruction.com/posts/goodjulia/#the_package_manager_is_amazing
I've never thought of a package manager that way.
I just saw the neat language which based on D . I think language plug-in is really a very good concept. The D plug-in author can specifically open/close some D features In this way, the author of the D plug-in does not need to set up a separate branch, but directly set up a sub branch under the plug-in directory of theD language. The author of the D plug-in can use the latest D features at any time, and theD user can also enjoy the D plug-in feature.
In this way, people do not need to establish branches of 'D' .
Note that an important attribute of the way I use macros is that they're pulled into the compiler automatically, but only directly affect code that imports them. So the meaning of existing syntax can be overloaded at the use site by a macro type like all types can, ie. opCall, opBinary, etc., but you only get new syntax if you macro import . The goal is to have a rich central type system that macros can internally fall back on.
If you treat macros as compiler plugins that you pass on the command line, for instance, you fracture the ecosystem because you can no longer combine two libraries with macros that occupy the same syntax. The goal is to keep macros, broadly, encapsulated to the site of use.
|