New concise guide I am creating:
http://www.coolpage.com/commentary/economic/shelby/Functional_Programming_Essence.html
I was able to condense Category theory and implementation of Monads to one
screen:
Simon Marlow replied:
http://www.haskell.org/pipermail/cvs-ghc/2009-November/050946.html
=
Also I received privately a very much appreciated and stimulating reply
about the convolution of the competition for the shared resources in the
external state machine. My quick (not deeply
stimulating reply
about the convolution of the competition for the shared resources in the
external state machine.
Apparently the concurrency problem is potentially convolved with external
state in much more convoluted and intertwinded spaghetti:
Shelby Moore wrote:
...A type class is a polymorphic
(relative to data type) interface, and the polymorphism is strictly
parameterized for the client/consumer of the interface, i.e. the data
type
is known to the function that inputs the interface AT COMPILE TIME.
...A problem with virtual
Shelby Moore writes:
* 1856 Thermo Law: entire universe (a closed system, i.e. everything)
trends to maximum disorder.
Will Ness wrote:
On the very, *very*, VERY long timescale.
I love your ascii art :)
Note I put it last in the list for reason.
Not to be combative, but your statement
I was correct before, except I conflated the word extended with
eliminated in my mind:
http://lambda-the-ultimate.org/node/1277#comment-51723
The most robust solution to Tim Sweeney's problem is to rethink what a
class should be:
Magicloud wrote:
I am not saying that the code has to be in OO style. When I say OO is
general, I mean I am thinking in OO style. This reflects on modeling,
program structure, even code organization.
Style is how we present things. I think that is less important than
how we think about
The style of OOP is irrelevant, and if one means by style the
conflation of the interface with the data and/or use of virtual (runtime)
base class inheritance and the style of that induces, then it is an
architectural mistake:
Opportunity cost minimization problem:
No no no! Why not download the normal (signed) cabal list from the
DHT (and optionally directly from hackage.haskell.org)? These are all
the packages that would appear on the website. Why serve any other
content? All nodes in the DHT may check and
This is an opportunity cost minimization problem:
http://www.haskell.org/pipermail/haskell-cafe/2009-November/068435.html
One of the worst (most unoptimized and conflated) solutions is to force
some determinism at the low-level language architecture specifically
targetted to achieve determinism
Thus my analysis so far is Haskell has it correct, and I am suggesting the
missing optimization is to let us automatically put an upper bound on the
space non-determinism (the topic of this thread), then the programmer can
optimize beyond that with...
Arghh, the mailing list web archive did
Shelby Moore wrote:
...A type class is a polymorphic
(relative to data type) interface, and the polymorphism is strictly
parameterized for the client/consumer of the interface, i.e. the data type
is known to the function that inputs the interface AT COMPILE TIME.
...A problem with virtual
I found the post at the following link to be the most useful in explaining
declarative versus imperative:
http://www.haskell.org/pipermail/haskell-cafe/2009-September/067000.html
Here follows what I want to add to the discussion:
Shelby Moore wrote:
The most accurate question should be, How do you add some numbers with
minimized instructions?, because it forces them to realize they must
order the set.
An answer might be, Zero if empty, else order the set, sum the first
number with the sum of remainder of the set
http://www.haskell.org/pipermail/cvs-ghc/2009-October/050928.html
Shelby Moore wrote:
One possible runtime optimization to provide an upper bound for cache
control, might be to not cache thunks when the runtime computation time
times number of cache hits, is less than the round-trip paging time
15 matches
Mail list logo
