What Julia Does Right

[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:
>>
>>
>> 1. 
>> 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 the`D`language. The author of the 
> `D` plug-in can use the latest `D` features at any time, and 
> the`D` 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.