Re: [stack] Concatenative Research
"Justin" <[email protected]> Mon, 31 Jan 2011 23:36:01 -0000
| Newsgroups | gmane.comp.lang.concatenative |
|---|---|
| Message-ID | <[email protected]> |
--- In [email protected], "William Tanksley, Jr" <wtanksleyjr@...> wrote: > > Justin <zallambo@...> wrote: > > "William Tanksley, Jr" <wtanksleyjr@> wrote: > >> I'm currently working on exploring a useless nook of concatenative > >> languages that I called "completely flat languages". A completely flat > >> concatenative language is defined not only by being concatenative > >> (that is, any two valid programs can be concatenated to form a valid > >> program), but also by being completely flat -- there is no discernible > >> syntactic structure. This means that every bitstring is a valid > >> program, and a program can be cut at any location to produce two valid > >> programs the composition of whose semantics is the original program's > >> semantics. > >> > >> Naturally, I reduced this to the single-bit case: a language with only > >> two words, "0" and "1". "0" pushes some quotations on the stack, and > >> "1" pops and executes things from the stack. I'm currently using the > >> "k" combinator for "1", and usually "0" is something like "[], [cake], > >> [k]". (See Kerby's definitions of common combinators on > >> http://tunes.org/~iepos/joy.html#cakek for explanations.) > > > If "1" executes things from the stack, then it's undefined on an empty stack. And if it behaves differently on an empty stack than it does otherwise, you'll lose the concatenative property. How do you get around this? > > That's a runtime error, not a syntax error. And any word that takes > ANY parameters behaves differently on different stacks; that's the > purpose of taking parameters. :-) Mm, I realize now that as I was thinking about your stated goal, I didn't have a precise definition of 'semantics' in mind. Would you agree with me that a semantics is a partial function from states to states, where in this case the state is a stack of quotations? (They must be _partial_ functions because they can (i) encounter runtime errors, and (ii) fail to halt.) > A Haskell programmer. You're smarter than I am, then. :-) Only until you learn Haskell :-). I highly recommend it.