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

paths & lookups & change

 [1/24] from: robert:muench:robertmuench at: 18-Oct-2003 10:16


Hi, I seem to be stucked here:
>> test
== ["Bug Report" 1]
>> key
== "Bug Report"
>> type? select test key
== integer!
>> add select test key + 1
** Script Error: Cannot use add on string! value ** Near: add select test key + Hmm... Ok, maybe a priority problem:
>> add (select test key) + 1
** Script Error: add expected value2 argument of type: number pair char money date time tuple ** Near: add (select test key) + 1 Strange. Shouldn't this be possible? I would like to write something like this, to increment the integer in the block: test/:key: test/:key + 1 How can I do such a thing? Using to-set-path? I tried but failed. Robert

 [2/24] from: ingo:2b1 at: 18-Oct-2003 11:28


Hi Robert, Robert M. Münch wrote:
> Hi, I seem to be stucked here: >>>test
<<quoted lines omitted: 12>>
> ** Near: add (select test key) + 1 > Strange. Shouldn't this be possible?
Have a look at these to statements, please
>> add select test key 1
== 2
>> (select test key) + 1
== 2 You're doing both of the above in one line, so the '+ eats away one of 'add s arguments
> I would like to write something like this, to increment the integer in the > block: > > test/:key: test/:key + 1
I'd like that, too ;-) But until then, this works:
>> change next pos: find test key pos/2 + 1
== []
>> test
== ["Bug Report" 2] Though I'm sure, someone will come up with a better idea ...
> How can I do such a thing? Using to-set-path? I tried but failed. Robert
I wouldn't know how to do it, either, anyone else? Kind regards, Ingo

 [3/24] from: SunandaDH:aol at: 18-Oct-2003 5:41


Robert:
> I would like to write something like this, to increment the integer in the > block: > > test/:key: test/:key + 1
That'd be a great extension to the language.
> How can I do such a thing? Using to-set-path? I tried but failed. Robert
This works, and you could make a function of it: test: ["Bug Report" 1] poke test ;; series index? temp: next find test "bug report" ;;location in series 1 + first temp ;; new value Sunanda

 [4/24] from: antonr:iinet:au at: 18-Oct-2003 19:57


Robert, which addition operator are you going to use :-D I count two additions, I think you only want one: add (select test key) 1 or (select test key) + 1 Anton.

 [5/24] from: robert:muench:robertmuench at: 18-Oct-2003 15:48


On Sat, 18 Oct 2003 11:28:07 +0200, Ingo Hohmann <[ingo--2b1--de]> wrote:
> You're doing both of the above in one line, so the '+ eats away one of > 'add s arguments
Even in the danger I repeat myself: no comment
> I'd like that, too ;-) But until then, this works: > > >> change next pos: find test key pos/2 + 1 > == [] > >> test > == ["Bug Report" 2] > > Though I'm sure, someone will come up with a better idea ...
Is it really that complicated? I wanted to avoid this. I thought about it too but I can't believe that we need to do all this just to add a value to some word stored in a block. Robert

 [6/24] from: robert:muench:robertmuench at: 18-Oct-2003 15:48


On Sat, 18 Oct 2003 19:57:52 +1000, Anton Rolls <[antonr--iinet--net--au]> wrote:
> Robert, which addition operator are you going > to use :-D
Hi, no comment :-| Robert

 [7/24] from: brett:codeconscious at: 19-Oct-2003 3:44


