On 11-Jun-02, Joel Neely wrote:
> Hi, Carl,
>> Okay, not a good example, so you missed my point. (:
>>
> I don't think so... but it's possible.
Hi Joel,
And yes - I think you still have! (:
> 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.
Yes, but REBOL's a Net-centric language, so it's from the Net my
example come from...
<TABLE WIDTH="80">
<TABLE WIDTH="80%">
> 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 don't know Perl, though I think I know what you mean by the above
example, (by reading your description, not the Perl code:), and I
can't see it taking "substantially" more code, though perhaps a bit
more typing. I may have misunderstood though, so how would you do it
in REBOL? (Then I'd be sure I know what it is meant to do...)
> 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
Not in the above HTML example it can't be... (Says Carl, wondering
what actually is supposed to happen when a decimal value is given as
a width in HTML. His guess is it's meant to be part of a pixel...)
> 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.)
Me neither. But how much time do you spend writing View/VID code?
Because of this discussion I've started to wonder if one of the
reasons there's no book on View from RT yet is because they haven't
implimented the percent datatype yet. Without it and the appropriate
updates to View and VID it's severly crippled in the user-friendly
department. We should be able to write dynamic, auto-resizing
layouts with ease using something like this...
view/options layout [
across
box red 10% box green 20% box blue 70%
][resize]
with the boxes changing their sizes automatically when the user
resizes the window. (Obviously pairs need to be updated as well to
allow for the likes of 10%x20% and 12%x20 and so on.) Sizes then
would be measured as pixels when numbers are used and as percentages
of the width of the pane's parent when percentages are used. (Just a
simple example of how it might work. Mixing dynamic and fixed panes
within a face obviously requires more thought.)
This to my mind is the attraction of datatypes - they describe what
they are by themselves, to both the programmer and REBOL. This is
useful for a lot of reasons. In the above example for instance
where the difference between a 15 and a 15% could be easily spotted
when a layout didn't turn out how you expected. And if a function's
expecting money then it'll trip up if a decimal is given. But if you
want a function to accept a percentage value it'll happily confuse a
decimal for one in the current REBOL. Of course, we could get by
quite happily on just binary! and char! datatypes I guess. I don't
want to though...
[Snipped sidetrack about calculator buttons:]
> 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,
Ah - but it wouldn't, as hopefully I've explained above. VIEW NEEDS
PERCENT! (;
> whereas the former would extend REBOL in
> a way that would allow programmers in all kinds of application
> areas to benefit.
Yes, that'd be nice. View still needs a native percent! datatype
though. (IMHO:)
> Just my $0.02...
And my 0.02... (;
--
Carl Read
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the
subject, without the quotes.
