to-path newline problem?
[1/16] from: arolls::bigpond::net::au at: 12-Aug-2001 22:18
What do you people think of
the difference in the following two?
(1) Produce a nice path:
to-path [hello there]
== hello/there
(2) Produce a broken path:
to-path [hello
there]
== hello/
there
Note a newline in the input block
produces a newline in the output.
But why is it not the same as the first one?
A bug?
Is there any way to quickly remove the newline
from the block, perhaps, as a workaround?
[2/16] from: larry:ecotope at: 12-Aug-2001 13:17
Hi Anton,
I think it is a bug, because to-path is converting a block of words to a
path datatype and the presence of newlines in the molded block should not
have any effect on the interpretation.
You should send it in to feedback!
The work-around of removing the newline can not be done directly because the
newline is not in the block (not accessible with pick, etc.) but you can fix
the offending block in a more devious fashion. At the console:
>> b: [hello
[ there]
== [hello
there]
The block be cannot be converted with to-path
>> path: to-path b
== hello/
there
But we can go back to the mold of b and remove the newlines, load it back
and convert:
>> path: to-path load replace/all mold b "^/" ""
== hello/there
Cheers
-Larry
[3/16] from: arolls::bigpond::net::au at: 13-Aug-2001 12:59
Re: to-path newline problem? - sent to feedback
Ok, thanks Larry, I forwarded this to feedback.
[4/16] from: lmecir:mbox:vol:cz at: 13-Aug-2001 12:13
Re: to-path newline problem?
Hi Anton,
> What do you people think of
> the difference in the following two?
<<quoted lines omitted: 12>>
> Is there any way to quickly remove the newline
> from the block, perhaps, as a workaround?
The newline does no harm IMHO. In fact, the following holds:
block1: [hello there]
block2: [hello
there]
path1: to path! block1
path2: to path! block1
path3: to path! block2
equal? :path1 :path2 ; == true
equal? :path1 :path3 ; == true
same? :path1 :path2 ; == false
same? :path1 :path3 ; == false
same? :path3 :path2 ; == false
Ladislav
[5/16] from: joel:neely:fedex at: 13-Aug-2001 1:37
Hi, Ladislav, Anton, and all!
Ladislav Mecir wrote:
> Hi Anton,
> > What do you people think of
<<quoted lines omitted: 15>>
> >
> >
...
> > A bug?
>
Certainly a misfeature, if not a bug!
> The newline does no harm IMHO. In fact, the following holds:
> block1: [hello there]
<<quoted lines omitted: 9>>
> same? :path3 :path2 ; == false
>> b: [hello
[ there]
== [hello
there]
>> bp: to path! b
== hello/
there
>> ubp: to path! foreach c b [append [] to-word c]
== hello/there
>> equal? :bp :ubp
== true
>> mold :bp
== "hello/^/there"
>> mold :ubp
== "hello/there"
>> equal? mold :bp mold :ubp
== false
Well, it certainly defies my notion of EQUAL? to say that
one can have two values which are equal but MOLD unequally!
What's next? Do we have to add another function to our
user.r files ...
really-and-truly-equal: func [:x :y] [
to-logic all [
equal? x y
equal? mold x mold y
]
]
>> really-and-truly-equal :bp :ubp
== false
... and, of course, test with all possible datatypes as
arguments (and equality tests over all possible generic
transformations) to make sure we don't need another phrase
in the ALL block! ;-)
--
------------------------------------------------------------
Programming languages: compact, powerful, simple ...
Pick any two!
joel'dot'neely'at'fedex'dot'com
[6/16] from: arolls:bigpond:au at: 13-Aug-2001 22:37
> The newline does no harm IMHO. In fact, the following holds:
It could cause harm somewhere if code
generated with this is first written to a
rebol script file which is executed.
[7/16] from: lmecir:mbox:vol:cz at: 14-Aug-2001 7:53
Hi,
> Well, it certainly defies my notion of EQUAL? to say that
> one can have two values which are equal but MOLD unequally!
<<quoted lines omitted: 12>>
> transformations) to make sure we don't need another phrase
> in the ALL block! ;-)
Some comments:
words behave the same way:
alias 'a "aa"
equal? 'a 'aa ; == true
equal? mold 'a mold 'aa ; == false
another example:
equal? "a" "A" ; == true
equal? first "a" first "A" ; == false
Cheers
Ladislav
[8/16] from: joel:neely:fedex at: 14-Aug-2001 2:02
Hi, Ladislav,
Thanks for the examples!
Ladislav Mecir wrote:
> >
> > really-and-truly-equal: func [:x :y] [
<<quoted lines omitted: 17>>
> equal? 'a 'aa ; == true
> equal? mold 'a mold 'aa ; == false
Fortunately this one requires no new test ;-)
>> really-and-truly-equal 'a 'aa
== false
> another example:
>
> equal? "a" "A" ; == true
> equal? first "a" first "A" ; == false
>
>> equal? "YouAreNowhere" "YouAreNowHere"
== true
Ah, yes! The old IBM-mainframe-3270-and-80-column-punch-card
concept of "Shift key? We don't need no stinkin' shift key!"
still perpetuated in Visual CP/M 2000.
How silly (or Freudian) of me to forget this "feature"!
really-and-truly-equal: func [:x :y /local same-chars?] [
same-chars?: func [ls [string!] rs [string!]] [
forever [
if all [empty? ls empty? rs] [return
true]
if (first ls) <> first rs [return
false]
ls: next
ls
rs: next
rs
]
]
to-logic all [
equal? x y
equal? mold x mold y
same-chars? mold x mold y
]
]
... thus your new examples ...
>> really-and-truly-equal "YouAreNowhere" "YouAreNowHere"
== false
>> really-and-truly-equal 'a 'aa
== false
... and the original ...
>> b: [
[ hellow
[ therex
[ ]
== [
hellow
therex
]
>> bp: to-path b
==
hellow/
therex
>> ubp: to-path foreach w b [append [] to-word w]
== hellow/therex
>> equal? :bp :ubp
== true
>> really-and-truly-equal :bp :ubp
== false
Any others?
Seriously, at least the case-ignorant behavior of string
equality testing is documented, and the use of ALIAS is
sufficiently uncommon that one might be cautious about
making too many assumptions. However, the insistence on
retaining the locations of line breaks in the original
expression is really a puzzler, especially in view of the
difficulty of getting rid of (some of) them.
>> b
== [
hellow
therex
]
>> copy b
== [
hellow
therex]
>> copy/deep b
== [
hellow
therex]
>> foreach w b [append [] w]
== [
hellow
therex]
>> compose [(b)]
== [
hellow
therex]
>> foreach w b [append [] to-word w]
== [hellow therex]
This "feature" really cries out for some form of official
documentation IMHO.
-jn-
--
------------------------------------------------------------
Line breaks: sneaky, obscure, mysterious ...
Pick any two!
joel'dot'neely'at'fedex'dot'com
[9/16] from: brian:hawley at: 14-Aug-2001 9:35
Joel Neely wrote (some skipped):
>Ladislav Mecir wrote:
> > another example:
<<quoted lines omitted: 8>>
>still perpetuated in Visual CP/M 2000.
>How silly (or Freudian) of me to forget this "feature"!
It _is_ a feature. It is case-insensitive. The case-sensitive
function is strict-equal?, or == as an operator. Sometimes you
want a case-insensitive comparison.
Brian Hawley
[10/16] from: g:santilli:tiscalinet:it at: 14-Aug-2001 16:41
Hello Larry!
On 12-Ago-01, you wrote:
(BTW, to-path is quite low-level... it does strange things:
>> to-path "[hello there]"
== [hello there]
>> to-path "[hello there] [ha]"
== [hello there]/[ha]
>> p: to-path "system words"
== system/words ; it looks ok, but it is not bound (as expected)
>> p
** Script Error: system is not defined in this context.
** Where: p
>> to-path [look/at this]
== look/at/this ; this is subtle
>> first to-path [look/at this]
== look/at
>> second to-path [look/at this]
== this
It all happens because a path seems to be implemented as a variant
of block!, like most series.
)
LP>>> path: to-path load replace/all mold b "^/" ""
LP> == hello/there
or:
path: to-path load trim/lines mold b
Regards,
Gabriele.
--
Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer
Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/
[11/16] from: holger:rebol at: 14-Aug-2001 10:17
On Mon, Aug 13, 2001 at 01:37:41AM -0500, Joel Neely wrote:
> Well, it certainly defies my notion of EQUAL? to say that
> one can have two values which are equal but MOLD unequally!
*grin*
You stumbled across one of those relatively few, "magic" undocumented
features in REBOL :-). Here is the story:
When REBOL loads a script and saves or molds it back, it attempts to
preserve the positions of line feeds in each block, to make the output
look closer to the original. This is very useful, e.g., for
structured configuration files.
>> a: [12
[ 34
[ ]
== [12
34
]
>> a
== [12
34
]
>> b: [12 34]
== [12 34]
>> b
== [12 34]
>>
Internally in REBOL, paths are very similar to blocks. They are both
subtypes of any-block!. That's why converting a block which has those
line feed hints
in it to a path preserves the hints, and why molding
such a path reproduces them in the output as well.
At the moment it is not possible to manipulate the line feed hints
from the REBOL level. This is planned for a future version. Copying
values to a new block resets the hints though.
--
Holger Kruse
[holger--rebol--com]
[12/16] from: joel:neely:fedex at: 14-Aug-2001 13:07
Hi, Holger,
Holger Kruse wrote:
> When REBOL loads a script and saves or molds it back, it attempts
> to preserve the positions of line feeds in each block, to make the
> output look closer to the original. This is very useful, e.g., for
> structured configuration files.
>
It just seems that this is a case of the tail wagging the dog. I
can see the benefit of doing so in a few rare cases, but always???
It seems rather analogous to LOAD vs. LOAD/MARKUP, where the
unusual (or more complex) case is signalled by the presence of a
refinement.
> Internally in REBOL, paths are very similar to blocks. They are
> both subtypes of any-block!. That's why converting a block which
<<quoted lines omitted: 3>>
> from the REBOL level. This is planned for a future version. Copying
> values to a new block resets the hints though.
How? Any standard way of simply "copying values" that I can think
of doesn't do the trick (except for discarding the last "hint").
>> b: [
[ 1
[ 4
[ 16
[ ]
== [
1
4
16
]
>> b1: copy b print mold b1
[
1
4
16]
>> b2: copy/deep print mold b2
[
1
4
9
16]
>> b3: [] foreach be b [append b3 be] print mold b3
[
1
4
16]
>> b4: compose [(b)] print mold b4
[
1
4
16]
Of course one can always do something like
>> b5: [] foreach be b [append b5 0 + be] print mold b5
[1 4 16]
but that is hardly the same as simply copying, as it requires
knowing an operator and identity element suitable for the
type(s) of the values in the block!
Any suggestions welcome!
-jn-
--
This sentence contradicts itself -- no actually it doesn't.
-- Doug Hofstadter
joel<dot>neely<at>fedex<dot>com
[13/16] from: joel:neely:fedex at: 14-Aug-2001 13:21
Hi, Brian,
I had hoped that the subsequent paragraph beginning with
> Seriously, at least the case-ignorant behavior of string
> equality testing is documented, and the use of ALIAS is...
and the exaggerated quotation ("Shift key?...") would signal
that I wasn't *totally* serious in my mild grumbling.
However...
Brian Hawley wrote:
> It _is_ a feature. It is case-insensitive. The case-sensitive
> function is strict-equal?, or == as an operator. Sometimes
> you want a case-insensitive comparison.
>
Speaking for myself (who else! ;-) I *very rarely* want a
case-ignorant comparison. And in those cases where I really
do, I find the mental overhead of typing
equal? lowercase somestring lowercase otherstring
much lighter than the bewildering state of EQUAL? vs SAME? vs
STRICT-EQUAL? vs NOT-EQUAL? vs STRICT-NOT-EQUAL? that has been
at the root of so much discussion on this list. (OBTW, why
isn't there a NOT-SAME? or its synonym DIFFERENT?)
But, again, that's just speaking for myself. YMMV.
-jn-
--
This sentence contradicts itself -- no actually it doesn't.
-- Doug Hofstadter
joel<dot>neely<at>fedex<dot>com
[14/16] from: lmecir:mbox:vol:cz at: 14-Aug-2001 23:15
Hi,
...snip...
> > > ... and, of course, test with all possible datatypes as
> > > arguments (and equality tests over all possible generic
> > > transformations)
...snip...
an interesting idea. If I consider the following functions to be
transformations
(I am not claiming any "genericity"), I come to:
trans1: :type?
trans2: :head
trans3: :get
trans4: :visualize-context ; see http://www.sweb.cz/LMecir/contexts.html
trans5: :special? ; as above
a: 1
b: 1.0
equal? a b ; == true
equal? type? a type? b ; == false
a: tail [1]
b: tail [2]
equal? a b ; == true
equal? head a head b ; == false
a: use [c] [c: 1 'c]
b: use [c] [c: 2 'c]
equal? a b ; == true
equal? get a get b ; == false
a: use [c] [c: 1 'c]
b: use [c d] [c: 1 'c]
equal? a b ; == true
equal? visualize-context a visualize-context b ; == false
a: 'c
b: first find first system/words 'c
equal? a b ; == true
equal? special? a special? b ; == false
Regards
Ladislav
[15/16] from: g:santilli:tiscalinet:it at: 15-Aug-2001 13:03
Hello Joel!
On 14-Ago-01, you wrote:
JN> but that is hardly the same as simply copying, as it requires
JN> knowing an operator and identity element suitable for the
JN> type(s) of the values in the block!
While thinking about this, I found out another "strange" behaviour:
>> block: [
[ 1
[ "one"
[ [e--mail--com]
[ word
[ [block]
[ $10
[ 15-Aug-2001
[ a/path
[ :get-word
[ set-word:
[ #etc.
[ ]
>> block2: []
>> foreach value block [append/only block2 make :value :value]
== [1 "one" [e--mail--com] word [block]
$10.00
15-Aug-2001 a/path :get-word set-word: #etc.]
So money! and date! are not copied by make... or it copies the
newline hint too. (I think the former is more likely, looking like
an optimization. But why not on integer!s?)
Regards,
Gabriele.
--
Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer
Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/
[16/16] from: brian:hawley at: 15-Aug-2001 11:19
Hi Joel,
Joel Neely wrote:
>I had hoped that the subsequent paragraph beginning with
>
> > Seriously, at least the case-ignorant behavior of string
> > equality testing is documented, and the use of ALIAS is...
>
>and the exaggerated quotation ("Shift key?...") would signal
>that I wasn't *totally* serious in my mild grumbling.
Sorry, I've been a little humor-impaired lately. Use smileys :)
>However...
>Brian Hawley wrote:
<<quoted lines omitted: 12>>
>isn't there a NOT-SAME? or its synonym DIFFERENT?)
>But, again, that's just speaking for myself. YMMV.
Alas, it does. I've been doing REBOL work primarily on Windows
and Mac machines, where one needs case-insensitive comparison
for operations on file names. And it's useful for parsing of
case-insensitive languages and such.
On the other hand, the multiplicity of functions in REBOL has
been just as tricky for me as it apparently has been for you.
I usually program with another copy of REBOL running for tests
and online help, and a browser up with the Dictionary. Not as
easy on Mac, though, because of the aforementioned troubles
with running multiple app instances. Or with WinCE, which has
similar troubles to the Mac for entirely different reasons. It
will be nice to get to work more on Linux...
I'd put in a vote for NOT-SAME? instead of DIFFERENT? because
of the DIFFERENCE native, and balance. I'm OK with writing
NOT SAME? until then, though :)
Brian Hawley
P.S. If you really want a confusing language, try Icon (one of
my favorites). If I remember correctly, it has 4 operators for
different kinds of equality, with another 4 for corresponding
inequalities. And no written-out equivalents. Add to that some
strange control-flow gotchas and you sometimes get a debug-only
language. Powerful, though - its backtracking prepared me to
understand the more interesting aspects of the parse dialect.
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted