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

URL & setword bugs

 [1/10] from: al::bri::xtra::co::nz at: 18-Aug-2002 11:46


Joel wrote:
> Does anybody besides me think that this should be reported as a bug?
As shown by Joel on the mailing list:
>> type? garbage:"trash"
== string!
>> foo: garbage:"trash"
== "trash"
>> foo
== "trash" I feel that garbage:"trash" should result in a syntax error. And:
>> test: ["a" "b" "c" "d"]
== ["a" "b" "c" "d"]
>> i: 2
== 2
>> test/:i: "BBBB"
** Syntax Error: Invalid word -- :i: ** Near: (line 1) test/:i: "BBBB" I feel that test/2 should now be "BBBB" instead of the syntax error. After all the following works:
>> test
== ["a" "b" "c" "d"]
>> test/:i/1: #"z"
== "z"
>> test
== ["a" "z" "c" "d"] I've notified feedback of this problem. Andrew Martin ICQ: 26227169 http://valley.150m.com/

 [2/10] from: ptretter:charter at: 17-Aug-2002 23:19


The first part you referenced is not a problem. We often set multiple values this way - such as: this: that: none This way everything can be set to none. Gotta be careful with this though as some datatypes have problems doing this. And for your second example the test:i would be getting the value at index 'i and not setting do to the placement of the ":". try: change test/:i "BBBB" Paul Tretter

 [3/10] from: carl:cybercraft at: 18-Aug-2002 18:00


