On Sun, Feb 17, 2013 at 5:28 PM, Boyko Bantchev <[email protected]> wrote:
> On 17 February 2013 19:43, Raul Miller <[email protected]> wrote:
>> For example, a dictionary search (using
>> http://www.google.com/cse/home?cx=016147560673599814097:rk5jmigdjse)
>> for the phrase "functional programming" finds me zero results.
>
> So you are out of luck.  Sorry, can't help.
>
>> I wish you would provide specific references, instead of vague references.
>> The only message I see from him in this thread is:
>
> It is the only message (itself of 2+ lines) and you call it 'vague
> references'?  Again, sorry, but cannot help you.

My issue, here, was that the references do not seem to support the
statements you made.  If you cannot help me, I will take that as a
lack of interest on your part, in discussing those statements, and
will drop further discussion (after noting that I am dropping it -
something I feel socially compelled to provide).

>> Anyways, I do not see enough material here to think that I have a
>> valid basis for submitting a change to the wikipedia page describing
>> functional programming.
>
> I don't have even the slightest interest about whether you are
> contemplating editing anything or not, so please do not feel obliged
> to keep me informed on this otherwise extremely important subject.

Here, my issue was that you were indicating that the text was invalid.
 Since you are now expressing no interest in making a consistent,
valid rephrasing of that text, I will drop it.

>> Here, the phrase I have problems with is "not those of".
>
> As you yourself confess, the one that has problems is you.

Indeed.  I do.

Solving problems I do not have is beyond my abilities. Solving
problems I do have is sometimes within my abilities.

>> In a language which I would call a purely functional programming
>> language, there's no distinction between closures and currying.
>
> If you really think so, your problems with regard to understanding
> basic functional programming concepts are more serious than it was
> apparent so far.

Excellent. Please provide a clear example of this difference.

Or did you mean that there was a syntactic difference in some
languages? That is a non-issue, from my  point of view - that's like
saying 1+1 is different from 2 because we use different characters.

>> In J, we might implement that like this:
>
> As far as closures are discussed, it is completely irrelevant whether
> or how you model a specific example in J.  Having closures means
> automatically capturing non-locals that emerge from nesting.  You
> might consider an example where *that* general concept is modelled,
> but, of course, there is no function nesting in J, to start with.

First, it is  not completely irrelevant.  Notice, for example that the
email address we are using is <[email protected]>

Second, only referenced non-locals are captured.

>> On the other hand, there's not enough code, here, to implement Paul
>> Graham's challenge -- the existence of lambdas alone does not give
>> you the persistent state changes that he was asking for.
>
> Graham's 'accumulator generator' requires more than lambdas.  It even
> requires more than lambdas with closures.  In addition to these, it
> requires that changing state (i.e., changing the values of certain
> variables) is possible.  But again, as far as closures themselves are
> discussed, whether Graham's problem requires anyting beyond stateless
> functions is not of relevance.

I think that it's relevant since your original post in this thread
http://jsoftware.com/pipermail/programming/2013-February/031561.html
opened by claiming that a page discussing Graham's challenge was
false.

>> Certainly.  And we can use f. to fix this (for example) or we can
>> simply not redefine words.
>
> You can also abstain from programming at all – then the possibility
> of producing a stateful function almost vanishes.

Yes, but that's a trivial (empty) approach to programming.  But
perhaps a fruitful source of empty array jokes. Except perhaps,
without any arrays.

That said, it would be interesting, I think, to implement a foreign
with a scope similar to 18!:4 which disables disables =: on names with
definitions and =. on names in locales.  (The resulting scope would be
non-interactive, I imagine, so it's important for the interactive
environment that it be possible to use this in a temporary context.)

>> A similar issue arises with Haskell when you edit the file and
>> recompile, or when you copy and paste and expression into some other
>> program (perhaps involving multiple programmers with blog posts or
>> email messages as a transport for the code snippets).
>
> Oh, dynamic binding in one programming language is similar to editing
> text in another one?  A very interesting concept.

Well, not so much "editing" text but using additional text -- if we
had our roles reversed in this conversation I expect you would be
pointing out to me that "editing" of text is not necessary, the only
necessary element is having multiple textual contexts and the details
of how that text came to exist does not need to be specified.  That
said: yes - that's close enough to be considered accurate.

Haskell from the sort of  interactive development (debugging, testing
of alternatives) has I think been an important part of the reason that
J allows names to be rebound with new definitions.

Note, also, that J has in some cases restricted the scope of this
effect, when that made implementation easier.  I can show examples of
that issue, if you like (though most likely you are not interested).

FYI,

-- 
Raul
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to