The Master Guardian of the Source wrote:
> I'm strongly in favour of not keeping changing names. If we can do
> it, let's put the naming scheme you guys have settled on in 4.07.
Well, that's exactly my point: There is no coherent "scheme" yet. And
I'm not proposing random changes, only three small additions, one
having an additional bonus (see below).
> It's not officially out yet, but when it is people will start using
> it, and be cross if we change it in 4.08.
And that's exactly what I'm trying to avoid: Non-uniform names
becoming folclore. So again my plea is:
Every monadic constructor of a data type, i.e. a function of type
`... -> IO DataType' should be named `newDataType'. The old names
are retained for at least 4.07 and probably 4.08, but are clearly
marked as deprecated.
This will only break programs which e.g. import the whole module
StableName and contain a home-made function `newStableName', but let's
face it: How many people in the whole world are there having this
problem? Even in that highly improbable case, an explicit import list
(preferred for backwards compatibility) or a simple hiding clause can
cure the problem.
Perhaps we should start a small discussion thread in the Haskell list
around naming conventions and write down some guidelines.
> Im also still wondering whether the original makeForeignObj (or
> whatever it was) should be restored, since I gather its name is now
> available, to avoid gratuitously breaking people's existing programs.
> Sigbjorn might legitimately be irritated at having to change HDirect
> back, but we might all consider it worth it to avoid causing hassle to
> others.
I'm in favour of resurrecting the old definition, of course marked as
deprecated.
Some final remarks about my view of lib/compiler changes in general.
Existing programs fall in one of several categories:
* Programs written in pure H98 + standard H98 libs: Apart from very
few exceptions, these are probably only toy ones. They are not
affected by the changes in discussion, anyway.
* Programs written in pure H98 + non-H98 libs: This category is
probably much larger and *is* affected by the changes. But even
these programs must already have some time of #ifdef-ery/autoconf
magic ("Hmmm, is GetOpt in syslib/package util or exts? And where
is Addr?"). So some cautious changes in the libs don't make
things any worse here.
* Programs written in H98 + language extensions (FFI, one of the
several extensions to the type system, ...) + probably some
non-H98 libs: This category is probably the largest one. But the
*really* serious compatibility/portability problems are not some
simple name changes, but fundamental things like: Does the FFI
automatically unwrap newtypes or not? Are overlapping instances
supported or not? What about MPTC? Does a library like Storable
exist at all? You currently won't survive without comitting
yourself to a specific Haskell system (probably version no >= XY)
*plus* autoconf or something similar anyway.
The hslibs don't have a `final' status yet, like H98, and this is a
good thing. They still contain some rough edges and inconsistencies,
so let's get things right before it is too late.
And, hey! People obviously even live with the following cruel
versionitis (taken from the M$ compiler docs, one of my favourites):
-------------------------------------------------------------------
The InterlockedDecrement function both decrements (decreases by
one) the value of the specified 32-bit variable and checks the
resulting value. The function prevents more than one thread from
using the same variable simultaneously.
LONG InterlockedDecrement(
LPLONG lpAddend // address of the variable to decrement
);
Parameters:
lpAddend
Pointer to the 32-bit variable to decrement.
Return Values:
Windows 98, Windows NT 4.0 and later: The return value is the
resulting decremented value.
Windows 95, Windows NT 3.51 and earlier: If the result of the
operation is zero, the return value is zero. If the result of the
operation is less than zero, the return value is negative, but it
is not necessarily equal to the result. If the result of the
operation is greater than zero, the return value is positive, but
it is not necessarily equal to the result.
Remarks:
The functions InterlockedDecrement, InterlockedCompareExchange,
InterlockedExchange, InterlockedExchangeAdd, and
InterlockedIncrement provide a simple mechanism for synchronizing
access to a variable that is shared by multiple threads. The
threads of different processes can use this mechanism if the
variable is in shared memory. The variable pointed to by the
lpAddend parameter must be aligned on a 32-bit boundary; otherwise,
this function will fail on multiprocessor x86 systems.
-------------------------------------------------------------------
Quite a mess for an atomic `--lpAddend'... And what is W2k doing here?
:-P
Cheers,
Sven
