Add J

[RustemB]

• Name: J

• Website: https://www.jsoftware.com/

• Language Version: j807, j901

• Test Frameworks: just load file/script and use needed functions

• How to install:

# for j901
$ wget http://www.jsoftware.com/download/j901/install/j901_amd64.deb
$ sudo dpkg -i j901_amd64.deb
# for j807
$ wget http://www.jsoftware.com/download/j807/install/j807_amd64.deb
$ sudo dpkg -i j807_amd64.deb

---

• Installing (see above)
• Executing (jconsole)
• Testing
• Editing. CodeMirror mode. (J mode for CM 4.2)
• Icon (https://github.com/file-icons/icons/blob/master/svg/J.svg)

[Steffan153]

This would be interesting, but I think it would be tricky to get a working setup.

[g964]

The author will have to write tests using some J primitives since there are no testing framework. CW could concatenate the solution and the tests and run the whole but I know nothing about the CW runner. I wrote something from the "multiply" kata for J :

multiply =: 4 : 0
   x * y
)

testing =: 3 : 0
   t =. (actual = expect)
   if. t = 0 do. 
        echo 'Incorrect value, expected is: '
        echo expect
        echo 'but got: '
        echo actual
   else.
      echo 'correct'
      echo 'actual'
      echo actual
      echo 'expect'
      echo expect
   end.
   assert. t = 1
)
fixedtests =: 3 : 0 
   actual =: 5 multiply 8
   expect =: 40
   testing ''
   echo '---------------'
   actual =: 8 multiply 9
   expect =: 72
   testing ''
   echo '---------------'
   actual =: 10 multiply 1000
   expect =: 9999
   testing ''
   echo 'End of fixed tests'
)

fixedtests ''

The last test fails and tests are stopped without echoing 'End of fixed tests'.
The solution part is the function "multiply" and after that the tests part. You can try it at "tio" with the first two parts in "code" and the "fixedtests ''" part in input. You get the result in "output".

[RustemB]

There are many other ways to produce test units

[g964]

@RustemB: could be good if you gave something with details:-)

[Steffan153]

We could write our own test framework and just include it, right?

[kazk]

Yes, anything should work as long as it produces the Codewars output. We should use the existing tools when possible though.
How does J developers write tests?

[Bubbler-4]

How does J developers write tests?

Usually it's done using the built-in assertion primitive assert., but on assertion failure it gives a fixed output:

assert. 1 = 0
|assertion failure: examplePgm
|   1    =0

(And it can be turned off using system functions.)

So I think we will need a custom test framework. But we have a special challenge here because J does not allow multi-line statements or nesting multi-line definitions. Do we have other languages with similar constraints?

[kazk]

I found this: https://github.com/jsoftware/general_unittest

Can we fork that and customize the test output?
https://github.com/jsoftware/general_unittest/blob/c0916768bba3832fbb9bf2305d34575a5adc0ad0/unittest.ijs#L21-L62

But I guess we can only produce top level assertion results without test names with that.

---

So I think we will need a custom test framework. But we have a special challenge here because J does not allow multi-line statements or nesting multi-line definitions. Do we have other languages with similar constraints?

Can you elaborate? Do you mean it's not easy to have the test name and the test duration because of J's limitation?

[Bubbler-4]

I thought it's not easy to visually simulate how the test cases are written in other languages. That unittest library does look promising (though it might still need a complete rewrite for our needs, it's indeed worth taking a look).

[mlliarm]

Hello !

I'm not that well versed with J yet (currently learning APL), but I've found the following information about testing J programs:

• https://code.jsoftware.com/wiki/Addons/Test_scripts
• https://code.jsoftware.com/wiki/Addons/general/unittest (adds more information on the unittest Github repository you've already found, plus it has some examples of its use)

Hopefully people more knowledgeable than me in J will jump in and help, as it seems to me that the APL/j/k/... (array lang.) community just took notice of this feature request.

Cheers !

[Bubbler-4]

With the newly introduced {{...}} notation, I think I've got some nice way to write down tests. (Which makes this limited to J900 or higher, but I don't think J80x support is necessary after all.)

FmtMsg =: (LF;'<:LF:>')&stringreplace

Display =: {{
  'type message' =. y
  echo LF,'<', (toupper type), '::>', FmtMsg message
}}

