Tuples - Was Pair! thread

== false seems reasonable to me, but then again so do Joels arguments / logic, saying pair! are only meant to be used strictly in a Rebol/View pixel co-ordinate context seems like a cop out to me, either that or insufficient thought goes into REBOL language design & implementation, which is it Holger? Mark Dickson

Hmm.. nice piece of flamebait. -jeff

Aside from the generic argument that all built-in types should (IMHO) be allowed to participate in the widest possible range of primitive operations, consider the fact that tuples can be used to represent a wide range of concepts based on a small ordered sequence of small integers: section numbers (e.g., in a document) and IP addresses are the first two that come to mind. Simple lexical/dictionary order (compare first, second, etc. parts until order is established or equality is demonstrated by hitting the end of both simultaneously) serves nicely as an ordering for both of those. E.g., determining whether the IP address of a box lies within some assigned range of addresses requires that tested address be at least the low end of the range and at most the high end of the range. The fact that I can also use tuples to represent other concepts with quite different semantics doesn't change this fact; it simply means that I would need to raise my level of thinking above the "raw" data type level if I'm using tuples to represent one of those concepts. For example, tuples can also be used to represent colors -- for which there are a variety of useful orderings: lighter-than? darker-than? more-saturated-than? and so forth. But if that's what I'm doing with tuples, then I need to be thinking at that level and implementing those tests appropriately (or using code kindly provided by someone else who figured out how to do so and saved me the trouble).

NO! I think it is quite possible for persons of good will to have different views/priorities and to discuss those differences (even quite enthusiastically! ;-) without resorting to real or implied accusations of unprofessionalism. I freely admit to leaning strongly in the purist/perfectionist direction. However, I've done enough production software development to understand completely that highly competent developers who have specific practical goals, schedules, and various other considerations, may very well come to different conclusions than I might, and for totally wholesome reasons. My questions about ordering of pairs were stimulated by a confusing error message (which Holger quite readily agreed was not the best possible phrasing), but I continued the exchanges in the hopes of providing rationale for RT to reconsider the present state of the language WHEN THEY HAVE TIME TO DO SO, IF THEY EVER DO. And if they never do so, or (as has happened before on this list) RT considers a discussion and declines to accept an offered suggestion, that's OK too! Persons of good will can disagree and still continue to work together. I might also point out that -- over the years -- RT has been VERY GOOD about accepting discussion and suggestions from the folks on this list and acting on many of those to the mutual benefit (I hope) of REBOL, RT, and the REBOL community. I appreciate the attitude and track record of RT in this regard very much. I would like to think that we (list members) can use this list as a forum for discussions with each other and RT to try to understand (and occasionally make suggestions with the goal of improvement) this language that we all enjoy using. However, if my questions/discussion regarding language features are used as the basis for uncharitable accusations about the very folks that support this list and this community, I'll either keep my thoughts to myself or communicate offline with RT. -jn- -- ; sub REBOL {}; sub head ($) {@_[0]} REBOL [] # despam: func [e] [replace replace/all e ":" "." "#" "@"] ; sub despam {my ($e) = @_; $e =~ tr/:#/.@/; return "\n$e"} print head reverse despam "moc:xedef#yleen:leoj" ;

So have I.

