Jump to content

Talk:Function-level programming

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by SmackBot (talk | contribs) at 07:39, 10 September 2010 (Date maintenance tags and general fixes: build 514:). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.


Untitled

What would be an example of a function-level definition which is not the lifted image of a value-level one?

I am not sure there is a reasonable answer to that question. It is more of a notational and usage question. Composition can only be defined (other than as a primitive) as (f . g)(x) = f(g(x)). The notations are equivalent semantically, but computationally and for optimisation and implementation they may be different - function-level programming will clearly have composition as a primitive. Justinc 23:16, 4 August 2005 (UTC)[reply]
In general, program A and program B are significantly different when they reflect a different architecture. This tends to be relevant only for complex programs with significant structure, which have been derived independently in different contexts. This is where you would tend to see function-level programs which are not simple translations of value-level programs. Of course, once a design is implemented it will be possible to apply that design in other contexts -- the real issue here is the original time and effort needed to find and implement the design. That said, it's difficult to separate architectural influences from the language and architectural influences specific to function-level programming. This is especially true given that there are so few function-level programming languages. With those qualifiers, the J program to compute arithmetic mean (+/%#) illustrates in a small way how a function-level definition can be different from a typical value-level definition. Here, the absence of explicit variables quickly leads to a definition which works on arbitrarily sized and dimensioned data, with the language, rather than the programmer, defining the function domain. RaulMiller 06:04, 22 March 2006 (UTC)[reply]

Did the author really mean bottom-up semantics or did they mean to say bottom-preserving semantics?

After re-reading the entries on the FP programming language and strict functions I think he must have meant bottom-preserving semantics. RaulMiller 06:20, 22 March 2006 (UTC)[reply]
I also believe that "bottom-preserving semantics" is what was meant. John Nowak (talk) 02:15, 20 April 2009 (UTC)[reply]

It should be mentioned that in the end (the compiled program or similar) its all value level. whether you store data, function pointers etc. pp. so the distinction isnt between the way the programs execute but in how the humans perceive them

There's no reason to mention this. The language is function-level "in the end". Talking about the resulting binary isn't relevant. John Nowak (talk) 02:14, 20 April 2009 (UTC)[reply]

Misworded sentence

"Yet another is the existence of function level definitions that are not the lifted (that is, lifted from a lower value-level to a higher function-level) image of any existing value-level one: these (often terse) function-level definitions represent a more powerful style of programming not available at the value-level and, arguably, are often easier to understand and reason about."

Right after the closing parenthesis. -- Dougher (talk) 06:30, 30 April 2010 (UTC)[reply]