Re: special/readonly variables in sh emulation

[Oliver Kiddle <okiddle@xxxxxxxxxxx>]

Bart wrote:
> 
> My suggestion would be simply to disable module autoloading entirely when
> in sh emulation mode (and maybe ksh too).  A sh/ksh script can't possibly
> be expecting a dynamically loaded module, and "compinit" et al. can load
> anything they explicitly need.

That seems like a good plan to me. Perhaps excepting any module
autoloads explicitly defined by the user with zmodload.

> A slightly less drastic approach might be to disable autoloading only for
> non-interactive sh emulation.

I'm not sure that would gain anything and it can make it confusing or
hard to debug when interactive and non-interactive behaviour vary.

> On Mon, 18 Mar 2002, Peter Stephenson wrote:
> 
> > Another is to shift this sort of parameter into a namespace, as we've
> > been planning for a long time.  I think Sven had a way of doing this
> > simply by allowing dots in parameter names --- it wasn't a fully

Has anyone got a message number for that. I don't remember it.

> I've fooled around with this a bit.  The problem is that you have to allow
> the dots only inside ${...}, because lots of things break if $file.ext is
> interpreted as ${file.ext} rather than ${file}.ext.  This is a little
> tricky to acheive, because there'd need to be different typtab[] flags for
> lexing inside braces v. outside.

You would also have to cope with what things like .a..b mean. This
again shows why I think it is not a good idea to just allow dots in
identifiers. It should think of the references as
<identifier>.<identifier> and not as just <identifier>. This is
important with things like namerefs where it has to resolve each
identifier separately.

> On Mon, 18 Mar 2002, Oliver Kiddle wrote:
> > Compound variables could be implemented better by being like
> > associative arrays - the parent is a hash table of the elements the

> In fact, I deliberately used full parameter hash tables for the
> associative array implementation precisely so they could be extended in
> the future to support elements of any type.  What's needed is a sensible
> reference and assignment syntax.

You were very wise then. I can't think of any better assignment or
reference syntax than ksh's. Implementing the nested assignments could
be defered until later.

> > Also, am I right that we *need* a=() to assign an empty array?
> 
> No; `set -A a' will do it.

Hm, not as nice though.

Peter wrote:

> 
> Oliver Kiddle wrote:
> > So to start this off, if we start by getting together a list of:
> > 1. what we think is wrong with the current implementation
> > 2. what it has got right and should be preserved,
> > 3. what new features we might want to support
> > 4. any ideas for the implementation, in particular on the data
> > structure and the interface.
> > 5. anything else
> 
> What's wrong is that it's all very messy; there is a dense hierarchy of

Okay, we're agreed on the problem then. Following paragraphs also
made sense.

> Unfortunately there are dozens of different things you can do with
> parameters:

The whole complexity of parameters makes me think that we need to
evolve it into something better instead of ditching and rewriting.
How complete is the test suite for parameters?

My implementation idea is to take the param struct, get rid of sets,
gets and unsetfn from it and add a new pointer to a method table.

The method table would contain a list of function pointers. These
functions would be the "uniformly defined entry points". It should be
possible to implement a special by overriding the default versions of
these functions.

Initially, I would replace the gets, sets and unsetfn with functions
which pass particular types such as arrays, integers etc. Calling the
array set for an integer would change the parameter's type. The get
functions would not change the parameter but would do a conversion to
return the requested type - much as you described with your contexts
suggestion.

I could then add more functions to the method table bit by bit to move
more functionality in.

Does that approach sound reasonable?

>   - handle quoting, e.g. what a scalar does with an array slice may
>     depend on whether it is in quotes

I can't think of an example of this but this and areas like the value
struct is where I have fewer ideas on implementation.

> Very likely any consistent system would mean revisiting the rules on
> parameter susbstitution, unfortunately.  I suspect however hard we try
> to keep it the same there will be occasions where it doesn't fit.

Parameter substitution is one of the parts which worry me because I
don't understand it at all well.

>From here on, I got very lost:

> One other point:  I became aware when writing the map that calls to the
> system are inefficient.  Even if you're assigning a parameter, there are

the map?
and what do you mean by "the system" - the current parameter system?

Oliver

-- 

This e-mail and any attachment is for authorised use by the intended recipient(s) only.  It may contain proprietary material, confidential information and/or be subject to legal privilege.  It should not be copied, disclosed to, retained or used by, any other party.  If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender.  Thank you.