I'd say neither, though it wouldn't surprise me if Holger thought his comments regarding View and pair! could've been better put, or at least more fully explained. (I wonder if you do regarding the above?) But anyway, let's rephase your first question: Is there any reason then why comparators shouldn't work with tuples? I'd think not, but with pairs there is a reason, in that it could be confusing. Tuples have a few common uses - as RGBs, version numbers, net-addresses and such, but they don't favour any of them (as far as I know). Pairs though do favour 2 dimensional coordinates and sizes as apposed to other uses of them, hence their x and y refinements. Given that, what should a pair comparison compare? Size? As in the area of two pairs? Well no, as we can at least check if two pairs are equal, and it says 3x2 isn't equal to 2x3. (No doubt someone's already pointed this out.) Coordinates? As in the distance from 0x0? Well, perhaps, even though I'd guess you're more likely to want to compare a coordinate with a point other than 0x0 most of the time. This would be useful sometimes, anyway. Or should it be treated like a series? I'd say no, as even if I needed a series of just two numbers, I don't think I'd choose a pair for the job. (How many of you have used pairs for other than coords or sizes?) My point here is that comparing pairs as if they were series is the least intuitive and probably the least likely use for comparing them, which to my mind is a good reason not to allow it. If pairs are to be compared then it should be as coordinates, as I think this is what you'd expect a comparison of pairs to be doing. All things considered though, it's quite easy to see why RT thought comparing pairs is confusing and decided not to support it. -- Carl Read

The primitive operators '>, '=, and '< have very clear and unambigous meanings when applied to scalar values. Neither pairs nor tuples are scalar. That being said, I'd love to be able to sort colors. Imagine picking one of the recognized color solids, taking slices through it and sorting based on the slice that a color is a part of. Since there are several color solids, and many ways to slice them, perhaps the REBOLish solution would be to use the system object to explicitly specify which solid and through which axis one is slicing.

Doh! Coords are the same as sizes, in that points can be the same distance from 0x0 but not equal. (:

Couldn't have put it better myself. (; -- Carl Read

That may be fine for some software, but it isn't for a cross-platform, cross-Internet language. You can be sure that once people started rolling their own REBOLs the Net would fill up with scripts that weren't compatible with your version of REBOL.

-- Carl Read

I was talking about REBOL scripts, not Net protocols. Let's say you got your wish and REBOL was open-sourced and some here gave their REBOLs the ability to compare pairs for lesser and greater. Now, what's to stop them puting scripts on the Net that require those comparisons? It's a recipe for a mess. Like HTML and Javascript are a mess. When HTML and Javascript are updated, are all browsers updated at the same time? No, because they're produced by a wide range of competing factions. With REBOL we're currently avoiding that kind of mess and yet still getting it on a very wide range of platforms. I wish REBOL did everything I wanted too, but open-sourcing it would stop it doing what's most important, and that's being compatible across platforms. -- Carl Read

The history of the open source movement doesn't bear this out. Instead of sending the impassioned pages of deathless prose that I was first inspired to write ;-) I'll simply point out that some of the most important languages and tools, and IMHO one of the most significant developments in operating systems in many years, are all open source. Perl, Python, Ruby, gcc, Linux, GIMP, gawk, gnu-make, emacs, vim, gtk, Gnome, Apache, ... Far from destroying these languages and tools, the availability of source has caused them to be ported to far more platforms than the inventors ever would have been achieve to do on their own, and debugged far more rapidly. Most of these use some combination of respected-leader-guidance, delegated-responsibility-network, and marketplace/democratic let-people-try-it-and-see-what-wins strategies to effect the evolution and maintenance of the software. Do people try out different, unorthodox, and even hairball ideas? Absolutely! But the open source community does a good job of distinguishing experimental/unstable/work-in-process releases/branches from stable versions that represent the collected wisdom, preferences, and QA of hundreds, thousands, or tens of thousands of eyeballs and brains. Serious developers also know -- assuming they want their work to be accessible to the widest range of users -- that they should be cautious about depending on uncommon features, libraries, etc. The wild-eyed crazies who go off in random directions trying to make their pet version of emacs scriptable in VisualIntercal++ are free to do so, but their gibberish isn't taken seriously. Unless, of course, it's really good, in which case it will gain enough of a following that it will begin to influence the addition of capabilities to the "official" version. But people still know which is which. That's called massively-parallel progress. On the other hand, the very nature of highly-extensible languages such as FORTH, Smalltalk, and REBOL tends to work in *exactly* the direction you feared. How many people on this list have a library (or two, ...) of their own favorite tweaks and functions and then write new code based on those extensions? How many experienced REBOL users have customized their user.r files? How many times have we seen: - A bug reported and someone responding with a fix of the form "here's a rewrite of that function; put this in user.r" ? - A posted script, followed by a post that says "It doesn't work on my box", followed by a post that says "Ooops, here's my foo.r" or "Go get so-and-so's quux.r"? and so on. Open source doesn't create such problems; it actually helps alleviate them because it's a more efficient mechanism for fast-cycling both the bug finding/fixing process and the rate of scrutinizing (and then adopting or rejecting) potentially useful new ideas. I truly believe that open source works, and is in the long-term best interests of the advancement of our art. Consider where we would be without a modern educational system, which is founded on the notion that one achieves value to society by creating new ideas (or new ways to express useful ideas) ang giving them away as rapidly and enthusiastically as possible. Consider the fact that students of architecture can learn their field by going and looking at all of the details of the design and construction of great buildings. Even in the failure of specific projects, there is value in openness. What if the design of the Tacoma Narrows bridge had been kept secret? How many more bridges might have collapsed (and with what potential loss of property and life) if the next generation of engineers had been prohibited from seeing both the design and construction of Galloping Gertie? All of that said (and aren't you glad I shortened it ;-) , I am a firm believer in the right of a creator to determine the fate of his creation. REBOL is Carl's baby, and he (alone!) has the moral right to decide whether he will make it available via open source or whether he wishes to keep it closed. Likewise, prospective users of REBOL (or any other tool) have the right to make their choices: either to invest their time and energy in a language that they know in advance is not an open source project, or to take themselves and their time and energy elsewhere. Either way, all parties should respect the rights and decisions of the others. -jn- -- ; sub REBOL {}; sub head ($) {@_[0]} REBOL [] # despam: func [e] [replace replace/all e ":" "." "#" "@"] ; sub despam {my ($e) = @_; $e =~ tr/:#/.@/; return "\n$e"} print head reverse despam "moc:xedef#yleen:leoj" ;

protocols or whatever for REBOL or any other internet messaging & communications system.

whole internet wouldn't function.

and tru they are not as natural & inbuilt or as easy to use as REBOL's however surely your not trying to say that because these languages are open source that they are not suitable for multiplatform

functionality regardless of whether your working in REBOL, Perl, Python, JAVA or Microsoft DotNet.

specifications & messaging standards

the agreed minimum standard.

Python or REBOL?

languages all the time. I love REBOL and it's potential but i think it's losing the battle to become mainstream and part of the reason for that I believe is it's closed proprietary nature.

Absolutely nothing. Except their own good sense and wish to have other people actually USE their scripts. (And my earlier post touches on the point that variations of this sort are *already* happening WRT various libraries that people base subsequent code on.) Why do we have to make the assumption that programmers must have a centralized, absolute control "to stop them" from destroying the universe?

I must disagree. Let's use me as an example. A few months back we had a discussion of zero-origin vs one-origin WRT blocks. There is absolutely nothing *currently* preventing me from writing my own custom definitions of AT , PICK , POKE , INDEX? etc. that use zero-origin design, putting those definitions in my user.r file, then writing code that depends critically on that choice of origin. And then posting that code to the list. Actually that's not correct. There's no *external*authority* telling me that I can't do so, but I am restrained by my own sense of ethics and my desire to have others use my work and take it seriously. If I kept posting such code to the list, I'd run the risk of confusing newcomers to the language, and causing them to waste their time, energy, attention, enthusiasm, and interest on code that they wouldn't be able to use (and might think was their fault or representative of the state of REBOL). That would be wrong. If I kept posting such code to the list, I'd get the reputation of being "that crazy zero guy" and regular readers of the list would simply ignore anything I posted. That would be detrimental to my ability to contribute anything meaningful to the REBOL community, which would make me unhappy. However, both of those hypotheticals assumed that I failed to provide appropriate disclaimers and explanation. Anyone should have the right to post experimental or demonstration code along the lines of "Here's what we could do if we had the foo feature" as a part of a discussion of how things might be done. By the same token, anybody who isn't interested in the discussion of the foo feature is free to ignore such discussions. IMHO it's just a truth-in-labeling issue. Let's not forget that Freedom of Speech is A Good Thing, but it also implies the equally important Freedom Not To Listen.

You left out the important adjective "commercial". In the dog- eat-dog mentality epitomized by The Nameless Company From Redmond, one must introduce incompatibilities in order to lock one's customers into using only one's products, to the exclusion of all alternatives. One's value is largely determined by how much one can control other people's behavior. In the marketplace-of-ideas mentality of open source (and the entire educational system, I might add), there is the freedom for vigorous debate, exploration, experimentation, and difference of opinion, but the outcome is usually convergence on what works best for the greatest number of people. One's value is largely determined by how much one can contribute that others find to be useful to their needs and circumstances. However, the number of outright geniuses that can blaze brilliant new trail and accumulate a following is an incredibly small portion of the total community (and the community usually figures out who they are fairly quickly -- massively parallel processing works!) The bulk of the community are pragmatic folks who want to get a job done. They are motivated to stay with what has been shown to work well, rather than chasing the latest fad. Therefore their work tends to be portable and re-usable. And -- if it's open to the community -- others are usually more than willing to help them make it more so. I might point out that there's another variation on this issue; in a standards-and-interoperability-driven world, much of the energy of competition goes into doing the BEST job of delivering tools that conform to the standard, so that the consumer gets to make her/his own choices within the price/performance/features space. Having a published standard for residential electrical outlets (and then letting companies do their best to produce desirable outlets and extension cords) is IMHO a far more beneficial state of affairs than requiring everyone to buy their cords from a single manufacturer. Is that a perfect solution? Probably not, for most definitions of perfection. Does it always make everyone maximally happy? No. But as one wag remarked regarding democracy, "It's the worst system possible, except for all of the alternatives!" -jn- -- ; sub REBOL {}; sub head ($) {@_[0]} REBOL [] # despam: func [e] [replace replace/all e ":" "." "#" "@"] ; sub despam {my ($e) = @_; $e =~ tr/:#/.@/; return "\n$e"} print head reverse despam "moc:xedef#yleen:leoj" ;

Let me suggest that there's not a single yardstick for "success". There are certainly some measures by which some people would call Visual Basic a "success". There are certainly different measures by which Perl is considered a "success". An open marketplace allows the consumer to use her/his own criteria to select the product(s) that meet her/his needs, rather than forcing all consumers to live with the criteria of a single authority. I consider that to be a system-level "success". It will be interesting for us to look back in ten years and see whether there are still languages called "Perl" and "Visual Basic" being widely used, and -- if so -- what resemblance they bear to the artifacts of those same names in 2002. But even long-term viability of a label is only one measure of success. Almost nobody uses Algol for serious development any more, but it placed a number of crucial computing concepts into play which are fundamental to current programming practice, thus earning for its creators significant standing in the history of computer programming. Almost nobody remembers the name of the leading wool merchant in London during the late 1660's, but almost every educated person around the planet knows of, and benefits from the work of, Sir Isaac Newton. How's that for success? -jn- -- ; sub REBOL {}; sub head ($) {@_[0]} REBOL [] # despam: func [e] [replace replace/all e ":" "." "#" "@"] ; sub despam {my ($e) = @_; $e =~ tr/:#/.@/; return "\n$e"} print head reverse despam "moc:xedef#yleen:leoj" ;

all the time. I love REBOL and it's potential but i think it's losing the battle to become mainstream and part of the reason for that I believe is it's closed proprietary nature. I'm not sure this is the goal of RT in this moment. Are you? If this is the goal, from my point of view, RT has already been defeated. --- Ciao Romano

and developers that the market for REBOL products, be this interpreters, applications, books, tutorials, websites etc. becomes more active and self enforcing.

IT emplyment opprotunities etc. is enough to show you that REBOL isn't barely noticeable even in relation to other new small time languages like Ruby.

even Lisp / Scheme / ML / Haskell have a more noticeable profile than REBOL and this hasn't changed much since 1998 when I first encountered REBOL.

books came out, but nothing since then. At my local bookstore these two REBOL titles have sat in the clearance shelfs at bargain basement prices and still nobody buys them.

vacancies etc happen for these other languages every other day / week / month. RT inc are doing a great job in advancing REBOL but they are a very small in terms of manpower and there is only so much they can do with the resources they have, that is why they could be considered a bottleneck as virtually everything major in relation to REBOL has to happen through them.

ever taking off as a technology unless RT Inc are bought out by one of the industry giants who would then hopefully promote REBOL and give it a higher level of visibility and commit greater resources to it. None of these scenarios is by any means a certainty.

multifaceted aspects of REBOL

greater choice & growth of REBOL as a technology.

Romano Paolo Tenca <[rotenca--telvia--it]> writes:

developers that the market for REBOL products, be this interpreters, applications, books, tutorials, websites etc. becomes more active and self enforcing. Yes, I understand, and agree. But I'm not more sure that RT, in this exact moment, is working to arrive to this goal with Rebol. In this moment, and for now, i do not think that RT hope to gain "success" with Rebol. It was true some months ago, but now i feel that IOS is their main product. And IOS is a proprietary solution for small-middle-big companies who want to use the net for inner/outer connectivity. Rebol is the internal powerful language of this solution. It could be a necessary step, which permit at RT to find a solid base to start new projects (or remember the old ones). The only new about Rebol in these months is the Morpheus history (and Holger unofficial announce on new effect pipeline in this mailing). No new doc, no new how-to, no reference, no release date for new versions of Rebol, no visibility of future.

ever taking off as a technology unless RT Inc are bought out by one of the industry giants who would then hopefully promote REBOL and give it a higher level of visibility and commit greater resources to it. None of these scenarios is by any means a certainty. I think that RT hope to follow another strategy. From the faq of IOS: Is IOS free or commercial? IOS is an important part of our business strategy. We've given away more than a million copies of REBOL software over the last four years, but IOS is our commercial software. How to say: IOS is the way we make money, our main project. RT is becoming a service society, like IBM, hopefully like Sun. If Rebol could gain some success depends by the commercial success of IOS: more IOS systems, more Rebol programmers, more Rebol docs, more Rebol tools, visibility and so on. Today nobody (only Microsoft) can hope (without to dream) to break the market with a proprietary scheme like the Rebol's one, not when alternativies are free and not so bad, like Perl, Python, Ruby... But perhaps this can achieved when the product is something like IOS. It is a hope, not more, at least for me. I have already seen many excellent projects to go in the no man's land these years, to believe that the market always rewards the best ones (or its best idea is not mine).

multifaceted aspects of REBOL

choice & growth of REBOL as a technology. Adopt now Rebol IOS and hope. Market rulez! :-) --- Ciao Romano

