Sean O'Dell wrote:

>>>Here's a question: are "pure" functional programming languages
>>>implemented according to their own rules?  Internally, do they also never
>>>use variables? My guess is: no, or almost never.  They break the rules
>>>internally to provide an interface that adheres to the rules.
>>It depends. Functional languages implemented in functional languages
>>will be written in a functional style of course. C is no functional
>>language, but most function language interpreters are written in C where
>>you have so many side effects that you *have* to capture different
>>states into variables.
> But how are they usually implemented?  In ASM, C, ... ?

What are ASM interpreters implemented in? What are lambda calculus 
interpreters (mathematicians) implemented in?

And also note that there *are* machines out there that use LISP as their 
native language. (Which means that everything on them, even C compilers, 
are implemented in LISP.) :)

>>The idea of functional languages is that the only thing a function is
>>able to give to the outside is its return value.
> Precisely.  What is returned is most important; functions must return 
> consistent results for a given set of parameters, regardless of when they are 
> called or how often.

This is one important aspect, yes, but this definition still allows side 
effects which are disallowed in purely functional languages.

>>In such a pure functional world variables are no longer needed, because
>>you can just use the function call itself where you would otherwise need
>>to use the value that was captured to the variable.
> But within a function, local variables don't affect the return value.  True, 
> every new function a developer writes could be simply nested calls to other 
> functions, but for readability, local variables are very helpful, and as long 
> as they're not global or stateful, they don't affect the return value, so to 
> the outside world it's still just a function.

Yes, I didn't say that aliases for values were forbidden -- they're just 
not necessary in purely functional languages, because you can replace 
every refer with the alias to the computation. It's even reasonable to 
assume that the languages interpreter will automatically factor out 
multiple calls to the same function with the same arguments automatically.

And also note that your program won't be functional anymore when it 
depends on a non-functional function, because calling it is usually seen 
as replacing its call with its body with arguments inserted into the 
right places. (This is inherited from lambda calculus.)

>>The implementation really has nothing to do with this IMHO. It's not
>>really part of the interface after all. :) (And there can be multiple
>>interpreters for the same language all written in different languages of
>>course. The really interesting parts of this are language interpreters
>>that are written in the very same language that they interpret.)
> Think of new functions that developers write in the language as part of the 
> implementation itself.  You can give them tools to write new functions in the 
> language which don't allow them to break the functional language paradigms, 
> such as local variables, just like you can implement a functional language 
> such a C, which is definitely NOT a functional language.

If you give them something then it's part of your interface. If 
non-functionality is part of your interface then you can't be purely 
functional anymore in my opinion.

Regards,
Florian Gross