[REBOL] Re: percent! - new datatype request
From: carl:cybercraft at: 13-Jun-2002 12:09
Hi Joel,
On 13-Jun-02, Joel Neely wrote:
> 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.
I wasn't talking about parsing HTML, but about being expressive. That
one little "%" character makes all the difference. No need to have a
WIDTH-IN-PERCENTAGE along with WIDTH as a way of expressing table
widths. Anyone moving from HTML to REBOL would expect that kind of
ease of use in layouts and wonder why it isn't there. And the answer
is because there's no percent! datatype in REBOL yet...
>>> ++$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.
add-word: function [tally [block!] word [string!]][temp][
either temp: find/skip tally word 2 [
temp/2: temp/2 + 1
][
append tally reduce [word 1]
]
]
Seems to work...
>> test: []
== []
>> add-word test "Word A"
== ["Word A" 1]
>> add-word test "Word B"
== ["Word A" 1 "Word B" 1]
>> add-word test "Word B"
== ["Word B" 2]
>> head test
== ["Word A" 1 "Word B" 2]
>> add-word test "Word A" head test
== ["Word A" 2 "Word B" 2]
>> add-word test "Word A" head test
== ["Word A" 3 "Word B" 2]
>> add-word test "Word A" head test
== ["Word A" 4 "Word B" 2]
>> add-word test "Word C" head test
== ["Word A" 4 "Word B" 2 "Word C" 1]
though it was shorter than you English description of what you wanted,
so perhaps I'm still missing something?
>>> 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 this gives us an error Joel...
>> [box 10%]
** Syntax Error: Invalid integer -- 10%
** Near: (line 1) [box 10%]
>>> 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.
So, because you have no need for a percent datatype, noone has?
> - 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.
Fair enough. But others using other OSs and every IOS user (I assume)
are using View. And they need to be able to create dynamic layouts
with ease. A percentage datatype is the obvious way to do this.
>> 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.
And major parts of View are folklore too. (: And I can understand why
they may not have had time to do a View Guide, but I can also see
them thinking that there's no point in doing one till scalable
layouts are made simple. And, to belabour my point, it's a percent
datatype that will make them simple, and it'd be consistant with how
View/VID works now.
>> 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.
Your lack of knowledge of VID shows there. I know on its own a
percentage doesn't convey what it's a percentage of, but neither do
any of the other values used in VID styles. What for instance do you
think the color datatype here is applied to...
view layout [box "hello" 255.0.0]
? Is it the text or the box? And what about with this example...
view layout [box 255.0.0 "hello"]
? With VID styles, the most common (in RT's eyes) use for a datatype
doesn't have to be spelt out. Styles have default settings, but add
a datatype and that'll change one of the default settings. And with
layouts, a face's size would be the obvious thing to change if we
could add percent datatype after the style's name.
> 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?
Not that I know of, so I guess they may be reserved for percentages.
Though it's possible a percent datatype could be used for colors and
decimals for face sizes, but I supect RT would go for using a percent
datatype for sizes. Either way, it'll be a useful addition.
>> [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.
It was me who went up the sidetrack. It was just to show what people
expect. Like people expect a GUI, not a CLI. (;
>> 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.
And as I said, it wasn't a good example, so you didn't get what I was
on about. My example of its use in View is a better example of what
I mean about datatypes being descriptive to both people and REBOL.
> 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.
Well, I answered your problem regarding adding words to a list to my
satisfaction, (though perhaps not to yours), so perhaps you'd like to
show me an easy way to modify this little View layout...
view/options layout [text-list][resize]
so that when you resize the window the text-list resizes with it? My
prefered way to do it would be this...
view/options layout [text-list 100%x100%][resize]
--
Carl Read