> test/:key: test/:key + 1 > > How can I do such a thing? Using to-set-path? I tried but failed. Robert
You can sort of, but you may not want to :-)
>> test: ["Bug Report" 1]
== ["Bug Report" 1]
>> key: "Bug Report"
== "Bug Report"
>> do reduce [to-set-path reduce ['test :key] 1 + test/:key]
== ["Bug Report" 2]
>> test
== ["Bug Report" 2] Alternatively perphaps a change in your data format (adding some metadata) will help:
>> test: reduce ["Bug Report" [count 1]]
== ["Bug Report" [count 1]]
>> test/:key/count: test/:key/count + 1
== [count 2]
>> test
== ["Bug Report" [count 2]] Brett.

 [8/24] from: antonr:iinet:au at: 20-Oct-2003 12:30


Oh, I see what you're trying to do. I agree there seems to be missing a native to set the selected value. We have SELECT to get the value, but we have nothing to set the value, except the long solutions so far offered. Anton.

 [9/24] from: joel:neely:fedex at: 19-Oct-2003 22:20


Hi, Robert, Types are the issue... See below. Robert M. Münch wrote:
> On Sat, 18 Oct 2003 11:28:07 +0200, Ingo Hohmann <[ingo--2b1--de]> wrote: >>
<<quoted lines omitted: 7>>
> too but I can't believe that we need to do all this just to add a value to > some word stored in a block. Robert
Let's look closely at the example:
>> test: ["Bug Report" 2]
== ["Bug Report" 2]
>> key: "Bug Report"
== "Bug Report"
>> select test key
== 2 Note that the result of SELECT is an INTEGER! value, which is immutable. We can't make a 2 become a different value; we can only have a container which holds a copy of a 2 and replace that with a different integer. One way is:
>> if found? pos: find test key [pos/2: pos/2 + 1]
== ["Bug Report" 3] i.e. we need to change the block TEST so that the 2 following the value of KEY is replaced with a 3 (since we can't change a 2). Another way to keep the expression short is to provide an extra layer of container:
>> test: ["Bug Report" [2]]
== ["Bug Report" [2]]
>> if found? val: select test key [val/1: val/1 + 1]
== [3]
>> test
== ["Bug Report" [3]] However, the punch line remains the same; mutability requires use of a container; therefore the mutation must be specified in terms of the container. -jn-

 [10/24] from: robert:muench:robertmuench at: 21-Oct-2003 21:56


On Sun, 19 Oct 2003 03:44:30 +1000, Brett Handley <[brett--codeconscious--com]> wrote:
> You can sort of, but you may not want to :-) >>> test: ["Bug Report" 1]
<<quoted lines omitted: 5>>
>>> test > == ["Bug Report" 2]
Hi Brett, thanks for this. Looks terrible to me but it does the trick without a find.
> Alternatively perphaps a change in your data format (adding some > metadata) will help:
Yes, I thought about this too. But this will bloat the data so I prefer the first solution. Robert

 [11/24] from: robert:muench:robertmuench at: 21-Oct-2003 21:56


On Mon, 20 Oct 2003 12:30:54 +1000, Anton Rolls <[antonr--iinet--net--au]> wrote:
> Oh, I see what you're trying to do. > I agree there seems to be missing a > native to set the selected value.
Hi, yes correct that's the problem.
> We have SELECT to get the value, but > we have nothing to set the value, > except the long solutions so far offered.
Exactly, IMO this is a real gap in Rebol so far and RT should add such a feature in future releases. Robert

 [12/24] from: g:santilli:tiscalinet:it at: 22-Oct-2003 10:38


Hi Robert, On Tuesday, October 21, 2003, 9:56:23 PM, you wrote:
>>>> test: ["Bug Report" 1] >> == ["Bug Report" 1]
<<quoted lines omitted: 4>>
>>>> test >> == ["Bug Report" 2]
RMM> Hi Brett, thanks for this. Looks terrible to me but it does the trick RMM> without a find. It *IS* doing the FIND actually, it's just a different notation for it. You see, this is the reason why I don't like this kind of syntactic sugar. (Luckily in REBOL is not syntax but rather semantics at the function interpreter level, but the result is the same, i.e. people tend to forget what the notation actually implies.) I can't find a good name for it, so I'll just use MODIFY, but I'd rather make a function that was the complementary of SELECT: modify: func [series key new-value] [ ; should maybe cause an error here? ; or add the key... if not series: find series key [return none] ; doesn't allow poking functions, but i think this way ; is much more convenient... ; notice that you don't need to check if it is a function series/2: new-value series/2 series/2 ] That is very QAD but has a very nice behavior:
>> b: [test 1 test2 3]
== [test 1 test2 3]
>> modify b 'test2 4
== 4
>> b
== [test 1 test2 4]
>> modify b 'test func [v] [v + 1]
== 2
>> modify b 'test func [v] [v + 1]
== 3
>> b
== [test 3 test2 4]
>> increment: func [series key] [modify series key func [v] [v + 1]] >> increment b 'test
== 4
>> b
== [test 4 test2 4] Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amiga Group Italia sez. L'Aquila --- SOON: http://www.rebol.it/

 [13/24] from: brett:codeconscious at: 22-Oct-2003 20:07


Hi Gabriele, Robert, Interesting comments about the Find - I took Robert to mean that he didn't need to use the word Find in his code or data structure, but I see your point that evaluation of the path will likely cause an internal search operation. I'm certainly not defending my code example - it was UGLY :^) Maybe this situation indicates that the "why" of Robert's need should be looked at? So Robert, Why did you want the special set-path form - to save your fingers or for some other reason? Gabriele, About your Modify function. It is for you to define how it executes, but I wonder whether this sample:
> >> modify b 'test func [v] [v + 1] > == 2 > >> modify b 'test func [v] [v + 1] > == 3
.. should instead store the function in the block rather than doing an internal evaluation on it. That way it becomes more complimentary to Select. Regards, Brett.

 [14/24] from: g:santilli:tiscalinet:it at: 22-Oct-2003 12:24


Hi Brett, On Wednesday, October 22, 2003, 12:07:21 PM, you wrote: BH> .. should instead store the function in the block rather than doing an BH> internal evaluation on it. That way it becomes more complimentary to Select. My worry is, that if you need to operate on the previous value, such as incrementing it, you'd need to do the search two times. Of course, maybe that is not an issue so you can just change MODIFY to store the value even if it is a function... mine was just an idea. :) Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amiga Group Italia sez. L'Aquila --- SOON: http://www.rebol.it/

 [15/24] from: robert:muench:robertmuench at: 22-Oct-2003 20:17


On Wed, 22 Oct 2003 20:07:21 +1000, Brett Handley <[brett--codeconscious--com]> wrote:
> Maybe this situation indicates that the "why" of Robert's need should be > looked at? So Robert, Why did you want the special set-path form - to > save your fingers or for some other reason?
Hi, there are several reasons: - For storing data I'm always working with nested blocks of name/value pairs. This has proven to be the best approach yet. My goal is to keep this "database" as the master of data, the source. To avoid copying around and to minimize searches in big databases, I always try to work "in place" by using a reference. - Such paths are easy to create programmatically. This code can be used to access/alter record structures in an abstract way, because I can specify parts of a path! (including the last part of a path!) by variables. - I find it logical in the Rebol context. I hope these are good reasons for it :-) Robert

 [16/24] from: brett:codeconscious at: 24-Oct-2003 11:53


Hi Robert, Thanks for the explanation of your reasoning. Looking at the Core guide, paths look purpose-built for this sort of database. So your reasons have good company :^) Regards, Brett.

 [17/24] from: rebol:techscribe at: 23-Oct-2003 23:30


