next upload (was: Re: bug 219448)

Paul Boekholt
Sat, 21 May 2005 13:15:45 +0200

On Sat, 21 May 2005 09:43:02 +0100, Alastair McKinstry <> said:

> I was already packaging 2.0.2 when I received your mail; can you explain
> this issue a bit further? I don't see how implementing 2.0.0 helps (will
> hold off uploading 2.0.2 for the moment)

Packaging 2.0.0 would be OK because that version does not have the
incompatibility of 2.0.2.  In 2.0.2, an "autoload" statement such as
autoload("f", bar)

evaluated in namespace foo will create a name foo->f that will cause the
file bar to be evaluated in namespace foo when that function is called,
that is, when calls f().  But if contained the definition
public define f()
than this will lead to an error in slang 2.0.2,  you'd get the error

f already has static or private linkage in this unit

In this case the word "public" in was superfluous, and removing it
would get rid of the error.  However the fact that slang 2.0.2 will load
the file in the foo namespace, instead of just using the global
namespace, can cause deeper incompatibilities.  For example if
looks like
define f()

and both the global namespace and the foo namespace have a g(), 2.0.0 as
well as 1.x will use Global->g() and 2.0.2 will use foo->g() (if foo->g()
is static that is, private functions are now private to the file they are

So the solution is to make sure that the autoloads are above the
"implements" line.  So in this involves the change

autoload("f", "bar");


autoload("f", "bar");

It gets even worse when the require() and provide() functions of slang 2
(in /usr/share/slsh/ are used in a future version of JED.  Then
all requires and provides will also have to be moved above any implements

So quite a few scripts will have to be updated.