[REBOL] Re: paths & lookups & change
robert M. wrote > 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 Since you can use path notation with blocks too, then the point of using objects to store only data is lessened. -MAx -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: paths & lookups & change
On Thu, 23 Oct 2003 23:30:11 -0700, Elan <[EMAIL PROTECTED]> 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 -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: paths & lookups & change
> > 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?
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.
--
To unsubscribe from this list, just send an email to
[EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: paths & lookups & change
Or - then again - maybe not. ;-)
Elan wrote:
>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.
>
>
>
>
>
--
To unsubscribe from this list, just send an email to
[EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: paths & lookups & change
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:
>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
>
>
>
--
To unsubscribe from this list, just send an email to
[EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: paths & lookups & change
> 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
--
To unsubscribe from this list, just send an email to
[EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: paths & lookups & change
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 -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: paths & lookups & change
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: >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. > > > >>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 >> >> > > > > -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: paths & lookups & change
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. > 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 -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: paths & lookups & change
On Wed, 22 Oct 2003 20:07:21 +1000, Brett Handley <[EMAIL PROTECTED]> 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 -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: paths & lookups & change
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 <[EMAIL PROTECTED]> -- REBOL Programmer Amiga Group Italia sez. L'Aquila --- SOON: http://www.rebol.it/ -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: paths & lookups & change
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. -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: paths & lookups & change
Hi Robert, On Tuesday, October 21, 2003, 9:56:23 PM, you wrote: 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] 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 <[EMAIL PROTECTED]> -- REBOL Programmer Amiga Group Italia sez. L'Aquila --- SOON: http://www.rebol.it/ -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: paths & lookups & change
On Sun, 19 Oct 2003 03:44:30 +1000, Brett Handley <[EMAIL PROTECTED]> wrote: > 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] 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 -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: paths & lookups & change
On Mon, 20 Oct 2003 12:30:54 +1000, Anton Rolls <[EMAIL PROTECTED]> 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 -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: paths & lookups & change
Hi, Robert, Types are the issue... See below. Robert M. Münch wrote: > On Sat, 18 Oct 2003 11:28:07 +0200, Ingo Hohmann <[EMAIL PROTECTED]> wrote: >> >> >> 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 > 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- -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: paths & lookups & change
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. > On Sat, 18 Oct 2003 19:57:52 +1000, Anton Rolls <[EMAIL PROTECTED]> > wrote: > > > Robert, which addition operator are you going > > to use :-D > > Hi, no comment :-| Robert -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: paths & lookups & change
> 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. -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: paths & lookups & change
On Sat, 18 Oct 2003 19:57:52 +1000, Anton Rolls <[EMAIL PROTECTED]> wrote: > Robert, which addition operator are you going > to use :-D Hi, no comment :-| Robert -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: paths & lookups & change
On Sat, 18 Oct 2003 11:28:07 +0200, Ingo Hohmann <[EMAIL PROTECTED]> 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 -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: paths & lookups & change
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. > >> 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? -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: paths & lookups & change
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 -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
[REBOL] Re: paths & lookups & change
Hi Robert, Robert M. Münch wrote: > 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? 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 -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
