hanks for your comments.

See comments below.


On 2016-07-29 16:22, Raul Miller wrote:
Er... what makes a road a "dead end road"? Reaching the end of the
road too soon? (In other words: not enough problems and quirks?)
I think this way to write programs is a total mess.
There are some posts I made about this in the forums.
There is something on my blog. https://erlhelinfotech.wordpress.com/2016/05/30/j-a-functional-language/ -You have to count the verbs in a verb train to know if it's a hook or fork before you start deciphering it. -For every single function you have to think about which argument go in and out. -There are a lot of different ways to express the most simple thing like a number of consecutive monadic functions. -A lot of &,@,@:,[, ], [: and all imaginable combinations of those pretty complex operations are most often only used to get the right argument to the right function.

Anyways, I looked over your docs, and as near as I can tell, you just
left out user defined adverbs and conjunctions, as well as hooks and
forks. You might have left out some other stuff, like (name)=:
expression, and d. and so on. That is fine and good for a starting
effort, but some of your changes look like they would get in the way
of later development (so you might need to redo them or something).
But there's a lot you don't cover at all in your docs (like the
altered syntax rules you've used) so it's kind of hard to get an idea
of what all will not work.
My goal was just to implement the most basic parts of a language.
Yes, it's all an experiment.
I made some things a little different, for different reasons.
For example I wanted arguments to always be explicit, because I want the code to be easy to read. I don't want to have to think about which arguments get into every function. I wanted to be able to see exactly what a function does from it's notation, so I gave monadic and dyadic functions different notations. I split some functions. The monadic functions all got a leading bar. I got rid of underscore for negation and used citation signs to delimit strings.
I force a blank between each syntax element.
There is a syntax section on page 19. It should describe the exact syntax. You can try it out in the Mock Interpreter. There is a Windows installation of JWithATwist. The easiest way to get an overview of JWithATwist is to look through the test code. The manual is supposed to cover nearly every detail. Much more than all J documentation you can find covers the details in J. If something is missing I hope to get information about what. I wanted it to basically be like J, because I wanted a discussion here, so I kept most things like they are in J, even many things I would have done differently. If someone would finance a real development effort in line with this we'd rewrite and redesign it all.

(Writing good documentation - and getting it so people can find it
when they need it - is the hard part of an effort like this. As you
have no doubt been experiencing sometimes it's easier to just rewrite
a good part of the thing from scratch than it is to read the
documentation.)
Yes, well, I planned to make the manual really professional, but then I started to feel that I have to get the product out. I might well work more on it. As you see I removed the box characters and it made the manual very hard to read. For a professional manual I'd need a lot of illustrations.

You also might have some spurious characters in your documentation (|
and { and } in example lines - unless |": really is supposed to be
executable), so I am not quite sure if I understand your examples or
not.
These characters are part of the syntax. Yes, it is supposed to be executable, same ": as in J and a leading bar to show that it is monadic. The curly brackets are used for noun and verb definitions.

Also, you got rid of _ for negative numbers, which mean extra rules
around handling spaces and/or complications when reusing numeric
vectors. Since you have not yet gotten around to documenting what you
did there, I have no idea which set of problems you decided to give
us.
Yes, spaces are needed between all design elements. All should be documented, but the differences compared to J are not. I don't know what kind of vector problems I would get. I don't understand in what way I could give you problems.

Still, the core effort sounds like it might have been instructive. I'm
not sure this is useful enough yet that I would want to learn to use a
non-portable language like F#, but maybe going the other direction
(insight into some aspect of J) will have gotten somewhere good?
Yes, I learned a lot by basically copying J design.
I think you can run F# in mono nearly everywhere.
It might be useful for APL and J programmers who work in F#. You can use it as a cool calculator.

Thanks,


----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to