Disclaimer: thats my interpretation of things, if I'm wrong please someone correct me
On Thu, Apr 16, 2009 at 1:47 PM, Bruno Deferrari <[email protected]> wrote: > On Thu, Apr 16, 2009 at 1:09 PM, Stefan Schmiedl <[email protected]> wrote: >> On Thu, 16 Apr 2009 11:16:12 -0300 >> Bruno Deferrari <[email protected]> wrote: >> >>> And now that we are at it, integers as sequences can be confusing too >>> (like in your example, 0 matches because it is the first element of >>> the CHAR: a sequence, matches as the key and 1 being the second >>> matches as the value), is that necessary now that factor has ranges? >> >> Well, I'm thoroughly confused already by my string example. I have >> not yet really thought about the sequenciability of integers... >> >> On the one hand, "abc" seems to be interpreted as an association with >> three keys: "abc" keys -> { 0 0 0 } >> On the other hand, requesting a value for one such key yields something >> obviously not contained in the association. > > 1. Strings and Integers are Sequences (Integers are sequences from 0 > to n-1 and empty for 0) > 2. Sequences are instances of assoc (to make alists work I guess) > 3. "abc" is being treated as an alist (alist exampe: { { "key1" > "value1" } { "key2" "value2" } } ) > 4. being 'CHAR: a' one of the elements of the sequence, and being a > character an integer, and being integers sequences too, then CHAR: a > is like { 0 1 2 3 .. 96 } ('CHAR: a' is 97) > 5. On an alist, the key is the first element of the inner sequence (0 > here, or "key1" on the alist example) > 6. On an alist, the value is the second element of the inner sequence > (for 'CHAR: a' or any integer greater than 1 it is 1), thats why you > are getting 1 > >> On the third hand: Does any of the available assoc implementations actually >> support multiple usages of the same key? >> >> What I'd have expected of an assoc-conforming string, would be >> access to its characters: 2 "abc" at -> either b or c >> >> s. >> >>> >>> On Thu, Apr 16, 2009 at 11:11 AM, Bruno Deferrari <[email protected]> >>> wrote: >>> > I may be wrong, but I think that sequence is an instance of assoc to >>> > make alists work (look at the definition of at*). But yeah, I don't >>> > like how interacts with sequences in general. >>> > >>> > On Thu, Apr 16, 2009 at 10:35 AM, Stefan Schmiedl <[email protected]> wrote: >>> >> Recently on #concatenative >>> >> >>> >> [14:40] <swsch> What am I doing wrong: H{ { "a" 1 } } "a" at . >>> >> ---> f [14:41] <tizoc> swsch: "a" goes before H{ ... } >>> >> [14:42] <tizoc> at's stack effect is ( key assoc -- value/f ) >>> >> [14:48] <swsch> so ... I'm being stupid, that's ok >>> >> [14:48] <swsch> why does "a" implement assoc-protocol? >>> >> [14:57] <swsch> ah ... INSTANCE: sequence assoc does it >>> >> [14:58] <swsch> but a string is a somewhat strange assoc ... >>> >> "abc" keys --> { 0 0 0 } [15:00] <swsch> and even funnier 0 >>> >> "abc" at -> 1 ... what's the idea behind that? >> >> ------------------------------------------------------------------------------ >> Stay on top of everything new and different, both inside and >> around Java (TM) technology - register by April 22, and save >> $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. >> 300 plus technical and hands-on sessions. Register today. >> Use priority code J9JMT32. http://p.sf.net/sfu/p >> _______________________________________________ >> Factor-talk mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/factor-talk >> > ------------------------------------------------------------------------------ Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p _______________________________________________ Factor-talk mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/factor-talk
