Re: [stack] impure concatenativity: let without translation

----- Original Message ----- 
From: "William Tanksley, Jr" <[email protected]>
To: <[email protected]>
Sent: Thursday, March 20, 2008 11:03 AM
Subject: Re: [stack] impure concatenativity: let without translation


> John Nowak <[email protected]> wrote:
>> William Tanksley, Jr wrote:
>>  > I admit that it's entirely unproven whether an inferential static type
>>  > checker can work at all in a concatenative language,
>>  > let alone one with macros.
> 
>>  I don't see why macros would complicate the type checker. Perhaps you
>>  were suggesting that macros complicate concatenativity.
> 
> I was replying to your message, in which you appear to be talking
> specifically about the problems of making the type checker emit
> reasonable error messages in the presence of a sophisticated macro
> system. Did you mean something else?
> 
>>  >> Compositing quotations is equivalent to composing functions. I see
>>  >> this as a necessity. In either case, I don't see how you can create
>>  >> closures without quoting values and composing functions.
> 
>>  > What do you mean "closures"? In my book, a closure is a function which
>>  > refers to lexically available variables outside its local scope. A
>>  > purely concatenative language does not have variables, and so does not
>>  > have closures in that sense.
> 
>>  What I'm suggesting is code like this, where 'foo' is a function that
>>  takes an argument 'x' and returns a function with 'x' closed over:
>>     x foo = [bar x quux]
> 
> Okay, got it. You want dynamic code assembly. Forth (for example) does
> this by driving the compiler, which is available at runtime. Joy uses
> lists and interprets them. Either way, same basic idea: you need a
> word that incorporates a value as a literal and a word that
> incorporates a value as a function call into an ongoing definition.
> 
> Your "compositing functions" is my "incorporates a value as a function call".
> 
>>  > See http://factor-language.blogspot.com/2007/08/compiled-curry.html
>>  > for the obvious way to do partial application in Factor.
>>  The obvious way to implement partial application is in terms of quote
>>  and compose:
>>     pa = [quote] dip compose
> 
> You're right; I apologize. I meant the obvious way to make it
> reasonably fast, not the obvious way to do it.
> 
>>  The Factor example seems to only avoid this when the function created
>>  via partial application is not returned from the context in which it
>>  was created.
> 
> I don't see why this is a limitation.
> 
>>  > I do concede and admit that having more tools is more practical than
>>  > having fewer tools, so including locals and lexical scoping is better
>>  > than not doing so; the problem isn't the locals, but the fact that
>>  > most programmers are trained in nothing but them, and use them as
>>  > crutches for their own lack of understanding rather than as poles to
>>  > vault over problems that are truly helped by them.
> 
>>  This is a good point, although I see this as more of a problem to be
>>  solved via education and community conventions than anything else
>>  really.
> 
> You're totally right. I see part of the purpose of this group as
> finding what those conventions are, or at least might be. I admit that
> I take that purpose too seriously; there's also another purpose of
> this group, to find and explore uses of concatenative languages (which
> definitely includes useful things like math syntax and lambda syntax).
> 
> Stevan makes a good point -- as fun as theory is, we need written
> code, and even an application written by a newbie who had to lean on
> the crutch of local variables almost the entire time is probably more
> likely to contain something unique than something written by an old
> Forther who's set in his ways.
> 
> With that said, it makes sense to learn from the programmers of the
> old stack languages. There are two rules they use that seem
> appropriate: avoid syntax-changing macros, and avoid local variables.
> The interesting lesson for ME to take from these are that in both
> cases, the language provides facilities for these; the instruction to
> "avoid" them is just a recommendation, not a rule.

my experience can't be unique.  i've been close to language development
for 30 years.  the APL community had a high proportion of kibbitzers,
urging the addition of this or that language extension.  the developers
(who were also users -- no one wrote more APL code than iverson) were
always searching for new ways to solve problems which emanated from
the user community.  sometimes those were unexpected uses of existing
resources, and sometimes the problems clumped together in some new
way to suggest natural language extensions.  the evolution of k in
the direction of database programming is a case in point:  new primitives,
new datatypes.  but that wouldn't have happened if the language's author
and many of his users weren't themselves immersed in database problems.

so the developer can't restrict his attention to the inner workings
of the language.  he needs data about what's important and what's not.
those facts cannot be acquired purely deductively.

i agree with billy that teaching a concatenative language with training
wheels might be a useful approach.  newbies to APL often get a mixed diet of
looping solutions and array solutions.  good programmers will shed the
former quickly.  others won't.  
 
> 
>>  > (Problems such as the infamous quadratic formula. I'm preparing an
>>  > alternate, purely concatenative approach to that, one which is not
>>  > as pretty but has interesting features to it.)
> 
>>  Sometimes though, you just need something to work as quickly as
>>  possible. If your language requires that you sit down and ponder how
>>  to translate something like the quadratic formula, you have a problem.
> 
> Then every language short of Mathematica or MathCAD has "a problem" --
> the quadratic formula isn't an obvious translation even in a lambda
> notation, and it's one of the simpler practical formulas.
> 
> We're dealing with largely imperative languages here; they're always
> going to be clearer when expressing algorithms than they are when
> expressing formulas. This is one reason I find the idea of a math
> sublanguage attractive, because it adds something that the main
> language simply does not possess.
> 
>>  > Concatenative languages are in their infancy.
> 
>>  This is a very, very good point. I'm experimenting with one particular
>>  aspect of concatenative languages; that is, placing them into a typed
>>  context. Alternatively, I'm experimenting with effect systems and type
>>  systems in a concatenative context if you'd prefer to put it that way.
> 
> Either way, your work is very interesting. I don't know what an
> "effect system" is, by the way.
> 
>>  There's so much that I'm necessarily ignoring to be able to focus on
>>  these things. I'm still very interested in the purely concatenative
>>  approach as a way of writing simple, concise programs in a highly
>>  simplified language. The language I'm working on is not that language;
>>  I'm trying to convince myself to focus on just one for the moment.
> 
> That's a very good point. Your field contains enough to explore
> anyhow; no need to add yet more unknowns.
> 
>>  - John
> 
> -Wm
>