Re: [stack] Re: Barebone implementation of concatenative language in c or c++

On 23 Jul 2010, at 02:56, pml060912 wrote:

> --- In [email protected], Don Groves <dgroves@...> wrote:
>>
>>>
>>> .
>>>>>> In a call-by-value environment, It seems to me that encapsulating
>>>>>> all data in functions yields the same effect as call-by-
>>>>>> reference. If
>>>>>> a parameter is not needed, its evaluating function will not be
>>>>>> called.
>>>>>
>>>>> This gets confusing to me, so hold on tight... :-)
>>>>>
>>>>> In order to pass a function to a procedure, the function has to be
>>>>> available as data. If it's not, you can't pass it.
>>>>
>>>> I don't understand this -- I do it all the time in my C code by  
>>>> using
>>>> the
>>>> address operator, &, and the same is easily done in Forth, et al.
>>>
>>> That's pretty much the same indirection approach I use in Furphy
>>> (see http://users.beagle.com.au/peterl/furphy.html), to achieve the
>>> same effect with a workaround even when what actually happens is
>>> done eagerly. I even describe it there with an analogy to what you
>>> are thinking of in C:-
>>>
>>> Conditional code is mostly achieved by IF and a complementary pair
>>> of things, freezing and thawing. This is a bit like using
>>> indirection in C to pass parameters by name instead of the default
>>> by value. The analogy here is that IF does eager evaluation, and
>>> freezing and thawing change the behaviour to lazy evaluation. IF has
>>> this behaviour, using Forth documenting standards: (  true/
>>> false_flag  true_option  false_option  ---  result  ).
>>>
>>> FREEZE and THAW behave like an anonymous label (if that isn't a
>>> contradiction in terms - it really returns early and pushes a re-
>>> entry address to the stack) and a dynamic subroutine call, different
>>> from the Forth keyword EXECUTE that it resembles. Typically, you
>>> would put FREEZE at the beginning of each keyword that you might
>>> want to select with IF and then you would use THAW on whichever one
>>> got chosen, like this:-
>>>
>>> FREEZE TRUE_STUFF TRUE_OPTION
>>>
>>> FREEZE FALSE_STUFF FALSE_OPTION
>>>
>>> GET_FLAG TRUE_OPTION FALSE_OPTION IF THAW DEMO
>>>
>>> Later on I describe some syntactic sugar to make coding and using
>>> the indirection easier, too. P.M.Lawrence.
>>
>> Thanks. Do you feel your approach is equivalent to lazy evaluation?
>
> We had that discussion earlier, I think actually on this thread. I  
> feel it works out like this:-
>
> - From the program's point of view, it is equivalent to lazy  
> evaluation, because the behaviour it delivers is the same.
>
> - From the programmer's point of view, it is not, because he or she  
> has to do something explicit to achieve it. Before the syntactic  
> sugar, quite a bit is needed to get things like recursion and loops,  
> but even though that cuts it down it still doesn't eliminate it.
>
> Taking all in all, I decided to document it as "change the behaviour  
> to lazy evaluation", not to call it lazy evaluation as such.  
> P.M.Lawrence.
>

But if that behavior is built into the language, why does an  
application programmer have to do anything explicit?

don


> ------------------------------------
>
> Yahoo! Groups Links
>
>
>