Oleg Kobchenko <[EMAIL PROTECTED]> writes:
> This caused it:
> >>>
> 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.
> <<<
I can't see any suggestion (explicit or implicit) to program J in a particular
way, or to change the language in the quoted passage (apart from the
undesirability of computing 1 1 1 as ``3{. (1&,^:_)'' or ``3{. (1&,^:100)''
which I assumed most readers of this forum were already aware of).
> I believe it is possible to come up with an equivalent
> expression in Haskell both with needless computations and
> that will hang.
If this belief is based upon the assumption that Haskell is a Turing complete
language and consequently allows you to write programs that will loop forever
or just exhaust the system resources then it is certainly justified. If you
mean `equivalent' in some more specific sense, then I'm afraid you'll have to
be, well, more specific to convey your meaning (code would be ideal, but a
clear description would also do).
> What was this example supposed to demostrate: that
> there isn't such object in J as functionally defined sequence?
No. The example was supposed to demonstrate what lazy evaluation (which isn't
limited to sequences BTW) is about to someone with a background in J but not
functional programming. Just like if I wanted to explain agreement to someone
with a Haskell background, I might start out with "in Haskell, if you type ``3
+ [1,2,3]'' you get a type error, but in J the equivalent (``3 + 1 2 3'') will
give you 4 5 6. This is because ...".
Why did I bring up lazy evaluation, although Roger didn't explicitly ask about
it? Simply to illustrate one of things that become feasible if you (locally)
forgo imperative procedures, such as ``?''. Because without motivating
examples it is impossible to grasp why anyone would want to live with this
limitation and to really understand the nature of the difficulties ``?''
causes. Just like an extended agreement example above might serve as an
motivation for a Haskeller why J can't straighforwardly incorporate lazy
semantics (inter alia laziness is difficult to combine with agreement which is
quite useful for J's target domain). I'm maybe naive in that I would generally
not expect intelligent readers to construe this as an argument that Haskell
should now forgo lazyness and static typing, or that they need to adapt their
language or programming style -- *especially* given that the chosen example is
*obviously* contrived and trivially expressed more naturally otherwise (``map
(+3) [1,2,3]'' viz ``3#1''). Seeing or illustrating the value of something in
a particular context does not equate an implicit endorsement of that thing for
all other contexts and one ought to be especially careful in extrapolating
such value judgements when the specific illustrative example evidently owes
more to the desire of leveraging preexisting knowledge than its practical
relevance.
> -- that's a known fact; how to obtain a subset of such
> sequence by means available in J? -- it was shown in the reply.
I have trouble seeing how your showed such a thing, at least partly due to my
limited mastery of J no doubt. Would you mind demonstrating your technique on
the Hamming sequence (ideally in J5, J6 doesn't seem to run on my version of
linux) which happens to be more or less the canoncial toy illustration for
Haskell's lazy evaluation?
-- Defining the Hamming numbers in haskell (see e.g. wikipedia)
hamming = 1 : map (*2) hamming # map (*3) hamming # map (*5) hamming
where xxs@(x:xs) # yys@(y:ys)
| x==y = x : xs#ys
| x<y = x : xs#yys
| x>y = y : xxs#ys
> take 10 hamming
[1,2,3,4,5,6,8,9,10,12]
To help with the syntax, here's some pseudo lazy-J transliteration:
NB. The Hamming numbers in a hypothetical lazy dialect of J
hamming=: 1, ((2*hamming) merge=.((/:[EMAIL PROTECTED])@(,&{.) , merge&}.)
3*hamming) merge 5*hamming
Of course there are other ways of computing the Hamming sequence, this one
just has the attraction that it is particularly elegant (in that it closely
mirrors how one would normally define them). And need I mention that I do not
hold the elegance with which the hamming sequence may be expressed in a
particular programming language as a good metric for the overall merit of that
language?
> This is the distinction between a wrong answer and
> a wrong question.
You've lost me. I have no idea what any of the nouns in this sentence might
refer to.
>
> If you need syntactic sugar, it is also available in J
>
> ones=: 1 & ,
> take=: ^:
>
> ones take 3 ''
> 1 1 1
This isn't syntactic sugar it's nonsense (Haskell's ``take'' has nothing to do
with ``^:'', it is just like ``{.'').
'as
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
