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

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