--- Stavros Macrakis <stavros.macrakis@verizon.net> wrote:
> Apparently at least a few readers of this list are not set up to read
> HTML mail -- at least not HTML mail as generated by MS Outlook. I am
> surprised. I am responsible for my kids' online school newsletter
> (*not* a technically sophisticated group), and no one seems to have a
> problem with HTML mail there.
I'll bet that's why - they're probably all using Outlook ;-).
> Or perhaps some of you are "plain ASCII text" purists. Sigh.
The few, the proud. Actually, this explanation of ev might make a
great deal of sense in the Maximabook, except since it in essence calls
for a redo on the whole ev idea we might wind up redoing it all anyway
:-/. If ev survives longer than it should though, would it be OK to
adapt this explanation for the Maximabook? I'd never be able to
describe it so well.
> The documentation says that ev "is one of MACSYMA's [sic] most
> powerful and versatile commands." Spin-free version: it is sprawling,
> confusing, and inconsistent, full of misfeatures, warts, and bells
> and whistles (cf.
> http://developer.syndetic.org/query_jargon.pl?term=feature).
> The documentation describes these inconsistencies pretty accurately,
> so you can't call them bugs (a documented bug is a feature, after
> all). But I would certainly call them errors at the conceptual or
> design level.
We should probably do something about this. I remember some previous
discussion about ev being somewhat messed up, and if we are going to
fix it it would be very handy for documentation purposes if this were
fixed sooner rather than later.
> Well... it turns out that symbols and quoted expressions are
> special-cased. They get pre-evaluated in ev - even with noeval. This
> is a feature, to allow things like ev(%,numer) or ev(d23/d24,numer)
> instead of requiring ev(''%,numer) and ev(''(d23/d24),numer). But the
> result is that the semantics are a mess.
Hmm. This does present a problem. Surely we don't want to require
ev(''%,numer) though?
> So why is all this functionality in one messy function, instead of in
> multiple clean functions? Convenience. The command-line syntax x,y
> lets you access all sorts of functionality at the cost of typing just
> one comma (,), and no strain on the memory to remember
special-purpose
> functions.
[snip]
> I think it would be worthwhile to think of a better scheme for all
> this. Something easy to use for the simple cases, but consistent in
> the more complex cases.
I agree.
CY
__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/