Re: [stack] Re: Barebone implementation of concatenative language in c or c++
Don Groves <[email protected]> Tue, 20 Jul 2010 23:06:07 -0700
| Newsgroups | gmane.comp.lang.concatenative |
|---|---|
| Message-ID | <[email protected]> |
On 20 Jul 2010, at 21:32, William Tanksley, Jr wrote: > John Nowak <[email protected]> wrote: >> Don Groves wrote: >>> Isn't call-by-reference essentially equivalent to lazy evaluation? >> Nope. Call-by-reference is an abomination that shouldn't exist. >> Lazy evaluation is unrelated. > > Heh. John, is this because CBR hypothetically allows mutation of > arbitrary items? I'm not sure that it shouldn't exist, but it should > certainly be confined to explicitly declared OUT parameters. > >> A quick run through here should help: >> http://en.wikipedia.org/wiki/Evaluation_strategy > > Yes, that's what I used after I wrote my first draft to make it look > like I knew what I was talking about. > >> Caveat: It is possible to have an eager yet non-strict language. >> Wikipedia conflates eagerness and strictness which is unfortunate, >> although most existing eager languages are indeed strict. The Id >> programming language is an example of an eager, non-strict language. > > WP's explanation of non-strictness on that page is pathetic. BUT, I'm > puzzled... Their definition is clear, and it matches what the first > pageful Google results seem to be using, and their definition utterly > precludes yours... So I'm curious. How is Id both eager and > non-strict? > >> Wikipedia is bad at precision. > > If this is true, its accuracy is more to be bemoaned than its > precision. > > Usually its clarity is worse. Especially in highly technical matters. > >> Concatenative languages do not have lambda abstractions, but you >> can achieve a similar result by placing a function on the stack and >> lifting values into it (e.g. via Factor's misnamed 'curry' >> function; it really should be called 'partial-apply' or similar, >> although that's not exactly right either). > > In a more general sense, what you're describing is passing a function > _as_ data -- not data inside a function, but rather a function as > data. What I'm describing is passing a function as a data source. I feel data should be treated like any other (possibly) shared asset. That is, assign a semaphore to it in the guise of a function that is its one and only evaluator. Laziness comes along for the ride... don > >> - jn > > -Wm > > > ------------------------------------ > > Yahoo! Groups Links > > >