On 18-Aug-02, Paul Tretter wrote:
> The first part you referenced is not a problem. We often set > multiple values this way - such as: > this: that: none > This way everything can be set to none.
Yes, but in the example there was no space between the colon and the string. ie, this works (but probably shouldn't)...
>> this:"a string"
== "a string"
>> ? this
THIS is a string of value: "a string" while this doesn't...
>> that:none
== that:none
>> ? that
No information on that (word has no value)
> Gotta be careful with this though as some datatypes have problems > doing this. > And for your second example the test:i would be getting the value at > index 'i and not setting do to the placement of the ":". > try: > change test/:i "BBBB"
A possible conflict with using... test/:i: is that 'i could be interpreted as both a get-word and a set-word. It would be useful, but then maybe it'd open a can of words.
> Paul Tretter > ----- Original Message -----
<<quoted lines omitted: 38>>
>> [rebol-request--rebol--com] with "unsubscribe" in the >> subject, without the quotes.
-- Carl Read

 [4/10] from: gscottjones:mchsi at: 18-Aug-2002 5:54


Hi, Paul, From: "Paul Tretter"
> The first part you referenced is not a problem. > We often set multiple values this way - such as:
<<quoted lines omitted: 6>>
> try: > change test/:i "BBBB"
... does give ...
>> test
== ["a" "BBBB" "c" "d"] and then
>> change test/:i "b"
== "BBB"
>> test
== ["a" "bBBB" "c" "d"] which may or may not have been then intended action. I ask myself which result is the *least* surprise, and my guess is that it works correctly as is. So it seems that change test/:i "whatever" is an equivalent action to test/:i/1 but my expectation of Andrew's proposal would be test: ["a" "b" "c" "d"] i: 2 test/:i: "BBBB" test ; pseudo results ----> ["a" "BBBB" "c" "d"] I personally would like to see this type of action; I think it would add to the "intuitive" nature of the language. It is not clear that this behavior would break some other action/result. Can anyone else see that it does? Just curious. Thanks, Paul. --Scott Jones

 [5/10] from: joel:neely:fedex at: 18-Aug-2002 7:46


Hi, Scott, Please see my reply to Andrew's post for a discussion of this part. There's something tricky involved here. G. Scott Jones wrote:
> So it seems that > change test/:i "whatever" > is an equivalent action to > test/:i/1 >
Only in special circumstances!!! -- ; Joel Neely joeldotneelyatfedexdotcom REBOL [] do [ do func [s] [ foreach [a b] s [prin b] ] sort/skip do function [s] [t] [ t: "" foreach [a b] s [repend t [b a]] t ] { | e s m!zauafBpcvekexEohthjJakwLrngohOqrlryRnsctdtiub} 2 ]

 [6/10] from: gscottjones:mchsi at: 18-Aug-2002 8:31


Hi, Joel, From: "Joel Neely"
> Hi, Scott, > > Please see my reply to Andrew's post > for a discussion of this part. > There's something tricky involved here.
Maybe I am in a prion-induced state of confusion, but I cannot seem to locate the proper discussion. Maybe I've just used to many get-word set-word transformations on my thoughts and have mutated the source to where I can no longer follow a series in a sequential manner. :-) Maybe it is time for a mental reboot .... but that would not get rid of the prion. Hmmmm...
> "G. Scott Jones" wrote: > > So it seems that > > change test/:i "whatever" > > is an equivalent action to > > test/:i/1 > > Only in special circumstances!!!
If you have a moment and are feeling kind, can you point me to the mail list reference? Thanks. --Scott Jones

 [7/10] from: joel:neely:fedex at: 18-Aug-2002 8:18


Hi, Andrew (and Paul and Carl), Two different issues, and they're both a bit tricky... Andrew Martin wrote:
> As shown by Joel on the mailing list: > >> type? garbage:"trash"
<<quoted lines omitted: 4>>
> == "trash" > I feel that garbage:"trash" should result in a syntax error.
Gabriele already posted my goof in the first case. The opening quote effectively terminates the set-word! GARBAGE: therefore the syntax is quite legal. Other examples would be:
>> blk:[2 4 6 8] == [2 4 6 8] >> blk == [2 4 6 8] >> str:{no space required} == "no space required" >> str == "no space required" >> val:(copy/part str 3) == "no " >> val == "no "
My apologies for crying wolf over this one!
> >> test: ["a" "b" "c" "d"] > == ["a" "b" "c" "d"]
<<quoted lines omitted: 3>>
> ** Syntax Error: Invalid word -- :i: > ** Near: (line 1) test/:i: "BBBB"
I raised this issue at least a year ago. The syntax of paths doesn't allow the last segment to be a get-word followed by a colon, as if the lexical scanner is choking over the piece after the last slash, as indicated by the "Invalid word..." message. I agree that being able to add a colon to the end of ANY valid path expression to set the value at that "place" in the structure would be much cleaner and more notationally consistent that the hoops we currently must junp through. HOWEVER... it's easy to be misled by your example!
> I feel that test/2 should now be "BBBB" instead of the syntax error. > After all the following works:
<<quoted lines omitted: 4>>
> >> test > == ["a" "z" "c" "d"]
The reason that works is that TEST is a series (block!) of series (string!) values, therefore the three-component path is legitimate: test ["a" "b" "c" "d"] test/:i "b" (given that I was set to 2) test/:i/1 #"b" So we can use the example from Paul's post just as well:
>> test: ["a" "b" "c" "d"]
== ["a" "b" "c" "d"]
>> i: 2
== 2
>> change test/:i "BBBB"
== ""
>> test
== ["a" "BBBB" "c" "d"] Again, we're applying CHANGE to the series (string!) at TEST/2 to modify that series value. If we populate a block with non-series values, however, the same game doesn't work:
>> failure: [0 1 2 3]
== [0 1 2 3]
>> change failure/:i "BBBB"
** Script Error: change expected series argument of type: series port ** Near: change failure/:i "BBBB" I assume we can agree that we'd like to see test/:i: "Hello!" work in either case, equivalent to poke test (:i) "Hello!" under the theory that one should be able to make a "set path" value by appending a colon to any "non-set-path" case of a path. My original proposal was even more radical. I suggested that PAREN! values also be allowed as path components, so that one could navigate through a multi-level structure using expressions as selectors, so that test/:i/1 could be written as test/(i)/1 but one could also write something like test/(i + 1)/1 instead of the (kudgier IMHO) current j: i + 1 test/:j/1 After all, the "EB" in "REBOL" stands for "Expression-Based", so one would expect to be able to use expressions rather than having to create temporary words in such cases... My "poster child" illustration for this was the smoothing problem: Given a block of numbers, modify the block's content so that all interior value (i.e. except the first and last) are averaged with their immediate neighbors. With the expression-based path notation, this could be written as smooth: func [b [block!]] [ repeat i (length? blk) - 2 [ b/(i + 1): (b/(i) + b/(i + 1) + b/(i + 2)) / 3.0 ] ] instead of the (more cumbersome and less "expression-based" IMHO) smooth: func [b [block!]] [ repeat i (length? b) - 2 [ poke b i + 1 ((pick b i) + (pick b i + 1) + (pick b i + 2)) / 3.0 ] ] My $0.02... -jn- -- ; Joel Neely joeldotneelyatfedexdotcom REBOL [] do [ do func [s] [ foreach [a b] s [prin b] ] sort/skip do function [s] [t] [ t: "" foreach [a b] s [repend t [b a]] t ] { | e s m!zauafBpcvekexEohthjJakwLrngohOqrlryRnsctdtiub} 2 ]

 [8/10] from: joel:neely:fedex at: 18-Aug-2002 14:01


Hi, Scott, G. Scott Jones wrote:
> ... I cannot seem to locate the proper discussion. Maybe I've > just used to many get-word set-word transformations on my thoughts > and have mutated the source to where I can no longer follow a > series in a sequential manner. :-) >
My fault again. I was writing both replies concurrently, but hit the "send" button on the reply to your post, and then editied the other one some more (and took longer at it than I meant). The other reply is out there now... Sorry for causing confusion!
> Maybe it is time for a mental reboot .... >
Let me know if you figure out how! I could use that trick myself!
> > "G. Scott Jones" wrote: > > > So it seems that
<<quoted lines omitted: 3>>
> > > > Only in special circumstances!!!
The "special circumstances" being when test is a series of series values. -jn- -- ; Joel Neely joeldotneelyatfedexdotcom REBOL [] do [ do func [s] [ foreach [a b] s [prin b] ] sort/skip do function [s] [t] [ t: "" foreach [a b] s [repend t [b a]] t ] { | e s m!zauafBpcvekexEohthjJakwLrngohOqrlryRnsctdtiub} 2 ]

 [9/10] from: gscottjones:mchsi at: 18-Aug-2002 15:53


Hi, Joel, From: "Joel Neely" <snip size=huge>
> My original proposal was even more radical. I suggested that > PAREN! values also be allowed as path components, so that one > could navigate through a multi-level structure using expressions > as selectors, so that
<snip length=rest> I do remember this discussion from last year. I for one could more than easily adapt to the paren! approach. Of course, what I want and 35 cents used to buy a person a payphone call, but that is not even true anymore. Maybe it is time to make another proposal to RT (not for upcoming release, but for the ever illusive 3.0). Just thinking out loud. Thanks for the reminder on other ways to handle this problem. --Scott Jones

 [10/10] from: gscottjones:mchsi at: 18-Aug-2002 16:00


Hi, Joel,
> "G. Scott Jones" wrote: > > ... I cannot seem to locate the proper discussion. Maybe I've > > just used to many get-word set-word transformations on my thoughts > > and have mutated the source to where I can no longer follow a > > series in a sequential manner. :-)
From: "Joel Neely"
> My fault again. I was writing both replies concurrently, but hit > the "send" button on the reply to your post, and then editied the > other one some more (and took longer at it than I meant). The > other reply is out there now... Sorry for causing confusion!
No problem. I caught on soon after your post occurred. I just thought that I was overlooking a post. JN> > > Only in special circumstances!!! JN> The "special circumstances" being when test JN> is a series of series values. Although my comment to Paul was meant to apply only to the circumstance at hand, I had in fact forgotten about blocks of non-series values, so your point was well worth making IMO. --Scott Jones

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted