Sets are functions in Clojure, and so are vectors, but lists are not.
Are arrays functions?
131–140 of 145 posts
Re: Are arrays functions?
#132An array is a function that can be mutated at runtime. That’s essentially the main difference.
Depending on how you look at things, functions can also be mutated at run-time. Most impure languages allow you to define a function that has some internal state and changes it whenever it is applied. In C you would use 'static' variables, but languages with closures allow for a more robust approach. Scheme textbooks are full of examples that use this trick to define counters or other objects via closures. You can we…
Functions are rarely used this way, it’s bad practice. Typically when this is done the mutating state is scoped in an object and the function is not called a “function” it’s called a method.
Re: Are arrays functions?
#133Earlier quoted context omitted.
Memoization is a different way around though. You're turning part of a function into an array and a traditional function is still in charge. It doesn't depend on arrays being functions. I would also reject the idea that "Arrays are Functions" is equivalent to "Functions are Arrays". They're both true in a sense, but they're not the same statement.
We're talking past each other because we're using different definitions. If you actually read the article you'll see that the type of arrays and functions they're talking about are not necessarily the types you'll find in your typical programming language (with some exceptions, as others noted) but more in the area of pure math. The insights one can gain from this pure math definition are still very much useful for r…
> If you actually read the article
Needless.
> The insights one can gain from this pure math definition are still very much useful for real world programming tough (e.g. memoization), you just have to be careful about the slightly different definitions/implementations.
I agree completely here. But I think that undermines some of the earlier claims. The math definition only serves as inspiration, we're not using the math definition when we memoize. And the important part you need for that inspiration is a lot narrower than full equivalence.
Re: Are arrays functions?
#134Earlier quoted context omitted.
> One doesn't have to presume anything, there are general principles that people eventually find are true after plenty of experience. I guess I just disagree with you here. Plenty of programmers with decades of experience have found no such general principle. There is a time and place for everything and dogmatic notions about "never conflate X and Y" because they're "fundamentally different" will always fall flat due…
What is worthwhile to ponder has no bearing on what you say. Ponder all you want, but what you said wasn't a reply to what I said. Decades? You think that decades is long enough to get down to the fundamentals of a domain? It is enough for this because people have been going around in circles constantly the entire time. It isn't the same people, it is new people coming in, thinking up something 'clever' like conflati…
It is clear now that you don't understand the claim. It sounds like like you're conflating pure and impure functions. It's obvious from context (did you even read the blog post?) that the title of the blog post is referring to pure functions.
You obviously can't treat an impure function as an array and no one would ever claim that. The blog itself isn't claiming that either given that the author is commenting on a nugget from Haskell documentation, and the author is explaining design choices in his own pure functional language.
Your three points only make sense if you're definition of "function" allows side effects. If we're talking about pure functions, then due to referential transparency, arrays are in fact equivalent to functions from contiguous subsets of the integers to another type, as the Haskell documentation indicates.
Re: Are arrays functions?
#135Earlier quoted context omitted.
That's not really the lens I'm looking at it through. It's just entertaining that we're still discussing array function equivalence in the year of our lord 2026, long after every mainstream language supports said equivalence in practice.
I suspect there are two points you haven't fully understood: 1. The equivalence being discussed is not supported in "every mainstream language" in practice. If you disagree, read https://news.ycombinator.com/item?id=46699933 for a good overview of the equivalence in question and explain how you think mainstream languages support that. 2. The current discussion is in the context of a language targeting CUDA. Currently…
> very few languages aside from C++ have good CUDA support
CUDA happens to be (loosely) source-compatible with C++, but I'm not sure that's the same as saying C++ has good CUDA support. The majority of C++ code does not compile to CUDA (although the inverse is often true).
> C++ certainly doesn't achieve that by having its arrays be equivalent to functions "in practice" or in any other sense
The syntax may not be unified, but what else do you think iterators are for? They are an abstraction to let us ignore pesky details like the underlying storage of arrays, and instead treat them like any other generator function. This is perhaps more evident in a language like Python where generators and iterators are entirely interchangeable.
> in Futhark an array type such as [n]f64 explicitly indicates its size (and consequently the valid indices), which can even be extracted at run time. This is not possible with functions
These are specific oddities of Furthark - we have languages (i.e. C/C++) where the size of an array is not knowable, and we have languages where the range of inputs to a function are knowable (at least for numeric inputs, i.e. Ada)
> Futhark imposes restrictions on how functions can be used; for example banning returning them from branches. These restrictions are not (and ought not be!) imposed on arrays
Again, this is a case of Furthark's own design decisions restricting it. This is only a problem because their arrays are carrying around runtime size information - if they didn't have that, one wouldn't be able to usefully return them from branches anyway. Alternately, there are plenty of ML-family languages where you can return a function from a branch.
Re: Are arrays functions?
#136Earlier quoted context omitted.
We're talking past each other because we're using different definitions. If you actually read the article you'll see that the type of arrays and functions they're talking about are not necessarily the types you'll find in your typical programming language (with some exceptions, as others noted) but more in the area of pure math. The insights one can gain from this pure math definition are still very much useful for r…
> If you actually read the article Needless. > The insights one can gain from this pure math definition are still very much useful for real world programming tough (e.g. memoization), you just have to be careful about the slightly different definitions/implementations. I agree completely here. But I think that undermines some of the earlier claims. The math definition only serves as inspiration, we're not using the m…
> And the important part you need for that inspiration is a lot narrower than full equivalence.
The blogpost is discussing exactly what you gain (and lose) when arrays and functions fit this strict definition, allowing a unification of the syntax and possible compiler optimizations. I think the point they're making is exactly that having only a loose equivalence between arrays and functions might be a programming status quo that could be holding us back from a higher level abstraction.
Re: Are arrays functions?
#137Earlier quoted context omitted.
What is worthwhile to ponder has no bearing on what you say. Ponder all you want, but what you said wasn't a reply to what I said. Decades? You think that decades is long enough to get down to the fundamentals of a domain? It is enough for this because people have been going around in circles constantly the entire time. It isn't the same people, it is new people coming in, thinking up something 'clever' like conflati…
It is clear now that you don't understand the claim. It sounds like like you're conflating pure and impure functions. It's obvious from context (did you even read the blog post?) that the title of the blog post is referring to pure functions. You obviously can't treat an impure function as an array and no one would ever claim that. The blog itself isn't claiming that either given that the author is commenting on a nu…
It sounds like like you're conflating pure and impure functions.
No I'm not, this applies to both in different ways.
If we're talking about pure functions, then due to referential transparency, arrays are in fact equivalent to functions
Never ever. You're talking about a function that generates data from an index, which is trivial to make. Just because it is possible to disguise it as an array in haskell, C++ or anything else doesn't mean it is a good idea. An array will have vastly different properties fundamentally and can be examined at any time because the data already exists.
Confusing the two is again conflating two things for no reason. Making a function that takes an index and returns something is a trivial interface, there is no value in trying to mix up the two.
Evidence of this can be found in the fact that you haven't tried to explain why this is a good idea, only that it works under haskell's semantics. Being clever with semantics is always possible, that doesn't mean conflating two things and hiding how things actually work is a good idea.
Re: Are arrays functions?
#138Earlier quoted context omitted.
> If you actually read the article Needless. > The insights one can gain from this pure math definition are still very much useful for real world programming tough (e.g. memoization), you just have to be careful about the slightly different definitions/implementations. I agree completely here. But I think that undermines some of the earlier claims. The math definition only serves as inspiration, we're not using the m…
> And the important part you need for that inspiration is a lot narrower than full equivalence. The blogpost is discussing exactly what you gain (and lose) when arrays and functions fit this strict definition, allowing a unification of the syntax and possible compiler optimizations. I think the point they're making is exactly that having only a loose equivalence between arrays and functions might be a programming sta…
> I think the point they're making is exactly that having only a loose equivalence between arrays and functions might be a programming status quo that could be holding us back from a higher level abstraction.
Maybe. I'll sit here ready for those insightful uses of stricter connections.
But the memoization example is very loose, and memoization is what I was replying to.
Re: Are arrays functions?
#139Earlier quoted context omitted.
Yes, and as you point out even conditional statements. In Smalltalk constructs like b ifTrue: [ ... ] mean that the boolean value 'b' has its method (-function) ifTrue: called with the argument [...] which is a "closure" meaning it is a free-standing function (as opposed to bound functions which are the methods). There are similarly library methods in class Boolean for whileTrue: etc. Functions all the way. What woul…
Right.. So not only all data structures and operators, but all kinds of control flow can be described as functions. What an interesting way to look at programs, I'll study more in this direction. I wonder how languages support this question of "unevaluated arguments", like in the `if` conditional function. I guess in Lisp(s) they're simply quoted expressions, and in the above Smalltalk example, it sounds like the syn…
I think that's right. The "closure" is a function, it is not called until method #ifTrue: of the boolean value in question gets it as argument. But it is not just "a function", it is a "closure" meaning it carries with it values from its outer scope that were there at the time the #ifTrue: -method was called, which includes arguments to the outer method being called.
Re: Are arrays functions?
#140Earlier quoted context omitted.
It is clear now that you don't understand the claim. It sounds like like you're conflating pure and impure functions. It's obvious from context (did you even read the blog post?) that the title of the blog post is referring to pure functions. You obviously can't treat an impure function as an array and no one would ever claim that. The blog itself isn't claiming that either given that the author is commenting on a nu…
It sounds like like you're conflating pure and impure functions. No I'm not, this applies to both in different ways. If we're talking about pure functions, then due to referential transparency, arrays are in fact equivalent to functions Never ever. You're talking about a function that generates data from an index, which is trivial to make. Just because it is possible to disguise it as an array in haskell, C++ or anyt…
Notice that I never once in this discussion claimed that it was a "good idea". This is about research and experimentation. The blog post has the title because of the Haskell documentation. Also, claiming that the lack of an argument is evidence to the contrary is argument from silence, a logical fallacy.
The good idea surrounding this isn't about treating functions as data, but maintaining the purity of the type system allowing the implications of the type system to run their course. You seem to be a very pragmatic programmer and so the way Haskell builds up its own universe in terms of its own type system and Hask (the pseudo-category of Haskell objects) probably seems pointless to you. I can't say for certain, though.
I completely reject most of your claims because they appear to be incoherent within the framework of type theory and functional programming. It looks like you're using reasoning that applies only to procedural programming to attempt to prove why an idea in functional programming is bad.