Re: [stack] disallowing recursive definitions

----- Original Message ----- 
From: "Daniel Ehrenberg" <[email protected]>
To: <[email protected]>
Sent: Saturday, March 01, 2008 10:34 PM
Subject: Re: [stack] disallowing recursive definitions


>>  > I use tail recursion when I'm either (a) interfacing with non-arrays
>>  > that still have to be iterated over in some way, for example an I/O
>>  > stream (b) doing something weird that'd be awkward to express in terms
>>  > of the abstractions I know. So (a) would be hard to eliminate,
>>
>>  why isn't a stream a list?
> 
> Well, if by "list" you mean "lazy linked list", Factor doesn't work
> like that for input because it'd require memoizing past input values,
> and it wouldn't flush output well. If you mean something else I don't
> understand. As far as making input something you can iterate over with
> "each", that's something I'm working on (though it won't extend to
> map).
>>
>>  lower-to-upper case in k:
>>
>>  u:_ci@[!256;97+!26;-;32]
>>  i:_ic"a99*bc"
>>  u i
>>  "A99*BC"
>>
>>  no loops, no recursion. depends on - being defined on arrays.
>>
>>  look, this is what i meant when i said that the power of the array
>>  approach is not obvious -- it can't be "read off" the definitions of
>>  the primitives. or if i didn't say that, that's what i meant. as
>>  i *have* been trying to say for several years now is that with the
>>  right set of primitives and datatypes, all sorts of non-obvious
>>  solutions arise. that's why the k sudoku is so short (i think it's
>>  down to 54 characters now.)
> 
> Umm, well, in the general Unicode case, there's some more complicated
> table lookup involved, and a bunch of corner cases. My Factor
> implementation is somewhat inelegant, and it'd be interesting to see
> something in K like that.  Your implementation could be written in
> Factor as
> 
> : >upper ( string -- newstring )
>    [ dup CHAR: a CHAR: z between? [ CHAR: A CHAR: a - + ] when ] map ;
> 
> These definitions have basically the same token count, so this example
> doesn't present an advantage or disadvantage of K.

apologies for misleading you with how i presented my example.  here's
a better explanation:

    _ic takes a string and returns a vector of ascii values
    _ci takes a vector of ascii values and returns a string

e.g. 

    _ic "a9."
97 57 46

so we create a constant u by replacing in 0-255 the ascii values for
the lower-case letters with the ascii values for upper-case letters,
and convert that vector to a string:

    u:_ci@[!256;97+!26;-;32]

@ takes four arguments:  something to amend (in this case 0 to 255), 
indices into that thing (97+0 to 25), a function of two arguments (-),
and a value (32).  so this reads:  int-to-char of subtract 32 from
positions 97+!26 in !256.  this is an example of an array idiom --
you use phrases like this so often, you see them as building blocks
in larger structures.  what gives this approach its power is that
the same functional schemes are used repeatedly to solve different
problems.  

we don't u compute that again.  (the language could easily supply
this to us as a predefined "feature", but why bother?)

then for each string we want to upper-case, we convert it: 

    _ic "ab3Xc"
97 98 51 88 99

and use those values to index out the values in u:

    u _ic "ab3Xc"
"AB3XC"

upper-casing is just indexing, so the upper-case function is just

    {u _ic x}




> 
> Dan
>