PATCH: alias modules

PATCH: alias modules

[zefram]

Here are some alias modules to let the old module names work.  The old
names are not 100% equivalent to the new names; they work for loading,
autoloading and dependencies, which I think is enough.  I made aliases
for all the module names in 3.1.2-pws-12, except for `zsh' (`zsh/main'),
which can't possibly be being used in any way affected by the renaming.
We should probably pare down the alias list a bit; the 3.1.7 release
shouldn't need backward compatibility with anything later than 3.1.6,
and so shouldn't have aliases for any names that didn't exist in 3.1.6.

Before applying the patch, you'll need a directory Src/Aliases.
After applying the patch, you need to execute the script ".preconfig" in
that directory to build the *.mdd files, which remain in the source tree.
After that you can do a "make prep" in the build tree, and then everything
should build happily.

-zefram

diff -crN ../zsh+hname/Src/Aliases/.cvsignore ./Src/Aliases/.cvsignore
*** ../zsh+hname/Src/Aliases/.cvsignore	Thu Jan  1 01:00:00 1970
--- ./Src/Aliases/.cvsignore	Thu Dec 16 12:40:21 1999
***************
*** 0 ****
--- 1,16 ----
+ Makefile
+ Makefile.in
+ *.export
+ so_locations
+ *.pro
+ *.epro
+ *.syms
+ *.o
+ *.o.c
+ *.so
+ *.mdh
+ *.mdhi
+ *.mdhs
+ *.mdh.tmp
+ *.c
+ *.mdd
diff -crN ../zsh+hname/Src/Aliases/.distfiles ./Src/Aliases/.distfiles
*** ../zsh+hname/Src/Aliases/.distfiles	Thu Jan  1 01:00:00 1970
--- ./Src/Aliases/.distfiles	Thu Dec 16 13:17:45 1999
***************
*** 0 ****
--- 1,8 ----
+ DISTFILES_SRC='
+     .cvsignore .distfiles .exrc .preconfig
+     alias.mdd.in alias.c.in
+     cap.mdd clone.mdd compctl.mdd complete.mdd complist.mdd
+     computil.mdd deltochar.mdd example.mdd files.mdd mapfile.mdd
+     mathfunc.mdd parameter.mdd rlimits.mdd sched.mdd stat.mdd
+     zftp.mdd zle.mdd zleparameter.mdd zutil.mdd
+ '
diff -crN ../zsh+hname/Src/Aliases/.exrc ./Src/Aliases/.exrc
*** ../zsh+hname/Src/Aliases/.exrc	Thu Jan  1 01:00:00 1970
--- ./Src/Aliases/.exrc	Thu Dec 16 12:39:39 1999
***************
*** 0 ****
--- 1,2 ----
+ set ai
+ set sw=4
diff -crN ../zsh+hname/Src/Aliases/.preconfig ./Src/Aliases/.preconfig
*** ../zsh+hname/Src/Aliases/.preconfig	Thu Jan  1 01:00:00 1970
--- ./Src/Aliases/.preconfig	Thu Dec 16 13:18:19 1999
***************
*** 0 ****
--- 1,32 ----
+ #! /bin/sh
+ 
+ for zshmod in \
+     cap \
+     clone \
+     compctl \
+     complete \
+     complist \
+     computil \
+     deltochar \
+     example \
+     files \
+     mapfile \
+     mathfunc \
+     parameter \
+     rlimits \
+     sched \
+     stat \
+     zftp \
+     zle \
+     zleparameter \
+     zutil \
+ ; do
+     localname=$zshmod
+     aliasname=$zshmod
+     depname=zsh/$zshmod
+     sed '
+ 	s,@LOCALNAME@,'$localname',g
+ 	s,@ALIASNAME@,'$aliasname',g
+ 	s,@DEPNAME@,'$depname',g
+     ' < alias.mdd.in > ${localname}.mdd
+ done
diff -crN ../zsh+hname/Src/Aliases/alias.c.in ./Src/Aliases/alias.c.in
*** ../zsh+hname/Src/Aliases/alias.c.in	Thu Jan  1 01:00:00 1970
--- ./Src/Aliases/alias.c.in	Thu Dec 16 12:59:47 1999
***************
*** 0 ****
--- 1,59 ----
+ /*
+  * alias.c.in - blank module for zsh
+  *
+  * This file is part of zsh, the Z shell.
+  *
+  * Copyright (c) 1996-1997 Andrew Main
+  * All rights reserved.
+  *
+  * Permission is hereby granted, without written agreement and without
+  * license or royalty fees, to use, copy, modify, and distribute this
+  * software and to distribute modified versions of this software for any
+  * purpose, provided that the above copyright notice and the following
+  * two paragraphs appear in all copies of this software.
+  *
+  * In no event shall Andrew Main or the Zsh Development Group be liable
+  * to any party for direct, indirect, special, incidental, or consequential
+  * damages arising out of the use of this software and its documentation,
+  * even if Andrew Main and the Zsh Development Group have been advised of
+  * the possibility of such damage.
+  *
+  * Andrew Main and the Zsh Development Group specifically disclaim any
+  * warranties, including, but not limited to, the implied warranties of
+  * merchantability and fitness for a particular purpose.  The software
+  * provided hereunder is on an "as is" basis, and Andrew Main and the
+  * Zsh Development Group have no obligation to provide maintenance,
+  * support, updates, enhancements, or modifications.
+  *
+  */
+ 
+ #include "@NAME@.mdh"
+ #include "@NAME@.pro"
+ 
+ /**/
+ int
+ setup_(Module m)
+ {
+     return 0;
+ }
+ 
+ /**/
+ int
+ boot_(Module m)
+ {
+     return 0;
+ }
+ 
+ /**/
+ int
+ cleanup_(Module m)
+ {
+     return 0;
+ }
+ 
+ /**/
+ int
+ finish_(Module m)
+ {
+     return 0;
+ }
diff -crN ../zsh+hname/Src/Aliases/alias.mdd.in ./Src/Aliases/alias.mdd.in
*** ../zsh+hname/Src/Aliases/alias.mdd.in	Thu Jan  1 01:00:00 1970
--- ./Src/Aliases/alias.mdd.in	Thu Dec 16 13:12:06 1999
***************
*** 0 ****
--- 1,20 ----
+ name=@ALIASNAME@
+ 
+ nozshdep=1
+ 
+ moddeps="@DEPNAME@"
+ 
+ objects="@LOCALNAME@.o"
+ 
+ :<<\Make
+ @LOCALNAME@.mdd: alias.mdd.in
+ 	rm -f $@
+ 	cd $(sdir) && ./.preconfig
+ 
+ @LOCALNAME@.c: alias.c.in
+ 	sed 's,@NAME@,@LOCALNAME@,g' < $(sdir)/alias.c.in > $@
+ 
+ clean-here: clean.@LOCALNAME@
+ clean.@LOCALNAME@:
+ 	rm -f @LOCALNAME@.c
+ Make
diff -crN ../zsh+hname/Src/xmods.conf ./Src/xmods.conf
*** ../zsh+hname/Src/xmods.conf	Thu Dec 16 10:14:15 1999
--- ./Src/xmods.conf	Thu Dec 16 13:08:11 1999
***************
*** 8,10 ****
--- 8,29 ----
  zsh/computil
  zsh/parameter
  zsh/zleparameter
