Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[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 ]