Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!sdd.hp.com!hplabs!otter.hpl.hp.com!hpltoad!cdollin!kers From: kers@hplb.hpl.hp.com (Chris Dollin) Newsgroups: comp.lang.eiffel Subject: Re: Functions without side effects (was Old confusion) Message-ID: Date: 10 Jun 91 07:38:11 GMT References: <1991May30.141218.3446@mstr.hgc.edu> <130803@tut.cis.ohio-state.edu> <1991Jun7.135613.1515@mstr.hgc.edu> Sender: news@hplb.hpl.hp.com (Usenet News Administrator) Organization: Hewlett-Packard Laboratories, Bristol, UK. Lines: 23 In-Reply-To: jcm@mstr.hgc.edu's message of 7 Jun 91 13:56:13 GMT Nntp-Posting-Host: cdollin.hpl.hp.com Deep in the heart of James McKim's message I noted: Whoa! I thought you were at least willing to include _Top_ as a primary feature. If you only have Pop_Top then every time you need to make a decision based on the current top, you have to pop the item, save it since it's no longer on top of the stack, do whatever else you want to do with it being careful not to change it, and then push it back on the stack. My vision of Stack is one in which ``every time you need to make a decision based on the current top'' is a non-issue; you stuff things on the stack, later you get them back. Why would you want to ``make a decision'' based on the ``top element''? (All the code I've done with stacks just pops the element when it wants it. Repeated access to that element - while it's still on the stack - just doesn't seem to be one of the desired properties. No, this isn't an artifact of using imperative pop!) Perhaps we're talking about two different data-types both called ``Stack''? -- Regards, Kers. | "You're better off not dreaming of the things to come; Caravan: | Dreams are always ending far too soon."