[REBOL] Re: percent! - new datatype request
From: joel:neely:fedex at: 11-Jun-2002 6:56
Hi, Carl,
Carl Read wrote:
> Good to have you back.
>
Thanks, although I'll probably be intermittent for the next
few weeks (wedding is 6 July)...
> Okay, not a good example, so you missed my point. (:
>
I don't think so... but it's possible. My response was simply
that it's easy to deal with this issue in a variety of ways.
I'd rather see the time spent by RT (and the learning effort
by the user community) be spent on things for which there IS
NOT such an easy fix. For example:
pct: func [n [number!]] [n / 100.0]
allowing me to say
tax-rate: 8.25 ;; percent
tax: net-purchase * pct tax-rate
as one of many simple ways to handle the matter in a form
that should be obvious to most readers.
As an example on the other side of the issue, here's a very
simple (over-written, even) bit of Perl code that's much more
typical of the kinds of tasks I do day-in and day-out:
#!/usr/local/bin/perl -w
my %tally = ();
while (<>) {
tr/A-Z/a-z/;
foreach my $word (split /[^a-z]+/i) {
++$tally{$word};
}
}
foreach my $word (sort keys %tally) {
print "$tally{$word}\t$word\n";
}
(This is a complete Perl script that takes any number of
file names as command line arguments, reads each file,
splitting all input into "words" -- maximal strings of
alphabetic characters, all converted to lower-case --
and counts the number of times each word appears. The
output is a sorted list of word frequencies.)
While people poke fun at Perl's use of punctuation and other
obscure syntax, the fact remains that the notation serves as
abbreviation for a LARGE amount of (commonly-used, in my own
experience) boilerplate code, thus saving considerable effort
for the programmer. For just two examples:
tr/A-Z/a-z/
converts all (ASCII) alpha characters to the corresponding
case, and
++$tally{$word}
takes WORD as a key into the TALLY hash, and increments the
corresponding total. On the first such occurrence, the
result of looking WORD up in TALLY is the undefined value,
which Perl treats for numeric purposes as zero, therefore
no special-case code is needed for initialization. (I see
this as the numeric equivalent of the fact that REBOL views
NONE as equivalent to FALSE -- and non-NONE as TRUE -- for
the purpose of decision-making.)
Let me emphasize that I am NOT trying to turn REBOL into
Perl, but am simply trying to illustrate a conceptually
simple task that requires subtantially more coding effort
in REBOL. I fully realize that the nature of one's work
significantly influences one's view of which features are
most commonly used, but since REBOL is positioned as a
messaging language
to serve as the foundation of an
Internet Operating System, I respectfully suggest that there
would be more payback to investing effort in text processing
and efficient data structure manipulation than in helping
folks avoid remembering that
15%
can be rewritten as
.15
but that's a matter of opinion, I suppose. (And I freely
admit that I spend very little time calculating taxes and
discounts in my normal workload.)
> I don't think new datatypes should be added willy-nilly,
> but percent is definately one that should be there. They
> wouldn't give it a button on nearly every calculator if
> it wasn't in very common use now, would they?
>
Ah, but please don't forget that I can't teach my calculator
new words! There are some big differences here:
1) The calculator can ONLY do simple arithmetic;
2) It is purchased by people who need help with that very
specific task;
3) There's no way to shorten the sequence of keystrokes
required to multiply by a factor and then divide by
one hundred;
4) Many cheap numeric calculators fail to offer any means
to repeat an operation, nor to see an "audit trail" of
previous calculations; consequently undetected (and
undetectable, without repeating the calculation) errors
are much more likely;
whereas:
1) Arithmetic is only a very small fraction of what one can
accomplish with REBOL;
2) It is written by persons who presumably possess SOME
level of knowledge of arithmetic;
3) It is easy to write a trivial divide-a-number-by-100
function and then use it wherever one wishes;
4) REBOL source code can be examined, verified, debugged,
etc. and thereafter used by ... well ... "users" who
simply count on the script to continue to behave in the
same way, without their having to know anything about
how it works.
Again, (from the first point) let's consider "bang for the
buck" issues, as well as the old saying,
If you give a man a fish,
you've fed him for a day;
if you teach a man to fish,
you've fed him for a lifetime.
I'd much rather have REBOL extended with a facility that
would allow me to define lexical syntax for a new data type,
along with appropriate input/output formatting rules, than
simply to have a (no offense) trivial case like percentages
added to the core language. The latter would address only a
very narrow issue, whereas the former would extend REBOL in
a way that would allow programmers in all kinds of application
areas to benefit.
Just my $0.02...
-jn-
--
; Joel Neely joeldotneelyatfedexdotcom
REBOL [] do [ do func [s] [ foreach [a b] s [prin b] ] sort/skip
do function [s] [t] [ t: "" foreach [a b] s [repend t [b a]] t ] {
| e s m!zauafBpcvekexEohthjJakwLrngohOqrlryRnsctdtiub} 2 ]
