[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Help sought understanding shorthands wrt modules/packages

From: Richard Stallman
Subject: Re: Help sought understanding shorthands wrt modules/packages
Date: Fri, 11 Nov 2022 22:35:51 -0500

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I must admit that I don't understand what you are referring to.  Could
  > you please give an example of a module system doing that?

I can't.  I have never written code in a language which has such a
module system.  I read about these module systems decades ago.
For more details, or examples, you will need to ask people who have
actually used them.

                                                               At first
  > glance It sounds like visibility rules, or something, but I don't
  > remember a language with different visibility rules for functions and
  > variables, ATM.

What I recall is NOT that there are "different visibility rules",
but rather that the visibility rules would apply to specific definitions.

Perhaps in those languages a given symbol can have only one active
definition in any scope.  So a symbol could be have a function definition
or a variable definition in any given module, but never both.

I think that is the situation in Scheme.  But I have never programmed
in Scheme.

  > > The grave problem of :USE in CL packages could be fixed by replacing
  > > it with a new construct that specifies a list of symbols to be
  > > inherited from each other package, perhaos with renaming.

  > I fail to understand the "grave" problem, sorry.  Could you please give
  > a more concrete example?

Perhaps "shadow" or "shadowing-import" amount to the construct I was
envisioning.  I saw those terms only today, and I don't know what they

  > > We could call this system "corrected CL packages."
  > > It would not be compatible but it would be better.

  > It could be compatible, at least I don't see a reason right now why it
  > couldn't.

It could be made upward-compatible, but not fully compatible: programs
using :INHERIT would not load in standard Common Lisp.

Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]