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

percent! - new datatype request

 [1/80] from: al::bri::xtra::co::nz at: 7-Jun-2002 4:19


percent! - new datatype request It would be nice to see a percent datatype. It could be based on a combination of the money! and decimal! datatype. percent! datatypes would look like: 100% 1.23% 0.456% I've send a copy to [feedback--rebol--com] Andrew Martin ICQ: 26227169 http://valley.150m.com/

 [2/80] from: ammon:rcslv at: 4-Jun-2002 17:04


hi, And with it you could do something like:
>> 100 - 50%
== 50
>> 100 + 50%
== 150
>> 100 * 50%
== 5000 Enjoy!! Ammon A short time ago, Andrew Martin, sent an email stating:

 [3/80] from: anton:lexicon at: 7-Jun-2002 4:35


To be consistent, 100 * 50% should give 5000%. Addition and subtraction between integer and percent types is ambiguous. What would you expect from 200 - 50% ? There are four different, but all, depending on your point of view, correct, possibilities. Just remember that % means "per cent", or "divided by 100". So 100% is not the same as 100. Not a bad idea overall, though. Regards, Anton.

 [4/80] from: greggirwin:mindspring at: 6-Jun-2002 13:37


Hi Andrew, << percent! - new datatype request It would be nice to see a percent datatype. It could be based on a combination of the money! and decimal! datatype. percent! datatypes would look like: 100% 1.23% 0.456%
>>
I've thought about that as well, but the best way I can see using them is in a dialect (add 5% to total). --Gregg

 [5/80] from: nitsch-lists:netcologne at: 6-Jun-2002 22:26


Am Donnerstag, 6. Juni 2002 20:35 schrieb Anton:
> To be consistent, > > 100 * 50% should give 5000%.
should give 50. to-percent 100 * 50% should give 5000%
> Addition and subtraction between integer and percent > types is ambiguous. What would you expect from > > 200 - 50% ? >
with-heavy-rabatt: $1999 - 30 %
> There are four different, but all, depending on your > point of view, correct, possibilities.
<<quoted lines omitted: 37>>
> > > > > > Andrew Martin
nice idea :) next i want units :) -volker

 [6/80] from: ammon:rcslv at: 4-Jun-2002 20:21


hi, Thanks for the stimulating thoughts... I would personally expect to see the output data type be the same as the *first* argument. I find that to be more consistent within REBOL (i.e. try appending a path to a block, now a block to a path) so if you have an integer and you subtract, add, divide.... it should affect the integer not the percent. and if you are dealing with a number besides 100, it should be as you said, "per cent" example:
>> 200 - 50%
== 100
>> 500 + 100%
== 1000
>> 100 - 75%
== 250 After all, if you don't evaluate it that way, you have lost the advantage that you get from the datatype, or at least the most obvious reason that I can see (what did you have in mind to use it for Andrew?). Give me a point of view that would logically result in a different result than I have given. (I am often too blind to the things around. ;-) and while you are at it, please explain why 100 * 50% would result in a percent! rather than an integer. Thanks!! Ammon A short time ago, Anton, sent an email stating:

 [7/80] from: ptretter:charter at: 6-Jun-2002 16:12


The question always comes to mind - do we really need one? After all, why add more code to the binary when we already can handle percents with a few bits of code. I think only very complex useful functions should be added to the binary. Paul Tretter

 [8/80] from: steve:shireman:semaxwireless at: 6-Jun-2002 16:13


> nice idea :) > next i want units :) > > -volker
Units! please do not take this as an insult, but you think like me...;-) Boyles law: 3 bar * 4 liters = 4 bar * 3 liters ;I'll drink to that!! ; need a balanced-equation style, hmmmn? Steve Shireman PS. Cole's law = thinly sliced cabbage

 [9/80] from: jason:cunliffe:verizon at: 6-Jun-2002 13:47


> And with it you could do something like: > >> 100 - 50%
<<quoted lines omitted: 3>>
> >> 100 * 50% > == 5000
Shouldn't that be
>> 100 - 50%
== 50%
>> 100 + 50%
== 150%
>> 100 * 50%
== 5000% and thus
>> rate: 8.25%
== 8.25%
>> price: $100.00
== $100.00
>> tax: price * rate
== $8.25
>> taxrate: to-percent [$8.25 / $100]
== 8.25% ?? ./Jason

 [10/80] from: anton:lexicon at: 7-Jun-2002 14:12


Yeah, look - we're arguing already. :) But, I remember, to be consistent, shouldn't the second datatype be converted to the first before the operation takes place ? So, 100 - 50% == 50 ; as first stated I suppose 50% - 100 == -50% ; ? or should be illegal? And 50% * 100 == 5000% 100 * 50% == 50
> > And with it you could do something like: > >
<<quoted lines omitted: 21>>
> == 8.25% > ?? ./Jason
Uh oh, so to-percent involves an implicit multiplication by 100, then? Looks nice, though. Anton.

 [11/80] from: al:bri:xtra at: 7-Jun-2002 16:45


The email I received from Carl. Andrew Martin ICQ: 26227169 http://valley.150m.com/

 [12/80] from: chalz:earthlink at: 7-Jun-2002 1:12


I'm coming in to this discussion a little late, but here's the way I, personally, would see it.
> 100 - 50% == 50 ; as first stated
This, to me, would equate to: 100 - (100 * .50) == 50 Similarly: 200 - 50% == 200 - (200 * .5) == 100
> I suppose > 50% - 100 == -50% ; ? or should be illegal?
I don't think you could really do that, because just what is that 50% *of*? Perhaps 50% - 100% ..
> And > 50% * 100 == 5000% > 100 * 50% == 50
An interesting thought. Should 100 + 50% == 100 + (100 * .5) and 100 * 50% == 100 * .5 ? 50% * 100, though.. I can see where that would be believable. :/
> > Shouldn't that be > > > > >> 100 - 50% > > == 50%
Not necessarily. It'd be 100 minus 50% of 100, which is 50. Otherwise, you should stick with 100% - 50% = 50%..
> > and thus > >
<<quoted lines omitted: 4>>
> > >> tax: price * rate > > == $8.25
Precisely; the datatype of the first value, the value upon which the percent is being acted, should be the returned datatype. No?
> > >> taxrate: to-percent [$8.25 / $100] > > == 8.25%
to-percent on type block! ? I don't see why. Use parens, perhaps, if you feel the need, but traxrate: to-percent $8.25 / $100 should be fine. Results in (8.25E-2 * 100), more or less. Some related, interesting behavior. You can do money! + money!, money! - money!, money! / money!, but not money! * money!. Heh. money! / money! results in number!. (I like how integer! and decimal! values all fall under the category number! .. workes nicely.) --Charles

 [13/80] from: chalz:earthlink at: 7-Jun-2002 1:14


There's always the matter that the list can take up a large part of the thought and discussion on this matter, formulate a nice proposal, submit the proposal to the list with RFC, and once people are generally satisfied, submit the final draft to RT. Save Carl some headache ;)

 [14/80] from: jason:cunliffe:verizon at: 7-Jun-2002 1:16


> Yeah, look - we're arguing already. :)
lol Asking not arguing.. anyway my email was slow getting posted to the list
> But, I remember, to be consistent, shouldn't > the second datatype be converted to the first > before the operation takes place ? > So, > 100 - 50% == 50 ; as first stated
I am strongly reminded of my early schooldays when our Math teacher relentelssly brainwashed [initialized] us about percentages for whole term: "Always ask: 'percent of WHAT?'", he said. And he was right.. I can never listen to the news or advertising or marketing wonks wihout thinking of that man.. In which case the assumptions must be clearly stated:
>> 100 - 50%
== 50 That says that the percent is OF the preceding value. So what does this next one mean?
>> 50% + 100 ???
...If is truly REBOListic then % will have some suprising head tail first next behaviors.. Meanwhile some other to ponder
>> (100 - 50%) * 10%
== 5
>> 100 * 50%
== 5000%
>> 50% * 100
== ??
> I suppose > 50% - 100 == -50% ; ? or should be illegal?
No its an Enron hysteresis function. Negative growth.. The policicians love to ovecome it. ..unless 50% already has some internal series value it is indexing ??
> > >> taxrate: to-percent [$8.25 / $100] > > == 8.25% > Uh oh, so to-percent involves an implicit multiplication > by 100, then? Looks nice, though.
yeah aint it? ./Jason

 [15/80] from: robert:muench:robertmuench at: 7-Jun-2002 14:16


> -----Original Message----- > From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]On Behalf Of
<<quoted lines omitted: 6>>
> bits of code. I think only very complex useful functions should be added to > the binary.
Hi, I can second this. If RT can include the datatype with some byte increase than it's worth but if we get 5KB more... I wouldn't add it. Robert

 [16/80] from: carl:cybercraft at: 8-Jun-2002 1:50


On 08-Jun-02, Robert M. Muench wrote:
>> -----Original Message----- From: [rebol-bounce--rebol--com] >> [mailto:[rebol-bounce--rebol--com]]On Behalf Of Paul Tretter
<<quoted lines omitted: 7>>
> increase than it's worth but if we get 5KB more... I wouldn't add > it. Robert
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. Why we're on the subject of new datatypes, what others are needed? Degrees (and minutes) perhaps? -- Carl Read

 [17/80] from: henrik:webz:dk at: 7-Jun-2002 16:48


Citat Carl Read <[carl--cybercraft--co--nz]>:
> On 08-Jun-02, Robert M. Muench wrote: > >> -----Original Message----- From: [rebol-bounce--rebol--com]
<<quoted lines omitted: 20>>
> Why we're on the subject of new datatypes, what others are needed? > Degrees (and minutes) perhaps?
We could go on with every single SI unit in existance? It would be cool if Rebol knew that the unit of voltage divided with amps is ohm. This way, certain datatypes could get much more than just descriptive, but it would probably be too much bloat to implement that. Stupid idea, anyway. :-) Regards, Henrik Mikael Kristensen

 [18/80] from: jason:cunliffe:verizon at: 7-Jun-2002 10:58


> Why we're on the subject of new datatypes, what others are needed? > Degrees (and minutes) perhaps?
GPS Location = YES PLEASE!!! Mobile com devices will increasingly include GPS in them, some by law. Navigation, tranportation, vehicle tracking, in-built car systems, geographic data gathering, smart-maps, web mapping, emergency services, phones, cameras, monitoring equipemtn, land-mine detectnio, environmental mapping, urban planningand locations systems, tourism, traffic control, postal services, wifi.. After voice, geo-referencing is among the top 5 killer apps for mobile systems. REBOL could shine brightly in this area, playing to its strengths, opening up new apps and services. And without falling foul of heavy established monopolies. ./Jason

 [19/80] from: greggirwin:mindspring at: 7-Jun-2002 10:09


Hi Henrik, et al <<
> Why we're on the subject of new datatypes, what others are needed? > Degrees (and minutes) perhaps?
We could go on with every single SI unit in existance? It would be cool if Rebol knew that the unit of voltage divided with amps is ohm. This way, certain datatypes could get much more than just descriptive, but it would probably be too much bloat to implement that. Stupid idea, anyway. :-)
>>
Not a stupid idea at all. This is where I see dialects playing an important role, and comes back to what I said in my reply to Andrew, that this is where I've thought percentages would fit best. You might want to make them a compound data type, like money, with a precision component that you can specify. Dealing with monetary values would generally require less precision than decimal values in the context of scientific use. I haven't thought about it enough to come up with a good design but, in the past, I built a Percent object datatype with a number of properties for flexibility: DecimalPlaces, Precision (i.e. interval rounding), Rounding (up, truncate, etc), and range limits. For example, mortgages in the U.S. are priced in eighths, so you need to specify three decimal places with a precision of 1/8. Because of floating point errors, you may also need to perform intermediate smoothing of values to ensure the final outcome is what you expect. I haven't tested the money! datatype against my other stuff to see how it fares, but I expect I will at some point. I know there are some basic issues affecting it already, as people have mentioned here are elsewhere. Another thing to consider is how monetary values are changing. Eventually, though maybe not real soon, we will see micropayments instituted. How should money! and percent! work with .000125% of $0.0001? --Gregg

 [20/80] from: greggirwin:mindspring at: 7-Jun-2002 10:44


