A niladic function would make hook/fork impossible, right? If I can say
randlist
and have it execute the verb randlist to produce a noun, it follows that
rand =: +: randlist
would also execute the two verbs to produce a noun. (f g) and (f g h)
would cease to be hook/fork and would just execute the verbs.
I guess Ken had to decide whether to have a special class of niladic
verbs that doesn't follow the hook/fork rules, or just prohibiting all
niladics. He chose the latter - unquestionably the right decision.
Niladic verbs are rare and if you want one, you can easily write 3 :
'randlist l' for example.
If you're learning J, stick to explicit definitions and use tacit forms
only when you are sure the spec of the program will never change. And
remember that you can give an explicitly-defined verb a rank with
myverb =: verb define"1
...text...
)
BTW, in J8.06 you can use @ instead of bind.
Henry Rich
On 11/27/2017 12:50 PM, Andrew Dabrowski wrote:
Yes, J has a the function "prompt" that when called with the same
argument can return different values. So J is not a pure functional
programming language like Haskell. That's why I thought it might
allow nullary functions.
I didn't say it was a big problem, it's just a slight problem but one
that came up when I was trying to do something very simple. That's
what worries me: I can't write even simple programs without using what
seem like kludges and workarounds. No doubt after years of practice
those would come to seem natural to me and programming in J would be a
snap, as has happened to me to some extent with Perl. But Perl I was
forced to use, J I have the option of placing in the Museum of
Brilliant but Useless Languages, next to Haskell.
On 11/27/2017 12:30 PM, Daniel Lyons wrote:
On Nov 27, 2017, at 10:03 AM, Andrew Dabrowski
<[email protected]> wrote:
Is J supposed to be a pure functional language, like Haskell?
Outside of that narrow category functions like this are common, and
hard to get around for io - input functions are like this.
I thought I’d look into this specific example and found an
interesting page on the Wiki about the problem of reading user input
interactively:
http://code.jsoftware.com/wiki/User:Ric_Sherlock/Temp/InteractivePrompt
<http://code.jsoftware.com/wiki/User:Ric_Sherlock/Temp/InteractivePrompt>
All of the examples I see relating to I/O wind up requiring an argument:
- The foreign conjunction itself needs some parameters to figure
out which function it is returning
- (1!:1) needs an argument of either file name or file descriptor
- The prompt function defined on that wiki page needs an argument
for what prompt to display
I suspect that this is another case where it seems to us newbies like
it would be a big problem, but in practice it really isn’t. I note
that the addon installation procedure tells you to call the function
with an empty string argument. Every language has to make some
decisions about how to handle functions and those decisions always
have seemingly-obvious downsides. Usually they are compensated for by
other upsides, but the upsides aren’t always totally obvious. Ruby,
for instance, seems to improve on Python by not requiring parentheses
on nullary functions. But you pay for that later when you can’t pass
a function by reference (you must instead wrap it in a block).
Oftentimes increasing the complexity of a language’s function system
has downstream consequences, like worsening performance or
complicating metaprogramming. TANSTAAFL.
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
---
This email has been checked for viruses by AVG.
http://www.avg.com
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