There's no question that hardware advances have GREATLY outpaced our grasp on treating programming as a scientific discipline.

I'd nominate your countryman, Edsger W. Dijkstra, and an Oxfordian, C.A.R. Hoare, as two candidates for that role. Unfortunately, I am convinced that the true value of their work will not be recognized until many more years pass. Wasn't it Paul Dirac who was asked "When will quantum mechanics be the standard model in Physics?" and replied When all the old physicists die! ? ;-) -jn-

If I remember the last upgrade correctly, they either nearly all or were all upgraded together. As an Amiga user I noticed this, as the Amiga version nearly always had been the last to be upgraded. Whatever, they were getting better and better at the upgrades in my opinion, and currently all Core and all View versions are at the same version numbers. Can you show me an open-source project on a similar number of platforms where that is the case? Where all versions are at the same version numbers /across platforms?/

True. How would open-sourcing REBOL stop that from happening?

True, and the most up-to-date Cores and Views are available to all that want them on the platforms RT supports. Do you think that's the same with browsers within platforms, never mind across them?

So ignore trying for the ideal? I think there's general agreement that Core and View being seperate is a good idea, and in an evolving language, breaking some older scripts is inevitable as it's improved. (Unless that not happening is part of the languages design, which I think is in Perls's case.)

Gosh. Just think, if they did RT wouldn't even have had to write 2.5! They sure got it wrong there, eh?

I wouldn't say RT's shooting for the lowest common denominator. If they were, they'd be trying to use the GUIs that came with the OSs they're targeting. But they're not - they've designed their own GUI, which will allow them (and us) to have the GUIs of our desires, windows use excepted. -- Carl Read

Yes.

Pah - you just broke it up into two emails. (;

Firstly, I'm talking specifically about cross-platform, cross-Internet languages. (See above.) How many of those with GUI support can you name that can run programs without modification across as wide a platform base as REBOL does? That you can do the likes of this with... do http://www.wherever.com/a-view-script.r and have in most cases no problems with it?

Okay, let's assume REBOL's open-sourced. Now, it seems there's good reasons why RT hasn't put it on Palm, but being open-sourced, no doubt someone would try to port it to Palm anyway. Now, let's also assume they partially succeed, in that they get a version that sort of works, though it's restricted in what scripts it can run, and it doesn't function quite like REBOL should, so we're talking not just about a subset of REBOL, but a modified version. (ie, RT is right in that a real port isn't possible.) This they release as despite its flaws they think it'll be useful. If this became popular on Palms, you'd then get OS-specific scripts of REBOL appearing, thus defeating the cross-platform ideal.

Yes, but the fixes are in REBOL, not C, and don't require you to recompile your REBOL for them to work. These are just basic oversights and no different than forgetting to upload pic9.png and the like.

I'm not criticising open-source in general, just the belief that it's a good idea for a language where you want the programs to run on as many OSs as possible without modification.

Well said. And I do know the risk involved in puting my time and effort into a language that isn't open and which may go in directions I don't like. I consider REBOL's worth that risk.

-- Carl Read

The assumption is based on experience, the experience being that the OS that's dominant will be where cross-platform software gets mostly tested and if it's found to run on that then it's assumed it'll be okay for everywhere else - or if it proves not to be, it's elsewhere where the problem lies. Good central control can almost make that second assumption true. Don't forget that one day a large percentage of the "programmers" of REBOL could be of the amateur web-designer type who now hand-code their own HTML. REBOL might be the only programming they've ever done, (they of course starting with VID), and if their scripts work for them, that'll be good enough for them to place their scripts on the Net. REBOL's very like HTML in my opinion, (why else do we have a "reb"?), and I'd hate to see it go through some form of browser war. "At least the bugs are cross-platform" is a comment one of my REBOL scripts received. I want it to stay that way. (Big snip of the rest of Joel's comments - but all read. Oh, and the wag was Winston Churchill, Joel.) -- Carl Read