Re: [stack] S-K Construction of Dip?

Manfred Von Thun <[email protected]> wrote:
> "William Tanksley, Jr" <[email protected]> wrote:
> > But they do not accept the same programs. L accepts many more programs
> > than Joy does. L may even be more expressive than Joy (although I
> > haven't examined it to see whether it actually is).

> You are exactly right about L++ (in the terminology of my original post),
> but not about L.
> Reminder: L and L++ both use a stack of foyers, but they differ in whether
> they allow
> unmatched ³[³ before ³.² In a nutshell, again for both L and L++ :

I'm extremely confused. I thought you just said that L accepted
unbalanced brackets -- you said, "an incomplete Joy program (as Joy is
currently implemented) produces an error message..., whereas L would
not consider it to be incomplete."

How does this NOT mean that L accepts a superset of what Joy accepts?
The only thing I can think of is that you consider producing "an error
message" to be a way for a language to signify that it accepts the
text as a valid program. My texts list that as the ONLY way a parser
can reject a text as an invalid program.

> ³[³ starts a new foyer,
> ³]² appends the current foyer as a list to the previous foyer, and
> ³.² executes the current foyer on the foyer below.

> But there is a difference:

> L does not allow the sequence ³[³ ... ³.² because of unmatched brackets.
> L++ does allow this sequence, and as you rightly observe, it resembles Forth
> immediates.

I'm definitely completely lost on what L is. Your previous posts
seemed to indicate that it did something different from Joy, which I
interpreted as (in my own words) "it doesn't produce an error for
unmatched brackets." Now you're telling me that it doesn't allow
unmatched brackets.

> I still maintain that L = Joy, and agree that L++ is a superset.

They're your languages, so you have the right to define them as you
wish. I'm still phenomenally confused, however, because I you
previously defined L using language that (in your own words) implied
"nothing there says that '[' and ']' have to be properly nested."
Indeed, I assumed that was the case when reading your original post --
after all, if you were to imply that [ and ] nested the text they
contained, you wouldn't have been defining a flat language.

But now, looking very carefully at what you say, here's my opinion:

 - Joy isn't flat; it will reject programs that were cut at arbitrary places.
 - If L is exactly Joy, L isn't flat either.
 - If L is Joy minus the rejection of unbalanced nesting, L is flat.
 - I don't know anything about L++. I thought you were only using it
to mean "a language like L but with additional unspecified features."

There's nothing wrong with *not* being flat. I would strongly
recommend against making a language flat for any reason other than
pure research.

> But I am not at all sure
> whether the extras that L++ can do cannot also be achieved (in a different
> way) by using existing list- (and hence program-) manipulators. I just
> don't know.

Assuming that L++ is your name for a language that accepts any section
of a valid Joy program as a valid L++ program... Yes, since it's
Turing complete, Joy can do all the same things. But what Joy can't do
is be refactored 100% validly by cut and paste. L++ can.

Does that matter? A bit. A flatter language is easier to mentally
parse than a less flat one, all other things being equal. BUT... Not
all things are equal. Kerby's and my 01 languages are abominations
from the pit of mathematical hell (hey, maybe I *like* it warm!); L
and L++ add "foyers", a concept which is not needed to understand Joy
(so Joy is simpler).

So far nobody's been able to produce a flat language that's _actually_
easier to work with in general than a non-flat language. Anyone who
suspected that it's impossible would be in good company.

I don't think it's reasonable to ask for a perfectly flat language;
but I do think it might be possible to design a language that doesn't
need quite as much nesting. A _flatter_ language. Such a language
might (or might not) be like Joy, but using foyers _instead_ of
quotations (to reduce the number of simultaneous concepts that people
have to work with). I don't know. I'm taking a slightly different
approach at the moment, with no results yet to report on.

> I meant this posting to be more detailed, sorry Billy. But I got sidetracked
> by downloading
> the Factor tarfile and inspecting quite a lot of the files. A most
> impressive piece of work, congratulations to the author(s).

Indeed it is!

>   - Manfred

-Billy