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
>
>
>