Home   Archive   Permalink

why does the Rebol 'either' function misbehave

R E B O L [Testing script]
     either date? 2015-22-01 [
         print 'is a date'][
         print 'is not a date'
The purpose of the test is to determine the validity of a date. But the either function only works properly when a valid date is presented (it prints 'is a date' as expected). When an invalid date is presented Rebol throws a date syntax error instead of printing 'is not a date'. That's not appropriate, what's going on ??

posted by:   John Dutcher     7-Jan-2016/8:02:08-8:00

I see the same issue with the 'if' function when applied to a date; what value is a date test (date?) if it blows up when it isn't given a valid one ???

posted by:   John Dutcher     7-Jan-2016/8:30:18-8:00

Hi, first of all, you should use double quotes for strings. Second, Rebol checks script syntax before evaluating it. If your script does not have a valid syntax, you are out of luck evaluating it, meaning that the EITHER function is not called at all. This is a valid syntax example, and it does print what you expect:
     print either date? 1 [
         "is a date"
     ] [
         "is not a date"

posted by:   Ladislav     7-Jan-2016/8:36:35-8:00

Values in Rebol programs are checked to be valid when they are first loaded. Rebol automatically checks that you have correctly entered a date before your date? check is run. Only valid dates can be loaded.
You can get around this by entering your date as a string, trying to convert the string to a date and then checking if it is a date.
Like this:
>> date? attempt [to date! "2015-22-01"]
== false
>> date? attempt [to date! "2015-01-22"]
== true

posted by:   Peter W A Wood     7-Jan-2016/8:36:49-8:00

Perfect !! much obliged for the education !!

posted by:   John Dutcher     7-Jan-2016/8:51:38-8:00

Another, less trivial example letting the user to type whatever she likes and detecting whether it is a valid date:
     input: ask "type a date, please: "
     print case [
         error? try [set/any 'input load input] [
             "invalid syntax"
        date? get/any 'input [
            "a date"
        'else [
            "not a date"

posted by:   Ladislav     7-Jan-2016/9:05:39-8:00

Nick (because I don't know who better to address this to) I (and I suspect others) would benefit from a tutorial on "Gotcha!"s. You know: REBOL things that are most likely to cause frustration or simply "F^)# Rebol!" moments for the average new programmer. IMO, REBOL has a disproportionate number of these sorts of things...I'd guess 5-10 times as many as "most" languages. These things to NOT portray REBOL in the best light, but Rebol is what it is...so pretending that Rebol doesn't have a LOT of these sorts of perverse aspects (whatever their internal logic once you become a guru) doesn't IMO serve the community well. I think this is one example of a "gotcha" which an average-brained new recruit could easily spend hours tearing his/her hair out about. You've done a lot of tutorials which show how easily some things can be done in Rebol. I actually think it would be a positive to have at least one tutorial on the most common "gotchas".

posted by:   stever     28-Jan-2016/21:25:33-8:00

At this point, it's difficult for me to intuitively understand what may be perceived as unnatural "gotchas". Perhaps a sticky topic collecting submitted troublesome quirks would be a useful resource. I'll start it, and hopefully we'll get some input.

posted by:   Nick     29-Jan-2016/10:58:32-8:00

Yes. I can see that problem; a little of that is actually starting to happen to me...believe it or not :-/, If you've seen a newbie question 2-3 times it is likely a reasonable candidate. Anyway, thanks for the sticky. Let's see what accumulates. I will try and support it.

posted by:   stever     29-Jan-2016/20:51:11-8:00

I think this is absolutely a GOTCHA.
The date standard in the US, at least, for Jan 22, 2016 is 1/22/16. And the best rebol can do is vomit:
>> date? 1/22/16
** Syntax Error: Invalid date -- 1/22/16
** Near: (line 1) date? 1/22/16
It actually took me about five minutes of searching on startpage to get to this rather pathetic explanation on http://rebol.com/docs/core23/rebolcore-16.html#section-3.2:
"3.2.2 Format
"The REBOL language is flexible, allowing date! datatypes to be expressed in a variety of formats. For example, the first day of March can be expressed in any of the following formats:
probe 1/3/1999
probe 1+++1999
probe 1999+++1 ;ISO format
I don't think that is good enough. I don't think it is within a million miles of good enough if we really want rebol to see widespread adoption. Last I checked 1/22/16 was THE US standard for shorthand date formatting of Jan 22, 2016.

posted by:   stever     31-Jan-2016/13:21:47-8:00

"At this point, it's difficult for me to intuitively understand what may be perceived as unnatural "gotchas"."
That is an interesting comment. I wonder if there aren't some things such that, if you asked Carl, "Can REBOL do X?" his reaction might be something like, "Well, no. Who in their right mind would ever want to do that?"
I think that for those who have absorbed REBOL, or maybe any technology, the mind of a beginner is a thing of mystery. I have had past experiences, long ago, of people explaining things to me in a way that suggested they were absolutely amazed that I couldn't understand their explanations.
Maybe REBOL Technologies needs, in addition to that evangelist, and maybe a marketing manager, a "resident beginner."

posted by:   Steven White     1-Feb-2016/20:39:49-8:00

In order to use rebol's value system, programmers need to adopt the right format, and sometimes for beginners that's less than perfect or intuitive.
Since the beginning of rebol, I've only ever used the international date format, e.g., 1-Jan-2016, and avoided the US-centric notation. As a result, I've never had a problem with dates.
There are a handful of rebol values with formatting requirements-- i.e., things which are necessary for platform independence or to follow a unix-centric standard, etc. If values were implemented for units of measurement, I would expect rebol to embrace the international standard over the US one there as well.

posted by:   Edoc     2-Feb-2016/9:12:18-8:00

Ednoc, That meets my definition of insanity: Flip the bird at the LOCAL users in ***THE*** dominant market (or whatever market you absolutely MUST satisfy in order to succeed) adapt themselves to a to a uncommon, non-local standard. Oh, yeah! And HIDE what you have done...but crow and strut, deep in the bowels of the hidden programmers documentation where the end-users will never find it, how "flexible" your tool is! Hahahahahaha!!!

posted by:   stever     2-Feb-2016/10:40:07-8:00

That is a good point. Some have suggested (http://redprogramming.com/Rebol%20Business%20Programming.html#section-4) that a person shouldn't have to be a professional programmer with knowledge of lots of programming languages to make his/her computer do useful things. To that end, a person shouldn't have to beat his head too hard on something that intuitively seems like it should be simple.    
Maybe we need a library of functions for "data processing" in REBOL. If you want an enhanced GUI, you use rebgui.r, as an example. If you want to do "data processing," we have a library for that also. On the other hand, others have suggested that REBOL is powerful enough that it is easy enough to do those things on demand, so why bother to make something general-purpose.
Getting off topic...must think about this "off-line" as they say...might have to read all of Nick's 800-page book...

posted by:   Steven White     2-Feb-2016/11:50:52-8:00

I don't want to keep pounding on the date function, specifically, but I notice I haven't given a solution yet. I'm going to give several:
(a) Allow local user definitions so 1/2/16 means 2nd of January in the US but can mean 1st of Feb in Europe. (b) date-us AND date-international functions (c) date/us and date/international (d) MAKE THE ERROR CODE A *LOT* MORE HELPFUL and explicit in general (e) make the interpreter's "? date" (and other) functions a LOT more helpful with more examples and, ideally, a lot more specificity ... maybe a link to complete docs. (f) it seems to me that literally ANYTHING can and will blow up sometimes. So instead of suggesting "attempt" and "try" everywhere, how about making error trapping a given and let the programmer explicitly code for how to handle that...including recovery but also including a VARIABLE dump showing, exactly, what the interpreter THINKS is in the variable. (g) stop the automatic type conversion by default - make type conversions specific by default or have the interpreter evaluate the entire program at load time and identify such "leaky" spots where bugs are basically inevitable (haskell is a model here...for all languages to aspire to). (h) Help Nick put up a new tutorial on ALL the common "Gotchas"! :-)

posted by:   stever     2-Feb-2016/17:05:44-8:00

My experience is similar to that of Edoc. Dates haven't posed any problems for me or my users. In UIs, users tend to use a date picker, which bypasses the internal format. And when dates are printed by Rebol, they're displayed with the 3 letter month spelling in the middle, so there's no lack of clarity for users. When parsing dates from data sources which use other formats, the solution is typically trivially simple. A couple months ago I wrote a function for Steve (2 lines of code): http://rebolforum.com/index.cgi?f=printtopic&permalink=Steven%20White30-Oct-2015/11:10:45-7:00&archiveflag=new
Still, when any decision is made about anything in systems like this, it's a problem for a percentage of the users. Perhaps Carl didn't know who his user base would ultimately be - was it so wrong to have the foresight to consider that it may not be just the US, but all the world? Did you know, as it turns out, that the biggest user base for Rebol has actually been in France?
If it's still a problem for some in Red, the change can be made trivially. Perhaps a compiler flag can be added for 'dateformat. The nice thing about Red is that it's Rebol code, all the way down, so changes will be even easier for us users to make, and the code base is even easier to understand than in systems which are built in C. We can all hack changes which we need, and set preferences according to our own priorities.
I think communication and discussion about everyone's priorities is essential, but eventually the person in charge of a project needs to make a decision he thinks will benefit the greatest number of people, and work best in the overall design of the project. Some portion of the user base, perhaps even a significant percent, will disagree with any decision which is made. Luckily, Doc has made the licence choice easy to work with, and we are all enabled and free to make changes as we desire, in our own systems.
BTW, just yesterday I renewed my passport, and that US government web site used the same format as Rebol to display dates. I don't think it's such the definition of insanity which needs to be worried about so critically.

posted by:   Nick     3-Feb-2016/8:56:39-8:00

One of my favorite sayings (and one I need to review from time to time is "Which do you prefer: Pleasing habits or pleasing results?"
Personally, I have a bad habit of being too strident when I make on line posts. I am a lot more easy going in person, although not perfect. So please forgive my tone, Nick. If it means anything, if I didn't care (didn't want to make a positive contribution) I wouldn't say anything at all...I'd just go to another language/topic.
But I ALSO think that quote is something the Rebol community should take to heart. IN SPITE of being revolutionary in a good way, Rebol failed. We can say it just didn't get a chance or that it didn't have enough marketing muscle or money or whatever, but I think the truth is closer to: A really high percent of those who tried Rebol concluded that its gains weren't worth its pains. I see huge potential in Rebol or I wouldn't be hanging around and making suggestions; in particular I see RED as the opportunity for the community to evidence that they learned from their mistakes/shortcomings and are going to demonstrate they learned something...by doing some things differently.
International date standard is widespread, no doubt about it: https://en.wikipedia.org/wiki/Date_format_by_country
Note, however, that in FORCING IDS down the throat of people (instead of being flexible as we KNOW rebol COULD be) you are sacrificing acceptance in BOTH the US AND CHINA...the 1st and 2nd biggest economies. Not just the programmers of those countries but actually the consumer populations. Now is that smart when the rebol language could EASILY have been set up to accomodate all date entry formats?
On this site you got someone expressing their frustration over their code not getting a useful acceptance nor a useful error message. Instead of noting that MAYBE that would be a good thing to ameliorate going forward the response from the Rebol Gods was ... what exactly?
The Rebol community's graciousness is possibly Rebol's greatest asset. The Rebol community's "my way or the highway" (Rebol is perfect...we just need to get the 330 million people of the US and the many billions in China to acknowledge they are wrong and change all their habits and existing databases) is probably it's greatest challenge.

posted by:   stever     3-Feb-2016/23:06:38-8:00

I don't have any problem with what you've proposed, for Red. As I suggested, perhaps a simple flag could be added to indicate which date format to use by default. Everything you've suggested makes sense for Red, and I think you should make those suggestions to Doc. Also, as I've suggested, you can even implement the changes you prefer yourself, and submit a pull request. Doc seems to be listening carefully to the community. You'd certainly do better to write some working code, than to write prose here on this site. It would be more effective to communicate about Red at https://gitter.im/red/red - Doc is actively taking part there every day. He's the one to convince, not me.
I appreciate your input, and I apologize if my response came across in any way as dismissive. It's not meant that way. I'm taking a lot of time and effort to communicate here. It's just that we have no way of changing R2, as a community. Carl's reasons for setting the date format were made back in the 1990's, at a time when I'm sure he was anticipating taking over the world with Rebol. Once set, that became Rebol's standard. It was a reasonable choice at that point, and I haven't heard many loud complaints from the community about it. Those which I have heard had trivial solutions which posed no problem whatsoever. I have no reason to defend Carl's choice as right or wrong. I'm just sharing my perspective, that in use, it hasn't been a problem for me, so for any practical purpose, it's just one of those things for which I have no strong preference. Introducting that change to Rebol at this point would break every bit of date code written over nearly 2 decades. That's not a matter of hard headedness - just a matter of reality, which can't be ignored at this point, and which would become a REAL problem if implemented now. If it matters to you, rally the rest of the Red community and take it up with Doc. Now is the right time to take that initiative. I'd be happy to support that change if it's what the majority of the community prefers.

posted by:   Nick     4-Feb-2016/6:00:26-8:00

Thanks, Nick. Your support of rebol/red ranks right up there with Carl's and Doc's to my mind.
My hope for the "Gotcha's" is that for rebol they will ultimately form part of the "quick start" documentation (so people don't have to learn the hard way). For red I'm hoping some Gotcha's may drive change; where that isn't really possible they may drive better documentation and error reporting. Anyway, thanks for your reasoned response and all you do for all of us.
I suggest that when new-comers post questions here the questions be considered as VALUABLE feedback, especially to the degree that the newcomer appears reasonable and intelligent. People that don't care don't typically waste their time either questioning nor giving feedback. In my business, we encourage the position that we are LUCKY to have customers who care enough to complain. Well defined complaints are VALUABLE feedback and give us a change to improve and, ideally, actually make the customer even more loyal.
YOU are one of those in the Rebol community who has most made me a loyal and ardent advocate of the rebol/red language.

posted by:   stever     5-Feb-2016/3:42:53-8:00

"The Rebol community's 'my way or the highway' (Rebol is perfect...we just need to get the 330 million people of the US and the many billions in China to acknowledge they are wrong and change all their habits and existing databases) is probably it's greatest challenge."
This is comical. It must be a reference to a different topic thread.
1. Someone posts a question about rebol's date value.
2. A bunch of people respond with constructive tips and feedback about said value.
3. Another person arrives to the discussion to complain about "gotchas" of the date and other values-- decisions that none of us were part of (as if it were opened up for vote at a closed-source vendor) and which took place 2 decades ago.
4. One or two people respond (paraphrasing) "Meh, it hasn't caused us significant problems; the requirements of this value are quite documented, actually."
5. The volume escalates: BUT USA!! BUT CHINA!! The community condones insanity, flipping the bird at the world, their-way-or-the-highway, thinking REBOL is beyone reproach!!
It should not need stating that the rebol community did not design the date value, and until relatively recently has not had access to the source to make rebol less disadvantaged (!!) for US and Chinese markets.
Frankly, the language has a long list of issues that could easily be prioritized ahead of an easily-worked-around format issue.
Stever I don't think there's a person here who doesn't appreciate your feedback and interest in rebol. And I also don't think you'll find a single person person in this community who doesn't think rebol is faced with many challenges and flaws. The only sentiment I disagree with here is the tone of discourse and your mischaracterization differing viewpoints.
I'm no spokesperson for the community, but if you want to entreat people to share your priorities, rhetoric, hyperbole and sarcasm are unlikely to win over converts. Your voice has been heard. That's the easy part. Rebol 3 is open-source and Red is a great viable project, please consider contributing to the source code and/or the documentation to help address the gotchas. No invitation necessary. I hope I don't sound too polite when I say that I am grateful for any constructive conversation and/or undertaking with rebol and red, stever.

posted by:   Edoc     7-Feb-2016/8:51:05-8:00

Hi Ednoc,    
In all honesty, thanks for the feedback. I would be interested in seeing your long list of issues; especially if you can suggest priority and a possible improvement or two for the issue. Indeed, I think one way we can really help doc with red the most, and in process help ourselves, is by ranking "issues" and proposing a solution.
I worry a bit that with the release of red-gui the language is going to begin quickly gaining attention and momentum. With that in mind, I see some urgency to organizing and formalizing proposed changes or enhancements. By the time red 1.0 is out I would expect it to be orders of magnitude more difficult to implement any change which might "break" existing code.
I do worry about the things which trip "newbies" up and are scarcely seen by those who have been on the rebol road for many years. I do worry that those who are already very comfortable with rebol's idiosyncrasies -- especially the arbitrary ones they long ago adapted themselves to work around -- might take the "that's not a bug; that's a feature!" position. And that's they way I took the tone of your earlier post and Nick's. I apologize for apparently being mistaken.
I proposed a number of work-arounds for the date formatting issue. Any preferences or other proposals? Doc made a comment within the last few days that he was going to significantly advance the timetable for coding "time" functions. With that in mind, I think it would be nice to float a date proposal?

posted by:   stever     7-Feb-2016/21:57-8:00

BTW, I think it's evident I am very much a newbie with rebol. I believe I would have been to at least some intermediate status half a year ago or more except nearly every attempt I've made to write even "simple" starter code to ramp myself up has run into a thicket of ...for lack of a better description...gotchas. And I couldn't find documentation sufficient to move me past many of the gotchas. And the language appeared to be dying, anyway.... Anyway, Rebol is clearly remarkably productive in experienced hands. But gaining that experience can be the rub. In some regards (esp thanks to Nick) some things are amazingly easy. But then some things are amazingly difficult/inexplicable.    
I know I am not the most gifted coder, but I have done significant coding in probably a dozen languages though the years. I haven't seen any language quite like Rebol in terms of just how NON-productive the learning process appears to be...or at least is for me. In spite of which, I see the potential and I keep hanging around and ... with red... I expect I will finally, eventually, earn my "chops".

posted by:   stever     7-Feb-2016/22:27:40-8:00

Thanks for keeping it civil, stever. We are all on the same side after all.
I'm not very familiar with Red, but I'm excited to see what they are doing and I hope they can produce a great tool which is well documented, and which can attract a community.
I'm not a coder at all, I'm more of a business user who works in a corporate field (ecommerce) where rebol is very useful in helping me get stuff done. I feel like in some ways, rebol is designed for people like me-- people who need a small, personal, consistent, highly flexible language and *not* a monstrous multi-layered system of classes, modules and packages to sort through in order to produce results.
An example of the kinds of things I use rebol for: We are implementing a type-ahead search feature in our transaction site which will query Google's API when our platform has zero results. Google has 5 or 6 search APIs, each with different emphasis. I wanted to see which API would be the best fit for our needs. I first had to parse our current search logs to determine the most frequently searched keyword terms. Then I took those 500 top keywords, and then parsed the results of each Google API with the first three chars of these terms (to simulate an auto-suggest fragment) and grabbed the first 5 type-ahead results. This Google API search script required only 5 lines of code!
Maybe in the "gotchas" topic, you can let me know what kind of things you need to be able to do with rebol. That would help some of us figure out if there are some tutorials that can be written up for medium.com or elsewhere. For the exercise I described above, I already wrote a solid walkthrough for my team of reports to study.

posted by:   Edoc     8-Feb-2016/12:51:39-8:00

Chinese date format "yyyy-mm-dd" works in REBOL, so I don't understand the problem here. A default output in international date format makes sense, and it's trivial to do something like this:
rejoin [now/month "/" now/day "/" now/year]
Allowing different date formats for code and data that can be used in different countries is dangerous. Too many applications fail to work outside their country of origin - or work unreliably - because of that.
Having a formatting function to convert the date format in a localized one is fine, but code incompatibility because of local settings is a big problem. It's not only how dates are displayed, but how they are transmitted and parsed.

posted by:   Scureuil     11-Feb-2016/9:06:58-8:00