[REBOL] Re: percent! - new datatype request
From: joel:neely:fedex at: 12-Jun-2002 7:36
Hi, Carl,
Carl Read wrote:
> Yes, but REBOL's a Net-centric language, so it's from the Net my
> example come from...
>
> <TABLE WIDTH="80">
>
> <TABLE WIDTH="80%">
>
The majority of this thread dealt with adding a data type to
REBOL. I see that as a different issue than parsing HTML.
> > ++$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 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...)
>
Let me rephrase the problem in REBOL terms, rather than as
a proposed solution:
Write a function of two arguments,
a block named TALLY, which is expected to contain a
collection of strings/count paired values, and
a string named WORD,
which will modify the content of TALLY so that if WORD
already appears in TALLY the corresponding count is
increased by one, but if WORD does not appear in TALLY
it is added along with a count of one.
> > 15%
>
> > can be rewritten as
>
> > .15
>
> Not in the above HTML example it can't be...
>
But, as I said before, the above example is HTML, not REBOL. I
was responding to the idea of adding notation to REBOL for a
percent data type. One can already parse HTML tag attributes
whose value ends in #"%" , and use the presence or absence of that
character suffix as a bit of knowledge in subsequent processing,
without having a new data type created in REBOL.
> > 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?
>
Essentially none, for two reasons:
- Much of my work is oriented toward analysis of data or
processing of textual content. When working on something
that requires an interface for an end user, I tend to use
HTML so that my user needs nothing but a plain browser.
(I avoid complex JavaScript, Flash, etc. for the same reason.)
When working on something for myself, or for the generated
output, I am perfectly happy with a command line.
- I move among many different environments at work and home
(with a fuzzy boundary between those two...) including:
Solaris, HP-UX, Linux, w95, w2k, and Mac OS X (the personal
laptop on which I do most of my "private" thinking/writing).
I won't be using REBOL/View (or any other tool) until it is
available for all of those platforms.
> 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...
>
I've always assumed a simpler reason; my pre-View experience with
Core was that RT was more busily engaged in working on the design
and implementation of the language itself than in documenting it.
There are still significant parts of Core for which folklore is the
best source of explanation/documentation available. So I'm not at
all surprised to see the same with View.
> view/options layout [
> across
> box red 10% box green 20% box blue 70%
> ][resize]
>
...
> This to my mind is the attraction of datatypes - they describe
> what they are by themselves, to both the programmer and REBOL.
>
To piggyback on a comment already made in this discussion, there
are only two ways I know of to understand a percentage value:
- as a portion of *something*, in which case it is necessary to
indicate the "something" one has in mind, or
- as a "pure" real number with the radix point left-shifted
by two digits.
Simply exhibiting a numeric string with "%" tacked on the end
doesn't automatically convey which of the above, nor in the
second case what the base "something" might be. Therefore, I
have two responses to your hypothetical (I assume) example
(and I freely confess limited exposure to View for reasons
stated above):
1) I spend a bit of time with graphics and color issues, so
my first thought on seeing the above was:
Hmmm... He's describing a box colored 10% red (25.0.0),
another box colored 20% green (0.51.0) and a third box
colored 70% blue (0.0.178).
As I'm just as comfortable using percentages to specify
colors as sizes, merely exhibiting a percentage value simply
*doesn't* "describe what they are by themselves" without more
context -- which clearly I lacked in this case.
2) If the point is to have notation to show a factor by which
something is related to something else (given the need for
the *two* somethings to be clearly understood), why couldn't
your hypothetical example have been written just as easily as:
view/options layout [
across
box red .1 box green .2 box blue .7
][resize]
or do decimal! values already have some specific meaning within
the View dialect?
> [Snipped sidetrack about calculator buttons:]
>
I guess I'm puzzled by the "sidetrack" description. IIRC you used
the existance of a "%" key on a calculator as part of your argument
for creating a new type in REBOL, so I responed with reasons why I
think calculator keyboards and REBOL are different.
> Ah - but it wouldn't, as hopefully I've explained above. VIEW NEEDS
> PERCENT! (;
>
...
> Yes, that'd be nice. View still needs a native percent! datatype
> though. (IMHO:)
>
In order to what? I've just gone back and reread the entire thread
and your last post is the only place I see part-sizing in View as
the compelling reason why a percent data type is needed. Your own
argument earlier in the thread
> I think we need it, but not so much because it'd be easier
> (perhaps) for programming, but because it's more descriptive.
> For instance, we know what this means...
>
> prompt-payment-discount: $5.25
>
> but does this...
>
> prompt-payment-discount: 5.25
>
> mean money or percent?
>
> If it was this though...
>
> prompt-payment-discount: 5.25%
>
> we would know.
>
wasn't View-specific as far as I could tell.
I guess my point remains the same:
Within the context of RT's stated mission for REBOL/Core,
/View, and IOS, what are the highest-priority areas for
investment of RT's limited resources?
Overall, my answer would remain what it has been for quite some
time: producing comprehensive, authoritative specifications and
documentation for REBOL/Core, /View, etc... The members of this
list (and specifically those involved in existing books, the Zine,
and the REBOLforces web site) have already demonstrated that there
are several folks who could take up the torch and produce tutorial
and introductory material. However, that work would proceed much
more quickly in the presence of clear statements of what REBOL is
intended to do, avoiding the need for "particle physics" to try
to guess the intent or implementation.
If the question instead is "What feature, if added to REBOL, would
make it easier to promote widespread use of the language?" I'd
still have to say that improvements in the convenience of text and
data structure manipulation seem to me to have a higher payback than
the addition of what amounts to a variation on the decimal! type.
Just my 0.4% of $5.00 ... ;-)
-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 ]