Charles, Andrew, et al << There's always the matter that the list can take up a large part of the thought and discussion on this matter, formulate a nice proposal, submit the proposal to the list with RFC, and once people are generally satisfied, submit the final draft to RT. Save Carl some headache ;) >> Having not tried this before, here's an outline. Andrew, do you want to maintain this, or would you like me to? Does anyone else want to? Will it work if people post to this list with a subject starting with "RFC 001"...? It then falls to the maintainer to make decisions it seems. Should they have censorship authority, or include all pertintent discussion whether they agree or not? --Gregg ------------------------------------------------------------ RFC 001 Percent Datatype ===TITLE Addition of percent! datatype to all versions of REBOL. ===VERSION Maintainer: Gregg Irwin <[greggirwin--mindspring--com]> Date: 07-Jun-2002 Version: 0.0.1 ===ABSTRACT REBOL has a large number of native datatypes, and many people feel that a percent! datatype would a useful addition. ===DESCRIPTION Andrew Martin <[Al--Bri--xtra--co--nz]> posted a message to mailing list suggesting the addition of a percent! datatype to REBOL, and some discussion followed. The suggestion was made to put together an RFC as a basis for further discussion, and here it is. ===IMPLEMENTATION ---Declaration Syntax The proposed syntax is simply a numeric value followed by a percent sign (%). 100% 8.25% ---Operations against other datatypes What other datatypes can percent! values be used against? ---Result Coercion Does one operand or the other determine the resulting datatype? For example, is $100 * 50% the same as 50% * $100? ---Standard notation versus dialect Does it provide enough value to say: $100 * 50% versus: $100 * .5 As someone on the list pointed out, does that lead to the question "50% of *what*?" It seems much clearer to say: 50% of $100 or add 8.25% to total but then you need some way to tell REBOL that this is a new dialect (e.g. a CALCULATE function that takes a block, like LAYOUT does), or the REBOL lexer needs to know about the percent! dialect, which may be impractical. ---Precision, accuracy, and rounding How do you specify the extra information that may be useful, even required. Two examples I can think of are precision and accuracy (I'm open to better terms). Accuracy refers to the number of decimal places a value should maintain. Precision refers to an "interval" the value should be rounded to. E.g. eighths (1/8) Rounding refers to how values should be rounded, when rounding is required. Examples would be STANDARD (statistical), UP, TRUNCATE, FLOOR, and CEILING. ===REFERENCES

 [21/80] from: jason:cunliffe:verizon at: 7-Jun-2002 13:55


> Another thing to consider is how monetary values are changing. Eventually, > though maybe not real soon, we will see micropayments instituted. How should > money! and percent! work with .000125% of $0.0001?
Great points Gregg ./Jason

 [22/80] from: carl:cybercraft at: 9-Jun-2002 17:56


On 08-Jun-02, Jason Cunliffe wrote:
>> Why we're on the subject of new datatypes, what others are needed? >> Degrees (and minutes) perhaps? > GPS Location = YES PLEASE!!!
I'd second that. And I've been wondering why there isn't already a font! datatype. Cross-platform issues perhaps? -- Carl Read

 [23/80] from: robbo1mark:aol at: 9-Jun-2002 15:03


In a message dated 6/7/2002 3:20:21 PM GMT Daylight Time, [carl--cybercraft--co--nz] writes:
> Why we're on the subject of new datatypes, what others are needed? > Degrees (and minutes) perhaps?
How about these; complex! -1.234+567i ; complex numbers ratio! 2/3 ; fractions co-ord! 2.34x1.23 ; co-ordinate - more precise than pair! octal! 377oct ; octal numbers - integers hex! FFFFhex ; hexadecimal numbers - integers binary! 101010bin ; binary numbers - integers note current REBOL binary is actually a binary-string! and not a numeric value stack! s[ 1 2 3 4 ] ; a stack block! which grows from bottom up and for which insert is quasi-elementary - really the opposite of a block! ie a reverse block!
>> make stack! [ 4 3 2 1 ]
== #[stack! [1 2 3 4]] unicode-char! #'a' ; utf unicode two byte multi-lingual character sets unicode-string! u"Hello" & u{Hello} ; ditto as above for uni-code strings typed-series! vector decimal! [1.1 2.2 3.3] ; more efficient tpyed block! storage
>> vector integer! [1 2 3 4]
== #[vector integer! [1 2 3 4]]
>> vector integer! [1 2 3 "hello"]
** script error! Value "hello" of type string! expected type of integer! ** near vector integer! [1 2 3 "hello"] And these are only for starters - a better money! type which supports international currency symbols and formats would be better than the dollar centric nonsense we have just now. Just my thoughts, Mark Dickson

 [24/80] from: joel:neely:fedex at: 10-Jun-2002 7:03


Hi, Gregg, Gregg Irwin wrote:
> We could go on with every single SI unit in existance? > > Not a stupid idea at all. This is where I see dialects playing an > important role, and comes back to what I said in my reply to Andrew, > that this is where I've thought percentages would fit best. >
I agree completely. Such things belong in a dialect, not in the core language. Looking back at the history of programming languages, there's an issue of balance between a simple language a bloated language which is small and which is complex and easy to learn, but and impossible to learn too small for real because of unbridled programming tasks feature creep (and so never used) (and so never used) There's a "sweet spot" in the middle, and I respectfully suggest that REBOL/Core should seek to find (and STAY IN) that zone. The whole idea of an extensible language is to provide the most common and useful set of features, along with a simple means for the programmer to add those concepts that are required for the special circumstances of a particular task/project. That said... Instead of asking for specific twiddles, I'd be interested in the response of RT to the ideas of either: - providing a means for extending the syntax within dialects so that new forms could be added at the mezzanine level, or - providing a means for switching on/off classes of extensions (perhaps coded natively) to avoid bloat and namespace collisions for those cases where the extensions are not needed. Thoughts, anyone? -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 ]

 [25/80] from: joel:neely:fedex at: 10-Jun-2002 7:08


Hi, Carl, Carl Read wrote:
> 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
<<quoted lines omitted: 6>>
> prompt-payment-discount: 5.25% > we would know.
That's what comments (or descriptive names) are for. prompt-payment-discount-percent: 5.25 prompt-payment-discount-factor: 1.0 - (5.25 * 0.01) or prompt-payment-discount: 0.0525 ;; 5 1/4 percent IMHO. -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 ]

 [26/80] from: joel:neely:fedex at: 10-Jun-2002 7:12


Hi, Jason, Jason Cunliffe wrote:
> > Why we're on the subject of new datatypes, what others are needed? > > Degrees (and minutes) perhaps? > > GPS Location = YES PLEASE!!! >
...
> After voice, geo-referencing is among the top 5 killer apps for > mobile systems. REBOL could shine brightly in this area, playing > to its strengths, opening up new apps and services. And without > falling foul of heavy established monopolies. >
Having a new type (perhaps DEGREES!) which recognizes angle/lat/lon values with degrees, minutes, and seconds, handles the conversions and manipulation of the parts correctly/automatically would come much close IMHO to the case of an extension which COULD be written at mezzanine level but would greatly improve in performance if in the native level. That said, how many of us currently are writing code that would use such a type? (And, yes, I know that there's a chicken/egg issue here, but I'm still wondering...) -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 ]

 [27/80] from: joel:neely:fedex at: 10-Jun-2002 7:16


Hi, Mark, I think you've made my point... ;-) [Robbo1Mark--aol--com] wrote:
> In a message dated 6/7/2002 3:20:21 PM GMT Daylight Time, > [carl--cybercraft--co--nz] writes:
<<quoted lines omitted: 25>>
> ** near vector integer! [1 2 3 "hello"] > And these are only for starters ...
Is it really in the best interests of RT, REBOL the language, IOS, or the REBOL community for RT to be dealing with everything we can imagine???? Let's not forget that the foundation of the language something called REBOL/Core! Provided that we have the ability to extend the language ourselves at the mezzanine level, I respectfully suggest that RT can be using their time more productively on other issues than shopping lists such as the above. -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 ]

 [28/80] from: joel:neely:fedex at: 10-Jun-2002 7:05


Hi, Paul, I don't normally care for "I agree" posts that add no new ideas, but this is an important issue. Therefore I feel compelled to respond to your POV... Paul Tretter wrote:
> The question always comes to mind - do we really need one? After > all, why add more code to the binary when we already can handle > percents with a few bits of code. I think only very complex useful > functions should be added to the binary. >
I absolutely, completely agree, with the only exception that common cases which could receive a performance boost from being coded in the native layer should also be considered. (I.e. when there's a performance payback in things we often do...) -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 ]

 [29/80] from: g:santilli:tiscalinet:it at: 10-Jun-2002 14:54


Hi Joel, On Monday, June 10, 2002, 2:03:19 PM, you wrote: JN> - providing a means for extending the syntax within dialects so JN> that new forms could be added at the mezzanine level, or MAKE DATATYPE! would be really cool. :) (Together with MAKE NATIVE! ;) Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

 [30/80] from: ammon:rcslv at: 8-Jun-2002 15:49


Hi again Joel, I think that you are refering to the 'module functions that are promised for version 3.0? If that is the case then maybe we should be patient and in the mean time develop the dialect that effectively emulates a percent dataype, i just wonder....
>> type? 55%
** Syntax Error: Invalid integer -- 55% ** Near: (line 1) type? 55%
>> [55%]
** Syntax Error: Invalid integer -- 55% ** Near: (line 1) [55%]
>> parse [55%] rules
** Syntax Error: Invalid integer -- 55% ** Near: (line 1) parse [55%] rules hm... It appears that a dialect as has been described wouldn't even be possible. Any ideas? Enjoy!! Ammon A short time ago, Joel Neely, sent an email stating:

 [31/80] from: robbo1mark:aol at: 10-Jun-2002 12:49


To implement a percent! datatype or any other "shopping list" of new datatypes requires one to write an extended version of the LOAD function to parse script input and correctly identify and make new object! instances of the percent! and other new datatypes. You also have to extend the TYPE? function to correctly handle your special new object! datatype representations and return your intended percent! or whatever. Any other new methods such as arithmetic, print / output formatting etc also have to be defined. Basically your write another interpreter and functions on top of REBOL to handle your new datatypes, which is certainly do-able and REBOL/Core has loads of useful functions for implementing this. A reader macro function like the lisp / scheme 'extend-syntax and 'syntax-rules functions for REBOL would make this so much easier and allow for easier extensions of REBOL at the mezzanine level as Joel would like. Maybe it would be better if REBOL like Lisp, Scheme, Perl, PHP, Python, Ruby, TCL, OCAML, to name but a few, could be extended at ALL levels and not just the mezzanine level but we've done this to death before - sigh! Mark Dickson

 [32/80] from: greggirwin:mindspring at: 10-Jun-2002 10:30


Joel and Gabriele, << JN> - providing a means for extending the syntax within dialects so JN> that new forms could be added at the mezzanine level, or MAKE DATATYPE! would be really cool. :) (Together with MAKE NATIVE! ;)
>>
That could be really cool, but don't datatypes have to fit into REBOL's lexicon? The risk, of course, being that RT might have a very hard time adding extensions themselves unless we had a specific namespace where user datatypes lived. That pretty much bring us back to dialects, doesn't it? --Gregg

 [33/80] from: g:santilli:tiscalinet:it at: 10-Jun-2002 19:46


Hi Gregg, On Monday, June 10, 2002, 6:30:03 PM, you wrote: GI> That could be really cool, but don't datatypes have to fit into REBOL's GI> lexicon? Of course. But maybe having user datatypes as #[mytype! ...] is enough for us... what do you think? Or, it could be possible to plug in parse rules in REBOL's parser, that are used when the rest fails; this might create problems, so maybe its better not allowing it... Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

 [34/80] from: joel:neely:fedex at: 10-Jun-2002 15:31


Hi, Gregg, IANARTE (I Am Not A REBOL Technologies Employee... ;-) but I suspect that data types are entangled with the lexical scanning performed by LOAD. IOW, it might be necessary to provide a specification for how to recognize values of a new datatype at the lexical token level, and that might not be convenient/feasible... Just a guess! -jn- Gregg Irwin wrote:

 [35/80] from: carl:cybercraft at: 11-Jun-2002 20:12


On 11-Jun-02, Joel Neely wrote: Hi Joel, Good to have you back. And see below...
> Carl Read wrote: >> I think we need it, but not so much because it'd be easier
<<quoted lines omitted: 12>>
> or > prompt-payment-discount: 0.0525 ;; 5 1/4 percent
Okay, not a good example, so you missed my point. (: Instead, compare this... [1.05 12.75 1.15 19.22] with this... [%1.05 $12.75 1.15 19.22%] The datatypes make the data descriptive, both to people and REBOL. VID's a good example of making use of this, where a number is treated as width, a pair as width and height, a string as text and so on. And because they're individual datatypes we don't have to remember a specific order they need to be in. This doesn't of course work for all cases as you're often going to need more than one of each datatype, but it's a very useful feature to have. So instead of something like this... button label "A button" width 100 depth 50 color 255.0.0 we can have this... button "A button" 100x50 255.0.0 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? -- Carl Read

 [36/80] 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 ]

 [37/80] from: carl:cybercraft at: 12-Jun-2002 21:04


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.
<<quoted lines omitted: 7>>
> 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
<<quoted lines omitted: 37>>
> 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
<<quoted lines omitted: 7>>
> 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,
<<quoted lines omitted: 8>>
> 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

 [38/80] 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
