zsh-workers
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: "Zsh Hackers' List" <zsh-workers@sunsite.dk>
Subject: Re: PATCH: internal parameter flags (resend)
Date: Fri, 14 Dec 2007 21:56:19 -0800	[thread overview]
Message-ID: <071214215619.ZM2188@torch.brasslantern.com> (raw)
In-Reply-To: <200712141014.lBEAEmZt001008@news01.csr.com>

On Dec 14, 10:14am, Peter Stephenson wrote:
} Subject: Re: PATCH: internal parameter flags (resend)
}
} Bart Schaefer wrote:
} > schaefer<506> typeset -Z 5 -T ARY ary
} > schaefer<510> ary=(1 2)
} > schaefer<512> echo $ARY[3]
} > 00002
} > 
} > With PWS's patch applied, $ARY[3] becomes "1" in this example, which
} > I believe is wrong.  (I don't really think 00002 is correct either;
} > in fact I'd have said it should just be "2".  Why should the padding
} > flags of the entire string apply to a slice of it?)
} 
} I agree that the old value is wrong, but I don't see why the new value
} is.  You're now trying to add yet another rule that the padding flags
} are sometimes ignored.

Sorry; no, I'm not; that was just a remark in passing, it has nothing
really to do with the point I was making.  Please ignore it for this
thread.

} > This is distinct from ${${ARY}[3]}, which always was "1".
} > 
} > } % typeset -u param=upper
} > } % UPPER=VALUE
} > } % print ${(P)param}
} > } 
} > } prints nothing, even though $param outputs UPPER, because of the way
} > } flags are handled in the wrong place.
} > 
} > Again I think this was correct as it was.
} 
} I really can't see how. I think it just creates a confusing
} distinction on how parameters are accessed. Why would you set the -u
} flag for a parameter and then expect it not to be applied?  What's
} the point in having both flags on substitution and on parameters
} themselves if the latter only apply at the same time?

I would set it to save me from having to remember to do ${(U)param}
every time I mention $param, regardless of what order the flags are
applied ... but mentioning $param and mentioning ${(P)param} aren't
the same thing.

} > ${(P)param} and ${(P)${param}} should be distinct, because the first
} > uses the value of $param as a name whereas the second treats the
} > substitution of $param as a name.
} 
} To me that's just plain confusing.

Let's consider a parallel situation:  Parameter references in math
expressions.  If I write:

    setopt octalzeroes
    integer -Z5 x=9

Then $(( x )) has the value 9 but $(( $x )) is "bad math expression".
Why wasn't the parameter flag applied to x in the first case?  Do you
think I should have expected it to be?  What if x was not an integer?

So, although I still think that ${(P)param} should use the un-altered
value [*], I'm willing to let the other part of this go because of the
following bad inconsistency with the "old way":

torch% typeset -Z5 x=6
torch% print $#x
5
torch% print $x[4]

torch% 

Either $#x should report the "real" length, or $x[4] should index into
the string whose length was counted.  I suspect that changing $#x in
this case would break a lot more things than changing the subscript.


[*] In part because they're the closest thing we have to namerefs, and
namerefs would not allow these kinds of transformations on the value.


  reply	other threads:[~2007-12-15  5:56 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-13 20:43 Peter Stephenson
2007-12-14  4:46 ` Bart Schaefer
2007-12-14 10:14   ` Peter Stephenson
2007-12-15  5:56     ` Bart Schaefer [this message]
2007-12-16 13:52       ` Peter Stephenson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=071214215619.ZM2188@torch.brasslantern.com \
    --to=schaefer@brasslantern.com \
    --cc=zsh-workers@sunsite.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).