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