<<quoted lines omitted: 8>>
> 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.
<<quoted lines omitted: 6>>
> 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 ]

 [39/80] from: greggirwin:mindspring at: 12-Jun-2002 10:52


Joel, Carl, et al The argument for percent! being useful in VID makes me think......ouch! :) Quick thoughts: 1) VID is a dialect, so adding support for ##% syntax isn't the same as adding a percent! datatype. I don't have a problem extending VID's syntax in that way except that... 2) Adding that ability opens up a whole can of worms related to pair! values which don't support even decimal components at this time, only integers. --Gregg

 [40/80] from: jason:cunliffe:verizon at: 12-Jun-2002 14:15


Hi.. Interesting the twists and turns this has taken so far.. Although I am PRO a new REBOL percentage datatype, I don't buy into this argument that it's so essential to VID. VID needs documentation and example. But above all it needs a stronger set of useful modern interfaces for resizing, nesting tables, spacers, sizers, split views etc.. They need a friendly dialect/syntax suitable for reading and writing GUI layouts. percent% as datatype is surely the smallest part of that problem. Yes it might be nice, but the description of relative/absolute widths etc, could equally well be handled by a block syntax. Anyway, 'OF' seems like a valid addition and is very readable. Perhaps a new operator is more important than the datatype, and thus may be also easier to explore.
>> 50% x 20%
bothers me.. I argue don't mix pair values and percent.
>> 50% of 20% of something
ok now does make sense. Whatever happens with implementing % percent datatype, thinking about 'OF' has interesting consequences.. For example consider this:
>> position: 400x20 >> table: 120x30
== 120x30
>> type? table
== pair!
>> 0.4 * table
** Script Error: Cannot use multiply on decimal! value ** Near: 0.4 * table
>> 50% of xy ;<< wishful thinking
== 60x15 ...or if percent is not available, we can just use
>> 0.5 of table
== 60x15
>> 0.5 of table/x
== 60
>> half: 0.5 >> half of my-profit all of my-love >> position image-box half height of screen
In layout dialect we want to be smarter add more readable [x y width height area margin indent] What y'all think?? ./Jason

 [41/80] from: carl:cybercraft at: 13-Jun-2002 12:09


Hi Joel, On 13-Jun-02, Joel Neely wrote:
> Carl Read wrote: >>
<<quoted lines omitted: 7>>
> 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} >>
<<quoted lines omitted: 21>>
> 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% >>
<<quoted lines omitted: 10>>
> 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
<<quoted lines omitted: 9>>
> 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
<<quoted lines omitted: 5>>
> 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
<<quoted lines omitted: 26>>
> *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
<<quoted lines omitted: 6>>
> 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! (;
<<quoted lines omitted: 25>>
>> > 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,
<<quoted lines omitted: 15>>
> 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

 [42/80] from: carl:cybercraft at: 13-Jun-2002 9:52


On 13-Jun-02, Gregg Irwin wrote:
> Joel, Carl, et al > The argument for percent! being useful in VID makes me > think......ouch! :) > Quick thoughts: > 1) VID is a dialect, so adding support for ##% syntax isn't the same > as adding a percent! datatype.
Hi Gregg, Short of puting the percent value in a string, how do you write a dialect to get around the following? ...
>> [10%]
** Syntax Error: Invalid integer -- 10% ** Near: (line 1) [10%]
> I don't have a problem extending > VID's syntax in that way except that... > 2) Adding that ability opens up a whole can of worms related to > pair! values which don't support even decimal components at this > time, only integers.
Perhaps because they're saving decimals for percentages and didn't want a whole heap of scripts out there already using them in pairs when it's introduced? ie, so it /won't/ open a can of worms when it's introduced. -- Carl Read

 [43/80] from: kemp:extelligence at: 12-Jun-2002 21:09


For my 2 cents, I'd hate to see Rebol's layout capabilities being based on HTML - the Net != HTML, and HTML is not the end word in layout expressiveness; for that matter, it was originally designed to specifically AVOID layout. - Kemp

 [44/80] from: joel:neely:fedex at: 13-Jun-2002 7:45


Hi, Carl Carl Read wrote:
> >>> ++$tally{$word} >
vs.
> add-word: function [tally [block!] word [string!]][temp][ > either temp: find/skip tally word 2 [
<<quoted lines omitted: 3>>
> ] > ]
Your approach is essentially the same as the one I've used for such tasks. By my count 16 bytes versus 179 bytes, or 11 times as much code. I know that this is a dinky example (and if I take out all of the whitespace used to "pretty-print" the REBOL version, it shrinks to 139 bytes -- although that renders it significantly less readable), but here's the point I was trying to make with this dinky example: Manipulating non-trivial data structures in REBOL, even something as simple as a look-up table, involves much more code and much more intpreter overhead than with several other languages in the same space -- 'net applications. I truly believe that addressing that issue would be of significant value in promoting the wider use of REBOL. Just for the exercise, I coded the word-count problem in both Perl (using essentially the same code previously posted) and REBOL (using essentially the same approach you provided). I wrote both of them to use a hard-coded file name, to avoid the additional overhead of command-line parameter handling. For a sample file, I used the text of "Alice in Wonderland" from the Gutenberg Project, with the following typical results (median of three trials): (/export/home/jneely/try)# wc alice.txt 2415 26434 145197 alice.txt (/export/home/jneely/try)# time tally.pl > /dev/null real 0m0.31s user 0m0.30s sys 0m0.01s (/export/home/jneely/try)# time tally.r > /dev/null real 0m10.35s user 0m10.24s sys 0m0.09s For a ~142k file, Perl produced a sorted word-count list in under 1/3 second, while REBOL required over 10 1/3 seconds for the same data. I'm certainly not claiming that producing a dictionary of "Alice in Wonderland" is typical of the workload of all REBOL programmers, but I do believe that the type of processing involved *is* typical of many server-side scripts, whether CGI or "back-room" data reduction -- read one or more text files, parse them down and do some processing on the analyzed text, then spit out some results. The trade-off between native and mezzanine code is a significant performance factor in REBOL. The fact that I can write a function to do some task doesn't change the fact that there's a run-time cost influenced by how much of the work of that function must be expressed in mezzanine/user code. I'm certainly not ignoring the value of graphical user interfaces (I've been a Mac user since 1984, and my primary personal box is an iBook running Mac OS X), but I think it will be hard to sell the idea of a GUI whose underlying data manipulation is awkward to write and sluggish in performance. (Not to mention the fact that performance is *T*H*E* issue in server-side programming. Although Java was widely hyped as a universal client-side language, most of what I'm seeing in the Java word now is on the server side -- now that there are JVMs with adequate performance.) Hence my personal opinion that the cause of REBOL would be more advanced at this point by attention to facilities for working with non-trivial data structures and performance, than by adding another data type. As for the /View discussion, I'll reply separately. -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 ]

 [45/80] from: robbo1mark:aol at: 13-Jun-2002 10:04


In a message dated Wed, 12 Jun 2002 8:17:38 PM Eastern Daylight Time, [carl--cybercraft--co--nz] writes:
> Short of puting the percent value in a string, how do you > write a > dialect to get around the following? ... > > >> [10%] > ** Syntax Error: Invalid integer -- 10% > ** Near: (line 1) [10%]
No need to put the 10% in a string!. If you are writing a dialect - in this one which will implement a percent! datatype at the mezzanine level - we don't have the facility to do it at the native level - you can use REBOL objects! to simulate datatypes. ie 10% would be transformed into this; percent!: make object! [ datatype: "percent!" value: 0] make-percentage: func [ n [number!]] [ make percent! [value: n / 100] ]
>> a: make-percentage 10 >> probe a
make object! [ datatype: "percent!" value: 0.1 ]
>>
Yes your dialect has to write all the other methods so your percent! objects can interact with all the other "native" numeric datatypes in the correct way. With regards to 10% not generating an invalid integer! error message it's quite trivial to write a read/load source function to parse source code input for the XX% pattern and replace with make-percentage x functions. Basically the dialect implements a small interpreter on top of REBOL to handle your "percentages" or whatever other datatypes you may wish to implement correctly. You also have to extend the TYPE? function to return to-word object/datatype == percent! It's not that difficult, just some careful design, time and effort. cheers, Mark Dickson

 [46/80] from: joel:neely:fedex at: 13-Jun-2002 11:38


Hi, again, Carl, With respect to the View issues... Carl Read wrote:
> So, because you have no need for a percent datatype, noone has? >
I never said that. What I *did* say is that I believe RT could do some other things that would have a bigger effect on the widespread adoption of REBOL. So far the "datatype as clue to View layout" is the only issue I've seen raised in this thread that wasn't simply a matter of a shorter (and arguably more conventional) way to write floating-point values that indicate ratios or factors.
> 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. >
I might agree that it is *A* way to do it, but I don't think it's the only possibility by any stretch of the imagination.
> > 1) I spend a bit of time with graphics and color issues, so > > my first thought on seeing the above was: > > Your lack of knowledge of VID shows there. >
Now, with all due respect, I must insist that you missed *my* point. If the burning need here is to have a distinct data type so that one can stick an unlabeled value in a layout block and have View use it for control of scaling, then I'd still wonder whether a decimal! value could serve that purpose. It is certainly arguable that a string attribute of a button widget is most reasonably assumed to be the label displayed on the button. However, the more attributes we add to a widget, the more we have the possibility that multiple attributes can reasonably have values of the same type. Instead of addressing this situation by insisting on the creation of a new data type for every attribute (or for those attributes deemed most common for some purposes) I question whether the "datatype as only clue" approach itself scales well. The punch line is that I have serious reservations about a notation that leans heavily on datatypes (and large doses of assumption about the most likely meaning or most frequent use) to specify complex artifacts.
> 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. >
I'm sure some of use would consider it useful (for some definitions of use at least ;-). I'm just suggesting that "useful" and "most urgent to deal with right now" are distinct concepts.
> Well, I answered your problem regarding adding words to a list to > my satisfaction, (though perhaps not to yours), so perhaps you'd
<<quoted lines omitted: 3>>
> My prefered way to do it would be this... > view/options layout [text-list 100%x100%][resize]
I'll be glad to respond, with a few disclaimers: 1) I make no pretense at View expertise, so it'll be easy for someone to pick at details or inconsistencies with other View notation. I trust that's not the purpose of your question, however. 2) I've fiddled quite a bit over the years with a variety of toolkits for building GUIs, and have some fairly strong impressions about what was (or was not) well done in various languages. I believe that building a usable GUI for a non-trivial application is a very demanding task, already difficult enough if one assumes fixed-sized windows. If we throw resizing into the mix, then specifying what is and isn't to flex can become *highly* complex IMHO. Look at all of the complexity surrounding "layout managers" in Java (and how often programmers give up on the fancier options in favor of simplicity) as an indication of how nasty it can get. 3) I haven't thought long and hard about how I think a GUI specification notation should look or function, so you're getting off-the-cuff responses here. With that said, let me add my preference for a design strategy of "Make simple things simple, and complicated things possible" If I can imagine changing View to follow that principle, I would favor something like the following. If you write view/options layout [... some widget specs...] [resize] then ALL enclosed widgets would scale proportionally when the container resizes. I'd add widget-by-widget attributes of scalex to mean fixed-height, scaling-width, scaley to mean fixed-width, scaling-height, and noscale to mean just what it sounds like. Thus, for example, a vertical scrollbar would have SCALEY as an attribute to allow it to resize vertically but not change width, a horizontal scrollbar would have SCALEX, a thumbnail icon could have NOSCALE, etc... For any more complex scanarios, I'd put the monkey back on the programmer with something vaguely like view/options layout [... some widget specs ...] [resizeby function] where the offered function (by name or anonymous) would be invoked to handle the resizing, and would be able to use some simple interface to adjust the size of each component widget within the layout, so that a programmer wanting a more sophisticated layout-management strategy would have a way to implement it. Again, let me repeat that I'm not trying to play "duelling examples" here, but to ask the question "What could be done to make REBOL more attractive to users and developers who currently are not aware or interested?" I trust we all would like to see that result! -jn-

 [47/80] from: robbo1mark:aol at: 13-Jun-2002 12:57


In a message dated 13/06/02 17:46:27 GMT Daylight Time, [joel--neely--fedex--com] writes:
> Again, let me repeat that I'm not trying to play "duelling examples" > here, but to ask the question "What could be done to make REBOL more > attractive to users and developers who currently are not aware or > interested?" I trust we all would like to see that result! >
More fast / native text processing functions like PERL has and a "shopping list" of new rich datatypes! as well as succinct assignment op!'s for example
>> a: 5
== 5
>> a += 1 ; slightly shorter than as a: a + 1
== 6
>> a
== 6 Lots more ...... Mark Dickson

 [48/80] from: greggirwin:mindspring at: 13-Jun-2002 11:35


