Short version: I agree with Al that now/date/time and now/time/date
(and their cousins) do appear to be slightly broken. I also whine
annoyingly about the /blah/blah/blah notation one last time.
The fact that Carl (and company) have done a great job in designing
REBOL is confirmed by the fact that what I'm whining about is such a
minor point!
Thanks, guys!
-jn-
[EMAIL PROTECTED] wrote:
>
> Elliot wrote:
[snip]
> > >> now/time/date
> > == 596523:14:07
> >
> > Reversing time and data has the same result as the last one.
> > Where does this 596523 come from?
This one looks like a legitimate bug, as I just now typed the same
expression and got the same bizarre result:
>> now
== 25-Sep-1999/9:44:06-5:00
>> now/date/time
== 596523:14:07
>> now/time/date
== 596523:14:07
If it were returning some obscure piece of data (e.g. hh:mm:ss since
epoch) I'd have expected to get a DIFFERENT bizarre result. ;-)
>
> I tried assigned 'now to 't, then did much the same:
>
> >> t: now
> == 25-Sep-1999/20:50:42+12:00
> >> t/date
> == 25-Sep-1999
> >> t/time
> == 20:50:42
> >> t/time/date
> ** Script Error: Invalid path value: date.
> ** Where: t/time/date
> >> t/date/time
> == none
>
> Except with different results.
>
> I think this is a bug. Any other opinions?
>
I think it's a combination of a bug and a misfeature. I'd call it a
bug because of the following:
>> t: now
== 25-Sep-1999/9:47:03-5:00
>> t/date
== 25-Sep-1999
>> t/time
== 9:47:03
>> t/date/time
== none
>> t/time/date
** Script Error: Invalid path value: date.
** Where: t/time/date
The fact that the last two expressions produce different results makes
me suspect buggishness. (OTOH, with my language-geek hat on, I would
observe that if an expression is formally undefined, an implementation
is free to do whatever arbitrary thing it pleases.)
Regarding its being a misfeature...
I'll whine once more (and then shut up about it) on the basis that
notational similarity should mirror conceptual similarity. (Man, that
sounded pompous... What I'm trying to say is that things that look
alike should behave alike, and v.v., and that things that don't behave
alike shouldn't look alike.) Although path traversal, searching a
series, supplying optional arguments to a function, and asking for
special-case behavior from a data object all seem to have something
in common, there are enough differences that using the same notation
for all of them seems to be a fruitful source of confusion.
For example, path traversal and series searching are inherently
open-ended. I'd expect multiple levels to be allowed by the notation,
since the underlying data may be multiple levels deep. The tricky bit
is that an expression such as
pooh/bah/yow/ick
(where pooh is a path or [nested] series) sort of leaves the impression
that / is an INFIX OPERATOR whose right-hand operand is applied to the
EXPRESSION on the left. Thus one could read the above as if it were
((pooh APPLY bah) APPLY yow) APPLY ick
That is reasonable for the use of paths as directories, where one could
interpret the expression as
((pooh CD bah) CD yow) CD ick
or for the use of nested series(es(es(es(es...))) ;-), where one could
interpret the expression as
((pooh SELECT bah) SELECT yow) SELECT ick
However, this all breaks down with functional options, because
function-name/refinement-1 ...
DOESN'T mean "invoke function-name, then apply refinement-1 to the
result", and so on with additional refinements. In fact, I haven't
been able to find any notation that implements the quoted phrase,
except for
dummyvariable: function-name ...
dummyvariable/refinement-1 ...
Which gives me serious heartburn over the issue of having to bloat the
namespace with a conceptually meaningless variable. Of course, I will
be delighted if someone can show me that I've overlooked some obvious
way to do this without the variable -- this won't be the first time
that I've tasted shoe leather publicly. ;-)
Based on the above (and assuming that I'm not overlooking an obvious
solution), I'd ask the REBOL wizards to consider the following
suggestions:
1) Adding some notation to allow operation on an anonymous result of
a function call, such as
(function-name ...)/refinement-1 ...
or
function-name ... :/refinement-1 ...
I'm just asking for the capability; I'm NOT trying to suggest the
actual notation. I'm confident that you can do that better than I.
2) Adding some more discussion in the tutorial materials about path
expressions to warn the beginning REBOLite about the different
meanings of / (in the "REBOL in Ten Steps" page, or other docs
you may be developing)
But let me repeat that, although I've spilled a lot of virtual ink on
this point, it IS a minor point relative to the great job you've done
on producing a clean, usable, compact, cross-platform, language!
Thanks!
-jn-
