On Fri, Mar 30, 2012 at 5:37 AM, Boyko Bantchev wrote:
>>> (f∘g)(x) ≡ f(g(x))
>> In the original definition, which led us to this point, there
>> was no statement that f and g had domains.
>
> Are there functions without domains? Since when is it customary to
> explicitly enunciate suc
On 30 March 2012 01:01, Raul Miller wrote:
>
This time I am not going to answer everything in sequence ...
I'll start with where I was apparently mistaken:
the expression f(g(x)), with x an adverb, indeed can be equivalent
to f@g, as you asserted. So, ok, J lets us express f@g in t
Sent: Thursday, March 29, 2012 11:04 AM
To: Programming forum
Subject: Re: [Jprogramming] J functors
Boyko Bantchev wrote:
>> Definitions do not eliminate ambiguity.
> Speaking of formal definitions, I would say they ought to. There is
> not much use of defining formally and ambiguous
On Thu, Mar 29, 2012 at 2:09 PM, Boyko Bantchev wrote:
> (f∘g)(x) ≡ f(g(x))
>>
>> And yet, f and g are not defined here, and neither are x.
>
> Because of course they need not to. Whatever the domains and codomains
> of f and g, they do not change the meaning of composition as defined
have gained some insights about the (L:) conjunction in general
and (L:0) and (L:_1) in particular (it is now more clear to me why the latter
behaves similar to (&.>) while preserving some structural features of the
modified verb arguments).
From
(f∘g)(x) ≡ f(g(x))
>
> And yet, f and g are not defined here, and neither are x.
Because of course they need not to. Whatever the domains and codomains
of f and g, they do not change the meaning of composition as defined by
the above identity.
But leave that identity, and consider ho
On Thu, Mar 29, 2012 at 9:07 AM, Boyko Bantchev wrote:
>>> @: (or &:) is said to produce a verb of infinite ranks (of which,
>>> here, we are only interested in the monadic case). As I understand
>>> it, this can only be achieved by modifying the ranks of the arguments
>>> and/or the rank of the
Boyko Bantchev wrote:
>> Definitions do not eliminate ambiguity.
> Speaking of formal definitions, I would say they ought to. There is
> not much use of defining formally and ambiguously.
There is a formal definition for "formal". It does not mean
"unambiguous". In fact, it turns out that we can
>> @: (or &:) is said to produce a verb of infinite ranks (of which,
>> here, we are only interested in the monadic case). As I understand
>> it, this can only be achieved by modifying the ranks of the arguments
>> and/or the rank of the result.
>
> The rank of a verb is a part of the definition o
On Wed, Mar 28, 2012 at 6:27 PM, Boyko Bantchev wrote:
>>> (f∘g)(x) ≡ f(g(x))
>>
>> Definitions do not eliminate ambiguity.
>
> Speaking of formal definitions, I would say they ought to. There is
> not much use of defining formally and ambiguously.
And yet, f and g are not defined here, a
On Thu, Mar 29, 2012 at 3:30 AM, Boyko Bantchev wrote:
>> Are not Atop and At both able to keep, or alter, the rank at which an
>> argument verb is applied? I think whether rank is changed depends on the
>> rank of the verb.
>
> @: (or &:) is said to produce a verb of infinite ranks (of which,
> h
> Are not Atop and At both able to keep, or alter, the rank at which an
> argument verb is applied? I think whether rank is changed depends on the
> rank of the verb.
@: (or &:) is said to produce a verb of infinite ranks (of which,
here, we are only interested in the monadic case). As I understa
> f@:g and f&:g (in their monadic cases) are equivalent
> but are not the composition of f on g; what they
> compose is the results of changing (the ranks of) their
> arguments rather than the arguments themselves. The
> same holds of [: f g (in its monadic case).
Are not Atop and At both abl
>>(f∘g)(x) ≡ f(g(x))
>
> Definitions do not eliminate ambiguity.
Speaking of formal definitions, I would say they ought to. There is
not much use of defining formally and ambiguously.
> One issue, here, is that the definitions of f, g and x are contextual.
What do you mean by 'contextua
On Tue, Mar 27, 2012 at 8:16 PM, Boyko Bantchev wrote:
>> In essence the Haskell definition of "Functor" is meaningless until we
>> nail down the definition of "Composition".
>> Of course, if we are working in Haskell, it comes with an
>> implementation and, thus, a definition for composition.
>
>
> In essence the Haskell definition of "Functor" is meaningless until we
> nail down the definition of "Composition".
> Of course, if we are working in Haskell, it comes with an
> implementation and, thus, a definition for composition.
The definition of composition in Haskell comes with the defini
Yes...
In essence the Haskell definition of "Functor" is meaningless until we
nail down the definition of "Composition".
Of course, if we are working in Haskell, it comes with an
implementation and, thus, a definition for composition. But that is
not the case in J.
Still, for the examples here,
> And, since the earlier reference was discussing ocaml implementations,
> I think we can assume that my first post was focusing on the ML
> meaning of functor.
That reference discusses how the Haskell (not ML) meaning of functor
can be implemented (in OCaml).
However, it (as well as the posts in
On Tue, Mar 27, 2012 at 2:15 PM, Raul Miller wrote:
> Marc Simpson also mentioned http://www.catonmat.net/blog/on-functors/
>
> This describes how the term "functor" means different things in the
> context of different languages.
>
> And, since the earlier reference was discussing ocaml implementa
Marc Simpson also mentioned http://www.catonmat.net/blog/on-functors/
This describes how the term "functor" means different things in the
context of different languages.
And, since the earlier reference was discussing ocaml implementations,
I think we can assume that my first post was focusing on
fmap=. L:0
-Original Message-
From: Marc Simpson
Sent: Tuesday, March 27, 2012 6:08 AM
To: Programming forum
Subject: Re: [Jprogramming] J functors
Nice example. I also like the phrase "the idea of a functor" as
I'm not sure that we can claim these J cases are for
Nice example. I also like the phrase "the idea of a functor" as
I'm not sure that we can claim these J cases are formally
identical in the absence of a static type system.
With that said, we can simplify things a bit to make Aai's
approach even clearer:
Consider the task of squaring "some" intege
Another nice example of the idea of functor in Haskell is illustrated
with a binary tree (type) with e.g. string leaves:
]tree=. 'appel';<'peer';'pruim'
┌─┬┐
│appel│┌┬─┐│
│ ││peer│pruim││
│ │└┴─┘│
└─┴┘
In Haskeel you have to define a fu
J in fact involves two types of functors: arrays as discussed, and
functions.
"Mapping" over functions is a bit harder to visualize, but it's helpful to
think of a function as a value that depends on its input. In this case,
when we apply a fork to two functions in order to refer to their values (o
When I read about functor, in the sense used in that blogpost, I think that
at least one such functor is built in to J so that it is somewhere between
stilted and impossible to create examples that *don't* involve functor.
It seems that way to me because mapping is implied by the underlying
relati
http://blog.0branch.com/implementing-functor-in-ocaml
"A Functor is (somewhat informally): a structure that provides a
mapping operation that applies to a value in a given context,
preserving that context."
In other words, this is probably an example of a functor:
A=: 2 3 5 7 11 13
F=: *:
26 matches
Mail list logo