Hi Carl, << Short of puting the percent value in a string, how do you write a dialect to get around the following? ...
>> [10%]
** Syntax Error: Invalid integer -- 10% ** Near: (line 1) [10%]
>>
Yeah, that's a problem all right. The first option, which is ugly and not VID-oriented, is to use a string for your dialect data source, rather than a block. Blocks are awfully convenient for writing dialects though. :( The other option, also ugly, would be to make them an issue! (e.g. #10%), but I don't care for that much either. In any case, I hope RT has made a note about it so they can consider it in the grand scheme of things to come. --Gregg

 [49/80] from: kemp:extelligence at: 13-Jun-2002 13:50


>>
However, the more attributes we add to a widget, the more we have the possibility that multiple attributes can reasonably have values of the same type. Instead of addressing this situation by insisting on the creation of a new data type for every attribute (or for those attributes deemed most common for some purposes) I question whether the "datatype as only clue" approach itself scales well. The punch line is that I have serious reservations about a notation that leans heavily on datatypes (and large doses of assumption about the most likely meaning or most frequent use) to specify complex artifacts. << Well put! That was the first thing I questioned as I started working with VID. Too much implicit information makes for assumptions that don't scale. - Kemp

 [50/80] from: greggirwin:mindspring at: 13-Jun-2002 12:11


Hi All, << a += 1 ; slightly shorter than as a: a + 1 >> How about: incr a It's just as concise for the default case. This is an old bias of mine against certain operators. Without wanting to start a flame war over them, I hope they never show their face in REBOL. :) --Gregg

 [51/80] from: ammon:rcslv at: 11-Jun-2002 18:37


<< Make simple things simple, and complicated things possible
>>
Good philosophy! << If I can imagine changing View to follow that principle, I would favor something like the following. If you write view/options layout [... some widget specs...] [resize] then ALL enclosed widgets would scale proportionally when the container resizes. I'd add widget-by-widget attributes of scalex to mean fixed-height, scaling-width, scaley to mean fixed-width, scaling-height, and noscale
>>
Excellent! I would vote for that functionality over any that I have heard so far, unfortunately, that is not how it works. The resize flag simply allows the window to resize, not any of the faces within the window. It does however trigger the 'resize event which allows you to dynamically change the size of the faces in the layout (or do anything else you may deem neccisarry effectively enabling the resizeby example that you gave). Thanks to this discussion, I am lit up with all kinds of wonderful ideas of how to create dynamically resizing faces! Now as you can see, RT has fufilled half of your philosophy, complex things are possible. Now just to get the the simple things simple part... Enjoy, my 0.8% of $2.50. ;-) Ammon

 [52/80] from: joel:neely:fedex at: 13-Jun-2002 17:14


Hi, Gregg, and all, OK... I'm shocked! (Not by Gregg's comment, but by where some of this thinking took me!) (Note: timings discussed below were median-of-multiple-run values to reduce statistical variation.) Gregg Irwin wrote:
> Hi All, > > << a += 1 ; slightly shorter than as a: a + 1 >> > > How about: > > incr a > > It's just as concise for the default case... >
With a broad brush (in other words, I'm not trying to start a model or terminology war ;-) let me say that REBOL has primitive types (integer!, char!, ...) that are immutable, and has container types which are mutable -- we can add to, remove, or replace their content. Specifically, having said a: 1 there's a sense in which I can't modify the value associated with A but can only associate A with a new value. Thus when I say a: a + 1 the fact that A: is set to the value of an expression that also contains A is merely coincidental. Low-level languages (such as incr #"b") assume that a "variable" is just a name for a "place", location , "address", "storage cell", ... which I can get at. In REBOL, the *word* A is just a symbol, but a context associates a collection of symbols with corresponding values. I think of a context as analogous to a dictionary, which just relates words to values. The concepts of "place", "address", etc... don't apply. Now back to the word-counting problem Carl and I discussed earlier in this thread. I reported writing scripts for that problem in both Perl and REBOL, but didn't show the REBOL version (since it was essentially based on the idea in one of Carl's posts). Here is that version (renamed for contrast with some others to follow: 8<--------------------(begin tallyn.r)-------------------- #!/export/home/jneely/bin/rebol -sq REBOL [] text: read %alice.txt tally: [] alpha: charset [#"a" - #"z"] word: "" parse/all lowercase text [ any [ copy word some alpha ( either here: find/skip tally word 2 [ here/2: here/2 + 1 ][ repend tally [word 1] ] ) | skip ] ] foreach [word count] sort/skip tally 2 [ print [count tab word] ] quit 8<---------------------(end tallyn.r)--------------------- The timing (this afternoon, with a different overall load on the box) came out typically as follows: (/export/home/jneely/try)# time tallyn.r > /dev/null real 0m9.50s user 0m9.44s sys 0m0.05s At some point in the run, the TALLY has contents that resemble [ ... "written" 6 "wrong" 5 "wrote" 3 ... ] Of course, much of the complexity of the script above comes from the fact that the tally values (integers) can't be modified. We have to locate the "place" within the container (TALLY) that a count can be found, and then replace that count with a new number. That raises the question, "Is there another way to use containers to represent the number of times a word appears?" (In all of the variations below, the only change should be in the parenthesized action after a word has been found in the input.) Variant #1 ---------- OK, don't laugh! Remember counting things in elementary school (or later) by just making stroke marks on a piece of paper, and then counting the stroke marks when finished? Here's a script that takes that approach, using periods in a string instead of strokes on a piece of paper. (The final "s" is for "string".) 8<--------------------(begin tallys.r)-------------------- #!/export/home/jneely/bin/rebol -sq REBOL [] text: read %alice.txt tally: [] alpha: charset [#"a" - #"z"] word: "" parse/all lowercase text [ any [ copy word some alpha ( either here: select tally word [ append here "." ][ repend tally [word copy "."] ] ) | skip ] ] foreach [word count] sort/skip tally 2 [ print [length? count tab word] ] quit 8<---------------------(end tallys.r)--------------------- At a corresponding point in the run, this version's TALLY has contents that resemble [ ... "written" "......" "wrong" "....." "wrote" "..." ... ] To be honest, I created this variation as a joke. Imagine my surprise when I checked the run time, and saw: (/export/home/jneely/try)# time tallys.r > /dev/null real 0m8.28s user 0m8.21s sys 0m0.06s It's actually faster than the first version!!! In hindsight, there are fewer words and less data structure juggling (although there's memory management for the growing dot-per-occurrence strings). Well!!! Perhaps this is worth some more experimenting! Variant #2 ---------- Another way to manage the counts is to have a block containing the number as its only content. That leads to ("b" for "block): 8<--------------------(begin tallyb.r)-------------------- #!/export/home/jneely/bin/rebol -sq REBOL [] text: read %alice.txt tally: [] alpha: charset [#"a" - #"z"] word: "" parse/all lowercase text [ any [ copy word some alpha ( either here: select tally word [ change here here/1 + 1 ][ repend tally [word copy [1]] ] ) | skip ] ] foreach [word count] sort/skip tally 2 [ print [first count tab word] ] quit 8<---------------------(end tallyb.r)--------------------- At a corresponding point in the run, this version's TALLY has contents that resemble [ ... "written" [6] "wrong" [5] "wrote" [3] ... ] Despite the extra level of nesting, the speed improves again: (/export/home/jneely/try)# time tallyb.r > /dev/null real 0m5.53s user 0m5.45s sys 0m0.08s Variant #3 ---------- Finally, a last variation on the bare-numbers-in-the-block version that uses a different approach to getting at the place to have its content changed: 8<--------------------(begin tallyz.r)-------------------- #!/export/home/jneely/bin/rebol -sq REBOL [] text: read %alice.txt tally: [] alpha: charset [#"a" - #"z"] word: "" parse/all lowercase text [ any [ copy word some alpha ( either here: find tally word [ change next here (second here) + 1 ][ repend tally [word 1] ] ) | skip ] ] foreach [word count] sort/skip tally 2 [ print [count tab word] ] quit 8<---------------------(end tallyz.r)--------------------- I was yet again surprised to see the amount of improvement (compared to the first numeric version above) resulting from removing the /SKIP refinement from FIND (the majority of the benefit) and replacing the path expressions with CHANGE NEXT and SECOND, but here you have it! (/export/home/jneely/try)# time tallyz.r > /dev/null real 0m5.51s user 0m5.43s sys 0m0.08s This gets us down to the same performance level as the nested block version, although the notation probably looks a bit opaque compared with the path expressions of the first version. While there are often very nice ways to deal with the contents of data structures, such as FIND, FOREACH, and PARSE, there are still times when random access to, and modification of, contents of a data structre will be necessary. Sometimes the most obvious way to do such things is not the fastest! -jn-

 [53/80] from: rotenca:telvia:it at: 14-Jun-2002 1:55


> tally: []
Tally should be an hash! to gain speed. tally: make hash! 10000 --- Ciao Romano

 [54/80] from: greggirwin:mindspring at: 13-Jun-2002 18:19


Hi Joel, Excellent info! I don't want to make more work for you, but to be as apples-to-apples as possible, could you try using a hash! for tally and see what you get? I tried it here, with your last version, and got a pretty good increase. tally: make hash! [] Also, the timings exclude display of the results, correct? --Gregg

 [55/80] from: joel:neely:fedex at: 14-Jun-2002 7:05


Hi, Gregg, Have done. Gregg Irwin wrote:
> Excellent info! I don't want to make more work for you, but to > be as apples-to-apples as possible, could you try using a hash! > for tally and see what you get? I tried it here, with your last > version, and got a pretty good increase. > > tally: make hash! [] > > Also, the timings exclude display of the results, correct? >
Right. All timings were done with a command similar to (/export/home/jneely/try)# time tally.pl > /dev/null real 0m0.29s user 0m0.23s sys 0m0.04s which, of course, sends all script output to the bit bucket. (Notice that finding a time when the box is lightly loaded helps the run times...) As before, comparable median-of-3 times are (in increasing run-time order, the inserted "h" indicates the HASH! version of yesterday's scripts): tally.pl real 0m0.29s user 0m0.23s sys 0m0.04s tallyhs.r real 0m1.39s user 0m1.37s sys 0m0.02s tallyhb.r real 0m1.25s user 0m1.17s sys 0m0.08s tallyhz.r real 0m1.68s user 0m1.59s sys 0m0.08s tallyb.r real 0m5.63s user 0m5.53s sys 0m0.08s tallyz.r real 0m5.82s user 0m5.67s sys 0m0.10s tallys.r real 0m8.58s user 0m8.48s sys 0m0.08s tallyn.r real 0m9.77s user 0m9.63s sys 0m0.10s All of the times for the "h" version were obtained after replacing the initialization of TALLY with tally: make hash! [] (I didn't pre-allocate a large hash for the sake of fairness, as I hadn't done so for the block version nor for the Perl implementation.) Notice that there's no time for TALLYHN.R for a very good/bad reason. I wasted considerable time trying to figure out if I had inadvertently broken it!!! I finally used top to verify that, indeed, it was running (and eating up about 0.25 of a CPU -- that's 25% for the REBOL/Viewtopia users ;-). Inserting tracing output as shown below revealed that after adding 380 words, the *hn* version gets stuck, but continues to eat CPU time. In multiple runs it gets stuck at exactly the same place in the data, as illustrated in the following trace: ... added turned : now 754 found a : a 23 added corner : now 756 found oh : oh 3 found my : my 2 added ears : now 758 found and : and 30 added whiskers : now 760 found how : how 5 found late : late 2 found it : it 32 found s : s 4 found getting : getting 3 found she : she 35 I added the same tracing to *hz* and captured the output: ... added whiskers : now 760 found how : how 5 found late : late 2 found it : it 32 found s : s 4 found getting : getting 3 found she : she 35 found was : was 31 found close : close 2 added behind : now 762 ... which shows that *hn* is getting stuck trying to increment the count for the word "was", rather than trying to add a new word (if that matters to anybody or helps identify the nature of the problem). I am enclosing the code below in the hopes that someone will see something silly that I've overlooked. Otherwise I'll have to conclude that there's a bug involving path-based access into a hash! value. 8<--------------------tallyhn.r-------------------- #!/export/home/jneely/bin/rebol -sq REBOL [] text: read %alice.txt tally: make hash! [] alpha: charset [#"a" - #"z"] word: "" parse/all lowercase text [ any [ copy word some alpha ( either here: find/skip tally word 2 [ here/2: here/2 + 1 print ["found" word ":" copy/part here 2] ][ repend tally [word 1] print ["added" word ": now" length? tally] ] ) | skip ] ] foreach [word count] sort/skip tally 2 [ print [count tab word] ] quit 8<------------------------------------------------- Incidentally, don't take the timings *too* terribly seriously; as with all QAD benchmarks. These timings were run on a 4-CPU Sun 4500, but a variety of factors (transient loads, other tasks, stuff still in buffers, etc.) can introduce noticeable jitter in the times for runs as short as these. -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 ]

 [56/80] from: joel:neely:fedex at: 14-Jun-2002 7:06


Hi, Romano, Romano Paolo Tenca wrote:
> Tally should be an hash! to gain speed. > > tally: make hash! 10000 >
You're right, of course! Thanks! Most of the time I'm working with small enough data structures that the penalty isn't too severe, but that's no excuse for not remembering this. See my note to Gregg for results. -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 ]

 [57/80] from: gscottjones:mchsi at: 14-Jun-2002 7:54


