> Can I ask what particular expressions/programs led you to this decision?
> What do you mean by data-parsing?
>
>
I see that I have mixed domains here somewhat. By parsing I meant
applying complicated
algorithms to arrays, like Life1D as a simple example.
> First, objectively: it does not use "about the same real estate",
>
Objectivity counts for very litte since the reading is performed by
humans. My eyes
read that as fast if not faster than the equivalent J code.
> 55 chars it's approaching the limit of a line, and since it is such a
> simple function,
>
Whether you realize it or not, you have been spoiled by J. I'm starting
to feel that in my own
situation as well.
>
>> (;:'BAD OK') {::~ checkInput
>> That's pretty clear, so I would say very easy to compare with
>> (println (if (checkInput?) "OK" "BAD"))
>>
>
> Can you show the idiomatic extension to a 3rd possible response? As I
> said, in J this would be:
>
> (;:'BAD OK OTHER') {::~ checkInput
>
>
>
Its a good question and J certainly scales nicer in this regard. If I
was to match it in Clojure
I'd have to abtract a little bit.
The rule of thumb is:
1 condition: use 'when'
2 conditions: use 'if'
n conditions: use 'cond' or 'condp'
(condp = (checkInput?)
true "OK"
false "BAD"
:else "OTHER")
> If Lisp can offer me a way to express such non-functional programs with a
> consistent, clear extension of the functional syntax, that would be a big
> motivator for me to try it out. I hear this is possible and common in
> Haskell, using monads, but so far no one has been able to give me a
> straightforward definition of a monad (for someone unfamiliar with
> Haskell, and maybe that's the problem.)
>
>
Monads are in much wider use in Haskell programs than Clojure. In
Clojure everything is
per default immutable, which means that once you start handling state
you have to do
so explicitly. We have 3 datastructures which support us
atoms: Uncoordinated synchronous change
refs: Coordinates sync. change
agents: Uncoordinated async. change.
You can find some example of their respective use throughout my blog.
When using them
you can still be purely functional as you don't use different
flow-controls or functions to
mutate their values.
> Explicit code is essentially unavoidable if your program requires state or
> handles side-effects (though one can keep the explicit code minimal, to
> handle just these aspects, and express the rest tacitly).
>
>
And therein lies the argument for Jisp :)
> I suspect you'll need JNI. There's also a higher-level COM interface, if
> that helps.
>
>
Unless you know something that I don't, using JNA is esentially the same
as JNI, both provide
native interfaces to C/C++ modules. JNA being the less complicated of
the 2. No matter which
one I go with, I'll need to documentation of the J interface or have to
guess my way through all
arguments lists and return types - which I'm not going to do :)
/Lau
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