FmtValue =: {{
  s =. ": y
  ([: , ,.&LF)^:(<:#$s) s
}}

NB. [failure message] Expect value
NB. 0 is treated as failure, anything else OK
Expect =: 'Value is not what was expected'&$: : {{
  'failmsg value' =. x;y
  {{
    Display 'PASSED';'Test Passed'
  }} ` {{
    Display 'FAILED';y
  }} @. (0=y) failmsg
}}

NB. [failure message] AssertEq (actual ; expected)
NB. Use ,&< in place of ; if either side may be boxed
AssertEq =: {{
  'actual expected' =. y
  msg =. (FmtValue actual), ' should equal ', FmtValue expected
  msg Expect actual -:!.0 expected
  :
  'actual expected' =. y
  msg =. x, ': ', (FmtValue actual), ' should equal ', FmtValue expected
  msg Expect actual -:!.0 expected
}}

NB. [failure message] AssertNotEq (actual ; expected)
NB. Use ,&< in place of ; if either side may be boxed
AssertNotEq =: {{
  'actual expected' =. y
  msg =. (FmtValue actual), ' should not equal ', FmtValue expected
  msg Expect -. actual -:!.0 expected
  :
  'actual expected' =. y
  msg =. x, ': ', (FmtValue actual), ' should not equal ', FmtValue expected
  msg Expect -. actual -:!.0 expected
}}

NB. [failure message] AssertApproxEq (actual ; expected)
NB. Use ,&< in place of ; if either side may be boxed
NB. J has tolerant comparison built-in, but it cannot be set higher than 2^_34
AssertApproxEq =: {{
  'actual expected' =. y
  msg =. (FmtValue actual), ' should approximately equal ', FmtValue expected
  msg Expect actual -:!.(2^_34) expected
  :
  'actual expected' =. y
  msg =. x, ': ', (FmtValue actual), ' should approximately equal ', FmtValue expected
  msg Expect actual -:!.(2^_34) expected
}}

Describe =: {{
  Display 'DESCRIBE' ; u
  starttime =. 6!:9 ''
  v ''
  endtime =. 6!:9 ''
  elapsed =. (endtime - starttime) % 6!:8 ''
  Display 'COMPLETEDIN' ; 0j6 ": elapsed
}}

It =: {{
  Display 'IT' ; u
  starttime =. 6!:9 ''
  v ''
  endtime =. 6!:9 ''
  elapsed =. (endtime - starttime) % 6!:8 ''
  Display 'COMPLETEDIN' ; 0j6 ": elapsed
}}

NB. Example test suite

'Describe' Describe {{
  'It1' It {{
    'True' Expect 1
    'False' Expect 0
    Expect 1
    Expect 0
  }}
  'It2' It {{
    AssertEq 1 ; 1
    AssertEq 1 2 3 ; 1 2 3
    AssertEq 1.414213562373 ; %:2
    AssertApproxEq 1.414213562373 ; %:2
    AssertEq ('abc',:'def') ; ('abc','def',:'ghi')
  }}
}}

Outputs

<DESCRIBE::>Describe

<IT::>It1

<PASSED::>Test Passed

<FAILED::>False

<PASSED::>Test Passed

<FAILED::>Value is not what was expected

<COMPLETEDIN::>0.002855

<IT::>It2

<PASSED::>Test Passed

<PASSED::>Test Passed

<FAILED::>1.41421 should equal 1.41421

<PASSED::>Test Passed

<FAILED::>abc<:LF:>def<:LF:> should equal abc<:LF:>def<:LF:>ghi<:LF:>

<COMPLETEDIN::>0.004143

<COMPLETEDIN::>0.009831

2-space indentation is arbitrary because nested definitions were not allowed by the language, so there is no precedent of nested code blocks like this. Due to the limit in the number of args, I decided to put both data being compared on the right argument as a 2-item boxed array.

[kazk]

I thought it's not easy to visually simulate how the test cases are written in other languages.

We don't need to make it look like other languages. The tests should look natural for the language. I'm totally fine with the syntax of general/unittest if that's what J users are familiar with.

2-space indentation is arbitrary because nested definitions were not allowed by the language, so there is no precedent of nested code blocks like this.

<DESCRIBE::> is optional, so we don't need to support it.

Also, is it possible to use assert? The test to stop at first assertion failure.