+ cap
+ clone
+ compctl
+ complete
+ complist
+ computil
+ deltochar
+ example
+ files
+ mapfile
+ mathfunc
+ parameter
+ rlimits
+ sched
+ stat
+ zftp
+ zle
+ zleparameter
+ zutil
END

Re: PATCH: alias modules

[Peter Stephenson]

zefram@fysh.org wrote:
> Here are some alias modules to let the old module names work.

any reason you haven't done this the way I suggested, which would have put
aliasing under user control, would have allowed zmodload to show up aliases
clearly (e.g. `zutil -> zsh/zutil') and wouldn't have filled the place up
with bogus modules (some 30k each here)?  if it was just time, maybe I'll
have a go myself eventually, since it seems much cleaner.

-- 
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>

Re: PATCH: alias modules

[Zefram]

Peter Stephenson wrote:
>any reason you haven't done this the way I suggested, which would have put
>aliasing under user control,

We don't want aliasing under user control.  My view is that aliases are
for backward compatibility only.

The point of hierarchical module names is that each module can
have a canonical global name, and users loading modules can specify
unambiguously which module they want.  To do that, the user has to give
the fully-qualified module name at some point.  And since modules are
usually (auto)loaded in initialisation files anyway, there's no typing
saved by letting the user set up an abbreviated name.

But really the reason why I did it this way is that it seems neater.
It's adding no new semantics, just using the existing infrastructure
(module dependencies).  zsh has far too much semi-hidden state as it
is; it's time we started using its existing capabilities to their full
potential, rather than doing each new thing in C.  The new completion
system is heading that way, much to my delight.

>                             would have allowed zmodload to show up aliases
>clearly

zmodload -d

OK, this makes no distinction between alias modules and other
dependencies.  But OTOH, I don't think we want to treat straight aliases
specially.  What if we split a module into several: with this system, we
can make the old name an empty module depending on all the new modules,
and it is treated exactly like the 1-to-1 aliases.

>                                    and wouldn't have filled the place up
>with bogus modules (some 30k each here)?

Oh.  They're 3620 bytes each here, and I assumed they'd be small
everywhere, since they contain almost no code.  But as I explained
earlier, my intention is that there won't eventually be so many.  3.1.7
should contain aliases only for those modules that existed in 3.1.6,
and we should consider at some point which modules are really important
enough to warrant backward compatibility with the old names.

-zefram

Re: PATCH: alias modules

[Peter Stephenson]

Zefram wrote:
> We don't want aliasing under user control.  My view is that aliases are
> for backward compatibility only.
> 
> The point of hierarchical module names is that each module can
> have a canonical global name, and users loading modules can specify
> unambiguously which module they want.  To do that, the user has to give
> the fully-qualified module name at some point.  And since modules are
> usually (auto)loaded in initialisation files anyway, there's no typing
> saved by letting the user set up an abbreviated name.
> 
> But really the reason why I did it this way is that it seems neater.

Still not convinced.  I'm not interested in saving typing this way, but I
am interested in being able to load different modules for testing without
fiddling with $fpath.  The bogus modules don't seem neater to me,
particularly if you look at the library directory without knowing what you
expect to find.  Aliasing with zmodload seems to me to avoid, not create,
hidden grotesqueries within the shell (certainly if you consider the
essential modules to be part of the shell, which I would).

> But as I explained
> earlier, my intention is that there won't eventually be so many.  3.1.7
> should contain aliases only for those modules that existed in 3.1.6,
> and we should consider at some point which modules are really important
> enough to warrant backward compatibility with the old names.

The way I suggested, you can decide by yourself very easily which names
are to exist without the zsh/ prefix.

-- 
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>

Re: PATCH: alias modules

[Zefram]

Peter Stephenson wrote:
>The way I suggested, you can decide by yourself very easily which names
>are to exist without the zsh/ prefix.

We'd still have to decide what the default set of aliases is.  Making the
user decide which are to be aliased defeats the point: if the user is
aware of the need for aliases then they are aware of the new names,
and in that case they can just use the new names anyway.

-zefram