From: "Joel Neely" <snip amount=large />
> Variant #2 > ----------
<<quoted lines omitted: 29>>
> user 0m5.45s > sys 0m0.08s
<snip amount=(to end)> Hi, Joel, et al, Using this version of the algorithm and using precise timing on the parsing loop only on a Win98 deCeleron 500 and an apparently slightly different version of alice, I obtained 0:00:11.31. Making a hash out of tally by changing: tally: [] to tally: to-hash [] I obtained a time of 0:00:00.5. Unfortunately, I don't know enough Perl to run Joel's equivalent code with the Alice file for direct comparison. Having pointed out the significant improvement that hash provides should not distract from one of Joel's original points that if RT's time/resources is/are limited, it would probably be better to spend time optimizing core functionality and making the environment more readily extensible with ad-hoc native functionality, when needed. In other correspondence, Carl S. has apparently indicated that he thought a percent type would be useful in gui construction but that the ROI was not enough to spend the time to work out the details. As always, with a little bit of cash, I suspect RT would happily work out the details! :-) I wish I had 2% of $1 to give away!!! At least my ideas are *free* (0% of $1) and easily worth every penny of it! ;-) --Scott Jones

 [58/80] from: gscottjones:mchsi at: 14-Jun-2002 8:21


Hi, All, I posted my last post before I realized Joel had already done the hashed versions From: "Joel Neely"
<snip> > ... These timings were run on a 4-CPU Sun 4500 ...
I tried to find my 4-CPU Sun 4500 for better comparisons, but couldn't find that machine. So I settled for my 1-CPU Win98 Celeron ;-). --Scott Jones

 [59/80] from: joel:neely:fedex at: 14-Jun-2002 8:27


Hi, all, Just to bring the sad saga to closure... ;-) Joel Neely wrote:
> Notice that there's no time for TALLYHN.R for a very good/bad > reason... In multiple runs it gets stuck at exactly the same > place in the data... >
I left it running (on the same system) for over an hour and a quarter (125% of 3600 seconds ;-) and no further progress occurred. Looks like there might be a loop in a structure somewhere??? -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 ]

 [60/80] from: greggirwin:mindspring at: 14-Jun-2002 10:21


Hi Joel, Thanks for doing that. Your results are similar to mine (from ~3 sec. to ~.3 sec. on a W2K P900 using a ~168K %looking.txt I found). << I am enclosing the code below in the hopes that someone will see something silly that I've overlooked. Otherwise I'll have to conclude that there's a bug involving path-based access into a hash! value. >> It works here with the latest Core beta. I know hash! had some afflictions in earlier releases though, which is probably what you're seeing. --Gregg

 [61/80] from: nitsch-lists:netcologne at: 14-Jun-2002 19:36


Hi Joel, Am Freitag, 14. Juni 2002 14:05 schrieb Joel Neely:
> Hi, Gregg, >
[snip]
> Right. All timings were done with a command similar to > (/export/home/jneely/try)# time tally.pl > /dev/null
<<quoted lines omitted: 4>>
> (Notice that finding a time when the box is lightly loaded > helps the run times...)
[snip] could you give us startup-time of an empty rebol-script and empty perl? i don't think it makes a bit difference, just curious.
> -jn-
-Volker

 [62/80] from: joel:neely:fedex at: 14-Jun-2002 15:38


Hi, Volker, Volker Nitsch wrote:
> could you give us startup-time of an empty rebol-script and empty > perl? i don't think it makes a bit difference, just curious. >
Gladly. Using the same highly-scientific median-of-three sampling ;-) we get: (/export/home/jneely/try)# time tally0.pl real 0m0.02s user 0m0.01s sys 0m0.01s (/export/home/jneely/try)# time tally0.r real 0m0.17s user 0m0.11s sys 0m0.05s where each of the above scripts was stripped down to a bare "do nothing and quit" state. -jn-

 [63/80] from: carl:cybercraft at: 17-Jun-2002 1:50