Hi Robert. My preference for this kind of tasks is using objects. Even though it is a little more verbose, I find it quite intuitive to use the get and set functions, as in:
>> db: make object! reduce [ to-set-word "first word" 1 to-set-word
second word 2 ]
>> probe db
make object! [ first word: 1 second word: 2 ]
>> key: to-word "second word" >> set in db key (get in db key) + 1 >> probe db
make object! [ first word: 1 second word: 3 ] Elan Brett Handley wrote:

 [18/24] from: rotenca:telvia:it at: 24-Oct-2003 18:37


Hi Elan,
> >> db: make object! reduce [ to-set-word "first word" 1 to-set-word > "second word" 2 ]
but these don't work: probe do mold make object! reduce [ to-set-word "first word" 1] probe do mold/all make object! reduce [ to-set-word "first word" 1] and objects use a little more memory than blocks. But i agree on the fact that objects are more easy to use than blocks. For very small blocks of data, i like the form: db: [id1 [name "Joe" num 32]] to be read with db/id1/name db/id1/num --- Ciao Romano

 [19/24] from: maximo:meteorstudios at: 24-Oct-2003 12:55


> For very small blocks of data, i like the form: > > db: [id1 [name "Joe" num 32]] > > to be read with > > db/id1/name > db/id1/num
why is it that I missed this path ('select) notation for 4 years? DOH! -Max

 [20/24] from: rebol:techscribe at: 24-Oct-2003 14:11


Hi Romano. Right. Looks like a 'mold bug. The mold output in this case is: == { make object! [ first word: 1 ]} Should be: == { make object! [ "first word": 1 ]} Elan. Romano Paolo Tenca wrote:

 [21/24] from: rebol:techscribe at: 24-Oct-2003 14:47


Or - then again - maybe not. ;-) Elan wrote:

 [22/24] from: brett:codeconscious at: 25-Oct-2003 9:55


> > db: [id1 [name "Joe" num 32]] > >
<<quoted lines omitted: 3>>
> > db/id1/num > why is it that I missed this path ('select) notation for 4 years?
There's a discipline that needs to followed with REBOL. Once you think you feel confident about how to do things, it is precisely then that you must go back and read the manual AGAIN to search for the new insight that calls into question that which you assumed you already knew! :-) Regards, Brett.

 [23/24] from: robert:muench:robertmuench at: 26-Oct-2003 13:31


On Thu, 23 Oct 2003 23:30:11 -0700, Elan <[rebol--techscribe--com]> wrote:
> My preference for this kind of tasks is using objects. Even though it is > a little more verbose, I find it quite intuitive to use the get and set > functions, as in: > ...
Hi, I made several test WRT use blocks VS objects. To me it showed up that blocks are more flexible (it can be expanded) and neutral in that those molded blocks can be read by other applications without a big problem. Robert

 [24/24] from: maximo:meteorstudios at: 27-Oct-2003 10:16


---- robert M. wrote ----
> Hi, I made several test WRT use blocks VS objects. To me it > showed up that
<<quoted lines omitted: 3>>
> problem. > Robert
Since you can use path notation with blocks too, then the point of using objects to store only data is lessened. -MAx

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