The J equivalent of the expression below will
also print the same and require 3 concats:
(3{.1,])^:_ ''
1 1 1
There were earlier attempts to fit J into the
wrong mold. Why just not use it the way
it works best?
----- Original Message ----
From: Alexander Schmolck <[EMAIL PROTECTED]>
To: General forum <[email protected]>
Sent: Monday, July 3, 2006 5:10:06 PM
Subject: Re: [Jgeneral] J as a functional programming language
R&S HUI <[EMAIL PROTECTED]> writes:
I'm not an expert, but ...
> What are the problems with ? for functional programming,
> other than the definitional one?
Incorporating it and other side-effecting/imperative code without loosing the
benefits of functional programming.
The main advantages of functional programming over imperative programming is
that the stronger invariants make it easier to 'see' or prove things about the
code and that it allows a more abstract, declarative style. One thing that
this entails that certain optimizations become easier. By referential
transparency you can always replace EXP by A in a single scope if you know
that A = EXP somewhere in that scope. Also, if you know your functions are
pure you don't need to actually evaluate them unless you need the result to
which they evaluate. So not only does order of evaluation not matter (which
inter alia allows for parallel computations), you can get completely around
evaluation in many cases.
There is of course compile-time dead code elimination in many imperative
languages, but lazy languages offer a much more powerful run-time
optimization: evaluation only happens on a per need basis.
Take the follwing simple example in J:
3 {. (1&,^:100) ''
This will produce
1 1 1
but only after needlessly performing 100 concatenations.
3 {. (1&,^:_) ''
Will hang.
The Haskell equivalents of the expressions above (e.g. ``take 3 (repeat 1)'')
will print 1 1 1 and only 3 concatenations will be carried out. This means
that one may use expressions that carry out infinite computations or
computations that will fail at a certain point without the program
neccessarily looping forever or aborting, which adds quite a bit of
expressiveness to the language. Here is another cute example ( ``:'' is
atom-onto-list concatenation) :
> let ints = 0 : map (+1) ints
> take 3 ints
[0,1,2]
Typing ``ints'' in the prompt is a bad idea, though.
It is maybe not too difficult to see how mixing lazyness and imperativeness
can result in major headaches (think how much fun it would be if you couldn't
easily predict if your print statements will ever be executed and if so in
which order) -- it seems to be no accident that all lazy languages happen to
be purely functional (see category 2 below).
> Whatever functional programming is, it would be poorer if it can not
> accommodate ? (rule out Monte Carlo methods, etc.)
Of course all functional programming languages provide rand procedures like
``?''. There are two main schools:
1. Impure functional languages (prime example: Ocaml): although these
languages emphasize state free programming paradigms, they also allow to
mix in imperative programming in a pretty straighforward fashion.
If one squints a bit one could almost see J belonging to this group (the
main things that are missing IMO are proper tail recursion and proper
lexical scoping and one could certainly imagine a J variant that supplies
them).
2. Pure functional programming languages (prime example: Haskell): These
languages essentially completely isolate functional code from imperative
code (but not vice versa). That means a pure function (something like
``+'') could never call a side-effecting procedure like ``?'', but the
other direction is of course fine. In Haskell this separation (and much
else) is effected via Monads. BTW, Haskell also offers a random *function*
(that for each call apart from returning a 'random' number also takes and
returns a generator state), but generally one would want to hide this
plumbing via appropriate Monads.
The upside of 2. is that it allows lazyness and other neat things, the
downside is that it means a major paradigm shift that takes some getting used
to; it also can be difficult to intuit computational performance and memory
consumption. Hence Ocaml has a more pragmatic reputation that Haskell, but
significant real world code has been written in both languages.
'as
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