Hi Joel, (Note the first bit of this was written a couple of days ago.) On 14-Jun-02, Joel Neely wrote:
>> add-word: function [tally [block!] word [string!]][temp][ >> either temp: find/skip tally word 2 [
<<quoted lines omitted: 9>>
> version, it shrinks to 139 bytes -- although that renders it > significantly less readable),
Firstly, I don't buy the argument about the function using too many bytes as I've not heard many complaints about REBOL scripts being too long. As to there being less typing to do, and hence it'll take less time to write a script, well that may be true, if all else is equal, such as if perl scripts take a similar amount of time as REBOL ones to debug and maintain. I don't know if that's true - any others here with experience of both languages care to comment? But anyway, human-language words are the REBOL way of doing things and I think it's a bit late to get this changed now. (;
> but here's the point I was trying > to make with this dinky example: > Manipulating non-trivial data structures in REBOL, even > something as simple as a look-up table, involves much more > code and much more intpreter overhead than with several > other languages in the same space -- 'net applications.
I don't know about interpreter overhead, but to my mind a single character that means the same thing as a five-letter word is the same amount of "code". It's just that the five-letter word has a better chance of expressing to the reader what it means. An important point in an extensible language to my mind. As to trying to muscle into the net applications space, well I think REBOL will find a niche (and a big one) that's not already well occupied. IOS (I gather) points to one such space.
> I truly believe that addressing that issue would be of > significant value in promoting the wider use of REBOL.
<<quoted lines omitted: 25>>
> reduction -- read one or more text files, parse them down and do > some processing on the analyzed text, then spit out some results.
I'm sure that is common, but if I was worried about performance I would be thinking from the start that that was not a good algorithm as for every word you're doing a find of an ever-growing word list. If counting the words wasn't important, my REBOL approach would've been based on using 'unique... alice-words: sort unique parse read %alice-file.txt none (Of course, if needs be you'd change that to a parse/all with your own rule to handle how you'd want your words extracted if REBOL's default wasn't good enough.) As to what's the best way in REBOL to count the words as well I'm not too sure off the top of my head. However, I instinctively shy away from brute-strength aproaches even if I don't think there'll be a performance hit. It's a bad practice to get into in my opinion. (At about this time your post with example scripts turned up, hence this wasn't finished and sent then. See below...)
> The trade-off between native and mezzanine code is a significant > performance factor in REBOL. The fact that I can write a > function to do some task doesn't change the fact that there's a > run-time cost influenced by how much of the work of that function > must be expressed in mezzanine/user code.
I'm sure that's true. As I'm sure RT would like to convert a lot of that mezzanine code to native.
> I'm certainly not ignoring the value of graphical user interfaces > (I've been a Mac user since 1984, and my primary personal box is
<<quoted lines omitted: 10>>
> another data type. > As for the /View discussion, I'll reply separately.
And I'll answer that seperately too. But back to your coding example with the poor performance compared to Perl. Thinking about the find in the loop, I thought about two alternative aproaches: 1) Create tally as a suitably sized block of nones before you parse the file. Then, when parsing it, as the words are found generate (somehow:) a unique number from the word and use that number as the index into tally for storing your word and its count. As words that were the same would generate the same numbers, that'd be how you'd be able to count them without any need for a search. The problem with this approach was that I couldn't think of any sensible way to generate a unique number. It was a nice thought though. (; 2) Parse the file into a block of words (without attempting to extract or count them), sort this block, and then extract and count them with one simple loop through the block. Would sorting the main file first prove to be faster? Well, yes - and no... First I made a copy of your (original) script to use as a benchmark. This is it, modified to allow me to enter a file-name and to time the test... ---8<--- REBOL [] prin "file-name: " text: read file: to-file input time: now/time/precise tally: [] alpha: charset [#"a" - #"z"] word: "" parse/all lowercase text [any [ copy word some alpha ( either here: find/skip tally word 2 [ here/2: here/2 + 1 ][ repend tally [word 1] ] ) | skip ]] tally: sort/skip tally 2 time: now/time/precise - time print [time "Counter-1" file length? tally] ---8<--- Now for my first script. Well, it's not my first, as all attempts to get a version of... parse/all lowercase text "all characters except lowercase-letters" to properly dice up the text into words failed. Bugged I believe, going by my memory of long-ago posts to the list. So instead I just used a simplified version of your parse rule to build the block of words. And this is it... ---8<--- REBOL [] prin "file-name: " text: read file: to-file input time: now/time/precise temp: [] alpha: charset [#"a" - #"z"] word: "" parse/all lowercase text [any [ copy word some alpha (append temp word) | skip ]] sort temp tally: [] forall temp [ x: index? temp while [temp/1 = temp/2][temp: next temp] repend tally [temp/1 (index? temp) - x + 1] ] clear head temp time: now/time/precise - time print [time "Counter-2" file length? tally] ---8<--- This proved to be about three times as fast as your script, though that may vary on other systems of course. But, if hash is used with your script as others have suggested, it's about five times as fast, while I couldn't get hash to make any improvement on my script. (Not that I've tried very hard, as because of the hash bug (I'm assuming) it locked up your script when I gave it the biggest file I'd been using for testing, so I didn't play around with hash much.) So, your script still really wins in the speed stakes, though others may see some room for improvement in mine of course. (: I'd be interested to know how they compare in your tests if you've not lost interest by now... (: I also wrote the following, which has a bit faster first parse, though it's also more convoluted... ---8<--- REBOL [] prin "file-name: " text: read file: to-file input time: now/time/precise lowercase text alpha: charset [#"a" - #"z"] rest: charset [#"^(00)" - #"^(60)" #"^(7B)" - #"^(ff)"] word: "" parse/all text [any [ some alpha | x: copy word some rest (change/dup x " " length? word) | skip ]] temp: sort parse text none tally: [] forall temp [ x: index? temp while [temp/1 = temp/2][temp: next temp] repend tally [temp/1 (index? temp) - x + 1] ] clear head temp time: now/time/precise - time print [time "Counter-3" file length? tally] ---8<--- Thanks for the fun Joel. (: -- Carl Read

 [64/80] from: joel:neely:fedex at: 16-Jun-2002 15:52


Hi, Gregg, Gregg Irwin wrote:
> << I am enclosing the code below in the hopes that someone > will see something silly that I've overlooked. Otherwise I'll
<<quoted lines omitted: 3>>
> afflictions in earlier releases though, which is probably what > you're seeing.
I guess "beta" is the operative word. I checked again to make sure I was running an up-to-date version on the server: REBOL/Core 2.5.0.10.1 Copyright 1997-2001 REBOL Technologies REBOL is a Trademark of REBOL Technologies All rights reserved. ... so the "stock" /Core 2.5 does still have some problems. -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 ]

 [65/80] from: joel:neely:fedex at: 16-Jun-2002 16:22


Hi to all who've been following/participating in this thread. One or two additional random thoughts have been rolling around in my head, so I thought I'd evict them! ;-) Percentage expressions ------------ ----------- I haven't heard any other comment on the question of whether decimal! values have a pre-existing meaning when used within LAYOUT blocks. If not, here's a potential compromise that I'd be interested in feedback on. I suspect that it would be easier to make a slight modification to the lexical rules for LOAD than to implement an entire new data type. (Notice I'm up to 2 assumptions now!) How about adding #"%" as a valid suffix to any numeric datum, with the meaning of "left shift the decimal point by 2 and yield a decimal! value" ? With this lexical tweak in place, 1% would represent the same value as 0.01 3.5% 0.035 100% 1.0 and so on. This would allow those who wished to represent factors in REBOL source (or input, or files, ...) as percentages to get the notational convenience, but would (my guess) not take nearly so long or as much work as a complete new datatype. For those whose specific interest is in resizing/scaling within View, I'd still wonder if decimal! scaling factors or some other dialect enhancement wouldn't be just as convenient. Other priorities ----- ---------- While thinking about how this compares with other things that I know have been on the table for some time, I remembered another issue that has disappeared from the radar scope -- formatting for output. Every language I use for real programming offers some way to control the way in which internal values are converted to strings for output -- except REBOL. Such capabilities include: - left- or right-padding or truncating strings to fixed width, - padding numeric values to specified lengths, with either zero or blank left-padding, - fixing total length and number of fractional digits for floating-point values, - collecting a series of expressions/values into a single string, with appropriate formatting for each. I recall some discussion quite a while back about this issue -- specifically about exposing some way to get at the underlying printf mechanism, as REBOL is implemented in c -- and the reply from Sterling (on or about 19 Sep 2000 16:40:32)
> A quick comment: > I understand what you're asking for and I personally think that
<<quoted lines omitted: 6>>
> types of formatting issues within REBOL. I don't know when it'll > happen though.
In the intervening 175% of a year, we've had numerous discussions about how to format data for output, with decimal formatting being one of the most common/recent (including the issue of reliably rounding decimal values to a specified precision). Yet we still don't have a standard means of doing this common programming operation in REBOL. Let me add that to my things-that-keep-coming-up list that I'd like to see addressed before we start inventing new things to ask for (including my lexical compromise idea above!) -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 ]

 [66/80] from: joel:neely:fedex at: 16-Jun-2002 15:49


Hi, Carl, Carl Read wrote:
> >> add-word: function [tally [block!] word [string!]][temp][ > >> either temp: find/skip tally word 2 [
<<quoted lines omitted: 6>>
> many bytes as I've not heard many complaints about REBOL > scripts being too long.
That's task- (and algorithm-) dependent, IMHO. I've said very little about the effort of using REBOL to do complex numerical and matrix computation because I simply don't use REBOL for those types of tasks. The issue, again, is "how much work/code/runtime is required to do comparable things?"
> As to there being less typing to do, and hence it'll take less > time to write a script... > > I don't know about interpreter overhead, but to my mind a single > character that means the same thing as a five-letter word is > the same amount of "code"... >
Actually, we're focusing on the same issue here (IMHO) but using different words to express it. Let me try an analogy: When I write a program to perform some task, I'm building a conceptual bridge between the natural terms of discourse for the problem and the level of the concepts built into the programming language at hand. The further apart those two shores are, the more bridge I have to build, even if I build it by pre-fabbing I-beams and trusses (functions/subroutines) and then constructing the bridge in terms of those sub-assemblies. To my mind, handling multi-level data structures is something that should be easy in a modern programming language (and I agree with your comment about a single operator being a single concept, regardless of how many characters it takes to spell it out). So let's look at the two cases: ++$tally{$word} to my eye parses out as follows: ++ increment (by one) $ the value tally in the structure named "tally" {} at the symbolic key in $word the variable named "word" In contrast, the REBOL version makes me deal explicitly with deciding whether the key is already present, handling presence by constructing a positional reference into a data structure so that I can replace an integer with its successor, and handling absence by explicitly including the new key and an initial count of one. (For sake of space, I didn't explode the REBOL into token-by-token annotation as I did the Perl version. But notice that I still had to use many more words at a much more detailed implementation level to explain what the REBOL version was doing.) Again, I'm not trying to bash REBOL, but to point to an area where REBOL requires much more code, time, and attention to detail than some other languages. Since I believe that zone contains many common sys admin, server-side programming, and general data processing tasks, I think it would be very useful to see REBOL extended to handle that area more effectively.
> I'm sure that is common, but if I was worried about performance > I would be thinking from the start that that was not a good > algorithm as for every word you're doing a find of an ever-growing > word list. If counting the words wasn't important, my REBOL > approach would've been based on using 'unique... >
While I remain happy to exchange ideas about more effective ways to do almost anything with REBOL, I really don't want to become so focused on how to optimize a specific example that we miss the big picture. As I said before, I believe the *types* of processing in the word-count example were typical, not the specific task itself. I wanted to offer a simple illustration that wouldn't take too much explanation, and to show the performance of *comparable* approaches. A more realistic example (since it's real -- I recently wrote a script for a task very similar to this ;-) would be to write a script that would read the log file of a web server, searching the URL fields for requests that matched certain criteria. For each such line found, output the requesting IP or host name, date and time (including time zone) of the request, representing all output in XML. However, specifying all of that (including the kinds of criteria and the XML specs) would have taken too much time and detracted from the main point. However, this is another example of a task that requires * reading from a file, * treating the content as lines, * transforming and parsing each line, * computing output based on the contents found, but for which something as simple as "sort unique" would not suffice.
> But back to your coding example with the poor performance compared to > Perl. Thinking about the find in the loop, I thought about two > alternative aproaches: > > 1) Create tally as a suitably sized block of nones before you parse > the file... >
Specifying "suitably-sized" would be infeasible for the typical case; for problems of the kind I had in mind, one usually doesn't know in advance how much data will be processed (or the size will vary from file to file), so a "flexible" structure offers real advantages.
> Then, when parsing it, as the words are found generate > (somehow:) a unique number from the word and use that number as the > index into tally for storing your word and its count... > > The problem with this approach was that I couldn't think of any > sensible way to generate a unique number. It was a nice thought > though. (; >
A home-grown hashing algorithm, perhaps? Something based on the result of CHECKSUM/SECURE (scaled down drastically)? Of course the trick would be to handle collisions gracefully...
> > 2) Parse the file into a block of words (without attempting to > extract or count them), sort this block, and then extract and > count them with one simple loop through the block. Would sorting > the main file first prove to be faster? Well, yes - and no... >
As for the ultimate relevance of continuing to redesign this intentionally simple problem, see above. (However, I can't resist one further bit of off-topic tweakage... ;-)
> Now for my first script. Well, it's not my first, as all attempts > to get a version of... > > parse/all lowercase text "all chars except lowercase-letters" > > to properly dice up the text into words failed. Bugged I believe, > going by my memory of long-ago posts to the list... >
Which is why I'd also put "fixing all known bugs" as a higher priority than adding *any* new features at this point.
> ... So instead I just used a simplified version of your parse rule > to build the block of words. And this is it...
<<quoted lines omitted: 20>>
> print [time "Counter-2" file length? tally] > ---8<---
I took your solution above, restored the hard-coded file name, eliminated internal time capture, and wrote word/count pairs to standard out (instead of appending them to another block) so that I could compare it to the tests I've got on the 4500. The "c" is in honor of "Carl", of course! 8<--------------------begin tallyc0.r-------------------- #!/export/home/jneely/bin/rebol -sq REBOL [] text: read %alice.txt tally: [] alpha: charset [#"a" - #"z"] word: "" temp: [] parse/all lowercase text [ any [ copy word some alpha (append temp word) | skip ] ] sort temp forall temp [ x: index? temp while [temp/1 = temp/2][temp: next temp] print [(index? temp) - x + 1 tab temp/1] ] quit 8<---------------------end tallyc0.r--------------------- I then applied a standard file-processing trick to simplify the processing of the sorted block-o-words, and got this minor variation: 8<--------------------begin tallyc1.r-------------------- #!/export/home/jneely/bin/rebol -sq REBOL [] text: read %alice.txt tally: [] alpha: charset [#"a" - #"z"] word: "" temp: [] parse/all lowercase text [ any [ copy word some alpha (append temp word) | skip ] ] oldword: none count: none foreach word sort temp [ either word = oldword [ count: count + 1 ][ if count [ print [count tab oldword] ] oldword: word count: 1 ] ] quit 8<---------------------end tallyc1.r--------------------- I made corresponding changes to your last script (the one with the "modify-in-place" parse rule) to create tallyc2.r and tallyc3.r Finally, if we're going to do fair apples-to-apples, we need to apply the same (highly ad hoc) optimization hacks to the Perl version (reading the entire file at once, breaking that single string into a collection of words, sorting them, and just tallying up the occurrences in a single pass). Doing so gives us this (in case anybody cares to see what it looks like...): 8<--------------------begin tally1.pl-------------------- #!/usr/local/bin/perl -w open (TEXT, "< alice.txt") or die "Can't open 'alice.txt'\n"; undef $/; my $text = <TEXT>; close (TEXT); my ($oldword, $count) = ("", 0); foreach my $word (sort split /[^a-z]+/, lc $text) { if ($word eq $oldword) { ++$count; } else { print "$count\t$oldword\n" if $count; ($oldword, $count) = ($word, 1); } } exit (0); 8<---------------------end tally1.pl--------------------- I reran the benchmark for tallyn.r, tallyz.r, tallyhb.r, tallyhs.r, and the variations described above. NOTE: The server has a different overall load right now, so the numbers should only be compared among each other, not directly with numbers from other runs on another day. The median-of-three results are: tallyn.r real 0m11.41s user 0m11.35s sys 0m0.05s tallyz.r real 0m7.20s user 0m7.11s sys 0m0.08s tallyc0.r real 0m4.76s user 0m4.76s sys 0m0.39s tallyc1.r real 0m4.25s user 0m3.80s sys 0m0.40s tallyc2.r real 0m3.97s user 0m3.86s sys 0m0.10s tallyc3.r real 0m3.47s user 0m3.32s sys 0m0.14s tallyhs.r real 0m3.25s user 0m3.18s sys 0m0.06s tallyhb.r real 0m3.12s user 0m3.03s sys 0m0.10 tally.pl real 0m0.71s user 0m0.68s sys 0m0.02s tally1.pl real 0m0.50s user 0m0.48s sys 0m0.01s A few observations: - Clearly, the more ad hoc (in the sense of specialized tuning for a specific situation) we make our algorithms, the more we would expect to improve performance. However, notice that this is language- and design-specific. tallyhb.r and tallyhs.r both still beat tallyc*.r despite the fact that tallyc*.r threw out the construction of the word/count table. (Thus we see that maintaining the hash-based data structure can be faster than sorting a block of all keys -- including duplicates -- for at least some input data cases.) - The other side of that coin is that more ad hoc (specialized) algorithms usually lose flexibility. If the "customer" came back and said ... Oh, I meant that I wanted it in frequency order (most common words first) not alphabetically by words! ... then either tally.pl or tallyn.r could be changed more quickly and easily than their specialized cousins. - Using path notation for random access of values within a block is surprisingly costly. This was seen earlier in the difference between tallyn.r and tallyz.r , where either here: find/skip tally word 2 [ here/2: here/2 + 1 ][ repend tally [word 1] ] required way substantially more time than either here: find tally word [ change next here (second here) + 1 ][ repend tally [word 1] ] This same issue is most of the reason that c1 and c3 were able to outperform c0 and c2, IMHO. - Performance is still an issue worth remembering when deciding whether to use REBOL for some task of significant size. Remember that "Alice" was a small text file (a little over 140K), while the web log processing I alluded to was chomping through many megabytes and doing much more processing per line. The first brute-force Perl version (tally.pl) was coded about as fast as I could type, and outperformed the brute-force REBOL versions significantly. After several of us have tried various ideas for streamlining the REBOL version, the fastest one tried to date is still 4-5 times slower than the QAD Perl version. When we throw the same speed-up tweaks at Perl (to get tally1.pl) it moves up to about 6 times as fast as the fastest REBOL model. Not complaining, just observing... The performance issues above are certainly not the only issue when comparing REBOL with other options, but we shouldn't pretend that they don't exist, either! Thanks to all for the interesting ideas/challenges/comments! -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 ]

 [67/80] from: g:santilli:tiscalinet:it at: 17-Jun-2002 0:54


Hi Joel, On Sunday, June 16, 2002, 11:22:26 PM, you wrote: JN> While thinking about how this compares with other things that I JN> know have been on the table for some time, I remembered another JN> issue that has disappeared from the radar scope -- formatting JN> for output. I have the feeling that Carl adds things to REBOL as soon as he needs them. Probably he never needed formatting yet, so it's not here... Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

 [68/80] from: greggirwin:mindspring at: 17-Jun-2002 11:04


Hi Joel, << How about adding #"%" as a valid suffix to any numeric datum, with the meaning of "left shift the decimal point by 2 and yield a decimal! >> I'd have to think about that for a while. I do think it could be a handy notation, but it would also tighten the lexical rules a bit more, which could have side effects on future development. Re: formatting for output. I agree that this is an important, and missing, piece of the REBOL puzzle. I have JUSTIFY and ROUND functions that I use, but only a few notes about a FORMAT function and dialect. Eric Long's format.r dialect didn't resonate with me, but that's just me. --Gregg

 [69/80] from: enter:your:email:address:here:rebol:(example: at: 15-Jun-2002 19:19


Hi, I perfectly agree with your proposal on the percent! type. It would do exactly what is necisary, and propably behave the 'nicest' I am with you on the formatting request as well, either in this post or another one ( i do not recall) you have mentioned that REBOL lacks some serious Server Maintainance type functions. I too would like to see these implimented before version 3.0. Let's create a list of those that would be most helpful and see what we can get... Enjoy, my $0.04 - 50% Ammon On Sunday 16 June 2002 05:22 pm, you wrote:

 [70/80] from: carl:cybercraft at: 18-Jun-2002 17:46


Hi Joel, Seems a while since you wrote this now, but I've been a bit snowed under with stuff. Anyway... On 14-Jun-02, Joel Neely wrote:
> Hi, again, Carl, > With respect to the View issues...
<<quoted lines omitted: 4>>
> do some other things that would have a bigger effect on the > widespread adoption of REBOL.
This may be true. Actually, everything else has muddied the issue to my way of thinking. The question should be whether having a percent datatype is a good idea or not. If it isn't (and RT agrees:) then the issue of whether it should be implimented before other stuff is no longer a question. If it is a good idea though, then how high it should be on the to-do list is open to debate.
> So far the "datatype as clue to View layout" is the only issue I've > seen raised in this thread that wasn't simply a matter of a shorter > (and arguably more conventional) way to write floating-point values > that indicate ratios or factors.
Well, consider these two, (no, make it three), hypothetical functions... add-tax: func [price [number!] tax [number!]][price * tax + price] add-tax: func [price [money!] tax [number!]][price * tax + price] add-tax: func [price [money!] tax [percent!]][price * tax + price] The first two we can already do in REBOL. However, using the money datatype as with the second example has the advantage of built-in error-detection if a money-datatype isn't supplied to the function...
>> add-tax $10 .10
== $11.00
>> add-tax 10 .10
** Script Error: add-tax expected price argument of type: money ** Near: add-tax 10 0.1 So to the third example with the percent datatype. This would also have the advantage of built-in error detection if a percent value wasn't surplied, plus there'd be no need for converting the percentage values supplied by users to 100th of their value before they were used. That means there's extra chances for errors in our code as we think "ten percent" but have to use "point one". For instance, which of these two is the correct way to do things... tax-percent: 12 tax-percent: .12 ? Then consider 12.5%... So much easier with... tax: 12% or... tax: 12.5%
>> Fair enough. But others using other OSs and every IOS user >> (I assume) are using View. And they need to be able to create
<<quoted lines omitted: 3>>
> I might agree that it is *A* way to do it, but I don't think it's > the only possibility by any stretch of the imagination.
And I didn't say it was the only way, just the obvious way. (:
>>> 1) I spend a bit of time with graphics and color issues, so >>> my first thought on seeing the above was:
<<quoted lines omitted: 14>>
> attributes deemed most common for some purposes) I question whether > the "datatype as only clue" approach itself scales well.
It doesn't, (lots on a GUI having at least two colours for instance), but there's 3 (I guess) levels of convenience with VID. The first is to use the style's default settings, the next is to alter those settings by just adding a datatype to the style with the datatype determining which of the settings will be altered, and the third is to figure out from the available docs, examinations of mezzanine code and questions to this list how to alter anything else you need to! (: The point with the datatypes though is when you want a GUI fast, as apposed to the perfect GUI for the job, they make it very easy to create a GUI in a hurry. An example... view layout [across text-list "aa" "bb" "cc" 100x300 area 300x300] The pair datatypes there are a good example of how datatypes are useful when you want a quick and easy way to build a GUI. Without it we'd need to either specifically indicate what we mean by (say) width and height words, or assume that two integers represented them. The latter is perhaps as efficient, but those "x"s make all the difference when it comes to clarity. As would a "%" on the numbers.
> The punch line is that I have serious reservations about a notation > that leans heavily on datatypes (and large doses of assumption about > the most likely meaning or most frequent use) to specify complex > artifacts.
As I pointed out above, it's just for convenience. The rest is possible to get at one way or another.
>> 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
<<quoted lines omitted: 3>>
> of "use" at least ;-). I'm just suggesting that "useful" and "most > urgent to deal with right now" are distinct concepts.
I agree, but what is most urgent is a bit subjective and depends on the individual's point of view. Mine is that designing GUIs with VID is quite close to being good but is seriously let down by how difficult it is to make them scalable. Execution speed is an issue with REBOL, but it isn't the usual reason you choose a high-level language, is it? Or more correctly, execution speed isn't, but developement speed probably is, as is ease of maintainance. All the better if the execution speed is good, but if a high-level language isn't easy to develope in, where's the advantage in chosing a high-level language over a lower-level one?
>> Well, I answered your problem regarding adding words to a list to >> my satisfaction, (though perhaps not to yours), so perhaps you'd
<<quoted lines omitted: 31>>
> With that said, let me add my preference for a design strategy > of "Make simple things simple, and complicated things possible"
I actually think that's how it is with VID now. Just that there's some simple things that still need to be made simple - and the rest of it just needs to be doccumented...
> If I can imagine changing View to follow that principle, I would > favor something like the following. If you write
<<quoted lines omitted: 10>>
> vertically but not change width, a horizontal scrollbar would > have SCALEX, a thumbnail icon could have NOSCALE, etc...
Using my example above as a template for a test of this, we get... view layout/options [ across text-list "aa" "bb" "cc" 100x300 scaley area 300x300 ][resize] Which is quite nice, and some might say better than using percentages without automatic scaling of everything, (my prefered option), which would look like this... view layout/options [ across text-list "aa" "bb" "cc" 100x100% area 100%x100% ][resize] A percentage value would mean the percentage of the space left by the parent face after the sizes of the fixed panes had been deducted. Same as with HTML table sizing. (I think.) Why I don't like the idea of resize turning every pane into a scalable one is you have the likes of buttons and so on which in most cases you wouldn't want to scale. They could have their defaults set to noscale though, which would be consistant with the current VID way of doing things.
> For any more complex scanarios, I'd put the monkey back on the > programmer with something vaguely like > view/options layout [... some widget specs ...] [resizeby > function] > where the offered function (by name or anonymous) would be invoked > to handle the resizing,
A good idea.
> and would be able to use some simple > interface to adjust the size of each component widget within the > layout, so that a programmer wanting a more sophisticated > layout-management strategy would have a way to implement it.
As we're really talking about every face here, ie, faces within faces and not just the outer, window-level face, that level of control would be a byproduct of implimenting either of our methods. Incidently, minimum and maximum sizes I guess will need to be catered for too.
> Again, let me repeat that I'm not trying to play "duelling examples" > here, but to ask the question "What could be done to make REBOL more > attractive to users and developers who currently are not aware or > interested?" I trust we all would like to see that result!
Indeed. Users do judge stuff on the GUI though. Being different to what they're used to is a big enough hurdle for them to get over, (hence the need for decent skins), and they certainly aren't impressed by less functionality than they're used to. As for developers, well you can never please them - they wouldn't keep looking at new languages if that was the case. (; Anyway, I can't see any major advantage in using percentages over your suggested method, so I grant you you may be right here. That said, the real test would be in the using. I wonder though whether adding a new datatype and updating VID would take much longer than just updating VID in the way you envisage? Now, just to muddy the waters even more, I've remembered there's this from the old View Beta docs... ---8<--- Virtual Coordinate Space (not working in beta 4 release) A virtual coordinate space makes it possible to develop a visual interface without needing to know the actual display size. This is to say, it is possible to use a virtual pixel space for aligning face objects. So, the resolution of a user's display does not need to be known before designing a visual interface. For instance, if you want to create a visual interface that will look the same between systems with a display resolution of 320x240 and systems with resolutions of 1280x1024 and greater. This can be done with View's virtual coordinate space capabilities. ---8<--- That's an extra layer on top of the resizable windows we're talking about. Anyone know if that's been dropped or just on the back-burner? -- Carl Read

 [71/80] from: carl:cybercraft at: 18-Jun-2002 21:07


Hi Joel, I think we've nearly done the perl vs REBOL thing to death, but just a few comments. Firstly, thanks for doing the script comparisons. They were surprisingly close to the results I was getting. And as your noted too, using hash was still a bit faster. On 17-Jun-02, Joel Neely wrote:
> While I remain happy to exchange ideas about more effective ways > to do almost anything with REBOL, I really don't want to become so
<<quoted lines omitted: 4>>
> much explanation, and to show the performance of *comparable* > approaches.
I realise that. But different languages perform differently, so I was trying to think of how best to approach the problem from a REBOL point of view. For instance, if the roles were reversed and Perl was the newer language for you and you'd been using REBOL as often and for as long as you've been using Perl, do you think you would've overlooked the use of hash? (Other than because it's bugged:) It takes a while for the best approaches to become second nature. That said, Perl at this stage is obviously the better choice for the kind of processing you're talking about when speed's an issue. -- Carl Read

 [72/80] from: anton:lexicon at: 18-Jun-2002 20:36


That's what face/span is hanging around for, if I remember correctly. Anton.

 [73/80] from: joel:neely:fedex at: 18-Jun-2002 7:04


HI, Carl, Carl Read wrote:
> Hi Joel, > > Seems a while since you wrote this now, but I've been a bit snowed > under with stuff. Anyway... >
I know the feeling!!!
> Well, consider these two, (no, make it three), hypothetical > functions... > > add-tax: func [price [number!] tax [number!]][price * tax + price] > > add-tax: func [price [money!] tax [number!]][price * tax + price] > > add-tax: func [price [money!] tax [percent!]][price * tax + price] >
...
> So to the third example with the percent datatype. This would also > have the advantage of built-in error detection if a percent value > wasn't surplied, plus there'd be no need for converting the percentage > values supplied by users to 100th of their value before they were > used... >
I'd only add (PTP;-) that add-tax: func [price [money!] tax [decimal!]] [tax + 1.0 * price] would work just fine with my later suggestion regarding #"%" as a numeric suffix, allowing add-tax $14.95 8.5% or add-tax $238.15 5% because (in that proposal) the "scale-radix-left-by-two" meaning of the trailing #"%" would always yield a decimal! value. Thus we get notational benefit (for those who think that's a benefit) and type checking with this approach as well.
> I agree, but what is most urgent is a bit subjective and depends > on the individual's point of view. Mine is that designing GUIs > with VID is quite close to being good but is seriously let down > by how difficult it is to make them scalable. >
If I may ask, what do you really mean by "scalable"? Is the issue to allow a user to arbitrarily change window size at any time for whatever reason, or is it to allow a user to adjust the display to fit the size of the monitor (e.g. closer to a "set it once and forget it" scenario)? If the latter, what about having a set of choices (based on the common monitor sizes) from which the user can select? In that case the UI designer can make sure that each is appropriately laid out and all the positioning/scaling is "right" for each but consistent in overall "feel" across all choices. The app should remember the selection in a config file so that, once set, it will present the same size every time (unless/until the user explicitly overrides it). A user behavior I've seen repeatedly is to size one or more app windows to (nearly) the size of the available display, then use window switching to move between apps. Some users like to keep the resolution low to make the text large and easily readable (or readable from further away) while others prefer to maximize the resolution to get as much content on the screen as possible. Providing pre-defined settings for common monitor sizes (e.g., 800x600, 1024x768, 1200x1024 (?), 1600x1200), initially auto- detecting the available real estate and picking the largest that will fit, and allowing the user a simple way to try other sizes (e.g., "small, medium, large, huge" or something else without lots of scary numbers) might be an approach that could actually simplify life for the users. Of course, I'm assuming in the above that users are treating their computers as tools to do some task, and the focus is on the task, not on playing around with the computer itself. That's not true for all computer users, obviously. Anyway, I guess I'm dancing around the underlying questions: - Why do windows need to be scalable? - Do all windows need that feature? - What problem are we really solving? - Are we playing with symptoms, or is there a real "root-cause" issue involved here?
> Execution speed is an issue with REBOL, but it isn't the usual > reason you choose a high-level language, is it? Or more correctly,
<<quoted lines omitted: 3>>
> where's the advantage in chosing a high-level language over a > lower-level one?
Good questions, all. I tend to see language selection (regardless of "high" versus "low") as a complicated balancing act in which one tries to find a happy compromise among a large number of factors (in no particular order): 1) Ease of development 2) Ease of maintenance 3) Availability within the target environment/platform 4) Skillset of the professionals who will do (1) and (2) 5) Access to more professionals who already have skills with the language/environment/platform 6) Interoperability with existing systems 7) Ability to re-use existing code/components 8) Run-time performance (both for current and projected loads) 9) Cost and availability of tools/training/learning and (not because I've exhausted the issue, but just worn out my fingers and your eyes... ;-) 10) The nature of the project (one-shot ad-hoc task, prototype, proof-of-concept, research, 24x7 dark room production, etc.) as it interacts with all of the above. I certainly don't believe that run-time performance is the most important issue in most cases (as long as it is adequate for the task at hand!), but it is one of the easier factors to measure! That means that, until REBOL can provide performance that is roughly comparable to some other widely-used tools, it's going to have a hard time elbowing its way into application areas where those tools are already in use.
> > If I can imagine changing View to follow that principle, I would > > favor something like the following. If you write
<<quoted lines omitted: 24>>
> area 100%x100% > ][resize]
Although I now have to point out that you are assuming TWO new types: a percent! type, and a percent-pair! type. Scope creep rears its ugly head once again! ;-)
> Why I don't like the idea of resize turning every pane into a scalable > one is you have the likes of buttons and so on which in most cases > you wouldn't want to scale. They could have their defaults set to > noscale though, which would be consistant with the current VID way of > doing things. >
Which is exactly what I had in mind (although I used icons as the example of a non-scaling widget rather than buttons). I can also imagine having a button that e.g. spans the width of a display across the bottom having a SCALEX attribute. -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 ]

 [74/80] from: carl:cybercraft at: 21-Jun-2002 15:02


Hi Joel, On 19-Jun-02, Joel Neely wrote:
>> I agree, but what is most urgent is a bit subjective and depends >> on the individual's point of view. Mine is that designing GUIs
<<quoted lines omitted: 3>>
> to allow a user to arbitrarily change window size at any time for > whatever reason,
Yes, that. I should've said resizable, not scalable.
> or is it to allow a user to adjust the display to > fit the size of the monitor (e.g. closer to a "set it once and
<<quoted lines omitted: 7>>
> set, it will present the same size every time (unless/until the > user explicitly overrides it).
No, that's much too much work for the programmer, and they'll invariably get it wrong for every second user, if they bother to attempt it at all. I think what RT mentioned in the beta docs about their "Virtual Coordinate Space" would be a better way than that. Another quote from it... ---8<--- Virtual coordinates are defined in the span facet of a window's top level face. To set the span, use the /span and /size refinements with layout to display a new face. The /span will indicate the virtual coordinate space while /size specifies the actual pixel size of the window. layout/span/size face 4096x3072 341x25 | | Virtual Coordinate Space | Window's Size (real pixel space) The top level face is inherited from the global face object. Using the /span and /size refinement with layout will set the span and size facets within the top level face as it is inherited. The /size refinement must be used with the /span refinement to set the actual pixel size of the window. If the real pixel space window size is not set in this way, undesirable results may occur. ---8<--- The full docs can be found in the Rebol Forces archives... http://www.rebolforces.com/archive/view099users.html
> A user behavior I've seen repeatedly is to size one or more app > windows to (nearly) the size of the available display, then use > window switching to move between apps. Some users like to keep > the resolution low to make the text large and easily readable > (or readable from further away) while others prefer to maximize > the resolution to get as much content on the screen as possible.
Ideally they should be able to choose the fonts they're using on an apps by apps and windows by windows basis, overiding their default REBOL skin.
> Providing pre-defined settings for common monitor sizes (e.g., > 800x600, 1024x768, 1200x1024 (?), 1600x1200), initially auto-
<<quoted lines omitted: 3>>
> lots of scary numbers) might be an approach that could actually > simplify life for the users.
Just resize and snapshot a window seems the simpliest approach to me. (Of course, you're thinking scaling there, but anyway...) I've done something like this with some of my view scripts. ie... rebol [] win-size: 300x200 win-offset: 50x50 lo: layout [ across vh2 "Window Title" snap: button 20 "S" [ ; Clicking the button saves the window's size and offset. ] return stuff: area ] resize-response: does [ snap/offset/x: lo/size/x - 40 stuff/size: lo/size - 40x80 show lo ] resize-response view layout [ button "Test" [ view/new/offset/options lo win-offset [resize] lo/feel: make out/feel [ detect: func [face event][ if event/type = 'resize [resize-response] event ] ] ] ] That keeps the snapshot button in the top right of the window when you resize it. (The need for the window with the "Test" button is because you have to setup the event routine after the window has opened to capture a resize. So you have to use view/new for this to work - which doesn't work if it's the first window you open in View...)
> Of course, I'm assuming in the above that users are treating > their computers as tools to do some task, and the focus is on > the task, not on playing around with the computer itself.
Of course. (;
> Anyway, I guess I'm dancing around the underlying questions: > - Why do windows need to be scalable?
Because if not, your average programmer assumes everyone has a 1024x768 display or better...
> - Do all windows need that feature?
It should perhaps be the default, but probably a bit late to introduce it as the default now.
> - What problem are we really solving?
Different sized displays - from 320x200 (cell-phones and the like) upwards...
> - Are we playing with symptoms, or is there a real "root-cause" > issue involved here?
Root cause is different sized displays. But that's with scaling. Resizing's different... --- Why do windows need to be resizable? 1) Because sometimes the same window will have different amounts of content. Text in an area is an obvious example. It's nicer to avoid scrolling if you can, and enlarging the window can do that in some cases. 2) And because sometimes you like to shrink a window just to give you more deskspace to get at other stuff. If the contents don't resize with the window, shrinking the window can mean you can't see some of it. A shrunken text-box which you can still see and scroll through is better than one you can't see at all. --- Do all windows need that feature? Probably not. A... view layout [banner "Quit?" 210 across button "Yes" button "No"] is better without resizing I think. --- What problem are we really solving? Insufficient space to have all the information you want on screen at once. --- Are we playing with symptoms, or is there a real "root-cause" issue involved here? The root cause is room-wide screens cost too much. (; And they also can't fit in your pocket. [snip comments about percent datatypes]
> Although I now have to point out that you are assuming TWO new > types: a percent! type, and a percent-pair! type. Scope creep rears > its ugly head once again! ;-)
Actually, I was just thinking of a modified pair. Pair was added with pixel coordinates in mind I believe, hence it only accepts integers, not numbers. So adding percentage support shouldn't break any existing scripts. (He guessed wildly:) -- Carl Read

 [75/80] from: joel:neely:fedex at: 21-Jun-2002 11:31


Hi, again, Carl, On Thursday, June 20, 2002, at 10:02 PM, Carl Read wrote:
>> - Why do windows need to be scalable? > > Because if not, your average programmer assumes everyone has a > 1024x768 display or better... >
Yow! Any programmer who would make such an assumption (or assume that everybody is running a particular browser, or has millions of colors, or a 1.2 GHz processor, or ...) needs some professional experience (unless, of course, (s)he is working in a closed environment where all resources are centrally controlled.
>> - What problem are we really solving? > > Different sized displays - from 320x200 (cell-phones and the like) > upwards... >
YMMV; but my experience is that when I'm designing a palm-top-sized display, I'll want to lay out a screen in a totally different way that I would for a desktop-/laptop-sized screen. Of course, that's just me...
> Because sometimes the same window will have different amounts of > content. Text in an area is an obvious example. It's nicer to avoid > scrolling if you can, and enlarging the window can do that in some > cases. >
That assumes that making the window larger keeps the font sizes the same. It seems to me that sometimes that would be the desired effect, but that sometimes one would like the fonts to scale up with the window. Just an observation that we have one more moving part here.
>> Although I now have to point out that you are assuming TWO new >> types: a percent! type, and a percent-pair! type. Scope creep rears
<<quoted lines omitted: 3>>
> not numbers. So adding percentage support shouldn't break any > existing scripts. (He guessed wildly:)
But IIRC the two elements of a pair are defined as integral. Having a modified pair that has non-integral elements sounds like a different data type to me. -jn-

 [76/80] from: greggirwin:mindspring at: 21-Jun-2002 12:08


Hi Carl, << Pair was added with pixel coordinates in mind I believe, hence it only accepts integers, not numbers. So adding percentage support shouldn't break any existing scripts. (He guessed wildly:) >> As a side note, pairs don't allow you to use a separator, like regular integers so there may be more to these lexical limits than we think.
>> p: 100x100
== 100x100
>> p: 1'000x1'000
** Syntax Error: Invalid pair -- 1'000x1'000 ** Near: (line 1) p: 1'000x1'000 --Gregg

 [77/80] from: greggirwin:mindspring at: 21-Jun-2002 12:44


<< Yow! Any programmer who would make such an assumption (or assume that everybody is running a particular browser, or has millions of colors, or a 1.2 GHz processor, or ...) needs some professional experience...>> True, but I'd bet money there are a *lot* of developers out there, even good ones, that design and test on a single machine. I know I've seen a fair amount of software that had quite obviously never been tested on more than a single configuration. View has a great 24 bit compositing engine built in, but I can tell you that gradients can look pretty darn ugly at low color depths. The common "out" is to define "minimum system requirements". My experience is that product managers (excluding, perhaps, large horizontal market apps) will gladly put that kind of disclaimer out there to save time and effort. << YMMV; but my experience is that when I'm designing a palm-top-sized display, I'll want to lay out a screen in a totally different way that I would for a desktop-/laptop-sized screen. >> That assumes you know where your app is running. :) Historically, this would be true because you would have to port your app to those platforms. So, I guess another question is: Should we continue down the path of platform-specific designs or try to create cross platform UIs? Lots of gray areas in there as I see it. I think it will depend on the app and the platforms it runs on. << That assumes that making the window larger keeps the font sizes the same. It seems to me that sometimes that would be the desired effect, but that sometimes one would like the fonts to scale up with the window. Just an observation that we have one more moving part here. >> Resizing and scaling are two completely distinct features/behaviors. Scaling implies that *everything* scales uniformly. Mixing the two behaviors is a design error IMO. --Gregg

 [78/80] from: joel:neely:fedex at: 21-Jun-2002 17:34


Hi, Gregg, Noooooo!!!! Gregg Irwin wrote:
> << YMMV; but my experience is that when I'm designing a palm-top-sized > display, I'll want to lay out a screen in a totally different way that
<<quoted lines omitted: 3>>
> guess another question is: Should we continue down the path of > platform-specific designs or try to create cross platform UIs?
My choice of wording was deliberate: ... a palm-top-SIZED display ... desktop-/laptop-SIZED screen ... I did not say I wanted to know where my app was running, but was talking about the design characteristics of the user interface vis-a-vis the SIZE of the current display environment. Having designed apps that would run on very small and very large screen sizes, I have seen many cases in which I do not believe that the same widget layout could be scaled sucessfully from 240 pixels wide up to 1024 or 1600 pixels wide. I suggest that the program should be able to inquire of its current execution environment for the dimensions of the current display, and then select a layout (or chioce of layouts) that the application, workflow, or GUI designer(s) have prepared for displays in that range.
> << That assumes that making the window larger keeps the font sizes the same. > It seems to me that sometimes that would be the desired effect, but that
<<quoted lines omitted: 3>>
> implies that *everything* scales uniformly. Mixing the two behaviors is a > design error IMO.
I simply meant that there's a need for both, although often under different circumstances (but not always). For example: - I often use a particular 3270 emulator that knows that it can only display 25x80 characters, so when the window is stretched the fonts scale proportionately. - I was recently giving a presentation in a large room using a video projector on my laptop. I popped up a terminal window to one of our hosts to show ... something or other. I normally use fairly small font sizes to allow me to have as much content as possible on my screen, but the audience had trouble reading the window. I wanted both the window and the fonts to enlarge. - Sometimes when I enlarge a terminal window its because I want more lines (or wider lines, or both), but in this scenario I want everything zoomed up. Also, sometimes (e.g. when my eyes are tired) I'll enlarge a term window and the fonts so I can lean back in my chair and look at the screen for a while from a longer distance than usual. Having both as choices to be exercised appropriately is A Good Thing IMHO. -jn-

 [79/80] from: carl:cybercraft at: 23-Jun-2002 23:09


On 22-Jun-02, Joel Neely wrote:
> On Thursday, June 20, 2002, at 10:02 PM, Carl Read wrote: >>> - Why do windows need to be scalable?
<<quoted lines omitted: 6>>
> experience (unless, of course, (s)he is working in a closed > environment where all resources are centrally controlled.
Well, I've seen plenty of View scripts with windows that won't fit on an 800x600 screen, never mind smaller ones... (:
>>> - What problem are we really solving? >> >> Different sized displays - from 320x200 (cell-phones and the like) >> upwards... > YMMV;
That one I don't know. (:
> but my experience is that when I'm designing a palm-top-sized > display, I'll want to lay out a screen in a totally different way > that I would for a desktop-/laptop-sized screen. > Of course, that's just me...
I wouldn't think so. Whether we're talking scaling or resizing a window, it is a problem that needs to be addressed. However, bigger screens are usually used for having more windows open, not more stuff in a window. Gadgets seem to be a big waster of window space. (He says, just thinking out aloud...)
>> Because sometimes the same window will have different amounts of >> content. Text in an area is an obvious example. It's nicer to avoid >> scrolling if you can, and enlarging the window can do that in some >> cases. > That assumes that making the window larger keeps the font sizes the > same.
Yes, resizing, not scaling.
> It seems to me that sometimes that would be the desired effect, but > that sometimes one would like the fonts to scale up with the window. > Just an observation that we have one more moving part here.
I agree that it's desirable to both resize and scale windows. It could be made simple and intuitive for the user too. Resize by dragging on the windows' edges or corners as we're used to now, (and which is done outside of a View window anyway - we just have to watch for a resize event), and scale by clicking on "+" or "-" buttons, (just a suggestion for how it could be done), which would need to be part of our layouts. If RT do add scaling to View, then to get that working would be trivial. I suspect fonts are the big problem with getting scaling to work though. -- Carl Read

 [80/80] from: joel:neely:fedex at: 23-Jun-2002 21:38


Hi, Carl, Carl Read wrote:
> > YMMV; > > That one I don't know. (: >
Your Mileage May Vary (mine usually does... ;-) -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 ]

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted