what makes it APL?
Bjorn
end?
It is probably a combination of both as well as a set of addons and
tools.
Is the character set part of the engine or part of the front end?
We have J with a J engine which in many ways is pretty much the same
as other APL engines.
The character set used in J is completely different.
The Guis vary a lot between APLs.
J uses scripts and locales instead of workspaces even if the locales
are very similar to workspaces.
Then the front end for developer, design studio or whatever it is
called needs not to be seen by the users of applications in APL and is
it then a part of what makes it an APL?
I think that the engine behind an APL is what makes it unique.
Too often we associate the front ends too heavily with APL.
Like now in the J side of the world there are two major new front end
guis being developed but the J engine is not changing much if at all.
The APL engines are in many ways much more similar than the front
ends.
aleph1c
when I'm talking about APL I'm talking about a programming language and
its basic concepts and rules.
Front end a important for supporting the APL developper but doesn't
define APL. As another an example you can use a simple text editor and
the command line for developping Java applications, or you can use
Eclipse (I prefer the latter). In both cases I'm using Java.
From my point of view the APL symbols are part of the basic idea to
express mathematical concepts in an executable context. You can even
think about using different symbols, i.e. # instead of the greek rho.
Bjorn
of symbols.
It means that you can easily use ordinary text editor to edit/create J
programs/systems.
Some people seem to have a difficult time accepting APL without APL
chars.
Users of APL applications should not need to be bothered with the APL
chars.
aleph1c
APLs. Interesting that you write J and other APLs. Indeed, from my point
of view J is just another APL dialect (you even could say APL+Win (i.e.)
is just another J dialect, but APL was first with APL/360).
I like APL because of its clarity and stringency but I like the APL
symbolset, as well. Maybe because I'm using it since almost 30 years.
BTW: the J symbols doesn't make J easier to read than APL.
Bjorn
It is probably like learning a new language.
If you know german type languages going to latin based is harder than
learning a new german type.
As the concepts in J are the same or similar it is more a question of
getting used to the symbols.
As you do not need to use the symbols because you have all kinds of
tools with words and you can create new words to use it can make life
easier.
Also like any new language you have to spend some time talking to the
natives to become good at it.
There are a number of learning materials available.
Like in all other modern APLs it is possible to program like other
computer languages and communicate with the rest of the world.
In J communicating with the rest of the world it is actually easier
because of symbol set used is not specialized.
You do not have to be fluent to start.
You can start doing simple things and if you do want to do more
complex things there are a load of people willing to help you along.
It is interesting to see many lines of code more or less disappear
when the experts get in on a challenge.
It is unfortunate sometimes that people get scared away from complex
issues that work but are hard to read and understand.
Who cares really if you can solve something if it works even if it is
a bit longer and takes a bit longer to execute.
If you do want to try out J it does not mean you have to give up other
APLs.
kai
Sorry guys but I wholeheartedly disagree.
For that it must be possible for a fluent APLer to write some simple
programs in J, because it's "just another APL". That is not the case.
The symbols are an important part of the language as such. That's why
some people have difficulties to accept APL without APL symbols: it's
not APL any more. It's also why J is NOT just another APL.
Although J is a close relative of APL it is an independent programming
language.
Bjorn
kai wrote:
> J just another APL?!
>
> Sorry guys but I wholeheartedly disagree.
>
> For that it must be possible for a fluent APLer to write some simple
> programs in J, because it's "just another APL". That is not the case.
>
Quite a lot of APLers have done and do just that.
There is a difference between IPSAPL and APL2 and J is closer to
IPSAPL or SAX.
Those who are fluent in IPSAPL have relatively less problems adjusting
to J than those coming from an APL2 background.
There a number of people who do know both APL2 and IPSAPL and know it
is not absolutely easy to go from one to the other.
Both have their merit but they are absolutely not the same.
It is actually a lot easier to go from IPSAPL to J than from APL2 to
IPSAPL.
I know because I did.
> The symbols are an important part of the language as such.
That is something this thread is all about and I strongly disagree.
The more I think about it the more I realize that the symbols are not
the language.
The symbols are used to express your thoughts and help give
instructions to the computer what to do.
Once an application has been created the symbols are not needed and
the users never need to see the symbols and in most cases do not want
to.
> That's why
> some people have difficulties to accept APL without APL symbols:
I do know that is so and it is a pity.
Some of those people have been very angry and said things about J that
are not very good for anyone.
They managed to scare off many people so J has mostly been discussed
in other newsgroups and forums.
I think that J should be discussed in this newsgroup as well.
> it's
> not APL any more. It's also why J is NOT just another APL.
Well.... I guess we will have to disagree on that issue.
I use mostly J but I occasionally use other APLs as well.
>
> Although J is a close relative of APL it is an independent programming
> language.
Actually then Ken Iverson who created APL wanted to correct many
mistakes he considered he had made during implementing APL so he
created a more correct version.
Because of the correction being so different in many ways and not
according to ISO he decided on a new name for his new version of his
Programming Language.
Actually no or hardly any version or dialect of APL is doing much of
ISO anymore or rather ISO is such a small part of the APLs that it
does not mean much.
You can hardly move any IPSAPL program to APL2 or the other way round
or just so little it does not really matter.
The APL symbols are pretty much the only thing they do have in common
but as they do not even perform the same operations using those
symbols it is questionable if they are sharing those symbols or not.
This has been so for 30 years and happened 10 years before J was even
created.
IPSAPL and APL2 pretty much as different as APL2 and J.
Ken Iverson continued his work from old APL through IPSAPL to J.
So as far as I am concerned J is probably more of Kens original
creation than any other APL that has been implemented on a computer.
Simon Marsden
think the following experiment would make clear...
Take a new user and get them to read an APL tutorial. After reading
it, they should be able create simple programs using APL2, APLX,
Dyalog, APL+Win, NAR2000, etc. They would not have the first idea how
to do the same in J.
Personally I think that the APL symbols are an important part of the
language. Part of the reason I don't use J is that I find it ugly to
look at. By contrast, APL looks beautiful - concise, but also elegant.
Bjorn
wrote:
>
> Take a new user and get them to read an APL tutorial. After reading
> it, they should be able create simple programs using APL2, APLX,
> Dyalog, APL+Win, NAR2000, etc. They would not have the first idea how
> to do the same in J.
Same goes for IPSAPL.
All the dialects you mention are APL2 based as far as I know.
Read a tutorial for IPSAPL and you might be able to use some of it for
J.
It is really silly to ban talks about J being an APL just because it
uses different symbols.
The rest of the APLs might benefit from ideas introduced in J and
actually some like Dyalog are doing just that in some of its
extensions.
So even if Dyalog is mostly APL2 compatible it has extensions in other
directions too.
It is actually very difficult to take a tutorial in any APL and expect
it to work in other dialects.
Unless the tutorial in ISO which is a very very limited subset of any
APL.
Bjorn
Beauty is in the eye of the beholder.
Which APL is most concise - well - in my opinion J would win hands
down.
Phil Last
APL*PLUS/PC used to have a keyword mode where each primitive was a
short word with an initial "$" being either the name of a symbol e.g.
"$rho" or of a function (or abbreviation) e.g. "$in". (examples may be
erroneous after 20 years of deteriorating memory).
MicroAPL had a keyword version where the primitives were reserved
words in a-z and user function and variable names began with A-Z.
No one doubted these were APL. Had a Hungarian company released a
keyword version in Magyar it would still have been APL there being
nothing intrinsically Greek or English about APL.
"x/iota rho x" unfortunately lacks the immediacy of "x/⍳⍴x" but a
direct transliteration from APL to keyword and back would have been
possible.
To a very large degree such a transliteration is possible between J
and (dare I say) any other APL. In other words a direct mapping is
possible between most of the primitives of APL and J to the extent
that they differ only in their "names". As Bjorn says, many of the
exceptions to this were already present in the difference between
Sharp APL and APL2. The main break came when these two branches went
their different ways over enclosure, strand notation and the
generalisation of the application of operators to non-scalar
functions.
The difference is that between (say) APL2 and Dyalog there may be some
slight variation of vocabulary: "↑"&"⊃"; "⊃"&"↑"; and one or two
variations in edge conditions: Dyalog's extension of fill to reshape:
⍬⍴⍬; the spurious execution of f in "f¨⍬" and "⍬∘.f⍬" as opposed to
APL2's identity functions; whereas the inclusion of strand notation in
APL2 versus its exclusion in Sharp APL changes the syntax and the
application of reduction between whole cells in Sharp APL as opposed
to items along axes in APL2 changes the semantics.
In these respects Sharp APL is more closely related to J than to APL2.
Are they sufficient to mark Sharp APL and APL2 as different languages?
If not then I submit that APL and J aren't either.
Michael Jenkins
In the spirit of inclusiveness the APL community decided many years
ago to encompass all array programming languages as part the group.
This inclusiveness welcomed developers and users of Nial, J, A+, K and
several functional programming languages into the community and
encouraged cross-pollination of ideas.
In my opinion the essence of an array programming language is one that
treats all data objects as arrays. This means all data objects have
shapes including scalars (or atoms Nial calls them). The other key
feature is that all first order functions have arrays as arguments and
produce an array as a result.
All of these programming languages can express substantial
computational algorithms as a single expression on one virtual line of
code. They all use first and second order functions to combine values
in sophisticated ways. The set of predefined first order functions are
much more powerful than the operations in scalar-oriented languages.
As a result, programs have a brevity that is attractive to people who
want to rapidly design and implement an algorithm or an entire
application.
However, one drawback is that while such programs are easy to write
once the programmer knows the operation set and the syntax rules, they
are difficult for another person to comprehend. This is why some wags
refer to all APLs (in the wider sense) as write-only languages.
The problem of readability of programs is compounded by the following
issues:
- the same symbol may have more than one meaning, e.g. "rho" means
"shape" in monadic use and "reshape" in dyadic use.
- the reader has to know what symbols represent second order
operations in order to parse an expression and some symbols can be
both first and second order e.g. "/" and "\".
- some operations are state dependent and hence the meaning of an
expression depends on context e.g. "iota"
My point is that many of the issues in the APL community are inherent
in the core design ideas used in the original APL and many have been
carried over to J and the various APL variants. There is little use in
discussing them in the "APL in 2020" forum since they have little
chance of being changed. The discussion of index origin is in this
category.
APL has survived because the core idea of having highly expressive
programming tools allows it to be used for rapid development of
complex algorithms in engineering, finance and scientific computing.
It is a tool for thought and a practical way to develop a large class
of applications. I suggest the focus of the Berlin discussions should
be on building on these strengths and not on particular language
details.
Mike Jenkins
Park Corner, PEI, Canada
Bjorn
............
> The problem of readability of programs is compounded by the following
> issues:
> - the same symbol may have more than one meaning, e.g. "rho" means
> "shape" in monadic use and "reshape" in dyadic use.
> - the reader has to know what symbols represent second order
> operations in order to parse an expression and some symbols can be
> both first and second order e.g. "/" and "\".
.........................
>
> Mike Jenkins
> Park Corner, PEI, Canada
One thing I find of particular interest is the use of the "rank"
operator.
I know the rank operator is in J but I am not sure if it is in other
APLs.
The same symbol can change meaning completely by applying rank
operator on it.
In the dictionary you have three options for each symbol.
One meaning for monadic use and then two for the dyadic case.
I guess the application of rank is one of the hardest part of J for
many people.
The rank defines how a symbol or collection of symbols works on the
data.
It can use individual elements, the whole matrix or subsets of it.
The rank as innocent looking as it is can be a huge barrier in the
beginning of understanding J.
Once learned many people start using it all over the place and has
given lot of people the possibility of calling J ugly.
It very much look like you have put salt and peppar all over the code.
Once you do understand rank and begin to appreciate it you on the
other hand find that spicing your code with rank and some other spices
who make J so unique you start to love it.
I guess it is frustrating to try to read compact J code with heavy
spices before you understand what the spices are doing.
If you cook something without spices it will often be a bit tasteless
and flat.
I guess that even if we have quite a lot of new learning material it
is still a lot more to be done.
And incidentally I would like to know if I am correct in assuming that
other APLs do not have anything similar to the spices ",& and @ .
Or each on a line
"
&
@
They also have a different meaning with . and :
".
&.
@.
":
&:
@:
If I am wrong then it would be nice to know.
Obviously code peppered with the above can look strange to newcomers.
David Liebtag
BTW Please take these remarks with a grain of salt since I am not an
accomplished J user and have only a student's interest in rank.
One of the things many people to not realize about the rank operator it that
impies that functions have rank. In particular, one of the beauties of J is
that all functions have well defined and consistent rank. This not only
makes it easier to learn, it also makes it possible to implement the rank
operator. After all, if you think about it, having an operator that affects
the rank to which a function is applied hardly makes any sense at all if
functions have inconsistent or irregular rank.
Because APL2 functions do not have consistent rank, I have not been able to
find a way to define the rank operator that works exactly like the
description in the J dictionary. Has annyone else been able to do so?
David Liebtag
IBM APL Products and Services
PS My opinion is that J is a dialect of APL.
Phil Last
There's one in the Dyalog online "dfns" ws at http://www.dyalog.com/dfnsdws/n_rank.htm
that Roger Hui criticises for "jumping through too many hoops" and
he's probably correct. He demonstrated his own at Dyalog'09 in
Princeton. I believe they give consistent results though neither of
them actually gains you anything other than tidiness in the calling
code because both of them have to rely on another operator; reduction
in my case; each in Roger's; when it gets down actually to doing
anything.
Contrary to the notes in the Dyalog site it _does_ handle negative
rank correctly.
Translating either of them to "traditional" APL might prove difficult
their both being written as "direct" operators.
Roger Hui
> other than tidiness in the calling code because both of them
> have to rely on another operator; reduction in my case;
> each in Roger's; when it gets down actually to doing anything.
Both are models and if the models are consistent
(and they are) then they precisely define what exactly
is the rank operator. That is a non-trivial benefit.
I thought I have my Dyalog '09 presentation
online somewhere but apparently not. Anyway,
the model can be succinctly stated (Dyalog APL):
effrank ←{(0≤⍺)⊃(0⌈⍺+⍴⍴⍵)(⍺⌊⍴⍴⍵)}
cells ←{⊂[(-⍺ effrank ⍵)↑⍳⍴⍴⍵]⍵}
assemble←{↑((1⍴¨⍨r-⍨⌈/,r←⍴∘⍴¨⍵),¨⍴¨⍵)⍴¨⍵}
R←{
(m l r)←⌽3⍴⌽⍵⍵
0=⎕NC'⍺' : assemble ⍺⍺¨ (m cells ⍵)
assemble (l cells ⍺) ⍺⍺¨ (r cells ⍵)
}
data
1 7 4 5
2 0 6 6
9 3 5 8
(+/R 1) data
17 14 25
0 1 2 (,R 0 1) data
0 1 7 4 5
1 2 0 6 6
2 9 3 5 8
On Aug 16, 12:30 pm, Phil Last <phil.l...@ntlworld.com> wrote:
> On Aug 16, 5:54 pm, "David Liebtag" <lieb...@us.ibm.com> wrote:
>
>
>
> > Bjorn,
>
> > BTW Please take these remarks with a grain of salt since I am not an
> > accomplished J user and have only a student's interest in rank.
>
> > One of the things many people to not realize about the rank operator it that
> > impies that functions have rank. In particular, one of the beauties of J is
> > that all functions have well defined and consistent rank. This not only
> > makes it easier to learn, it also makes it possible to implement the rank
> > operator. After all, if you think about it, having an operator that affects
> > the rank to which a function is applied hardly makes any sense at all if
> > functions have inconsistent or irregular rank.
>
> > Because APL2 functions do not have consistent rank, I have not been able to
> > find a way to define the rank operator that works exactly like the
> > description in the J dictionary. Has annyone else been able to do so?
>
> > David Liebtag
> > IBM APL Products and Services
>
> > PS My opinion is that J is a dialect of APL.
>
> There's one in the Dyalog online "dfns" ws athttp://www.dyalog.com/dfnsdws/n_rank.htm
Bob Smith
One of the things many people to not realize about the rank operator it that impies that functions have rank. In particular, one of the beauties of J is that all functions have well defined and consistent rank. This not only makes it easier to learn, it also makes it possible to implement the rank operator. After all, if you think about it, having an operator that affects the rank to which a function is applied hardly makes any sense at all if functions have inconsistent or irregular rank. Because APL2 functions do not have consistent rank, I have not been able to find a way to define the rank operator that works exactly like the description in the J dictionary. Has annyone else been able to do so?
⍳¯3
¯2 ¯1 0
'abcdef'[⍳¯3]
def
L←'abcdef' ⋄ R←⍳⍴L
L ,⍤0 R
a 1
b 2
c 3
d 4
e 5
f 6
-- _________________________________________ Bob Smith -- bsm...@sudleydeplacespam.com To reply to me directly, delete "despam". http://www.sudleyplace.com - http://www.nars2000.org
Roger Hui
One is the rank operator and you can define it, model it,
implement it, in any of the APL dialects. (I just posted
a model in another msg just now.)
Another is functions having a defined rank. It is possible
to specify that all functions have infinite (unbounded) rank.
(This is another way of saying that functions do not have a
defined rank.) In fact, Arthur Whitney did that k.
In that case the only way rank comes into play is through
the rank operator.
David Liebtag
I guess I'm confused, which is not unusual :-)
I thought that in J all primitive functions have the same rank and the rank
operator changed the rank of the operand for the duration of the call. I
thought this was a valid way of thinking about and paraphrasing the idea of
applying a function at a particular rank. Is this incorrect?
If it is correct, I don't understand how you can write a rank operator in
APL2 since the primitive functions have different ranks. It seems like the
rank operator would have to know what function was being applied so that it
could adjust how to apply the function at the specified rank. And, there's
no way in APL2 for a defined operator to know what function is being
applied. So, it can't be done.
The best I could do was build something that worked in most, but not all
cases.
If this is too complicated to correspond about online, I would be delighted
if you would help me understand while we're at APL2010.
Thanks a lot.
Roger Hui
> online somewhere but apparently not.
http://www.jsoftware.com/papers/rank
Rank operator model (in Dyalog APL) and examples.
I note that the rank operator is in ISO/IEC 13751:2001(E)
sec. 9.3.3 to .5, so it's a perfectly respectable APL facility.
Phil Last
Whatever the intrinsic rank of the function the rank operator ignores
it and applies it (the function) to/between cells(subarrays) of the
specified rank(s). All apl functions have intrinsic rank. It's just
that it was never brought to our attention on the APL2 side of the
street.
Roger Hui
> operator changed the rank of the operand for the duration of the call.
This is quite a mouthful but unfortunately it's incorrect on two
points.
- It is incorrect (and misleading) to think in APL or J of an
operator
modifying an operand. More accurate to think of f Op1 or f Op2 g
deriving a new function having some specified property
(hopefully but not required to be related to f and/or g).
Why is it misleading? Please permit a longwinded explanation.
I got into a similar discussion with some APL colleagues on this
point.
Suppose you have an "index origin operator" IO where f IO k specifies
index origin k (0 or 1). If you think in terms of IO "modifying the
index origin to k" or "modifying f to have index origin k", you are
easily lead to the implementation (sorry I can only provide
examples in Dyalog APL):
IO←{⎕io←⍵⍵ ⋄ ⍺⍺ ⍵}
(⍳ IO 0) 5
0 1 2 3 4
(⍳ IO 1) 5
1 2 3 4 5
So far so good. But what happens with
(⍳ IO 0 IO 1) 5 ⍝ wrong
0 1 2 3 4
(⍳ IO 1 IO 0) 5 ⍝ wrong
1 2 3 4 5
You can get yourself twisted into knots thinking what (⍳ IO 0 IO 1)
means, if you think in terms of "modifying f" or "for the duration of
the call", etc. Instead, f IO k specifies a function that either
interprets its argument in index origin k and/or produces its results
in index origin k, no matter if f is ⍳ or ⍳ IO 1 or ⍳ IO 0 IO 0, etc.
- The second point is that primitive functions in J have various
ranks.
For example, + has ranks 0 0 0 (monadic, left, and right ranks);
#. (base 2 value and base value) has ranks 1 1 1; # (tally and
replicate/compress)
has ranks _ 1 _ (_ is infinity).
The difference between functions having defined ranks and functions
not
having defined ranks (i.e. having unbounded defined ranks), is more
readily explained with the model:
effrank ←{(0≤⍺)⊃(0⌈⍺+⍴⍴⍵)(⍺⌊⍴⍴⍵)}
cells ←{⊂[(-⍺ effrank ⍵)↑⍳⍴⍴⍵]⍵}
assemble←{↑((1⍴¨⍨r-⍨⌈/,r←⍴∘⍴¨⍵),¨⍴¨⍵)⍴¨⍵}
R←{
(m l r)←⌽3⍴⌽⍵⍵
0=⎕NC'⍺' : assemble ⍺⍺¨ (m cells ⍵)
assemble (l cells ⍺) ⍺⍺¨ (r cells ⍵)
}
(R was written to components useful in their own right, in
particular "cells".)
The rank operator slices and dices the array argument(s), via
the expressions (m cells ⍵), or (l cells ⍺) and (r cells ⍵).
After it's done that, it applies the function operand ⍺⍺
to these cells, via ⍺⍺¨. In that application, if ⍺⍺
has a defined rank, then that affects how ⍺⍺ is applied
(using some facility that probably uses the rank
operator). If ⍺⍺ does not have a defined rank, then
the application gets done in the way you have known and love
for the last 44 years.
I hope the above makes the point that the rank operator
(the slicer and dicer) and functions having defined ranks,
are independent and separable.
I leave you with the following example, which relates the
"two points":
data←2 3 4 5⍴⍳120
(+⌿R 1 R 2) data
R correctly executes the example. If you think in terms of f R m
modifying the rank of f, it is possible to get quite confused.
Looking forward to seeing you in Berlin in September.
Roger Hui
> index origin k (0 or 1). If you think in terms of IO "modifying the
> index origin to k" or "modifying f to have index origin k", you are
> easily lead to the implementation (sorry I can only provide
> examples in Dyalog APL):
>
So how, pray tell, _do_ you implement such an operator?
(Spoiler alert: answer at the end.)
⎕io←0
(⍳ IO 0) 5
0 1 2 3 4
(⍳ IO 1) 5
1 2 3 4 5
(⍳ IO 1 IO 0) 5
0 1 2 3 4
(⍳ IO 0 IO 1) 5
1 2 3 4 5
⎕io←1
(⍳ IO 0) 5
0 1 2 3 4
(⍳ IO 1) 5
1 2 3 4 5
(⍳ IO 1 IO 0) 5
0 1 2 3 4
(⍳ IO 0 IO 1) 5
1 2 3 4 5
(⍳ IO 1 IO 1 IO 1 IO 1 IO 0) 5
0 1 2 3 4
IO←{⍵⍵ {⍺+⍵-⍬⍴⍵} ⍺⍺ ⍵}
Phil Last
Doesn't this assume that the operand is going to be ⍳ ?
IO←{⍵⍵ {⍺+⍵-⍬⍴⍵} ⍺⍺ ⍵}
(⌽∘⍳IO 1)5
1 0 ¯1 ¯2 ¯3
Roger Hui
are left as an exercise for the reader.
Phil Last
Even with all the composes, commutes, splits, mixes, guards and what
not to be changed I decided rather than rewrite the whole thing I'd
make minimal changes to Roger's algorithm just quoting his dfns and
include a simple dfn operator.
So here is a working rank operator cut and pasted from APL2.
My apologies for the use of those right arrow thingies but I should
have had to include a lot more stuff to avoid them.
∇rank[⎕]∇
∇
[0] r←a(f rank g)w;m;l;r;effrank;cells;assemble
[1] effrank←'(0≤⍺)⊃(0⌈⍺+⍴⍴⍵)(⍺⌊⍴⍴⍵)'
[2] cells←'⊂[(-⍺(effrank dd)⍵)↑⍳⍴⍴⍵]⍵'
[3] assemble←'⊃(⊂[⍴⍴⍵]⌽1+⊃¯1+⌽¨⍴¨⍵)⍴¨⍵'
[4] (m l r)←⌽3⍴⌽g
[5] →(0≠⎕NC 'a')/dyad⋄r←f¨(m(cells dd)w)⋄→end
[6] dyad:r←(l(cells dd)a)f¨(r(cells dd)w)
[7] end:r←assemble dd r
∇ 2010-08-17 11.23.59 (GMT+1)
∇dd[⎕]∇
∇
[0] r←a(aa dd)w
[1] r←⎕FX 1 5⍴'r←a r'
[2] r←⍎(⊂('⍺⍵',aa)⍳aa)⌷'aw',aa
∇ 2010-08-17 11.19.33 (GMT+1)
kai
> APL*PLUS/PC used to have a keyword mode where each primitive was a
> short word with an initial "$" being either the name of a symbol e.g.
> "$rho" or of a function (or abbreviation) e.g. "$in".
> No one doubted these were APL.
Actually this is supporting my point: I've never heard of any
application written in these "keyword-APLs". Those where merely used
to investigate or learn APL, meaning that the symbols are really an
important aspect of the language. They are APLs, certainly, but APLs
with something essential missing.
In J the only thing any fluent APLer can do is something along the
lines of 1+2. In order to assign a variable or to print "hello word"
one has to learn how to do it, because it's different. Very different
indeed.
Phil Last
An interesting observation but wrong.
I was investigating, not the difference in spelling but that in
semantics. I guessed at "i." for iota (correct) and "#" for rho
(wrong; should have been "$")
Ok so a straight transliteration so far. Not different in magnitude
from that I did earlier from Dyalog to APL2.
2 4$i.6
0 1 2 3
4 5 0 1
I then guessed "e." for epsilon (correct) but then came the
interesting part:
e./2 4$i.6
1 1 0 0
Now I knew that J emphasises the first rather than the last dimension;
sensibly in my view. But in APL2:
∊⌿2 4⍴⍳6
0 0 0 0
Whence the 1 1 0 0 in the J result?
The point is that the semantics of reduction in J are not concerned
with items but with the content of cells. The equivalent in APL2 would
be:
⊃∊/⊂[1]2 4⍴⍳6
requiring those two extra steps of enclose with axis (split) and
disclose (mix). The above "∊⌿2 4⍴⍳6" being a vector reduction along
each column vector of the array as opposed to an array operation
between two vectors.
Now this is a much more profound difference than a minor spelling
change. Nevertheless to my mind it's a difference that amounts to one
of dialect - rather than accent in the one direction and language in
the other.
Roger Hui
and "assemble" as global rather than local functions.
They are as important and useful as "rank" itself.
Richard Nabavi
>
> Actually this is supporting my point: I've never heard of any
> application written in these "keyword-APLs". Those where merely used
> to investigate or learn APL, meaning that the symbols are really an
> important aspect of the language. They are APLs, certainly, but APLs
> with something essential missing.
>
>
That is incorrect. MicroAPL's keyword version of APL, introduced in
the late eighties, was designed as a fully-fledged language, and was
extremely popular amongst new users, especially on the Sinclair QL and
Atari. Users certainly wrote new applications in this version of the
language.
The big difference is that we chose meaningful names. Obviously the
old STSC idea of '$rho' or $iota' made absolutely no sense whatsoever
unless you were an APLer who just happened not to have access to an
APL keyboard and/or character set at the time; that had no hope of
widening acceptance of the language.
We were trying to do something different:
mean is (+ on x) / shape x
/ here means divide, of course - we were wanting to be as consistent
as possible with what people would expect from spreadsheets and other
languages.
It was very well received by our users (nearly all of whom had never
seen APL before). I believe the APL community made a big mistake in
not picking up this concept; I think it had the potential to be much
more popular than any current variant of APL.
However, to get there, it would have needed marketing resources which,
by ourselves, we didn't have. Marketing what is effectively a
completely new language (even if 'under the hood' it was actually APL,
with a one-to-one correspondence between keywords and symbols) is very
hard.
David Liebtag
Your explanation is clear and now I think I understand.
Thank you very much.
Phil Last
In fact I didn't actually define them as functions at all. They are
text strings. The dd operator executes them after switching '⍺'&'⍵' to
'a'&'w'. So they could be global text strings. You can't assign a
function in APL2 otherwise I should have done:
effrank←'(0≤⍺)⊃(0⌈⍺+⍴⍴⍵)(⍺⌊⍴⍴⍵)'dd
&c.
Roger Hui
> text strings. The dd operator executes them after switching '⍺'&'⍵' to
> 'a'&'w'. So they could be global text strings. You can't assign a
> function in APL2 otherwise I should have done:
> effrank←'(0≤⍺)⊃(0⌈⍺+⍴⍴⍵)(⍺⌊⍴⍴⍵)'dd
> &c.
If you can execute them you should be able to define them
as functions. There isn't anything magical about effrank,
cells, and assemble. Thus (APL2(?) or Dyalog APL with ⎕ml←2):
⎕cr 'effrank'
z←x effrank y
z←(0≤x)⊃(0⌈x+⍴⍴y)(x⌊⍴⍴y)
⎕cr 'cells'
z←x cells y
z←⊂[(-x effrank y)↑⍳⍴⍴y]y
⎕cr 'assemble'
z←assemble x
z←⊃(⊂[⍴⍴x]⌽1+⊃¯1+⌽¨⍴¨x)⍴¨x
data←2 3 4⍴⍳24
2 effrank data
2
5 effrank data
3
¯1 effrank data
2
disp 2 cells data
┌→────────┬───────────┐
│0 1 2 3│12 13 14 15│
│4 5 6 7│16 17 18 19│
│8 9 10 11↓20 21 22 23↓
└~───────→┴~─────────→┘
disp 1 cells data
┌→──────────┬───────────┬───────────┐
↓ 0 1 2 3 │ 4 5 6 7 │ 8 9 10 11 │
├~─────────→┼~─────────→┼~─────────→┤
│12 13 14 15│16 17 18 19│20 21 22 23│
└~─────────→┴~─────────→┴~─────────→┘
assemble (1) (2 3 4 5) (6 7)
1 0 0 0
2 3 4 5
6 7 0 0
assemble (1) (2 2⍴2 3 4) (6 7)
1 0
0 0
2 3
4 2
6 7
0 0
Phil Last
> as functions. There isn't anything magical about effrank,
> cells, and assemble. Thus (APL2(?) or Dyalog APL with ⎕ml←2):
Quite right but I couldn't be arsed. As I said:
Even with all the composes, commutes, splits, mixes, guards and what
not to be changed I decided rather than rewrite the whole thing I'd
make minimal changes to Roger's algorithm just quoting his dfns and
include a simple operator.
James J. Weinkam
> You can't assign a
> function in APL2 otherwise I should have done:
> effrank←'(0≤⍺)⊃(0⌈⍺+⍴⍴⍵)(⍺⌊⍴⍴⍵)'dd
> &c.
Sure you can. Use {quad}FX.
James J. Weinkam
Would you please explain the use of {quad} in the following lines:
>>
>> IO←{⎕io←⍵⍵ ⋄ ⍺⍺ ⍵} ⍝ wrong (the second instance)
>
> IO←{⍵⍵ {⍺+⍵-⍬⍴⍵} ⍺⍺ ⍵}
Thanks.
Dick Bowman
> [... deleted ...]
>
> The big difference is that we chose meaningful names. Obviously the
> old STSC idea of '$rho' or $iota' made absolutely no sense whatsoever
> unless you were an APLer who just happened not to have access to an
> APL keyboard and/or character set at the time; that had no hope of
> widening acceptance of the language.
>
> We were trying to do something different:
>
> mean is (+ on x) / shape x [... deleted ...]
A decision which makes a great deal of sense. One of the things we all
should do when verbalising APL is to use the names that describe what the
symbols do - not the names of the symbols.
More generally, this thread seems to show that we are too busy looking
inward - like a bunch of medieval monks arguing about what colour socks the
angels standing on a pinhead are wearing. The things that "are not APL"
are C, Ruby, Java and so forth.
Whather we like each other or not, we are all in this together.
Roger Hui
There is some miscommunication somewhere as there is only one quad
in the text you quoted. The two lines are:
: IO←{⎕io←⍵⍵ ⋄ ⍺⍺ ⍵}
IO is { quadio is omega omega space diamond space alpha alpha
space omega }
: IO←{⍵⍵ {⍺+⍵-⍬⍴⍵} ⍺⍺ ⍵}
IO is { omega omega space { alpha + omega - zilde rho omega }
space alpha alpha omega }
The two lines are D-fns in Dyalog APL, wherein alpha is the left
argument, omega is the right argument, alpha alpha is the left
operand, and omega omega is the right operand. Both lines
are defining the monadic derived function of a dyadic operator.
The second contains a local anonymous (unnamed) dyadic function.
The definitions are flawed in that they assume that the operand
is some sort of index-generator function.
zilde is the empty numeric vector, equivalent to rho 0.
diamond is a statement separator.
Ibeam2000
>
> mean is (+ on x) / shape x
>
Does any documentation still exist?
> It was very well received by our users (nearly all of whom had never
> seen APL before). I believe the APL community made a big mistake in
> not picking up this concept; I think it had the potential to be much
> more popular than any current variant of APL.
I would imagine that this would have gone a long way in relieving some
of the acceptance issues which have plagued APL over the years.
Granted this may be perceived as "less powerful" than APL on account
of it being somewhat less terse than APL, at least by members of the
APL community, it would be far less verbose than say Java.
> ... introduced in the late eighties ...
> However, to get there, it would have needed marketing resources which,
> by ourselves, we didn't have. Marketing what is effectively a
> completely new language (even if 'under the hood' it was actually APL,
> with a one-to-one correspondence between keywords and symbols) is very
> hard.
That was then, this is now. Today a new language has a chance as a
freeware product like Python. Arguably, this business plan would have
little to no short term return, but on a longer term basis, it could
significantly enlarge the array language community as a whole.
Further, existence of such a language could help bolster interest in
other array languages. But it remains very hard.
On a slightly different topic, I think we should think more in terms
of "solution", and not necessarily "language". There is a tendency to
get wrapped up in the technology (I see this in the Java world) while
the ability to provide solutions is what would sell a language.
Bjorn
There seem to be some marketing that you can program without a
language.
I have looked a bit at some and what they do is do programming using
graphics.
The graphics then generate c code.
That is actually an idea that could be of interest to the APL
community.
Creating grapics form APL code and vice versa.
Analysing the flow of the application in either way.
Also use mathematical notations - grapic - and compile into APL.
James J. Weinkam
as a statement separator, but the second really threw me because of the minus sign before it. I even
downloaded a Dyalog reference manual, but wasn't able to guess the {zilde}. Thanks for the
clarification.
Do you know if there has been a change in the mapping of APL symbols to unicode code points in
recent years? Back in late 2003, I was able to use the CTUTF supplied external function to translate
APL2 character vectors into UTF-8 and the results displayed correctly when sent using Content type
text/plain and charset UTF-8. Now when I try that I just get a bunch of upper and lower case letters
with diacritical marks.
Phil Last
try: http://aplwiki.com/AplCharacters and other associated pages for
input from many users on receiving and transmitting unicode. I notice
that your own post displays perfectly well here and included all of
Roger's code so I guess the only problem is likely to be the
availability of the correct font.
Bjorn
Bjorn
aleph1c
> community.
> Creating grapics form APL code and vice versa.
> Analysing the flow of the application in either way.
Nice coincidence. I thought about that some weaks ago trying to imagine
how application development with or without APL could look like in say
May 2019.
Here we are far away from this threads the original question: What makes
it APL?
I still agree that these are not the symbols. And I'm still convinced
that J and APLs are more than closely related.
But from my point of view Bjorns question is far from being answered.
Roger Hui
The text requires the APL385 Unicode font, which can be
downloaded from http://www.vector.org.uk/resource/apl385.ttf .
To resolve (or at least explain) problems with displaying APL
characters see http://www.vector.org.uk/archive/display.htm .
But I thought APL characters were "no longer a problem"? ;-)
> try:http://aplwiki.com/AplCharactersand other associated pages for
Bjorn
In the new J7 - JHS - the new browser front end can do nice graphics.
The following line is from a J7 demo example.
'reset &cht=tx&chs=200x50&chl=x=\frac{-b\pm\sqrt{b^2-4ac}}{2a}
show'jgc ''
It creates a nice relatively complicated display of a mathematical
expression.
Going back and forth with something like this is what I mean.
Ibeam2000
> 'reset &cht=tx&chs=200x50&chl=x=\frac{-b\pm\sqrt{b^2-4ac}}{2a}
> show'jgc ''
What happens the day when Google decides to charge money for this
service?
James J. Weinkam
> It usually has to do with config of the browser
>
> Phil Last wrote:
>>>
>>> Do you know if there has been a change in the mapping of APL symbols to unicode code points in
>>> recent years? Back in late 2003, I was able to use the CTUTF supplied external function to translate
>>> APL2 character vectors into UTF-8 and the results displayed correctly when sent using Content type
>>> text/plain and charset UTF-8. Now when I try that I just get a bunch of upper and lower case letters
>>> with diacritical marks.
>> try: http://aplwiki.com/AplCharacters and other associated pages for
>> input from many users on receiving and transmitting unicode. I notice
>> that your own post displays perfectly well here and included all of
>> Roger's code so I guess the only problem is likely to be the
>> availability of the correct font.
That has been my theory all along. From time to time I try every combination of configuration
options until I tire of the exercise.
Can you or someone who has transmission of APL characters working with Seamonkey post the
configuration options you are using and the correct font.
At present, Seamonkey displays question marks in the Mail and Newsgroup viewing window, but displays
the APL characters more or less correctly (something goes wrong with diamond and zilde, which BTW
doesn't exist in APL2) in the reply window. As far as I can see both windows are configured
identically. It doesn't matter whether I force UTF-8 or tell it to use the encoding specified in
the incoming message.
I will be most grateful if someone can pinpoint the guilty option.
James J. Weinkam
>>
>> Do you know if there has been a change in the mapping of APL symbols to unicode code points in
>> recent years? Back in late 2003, I was able to use the CTUTF supplied external function to translate
>> APL2 character vectors into UTF-8 and the results displayed correctly when sent using Content type
>> text/plain and charset UTF-8. Now when I try that I just get a bunch of upper and lower case letters
>> with diacritical marks.
>
> try: http://aplwiki.com/AplCharacters and other associated pages for
> input from many users on receiving and transmitting unicode. I notice
> that your own post displays perfectly well here and included all of
> Roger's code so I guess the only problem is likely to be the
> availability of the correct font.
I must be using the "correct" font since Roger's code displays more or less correctly here in the
reply window; The major problem seems to be that the CTUTF external function that converts an APL2
character vector to UTF-x, where x is the left argument and may be either 7 or 8, gives entirely
different encodings. For instnce, in Roger's code left arrow is E2 86 90 and quad is E2 8E 95
whereas 8 CTUTF gives 94 A5 89 for left arrow and 94 84 B2 for quad.
James J. Weinkam
Sorry to reply to my own post, but I have found the problem with display
of incoming messages.
I downloaded and installed the APL385 Unicode font, then I went to the
apl.wiki site cited above and compared the table of characters in AV
with the bitmapped version and found 13 characters not displayed
properly, among them zilde, diamond and quad! It turns out tat seamonkey
displays a rectangular box for codes it doesn't recognize; so quad was
producing the right graphic for the wrong reason.
I decided to see if the page displayed the same in Firefox. It turned
out that all characters display properly using Firefox.
I had been delaying installing Seamonkey 2.0 because the OS/2 -
eComStation version has some issues with printing. This problem
convinced me to bite the bullet and abandon version 1.19 in favor of 2.0.
Now APL characters in incoming messages display correctly in all windows
even using the OS/2 version of Courier APL2. Even the zilde displays
correctly although it is not in the APL2 character set.
Now all I need is a list of the UTF-8 codes for APL2's AV.
Morten Kromberg
> J is a dialect of APL
> No it isn't
> Yes it is
> Maybe it's a dialect of APL, but it certainly isn't a dialect of APL2 ...
Thanks for reminding me of one of my favourite Python sketches ...
http://www.youtube.com/watch?v=teMlv3ripSM
I have to admit I don't know what the definition of "a dialect" is.
What I do know is that I greatly enjoy the company of J and K folks,
and admire many of them. I'm keen to st... be inspired by anyone who
is thinking along valuely similar lines. Being an ex-SHARP APL user, I
find myself in the odd position of being able to TALK to J people
about code, and even WRITE code in J if I spend a little time with the
J Dictionary, but I read it about as well as my native Norwegian
allows me to read Icelandic :-)
My very PERSONAL view is that the "multicharacter symbols" used in J
are a "readability disaster". Since I was only 27 when J saw the light
of day, I like most of the other changes that were introduced into J,
and Ken has always been my hero, I don't quite buy the argument that
I'm "just an old dog". On the other hand, there are clearly people who
are comfortable with J, including lots of old APLers. My completely
unscientifc guess is that the user population has a slightly different
profile, and the J community contains a higher proportion people who
have a theoretical / mathematical background and are comfortable with
symbolic manipulation (so they don't care QUITE so much about how
things LOOK so long as there are rules), while the people who want to
stick with APL symbols have a more "visual" approach to things.
Talking about "who is right" is meaningless (to me).
J has some seriously cool ideas, many of which we are keen to adopt
into Dyalog APL. Contrary to what seems to be popular belief, there
are few real incompatibilities between J and the "APL2 dialects".
The form of nested arrays, and many of the new operators, including
rank, appeared in SHARP APL in the 1980s. SHARP APL and J are more
strict/formal, but pack a bit more algorithmic punch. APL2 is more
"easygoing". To my mind, there are two significant differences: One is
the switch to emphasis on the leading axis in J, which combines so
elegantly with rank. Fortunately, APL also contains symbols for expand
and compress on the leading axis, I suspect these will grow more
popular in APL when we introduce Rank. We also added support for short
left arguments to take, drop and index in Dyalog v13, another small
step in moving towards leading axis emphasis.
The really big difference is "verb trains" (hooks and forks) and the
emphasis on "tacit forms" which comes with them. These are truly
powerful constructs, but again (IMHO) probably more appealing to the
"symbolic" folks than the "visual" folks. At Dyalog, we find that D-
Fns give us about as much "poor mans tacitness" (they are nor strictly
tacit at all, of course) as we are comfortable with, and worry that
verb trains would be "language breaking" features. On the other hand,
as we extend Dyalog APL and design APL#, we're trying to make sure
that we don't introduce any syntax which would bar us from introducing
them at some point in the future.
I know less about the details of K, which I think of as a "reduced
instruction set" APL, with additional power (and incredible speed) for
dealing with large arrays of regular structures (aka "relational
tables"). I'm keen to learn more K and Q, the query language that is
built upon it, I know I will learn about some valuable ideas.
I think we a lot to gain by thinking of ourselves as one large
community focusing on different aspects of array processing, and
having chosen different solutions to the challenges that we face.
"Graphical" vs "ASCII-ART" symbols. Dictionaries vs arrays of objects.
Locales vs namespaces vs objects. Etc.
Roger Hui
> I have to admit I don't know what the definition of "a dialect" is.
Ken said that a language is a dialect with an army and a navy.
Bjorn
> find myself in the odd position of being able to TALK to J people
> about code, and even WRITE code in J if I spend a little time with the
> J Dictionary, but I read it about as well as my native Norwegian
> allows me to read Icelandic :-)
>
Ég er ansi hræddur um að íslenzka sé það mikið öðru vísi en danska að
þú eigir í meiri vandræðum með hana en joðið.
cjl
Catherine
Roger Hui
not APL" is "This is an APL conference/newsgroup/discussion,
J is not welcome here." One time, when I was bemoaning
yet another "J is not APL" discussion, Ken told me that
his father told him that, when a jackass kicks you, you have
to consider the source.
What I have learnt is that language design is a deep and
subtle business. Small differences can have large and
unexpected effects, and you can never learn enough.
An example is the introduction in J of the monad #, on
Arthur Whitney's advice. In Dyalog this is tally←{⍬⍴(⍴⍵),1} .
(J also has the monad $, exactly the monadic ⍴ of APL.)
Absent #x, everyone uses ⍴x, including the expression
(+/x)÷⍴x for finding the average, "the very best APL
expression". Well, the very best APL expression is flawed:
http://www.vector.org.uk/?vol=24&no=2&art=insession
On my part, I find Dfns very attractive and I think
I can <strike>steal</strike> learn something from it
and from APL conferences/newgroups/discussions.
You can't put too high a value on the chance to
talk with people like Arthur Whitney and John Scholes.
At any time they could say something which to them
is a throw-away line ("# is good"), and it'd
take you years to work out the implications.
1. For an APLer to call J a "readability disaster" is a bit
rich, the kettle calling the pot black, etc. If you show
|x
⌈x
x+.×y
x∘.+y
f∘g x
x f∘g y
+⌿x
x⌿y
x⌿¨y
etc. the average person with sufficient education to understand
the expressions would wonder where the "closing" | and ⌉ went,
and what exactly are . and ∘ and ⌿. That is, assuming the special
characters display correctly in the browser.
What about readability at a higher level? The following code for
solving the n queens problem is from
http://www.dyalog.com/dfnsdws/n_queens.htm
{⍵{↑¨↓↓(2|1↓⍳2×⍺)\((↑⍵)∘.=⍳⍺)⊃¨⊂'·⍟'}∪{{(⊃⍋↑⍵)⊃⍵},↑⍵}¨{{⍋⍵}\2/⊂⍵}¨∘
{{⍒⍵}\4/⊂⍵}¨⍵{(⍺=,↑⍴¨⍵)/⍵},¨↑⍬{↑(⍺⍺,⍺)∇∇
(1↓⍵⍵~¨⍺+(1+⍳⍴⍵⍵)×⊂¯1 0 1)/((⊃⍵⍵)~⍺+¯1 0 1),⊂⍵,⊂⍺⍺,⍺}
(1↓⍵⍴⊂⌽⍳⍵)/(⌽⍳⌈⍵÷2),⊂0⍴⊂⍬}
Unfair? After all, it is labeled on the page as "rather
opaque coding". The "official" solution is in
http://www.dyalog.com/dfnsdws/c_queens.htm
I won't exhibit it here since it is a screenful's worth
of code, 33 lines (7 lines of which are blank).
To get a more direct comparison, I translated the equivalent
J solution into Dyalog APL. From
http://www.jsoftware.com/jwiki/Essays/N%20Queens%20Problem
queens=: 3 : 0
z=.i.n,*n=.y
for. }.z do.
b=. -. (i.n) e."1 ,. z +"1 _ ((-i.){:$z) */ _1 0 1
z=. ((+/"1 b)#z),.n|I.,b
end.
)
∇ z←queens n;b;i
z←(n,1)⍴⍳n
:For i :In 1↓z
b←~↑(⊂⍳n)∊¨,¨(↓z)+[0]¨⊂({⍵-⍳⍵}1⌷⍴z)∘.ׯ1 0 1
z←((+/b)⌿z),n|{⍵/⍳⍴⍵},b
:EndFor
∇
I tried to be as fair as I could in the translation.
If you find better expressions please let me know.
In this one case I would say that if one is a readability
disaster then so is the other.
The Jwiki page whose URL was quoted above also has the function
queensw=: 3 : 0
j=. i.-y
d=. ((-i.)y)*/_1 0 1
stack=. ,&.> i.->.-:y
while. #stack do.
p=. >{:stack
if. y=#p do. return. end.
q=. p,"1 0 j-.p+(-#p){.d
stack=. (}:stack),<"1 q\:j#@-."1 2 q+"1 2 (_1-#p){.d
end.
)
which finds a single solution to the n queens problem.
Because it only finds a single solution it works
for large n in a reasonable amount of time and space
(e.g. queensw 64 takes 2 seconds and 200 KB). I would be
interested to know if you (or someone else; Mr. Last?)
can translate it into APL and if the result would be less
of a readability disaster.
2. The other objection you cited, "the really big difference",
is "verb trains" and "tacit forms". From your exposition I
believe you worry more about tacit forms than hooks/forks.
However, I am afraid it's too late for APL: tacit expressions
crept into APL in APL\360 in 1966, when +/ was implemented.
For Dyalog, the door opened wider when function assignment
was permitted, sum←+/ .
If you really want to forbid tacit expressions (or at least
curtail them, since they are already in the language),
you need to be more vigilant than just barring hooks and forks.
In my BAPLA 2009 talk I presented models for inner product.
dotc ← {↑ (↓⍺) ∘.(⍺⍺{⍺⍺/⍺ ⍵⍵ ⍵}⍵⍵) ↓(¯1⌽⍳⍴⍴⍵)⍉⍵}
dotc1 ← {↑ (↓⍺) ∘.(⍺⍺{⍺⍺/⍺ ⍵⍵ ⍵}⍵⍵) ↓flip ⍵}
dotc2 ← {↑ (↓⍺) ∘.(⍺⍺/at ⍵⍵) ↓flip ⍵}
dotc3 ← {↑ ⍺ ∘.(⍺⍺/at ⍵⍵)compose↓ flip ⍵}
dotc4 ← {⍺ ∘.(⍺⍺/at ⍵⍵)under↓ flip ⍵} ⍝ nonce error
dotc5 ← {⍺ ∘.(⍺⍺/at ⍵⍵)under↓∘flip ⍵} ⍝ nonce error
dotc6 ← {∘.(⍺⍺/at ⍵⍵)under↓∘flip} ⍝ nonce error
flip ← {(¯1⌽⍳⍴⍴⍵)⍉⍵}
at ← {⍺⍺(⍺ ⍵⍵ ⍵)}
compose← {(⍵⍵ ⍺)⍺⍺(⍵⍵ ⍵)}
under ← {(⍵⍵⍣¯1)(⍵⍵ ⍺)⍺⍺(⍵⍵ ⍵)}
All of the expressions not marked by "nonce error" are full-up,
executable Dyalog APL expressions. Not a hook or fork in sight.
If you slip up and let yourself be seduced by the operators
"at", "compose", and "under" and implement them, then the language
would be capable of much more tacitness, even without hook/fork.
"Under" is particularly seductive; I would even go as far as
to say that it is the main reason for having function inverses.
Its uses are legend. http://www.jsoftware.com/jwiki/Essays/Under
(Perhaps I worry too much on your behalf. In order to implement
"under" and friends you first have to find symbols for them.
I guess that's enough of a deterrent right there! ;-)
About the nonce errors: I believe dotc4 should work.
That it doesn't is due to a bug, I believe:
⎕ml
0
↑ ↓ 2 3⍴⍳6
0 1 2
3 4 5
↑ 2 3⍴⍳6
0 1 2
3 4 5
(↓⍣¯1) ↓ 2 3⍴⍳6
0 1 2
3 4 5
(↓⍣¯1) 2 3⍴⍳6
DOMAIN ERROR
(↓⍣¯1)2 3⍴⍳6
∧
As far as I can tell the interpreter treats ↓⍣¯1 as ↑,
and everything is OK except when the argument is simple.
If dotc4 works, then so should dotc5. The body of dotc5,
⍺ ∘.(⍺⍺/at ⍵⍵)under↓∘flip ⍵ , is pretty tacit.
An expression like ∘.(⍺⍺/at ⍵⍵)under↓∘flip would impress
even us theoretical/mathematical guys in J. dotc6 would
work if you succumb to the following seductive thing, viz.,
if the body of a Dop is of the form {⍺ f ⍵}, then the dyadic
derived function is just f, and it's not a leap too far
to permit {f} as equivalent to {⍺ f ⍵}.
FYI, the J equivalent for dotc6 is:
flip =: 0&|:
dotcj =: 2 : 'u/@:v"1/ flip'
I am going to have to ask you about the meanings of
"symbolic", "visual", and "easygoing" when I see you in Berlin.
You seem to be saying that J is more symbolic than APL.
I must be misunderstanding something because that can't
be right. And I am having trouble getting my head around
"APL2 is more "easygoing"". What does that mean?
APL2 does not have strict rules? APL2 has strict rules
but doesn't enforce them strictly?
On Aug 24, 12:40 am, Morten Kromberg <mk...@dyalog.com> wrote:
Roger Hui
> Its uses are legend.
Its uses are legion.
Also, I meant to include the URL to the inner product paper:
http://www.jsoftware.com/papers/innerproduct/ip.htm
Bjorn
> I am going to have to ask you about the meanings of
> "symbolic", "visual", and "easygoing" when I see you in Berlin.
> You seem to be saying that J is more symbolic than APL.
> I must be misunderstanding something because that can't
> be right. And I am having trouble getting my head around
> "APL2 is more "easygoing"". What does that mean?
> APL2 does not have strict rules? APL2 has strict rules
> but doesn't enforce them strictly?
I heard this said in 1982 in Heidelberg when the battle between APL2
and IPSAPL more or less started.
I did not understand it at the time but what it referred to then was
you did not need to put link between elements when creating a nested
array and thus APL2 got to be known as the missing link.
It took me years to understand the meaning of this difference.
Morten Kromberg
I think this means you think Icelandic is more different from Danish
than J is from APL.
If it doesn't, you are right.
If it does, the jury is still out :-)
With respect to the rest, I have made some rather loose statements
again and Roger has nailed me down rather well on a couple of points.
I shall go away and sulk for a bit and try to return with some remarks
which make it appear as though my brain was engaged :-)
Bjorn
I am afraid that Islandish is that much more different from danish
that it is more difficult for you to understand than J
Bjorn
> not APL" is "This is an APL conference/newsgroup/discussion,
> J is not welcome here." One time, when I was bemoaning
> yet another "J is not APL" discussion, Ken told me that
> his father told him that, when a jackass kicks you, you have
> to consider the source.
I have never understood why many people in the past were always trying
to find problems instead of trying to work together.
There still are occasional jackasses trying to kick but there are more
and more sensible people working for joining forces for the future.
I am starting to listen to a book - I am completely hooked on
listening to books - where the main character is quoting a saying of
his father.
"It will be never better than this" and meaning you should stop and
enjoy the moment.
Always be on the run after something better will hinder you in
enjoying the present.
I like all the dialects/implementations of APL I have come across and
all of them had qualities I could enjoy and use.
Obviously pretty much anything has shortcomings and can be improved.
If you seek problems you can always find them.
I used VSAPL and I really loved it and when APL2 came around I found
it absolutely brilliant.
I have to say I was a bit or actually really disappointed that REXX
and APL2 did not work better together than they did even if both of
them were brilliant in their own way.
In the same way it was/is really a pity that IPSAPL and APL2 did part
so much as they did.
If there is anything we should try to work for in the future then it
is to make sure that we either decide to work together to promote the
ideas of APL in general and stay different or try to work together
towards some common goal.
But at least try not to be so hostile as some have been in the past.
Try to enjoy what we have but keep the possibility open for
improvements.
The improvements I see in most need are in the way the products are
presented because technically there is nothing - or at least not much
- wrong with any of our products.
Morten Kromberg
> 0. As I see it, the main pragmatic implication of "J is
> not APL" is "This is an APL conference/newsgroup/discussion,
> J is not welcome here."
It does depend on the purpose of the newgroup, of course. In the
Dyalog Forum, readers have a right to expect that posts will be
"directly relevant" to the work that they are doing. Small amounts of
code written in j/k/other APL dialects are welcome if they illustrate
some interesting point, but people will be rightfully be upset if they
ask how to solve a problem in Dyalog APL and they get a bit of J code
back (in fact, that would be rude in any forum, except perhaps the J
forum itself).
My opinion is that comp.lang.apl currently mostly serves as a
discussion forum for (ideally polite and respectful) "comparative
studies" of various APL dialects, and the discussion on how we should
be presenting our tools. Users of J, K, all APL2 and SHARP APL
derivatives (remember Data General APL?), and users of functional /
array oriented languages who feel they have valid points to make,
should all feel welcome here.
If many readers of comp.lang.apl disagree with this, it could be that
we need a separate forum.
Bjorn
And if you want to use J to learn Islandish then there are the books
"J fyrir C forritara" a translation of "J for C programmers" and
"grunnur.pdf" a translation of "J Primer" available at:
http://groups.google.com/group/j-programming/files
I did this some years ago and I can tell you I had a difficult time of
translating many of the words and concepts.
Phil Last
things:
I am afraid it's too late for APL: tacit expressions crept into APL
in APL\360 in 1966, when +/ was implemented. For Dyalog, the door
opened wider when function assignment was permitted, sum←+/
Thank you Roger for clearing up something that's been bothering me for
a number of years. Not sufficiently to make me do anything about it I
must admit but bothering me nevertheless and also putting me off
learning the langu... sorry, vocabulary.
Various commentators have extolled J in terms of its abilities with
regard to tacit programming without explaining what they meant.
Obviously something unique to J and not for the ordinary folks using
APL. It seemed to me from the meaning of the word that they aught to
mean the composing of derived functions. But if that were the case
there would be nothing special for them to be crowing about because
you can do that in APL with its admittedly smaller set of primitive
operators and the ease with which others can be defined.
Thank you for undeceiving us.
Roger Hui
Regarding the term "tacit" or "tacit definition".
If Ken went to the trouble of using "verb" instead
of "function", "adverb" and "conjunction" instead
of "operator", he was at least consistent to use a
different term for "operator expression".
There _is_ something special about J re tacit definition:
as of this writing, J is the only APL dialect with fork.
What is so special about fork? If you want to write
things tacitly, i.e. as operator expressions, there is
a large class of expressions that are not expressible
without fork. (Morten was right to be vigilant against fork!)
The simplest example is to write f+g as in calculus. Try it.
Ken struggled for years to do it.
Scalar Operators, _Operators and Functions_, 1978
http://www.jsoftware.com/papers/opfns.htm
Til, _Rationalized APL_, 1984
http://www.jsoftware.com/papers/RationalizedAPL.htm
Union and Intersection, _A Dictionary of APL_, 1987
http://portal.acm.org/citation.cfm?id=36983.36984
Yoke, _A Commentary on APL Development_, 1988.
http://www.jsoftware.com/papers/commentary.htm
Fork, _Phrasal Forms_, 1988.
http://www.jsoftware.com/papers/fork.htm
"Tacit Definition" was defined in the APL92 paper _Tacit Definition_,
http://portal.acm.org/citation.cfm?id=114054.114077
The paper also explains why forks are necessary for expressive
completeness.
The story of fork is summarized in _Remembering Ken Iverson_
http://keiapl.org/rhui/remember.htm#fork0
Ken and I had in mind to implement _A Dictionary of
APL_ [8] together with hooks and forks (phrasal forms) [20].
For years, Ken had struggled to find a way to write f+g
as in calculus, from the “scalar operators”
in _Operators and Functions_ [5, section 4], through
the “til” operator in _Practical Uses of a Model of APL_ [6]
and _Rationalized APL_ [7, p. 18], and finally forks.
Forks are defined as follows:
(f g h) y ↔ (f y) g (h y)
x (f g h) y ↔ (x f y) g (x h y)
Moreover, (f g p q r) ↔ (f g (p q r)) . Thus to write
f+g as in calculus, one writes f+g in J. Ken and Eugene
McDonnell worked out the details on the long plane ride
back from APL88 in Sydney, Australia, with Ken coming up
with the initial idea on waking up from a nap.
A final point, one that Morten touched on: There is as
yet nothing in the various APL dialects that prevents them
from introducing fork. Dyalog APL:
f ← × + ÷
SYNTAX ERROR
f←×+÷
∧
If the SYNTAX ERROR were replaced by fork, then:
f ¯5 7
¯1.2 1.142857143
¯5 7 f 2 3
¯12.5 23.33333333
Ric
>
> There _is_ something special about J re tacit definition:
> as of this writing, J is the only APL dialect with fork.
Actually it appears that NARS2000 may implement fork?
From the Language features section of http://www.nars2000.org/index.html
:
Trains are supported, e.g., avg←(+/ ÷ ⍴) creates a function that
calculates the average of a numeric vector
Ric
> On Aug 26, 9:08 am, Roger Hui <RHui...@Shaw.CA> wrote:
>
>
>
> > There _is_ something special about J re tacit definition:
> > as of this writing, J is the only APL dialect with fork.
>
> Actually it appears that NARS2000 may implement fork?
>
> :
> Trains are supported, e.g., avg←(+/ ÷ ⍴) creates a function that
> calculates the average of a numeric vector
Roger Hui
My version 0.0.2.13 circa June 2009 does not have forks.
p.s. Bob, if you implement #, then you can define
average as +⌿ ÷ # instead of the defective +/ ÷ ⍴.
Bob Smith
> I guess it's time to download the latest NARS2000.
> My version 0.0.2.13 circa June 2009 does not have forks.
>
> p.s. Bob, if you implement #, then you can define
> average as +⌿ ÷ # instead of the defective +/ ÷ ⍴.
better version of the average function when I release the next version.
As the # symbol is already in use, I use right caret as the symbol for
Tally as in
>23
1
>⍳5
5
>2 3⍴⍳6
2
because that symbol evokes extraction of information.
However, I'm open to suggestions if there's a consensus to use a
different symbol. For example, the symbols available as monadic
functions and already on the APL keyboard (although I'm not sure about `
@ % & on international keyboards) include
< ≤ = ≥ > ≠ ∨ ∧ ⍱ ⍲ ` @ % &
as well as any new Unicode symbol.
--
_________________________________________
Bob Smith -- bsm...@sudleydeplacespam.com
To reply to me directly, delete "despam".
http://www.sudleyplace.com - http://www.nars2000.org
Phil Last
> The paper also explains why forks are necessary for expressive
> completeness.
>
Roger, when you say:
Try it. Ken struggled for years to do it.
Do you mean without the syntax change it can't be done in a general
way?
The version of the operator below was written in 2007. Its first
incarnation was several years before that.
fk←{
a m d g←112358314594370 774156178538190 998752796516730
336954932572910
⍺←a
⍺≡a:g ⍺⍺(m ⍺⍺ ⍵)(⍵⍵ ⍵)
⍺≡m:⍺⍺ ⍵
⍺≡d:⊃⍺⍺/⍵
⍺≡g:⊃⍵⍵/⍵
g ⍺⍺(d ⍺⍺ ⍺ ⍵)(⍺ ⍵⍵ ⍵)
⍝ fork
⍝ f fk g fk h
⍝ applies g between the results of f and h having
⍝ applied each to ⍵ or between ⍺ and ⍵
⍝ Phil Last ⍝ 2007-06-23 18:47
}
Its one limitation is that none of the four integers on line one may
be used as a scalar left argument. In another version the numbers are
generated as multiples of the latest fixed date of the operator which
aught to make them even less likely to be inadvertently encountered.
Also; not knowing J or SharpAPL I don't know if (f g h j k)y is ((f g
h)j k)y or (f g(h j k))y
The above operator owing to normal scope/binding treats it as the
former.
0 1 2 3 4 >fk∨fk= 4 3 2 1 0 ⍝ (>∨=)
0 0 1 1 1
0 1 2 3 4 <fk⍱fk=fk∨fk= 4 3 2 1 0 ⍝ ((<⍱=)∨=)
0 0 1 1 1
Bjorn
integrated with other languages.
Like in the new J7 JHS beta (the new browser GUI) then J and JS
(Javascript) are so integrated that it is hard to see which is being
used.
It is also heavily using XML there is actually a new concept called
ajax used in the communication.
From the J help:
"Ajax stands for 'asynchronous javascript and xml'"
When that is used the update of the GUI is much faster than when the
whole page is refreshed because there is hardly any data sent betweenn
the two.
In the mainframe world there used to be quite an interesting
interaction between ISPF, GDDM, REXX and APL2 which was very
interesting but it never went as far as I would have liked.
Even if all those products were IBM they missed doing it to a really
big hit.
I have seen a lot about some APLs integrating with .net but I do not
have much knowledge about that nor experience but maybe it is a good
thing.
I think that APL has to integrate well with the rest of the world and
I have always thought so.
Maybe that is slowly happening now?
Roger Hui
to do fork without having special syntax, this is the least
complex and least awkward. I'll see if I can do "fk" with
the facilities available to Ken in the 1970's and 80's,
i.e. functions, operators, boxed arrays, but no defined
derived function, which is what fk is.
The way fork is defined in J, (f g h p q) is (f g (h p q))
rather than ((f g h) p q), but I think that is not
relevant for the current discussion.
Aside from not having magic numbers and aside from being
shorter, the special syntax buys you another thing,
and that is not having to parenthesize the functions on the
tines if those functions are themselves operator expressions.
For example, sum divided product would be +/ % */ as a fork,
but would be +/ fk % fk (*/) using fk, where the parens
are required.
Phil Last
I think the hope of doing fork with neither an operator (defined
derived function) nor a syntax change is probably as vain now as
ever.
My purpose in writing fk was merely to show that an operator would do
the job albeit with a few more parentheses. It's often thought that a
distributed operation such as this (multiple calls to conjunctions
acting in concert (action at a distance)) is un-APL-like (cf square
brackets, control structures &c). By making it work with a single
operator I hope I've demonstrated that a fork operator doesn't break
the normal infix parsing rules.
Of course if it were a primitive the magic numbers could disappear and
be replaced by placeholders not unlikely but actually impossible
inadvertently to be reproduced.
I'd be inclined redundantly to parenthesise (+/%*/) to ((+/)%(*/)) in
any case as I doubt that even if I could be persuaded that the parsing
is consistent I'd never be comfortable with it. It seems to me that
whichever of (+-(*%#)) ((+-*)%#) is (+-*%#) and whichever of (+-(*%))
((+-)*%) is (+-*%) is an arbitrary precedence rule that would be
unnecessary if fork were a conjunction.
One last point. The current unuse of (f g h) as a syntax construct is
insufficient to make it available for the first suggestion that could
make use of it. Fork is only one candidate; all but one use (f∘w) of
the compose operator constitute another: (f g h)←→{f∘g∘h); function
vectors another: (f g h)x y x ←→ (f x)(g y)(h z). But for fork there
is fk; for compose we have compose anyway; for function vectors a
single defined conjunction can be written along the same lines as fk.
(f fv g fv h)x y z←→(f x)(g y)(h z).
When (if) an earthshatteringly important new feature is dreamed up
(that no-one ever needed before) that requires verb trains and that
can't be implemented with an operator, that will be the time to make
use of them.
Ibeam2000
The Yiddish linguist Max Weinreich published the expression, "A
shprakh iz a dialekt mit an armey un flot" ("אַ שפראַך איז אַ דיאַלעקט
מיט אַן אַרמײ און פֿלאָט ", "A language is a dialect with an army and
navy"; in Yivo-bleter.
Roger Hui
> any case as I doubt that even if I could be persuaded that the parsing
> is consistent I'd never be comfortable with it. It seems to me that
> whichever of (+-(*%#)) ((+-*)%#) is (+-*%#) and whichever of (+-(*%))
> ((+-)*%) is (+-*%) is an arbitrary precedence rule that would be
> unnecessary if fork were a conjunction.
"Never" is a long time, and your comfort may increase
with time and usage. I expect that most J users are
comfortable with +/ % # and find odd (+/) % # .
It helps with the readability if the writer inserts
spaces at strategic points, e.g. +/ % # instead of +/%# .
The J implementation influences this: In J, entering a verb
(function) causes its representation to be displayed. Thus:
avg=:+/%#
avg
+/ % #
+/%*/
+/ % */
There is a session parameter which controls the preferred
representation to be displayed (and whether more than one
representation is to be displayed). So if I choose to
display the fully parenthesized form, I'd get:
avg
(+/) % #
+/%*/
(+/) % (*/)
Of course, there will be cases where one'd put in redundant
parentheses to emphasize the symmetry in a particular expression.
For example, I'd be inclined to put in the extra parens into
(+/)fk÷fk(×/) instead of the permissible and exactly equivalent
+/fk÷fk(×/).
> When (if) an earthshatteringly important new feature is dreamed up
> (that no-one ever needed before) that requires verb trains and that
> can't be implemented with an operator, that will be the time to make
> use of them.
This is an example of an argument that is too powerful,
because it can be used to argue against replacing
any error with a computation, and in general against
doing anything new: we don't want to impose interpretation
X because someday a better interpretation Y may come
along. Judgment (and faith?) need to be involved to
decide whether interpretation X is good enough on its
own merits, and I think we can not have a hard and
fast rule along the lines of, if it can be done with
existing facilities, even readily done with existing
facilites, then we don't want a new construct for it.
To quote myself from a few days ago, language design
is a deep and subtle business. (I can add that it's
sometimes a mysterious business.)
Example: We don't need to have - because its monad is
{¯1×⍵} and its dyad is {⍺+¯1×⍵} (and, for you Dfun-istas,
- is {⍺←0 ⋄ ⍺+¯1×⍵}). In J we don't need to have j.
because its monad is {0j1×⍵} and its dyad is {⍺+0j1×⍵}.
When I implemented j. I did not argue with Ken or even
discuss it with him and just took it on faith that he knew
what he was doing. It's only recently when I implemented
complex numbers in Dyalog APL and was forced to use complex
numbers and write about them, that I think I understand
why Ken might have wanted j. . With j., and with fork,
I can write ^@j. = cos j. sin to express the identity that
(*0j1×z) = (cos z)+0j1×sin z ; without j., I have to write
^@(0j1&*) = cos + 0j1 * sin . And without fork, I'd have to write
^@j. fk = fk (cos fk j. fk sin) . Without fork and without j.,
I'd have to write ^@(0j1&*) fk = fk (cos fk + fk ((0j1&*)@sin)) .
Example: Bob Smith said that he can not use # in NARS2000
to denote the monad which produces the number of items
in its argument because it already has an interpretation
in NARS2000. I can tell you without knowing what the
interpretation of # is in NARS2000 (and whatever other
possibilities there are for #), that I have no regrets
about the interpretation of # in J, both the computation
and the choice of the glyph.
I feel the same about fork.
-
Roger Hui
without knowing that I should be looking for it.
http://en.wikipedia.org/wiki/A_language_is_a_dialect_with_an_army_and_navy
"A language is a dialect with an army and navy" is one of the most
frequently used aphorisms in the discussion of the distinction
between dialect and language. It points out the influence
that political conditions can have over a community's perception
of the status of a language or dialect. ...
-
Bjorn
using translate.google.com
from the hebrew
to german
Ein Spraach Iz a Dialaakte Ann Ermei Mitch Platt auf
to swedish
En Spraach Iz en Dialaakte Ann Ermei Mitch Platt På
to english
A Spraach Iz a Dialaakte Ann Ermei Mitch Platt On
to islandish
A Spraach Iz a Dialaakte Ann Ermei Mitch Platt Á
from the english
to german
Eine Sprache ist ein Dialekt mit einer Armee und Marine
to swedish
Ett språk är en dialekt med en armé och flotta
to islandish
Tungumál er mállýska með her og floti
from A
shprakh iz a dialekt mit an armey un flot
to islandish
A shprakh iz a mállýskum með Armey á un flot
to swedish
En shprakh iz en dialekt med Armey på un Flot
to english
A shprakh iz a dialect with Armey on un flot
So from analysing this I would say the english it should read:
"A language is a dialect with an army on a pram"
Roger Hui
would look like with a proper symbol for the fk operator.
I propose to use ψ (psi) :-). I am at a loss for a symbol
for j. so I'll use j←{⍺←0 ⋄ ⍺+0j1×⍵} for the nonce.
With fork and with j. in J:
^@j. = cos j. sin
With ψ in Dyalog APL, various attempts:
*∘j ψ = ψ (cos ψ j ψ sin)
cos ψ j ψ sin ψ = ψ (*∘j)
*∘jψ=ψ(cosψjψsin)
cosψjψsinψ=ψ(*∘j)
-
Phil Last
I can't argue with that.
I'm learning a lot from this and the first here is to dispel the
difficulty I had with parsing (f g.h p/) (say). Because I've always
viewed forks when attempting to read J as if they're derived functions
with the conjunctions stripped out I've failed to realise the symmetry
between (f g.h p/)y and f g.h p/ y APL's having no difficulty in
parsing the latter.
Nevertheless I still think other APLs would be better advised to
implement fork as a primitive conjunction rather than with a syntax
change. There's even a unicode character '⋔' U+22D4 (⎕UCS 8916) they
could use.
There's more to think about here.
Bob Smith
> I'm learning a lot from this and the first here is to dispel the
> difficulty I had with parsing (f g.h p/) (say). Because I've always
> viewed forks when attempting to read J as if they're derived functions
> with the conjunctions stripped out I've failed to realise the symmetry
> between (f g.h p/)y and f g.h p/ y APL's having no difficulty in
> parsing the latter.
>
> Nevertheless I still think other APLs would be better advised to
> implement fork as a primitive conjunction rather than with a syntax
> change. There's even a unicode character '⋔' U+22D4 (⎕UCS 8916) they
> could use.
train. Hooks and Forks are but two of the cars in a whole hierarchy of
trains (of course as the simplest, they are the most useful), just as I
have no regrets in using # as Dyalog and APL+WIN do to denote the System
Class. The fact that (f g) and (f g h) and (e f g h), etc. all follow a
common set of rules means we don't need a whole hierarchy of operator
symbols, just one set of parens to denote the train whose meaning
depends upon the number of functions in the train.
phil chastney
that's lovely -- thanks to UTF-8 and Thunderbird, I see fully pointed
characters, formed from (base + mark), rather than composites, but is
that the word order Max Weinreich used? or is there a problem somewhere
with the rendering of L←R text embedded in a L→R context?
/phil
Stephen Taylor <editor@vector.org.uk>
There is indeed a general problem with breaking lines in R-L text
embedded within L-R text.
Donald Knuth discusses it at length in Ch.4 of "Digital Typography":
http://www-cs-faculty.stanford.edu/~uno/dt.html
SJT
Bjorn
It is interesting that when you copy the text to a translating window
at google the text turns around
phil chastney
my apologies -- I'm being dense
אַ שפראַך איז אַ דיאַלעקט
מיט אַן אַרמײ און פֿלאָט
makes perfect sense, which, when the line break is removed, becomes
אַ שפראַך איז אַ דיאַלעקטמיט אַן אַרמײ און פֿלאָט
which is how it appears above, so the linebreak I saw last time was
provided by Thunderbird on my machine -- I'm really quite impressed
many thanks to Ibeam2000 for the opportunity to learn something new
/phil
Morten Kromberg
> For an APLer to call J a "readability disaster" is a bit
> rich, the kettle calling the pot black, etc.
[and a bit later]
> I translated the equivalent J solution into Dyalog APL.
[>>> omitted from function definitions for readability]
queens=: 3 : 0
z=.i.n,*n=.y
for. }.z do.
b=. -. (i.n) e."1 ,. z +"1 _ ((-i.){:$z) */ _1 0 1
z=. ((+/"1 b)#z),.n|I.,b
end.
)
z←queens n;b;i
z←(n,1)⍴⍳n
:For i :In 1↓z
b←~↑(⊂⍳n)∊¨,¨(↓z)+[0]¨⊂({⍵-⍳⍵}1⌷⍴z)∘.ׯ1 0 1
z←((+/b)⌿z),n|{⍵/⍳⍴⍵},b
:EndFor
> I tried to be as fair as I could in the translation.
> If you find better expressions please let me know.
Morten: I think you have been very fair in your translation of queens.
Perhaps the code can be made slightly more “colloquial” in modern
Dyalog. If you allow me to bring the code a wee bit closer to the J by
defining (Wh←{⍵/⍳⍴⍵}) so that we have the equivalent of your (I.)
which we don’t YET have in Dyalog APL, I like:
z←queens n;b;i;t
z←⍪⍳n
:For i :In 1↓z
t←(i-⍳i)∘.ׯ1 0 1
b←~↑{(⍳n)∊⍵+[0]t}¨↓z
z←((+/b)⌿z),n|Wh,b
:End
> In this one case I would say that if one is a
> readability disaster then so is the other.
The two solutions now feel almost identical to me, so perhaps I should
simply agree and shut up. Neither of us is likely to change our
position on this, it is all very subjective, and “my language is
better than yours” isn’t generally a very useful game to play. But I
think there *are* some interesting issues that are worth discussing.
The fact that many APLers are uncomfortable with J, like many other
programmers are uncomfortable with APL (or both APL and J), is worth
trying to understand for anyone involved in designing or promoting the
use of a notation - even if there is little that any of us can (or
want to) do about it at this point in space-time. Attracting a few
more APLers to J is probably less important to you than attracting all
kinds of other people, so I'm not really recommending that you do
anything about this - I'm really only venting my own frustration at
finding J hard to read and perhaps even secretly hoping that you'll be
able to help me see the light :-)
I think the J is “more succinct” in a couple of places: The
rationalizations in J don’t play a very big role in this case, but in
particular I think that (z +"1 _) is significantly nicer than ((↓z)
+[0]¨⊂), and I prefer (*/) to the rather anomalous (∘.×). We do plan
to add rank to Dyalog APL "soon" but we probablyl can't change the
current syntax for outer product without causing massive grief. We we
have ideas about adding the use of a centered Unicode “mathematical
dot” to construct both inner and outer products in the future, and
phase out the use of the full stop (if we can find a nice solution for
the keyboarding and the migration issues – which I think we can).
My real problem with J is very specific and related to the way multi-
character symbols are formed: Perhaps my brain is just "stuck" – but
here is another attempt to describe problem that I have now struggled
with for 20 years:
I "FEEL" that there is a big problem for me in the use of the symbols
(.:!) as part of the "symbol trains" that construct J primitives.
Trying to rationalize this, I have a few theories: One is that human
eyes are trained to interpret these symbols as punctuation or
separators, which means the basic instinct is not to try to form
"words" which include them. Once you cross this hurdle, there is an
additional lexical pass required to turn something like "e." into the
well-known symbol for membership (∊), and since I seem to chose my
languages based on the “immediacy of the notation”, I just don't LIKE
this (I think that I DO prefer it to EPSILON or MEMBER_OF,
though :-)). In APL environments, it is common to argue about WHICH
FONTS to use, in order to highlight the difference between primitive
and user-defined names, in order to enhance the readability. But in J
you encounter sequences of characters like “=.i.i,” , where the first
i is part of a primitive symbol and the other is a user-defined name.
A training issue of course, but I find myself looking left and then
right to be sure that am I have the context exactly right, and it
feels like a significant (and most importantly unnecessary) additional
burden.
In recent times, there is also the additional problem J cannot adopt
the more or less universal notation for object references (like
Excel.ActiveWorkbook.CurrentSheet), which many APL systems share with
just about every other programming language, and we know from
experience makes APL look much more attractive (and useful!) to
younger generations of programmers. A couple of minor gripes would be
the use of unpaired double quotes for rank - even though that
particular symbol actually looks comfortable to an APLer due to the
similarity to "each". Using unpaired symbols that the eye associates
with grouping, like {}[] (with or without following dots and colons)
also feels as if it make the code harder to (learn to) read.
This is my (personal!) "readability disaster", and I really wish that
different solutions had been found, so that J would feel better to me
– as I find J to be beautiful in so many other ways. Of course I CAN
train my eye to ignore these problems, but I’d rather use a notation
which doesn’t have THESE issues.
APL is of course also guilty of assigning new meanings to symbols
which already had a different use in other languages, like using *
and / to mean power and replicate rather than multiplication and
division (but FORTRAN had only been around for a decade at the time,
while × and ÷ had centuries of use). As previously mentioned, APL also
“abuses the dot” in the notation for inner and outer product; for us
this is a problem that we intend to address.
I think I understand most of the rationale behind the J notation, and
I do know that many people have happily learned J in the last 20
years. But paradoxically, now that Unicode has arrived, the use that J
makes of symbols is in some ways becoming "more special" than APL.
Roger: You seem to be saying that J is more symbolic than APL.
That was not my intention – the pet theory that I was trying to put
forward is that the PEOPLE who don’t find the J notation as
problematic as I do possibly have a more symbolic approach to
mathematics and programming than I do, and have minds which can more
easily become comfortable with the additional bit of “symbolic
manipulation” required to turn “e.” into ∊ and so forth. I find this
to be a significant additional burden; others clearly do not.
I’ll return to the verb train/tacit discussion in a separate message,
if I am able construct any coherent comments on that subject.
Roger Hui
and to put it into colloquial Dyalog. My goal in
talking about "queens" was more modest than arguing
that "my language is better than yours" (which I
seldom do, even against languages not in the APL family).
Rather, it was to demonstrate that J is not as unreadable
as you made it sound. I consider that I have achieved
my modest objective.
Some specific points about your version:
- I am surprised that you felt it necessary to
define Wh←{⍵/⍳⍴⍵} as a subfunction, rather than
just using {⍵/⍳⍴⍵} in-line. I would have thought
that that is one of the strengths of Dfns, that
you can easily define and use functions in-line.
Perhaps you thought that the comparison is on the
lengths of the expressions whereas I was going for clarity.
(That must be it. Otherwise, the subfunction would have
been named "Where" rather than "Wh".)
In-line Dfns is an advantage that Dyalog has over other
Dfn-less and forkless APL dialects, because there the
only "natural" way to have in-line functions is through
operator expressions, which are constrained by a very limited
set of operators. (Doing tricks with ⎕fx is not "natural".)
- I see that you exploited the loop variable i
to shorten some of the expressions. I could have
done that in both the J and my Dyalog version.
I did not do so because not using the loop variable
makes it easier to transform the n queens computation
into the form (f⍣(n-1))⍪⍳n. Kind of like the
tail-recursion tricks that Dyalog does with Dfns.
The question of character set design is actually
amenable to rational discussion, and I am now going
to try to have one. The symbols in J are based on 7-bit
ASCII (with the North American "national use characters"),
assumed to be universally supported everywhere without
extra work. When J got started in 1989, universal support
was the goal, and there were no other viable candidates.
Today, the arguments on the other side would be stronger,
but probably still not strong enough. e.g. I would venture
to guess that Unicode support requires the tender loving care
of a skilled and dedicated programmer, and you still run into
problems with the special characters that require descriptions
such as http://www.vector.org.uk/archive/display.htm .
It is possible for a dialect in the "Dictionary APL" family
to have the special characters, as the existence of SAX
(SHARP APL Unix) demonstrates. In the very early days J
itself had _both_ the ASCII spelling _and_ special characters.
http://keiapl.org/rhui/remember.htm#flexible says:
For the first few months, the special APL characters
and the ASCII spelling co-existed in the system.
It was Ken who first suggested that I should kill off
the special APL characters. I myself resisted
for a few weeks longer, until the situation became
too confusing, for reasons described in _J for the APL
Programmer_ [35, p. 11].
Even today, you can try to replace the ASCII spelling in J
with Unicode symbols. That this is not as easy as it sounds,
assuming aesthetics is a consideration, is demonstrated by the
following small example: j. is the computation {⍺←0 ⋄ ⍺+0j1×⍵}.
I spent about 10 minutes trying to find a Unicode symbol for it
that is as least as good as j., without success.
I understand the comment about the use of . and :
in the J spelling. I can say that facility with
reading the J spelling does come with training
and experience. When I see e., I don't go through
the intermediate stages of e and then . and then e.
and then "member"; when I see "e.", I go straight
to "member". I don't know what is it with other
J users (symbolically oriented or not), but I suspect
it is similar with them, because it'd take too long
otherwise. You yourself can try the following experiment:
when you see "man", do you see m a n, then go through
some sort of manipulation that you are conscious of,
before you think "biped male" (or other similar meaning)?
Moreover, do you have to process the serifs and other
little details of the letters before you see the m a n?
To me, the . and : in J words have become like the
serifs in the various fonts for English text.
Another experiment: in your "queens" function, there
are the keywords :For :In :End. (Ha! colons! :-) I doubt
that the colons give you much trouble, because by now
with training and usage you have learnt not to focus on them.
(BTW, just now I tried to define your "queens" function and
discovered something "not nice". If I put in your function
as is, with :End instead of :EndFor, and exit the editor,
it lets me exit but silently fails to define the function.)
A writer that produces =.i.i without putting in
spaces deserve a good talking to. On the other hand,
there is a "words" primitive (the monad ;:) that
tells you what are the "words" as far as the J system
is concerned, and with this primitive it is easy
to write a utility that spaces out everything. e.g.
t=: 'b=.-.(i.n)e."1,.z+"1 _((-i.){:$z)*/_1 0 1'
;: t
┌─┬──┬──┬─┬──┬─┬─┬──┬─┬─┬──┬─┬─┬─┬───┬─┬─┬─┬──┬─┬──┬─┬─┬─┬─┬─┬──────┐
│b│=.│-.│(│i.│n│)│e.│"│1│,.│z│+│"│1 _│(│(│-│i.│)│{:│$│z│)│*│/│_1 0 1│
└─┴──┴──┴─┴──┴─┴─┴──┴─┴─┴──┴─┴─┴─┴───┴─┴─┴─┴──┴─┴──┴─┴─┴─┴─┴─┴──────┘
]&.;: t
b =. -. ( i. n ) e. " 1 ,. z + " 1 _ ( ( - i. ) {: $ z ) * / _1 0 1
Such a utility in Dyalog APL would be non-trivial to write,
I believe. (e.g. to handle f⍣a b it has to know the
nameclasses of a and b, I believe.)
There are a couple of other examples of APL-like
languages that uses 7-bit ASCII. k severely curtails
the number of primitives so that only single-character
symbols are required. q has multi-character names
for primitives (e.g. reverse, raze, group). Some
commentators even attribute this as one of the key
factors in the commercial success of q. You can
investigate these alternative approaches and see
how you like them.
-
Bjorn
Unearthing the Excellence in JavaScript
By Douglas Crockford
A quote from the book:
"It is rarely possible for standard committees to remove imperfections
from a language because doing so would cause the breakage of all of
the bad programs that depend on those bad parts. They are usually
powerless to do anything except heap more features on top of existing
pile of imperfections. And the new features do not always interact
harmoniously, thus producing more bad parts."
In making J Ken mentioned a few mistakes or imperfections he had made
and wanted to correct but it would be hard to get the standard
committees to accept the changes.
In the past I had the APL chars more or less hard coded in my fingers
and did not need to have them on the keyboard.
After spending 20 years on J I am not as fluent on the APL chars
anymore because I tend to think in the ASCII signs that J uses.
I do see a difference between @ @. and @: and in some degree remember
the different names and operations that they perform.
I think that even today that Unicode is not yet a real option
everywhere and that our so beloved APL chars are a real hindrance.
The book mentioned above is about Javascript (JS) and the next version
of J and the current beta of J7 JHS is mixing J and JS.
It is often difficult to see what is what because they both use ASCII
signs.
It would probably be easier to see the difference if one was in APL
and the other in JS.
Then it would also be more difficult to use simple editors to write
the code.
When I read the quote above about languages in general I immediately
associated the quote with APL.
I do understand that correcting mistakes and making big changes would
make life difficult for the people who have programmed using those
mistakes.
Take a simple mistake like have two index origins.
There are numerous programs using one or the other or a mixture of the
two and there would be an impossibility to predict what would happen
to all the APL program if all of a sudden one would be removed so
people are amking all kinds of corrections to pile on top of this
simple mistake.
J of course removed this mistake as well as removed the character set
mistake.
When we want to think about where APL should be in twenty hundred and
twenty then at least a suggestion of removing those two mistakes could
be a start but then again we already do have a solution and it has
been around for a number of years now so it is not so hard really.
phil chastney
> <snip>
>
> J of course removed this mistake as well as removed the character set
> mistake.
>
> When we want to think about where APL should be in twenty hundred and
> twenty then at least a suggestion of removing those two mistakes could
> be a start but then again we already do have a solution and it has
> been around for a number of years now so it is not so hard really.
those who consider symbolic notations a "mistake" will doubtless be
charmed by
http://mathdl.maa.org/mathDL/47/?pa=content&sa=viewDocument&nodeId=1345&bodyId=1501
personally, I much prefer modern notation
why (some) programmers feel uncomfortable outside the ASCII character
set still baffles me, but there's no accounting for taste, I guess
/phil
phil chastney
all of which is undermined by the fact that the MAA don't use UTF-8
see
http://mathdl.maa.org/mathDL/47/?pa=content&sa=viewDocument&nodeId=1345&bodyId=1494
bizarre! . . . /phil
Roger Hui
> ...
> There are a couple of other examples of APL-like
> languages that uses 7-bit ASCII. k severely curtails
> the number of primitives so that only single-character
> symbols are required. q has multi-character names
> for primitives (e.g. reverse, raze, group). Some
> commentators even attribute this as one of the key
> factors in the commercial success of q. You can
> investigate these alternative approaches and see
> how you like them.
I find it worthwhile to pay attention when something _is_
a primitive in k.
Example 0: "where", whose symbol in k I've forgotten.
This is {⍵/⍳⍴⍵} in Dyalog (already supported by special code
aka recognized as an idiom) and the monad (# i.@#) or I. in J.
Having I. makes it easier to provide special code for
I.@:E. (indices of where x occurs in y as a subsequence),
I.@:> (indices where x is greater than y), etc.
Example 1: The dyad x?y in k is {?⍺⍴⍵} in Dyalog or ?x$y in J.
Since the dyad ? already had a meaning in J (the same as the
APL meaning), the computation is effected in J as special code
for ?@$ . Think of the advantages when the right argument is 2
(and ⎕io is 0). It is advantageous even in the more general case
where the right argument is not 2 but a single number.
Ibeam2000
> why (some) programmers feel uncomfortable outside the ASCII character
> set still baffles me, but there's no accounting for taste, I guess
It's not the programmers, but rather their managers.
Bjorn
It has always been problematic with characters outside of the ASCII
character set in one way or the other.
Some people find it a challenge to get it to work but most people just
see it as a nuisance.
At best you are only missing the fonts or see some blips on the screen
or printer.
Anoher is that when these blips perform powerful operations it is like
putting a machine gun in the hands of babies if you do not know how to
handle all that power.
Creating a bug in ordinary languages will create a lot of work for the
department in the future.
Creating a bug in funny characters can create a lot of work for the
computer and embarrasment to management.
Going from one computer where everything is working fine with all the
correct code pages and fonts to another where only ASCII is working
can be frustrating at best.
Even today we are seeing experts having problems in browsers and lack
of Unicode support.
How many more years we have to wait for Unicode stop being a problem
is hard to say.
romilly
I find that J, like XML, is not pleasing to my eye. I've had to use a
lot of XML and it still hurts my eyeballs, but perhaps J will become
more comfortable with practice.
I found APL to be aesthetically appealing even before I knew what any
of its symbols meant. That may not be a universal experience but it's
not unique to me. Several non-APLer colleagues have remarked
spontaneously how beautiful APL code looks. For me J has its own inner
beauty but it is of a different kind.
Until yesterday I shared Morten's unease about trains. I did not
understand them, and they represented a brick wall against which I
repeatedly hurt myself in successive attempts to get to grips with J.
For some reason something clicked yesterday and I can no longer see
what my problem was. Of course, I will need a few years to get
proficient in the application of trains, but that's fine.
Bjorn
If you try to learn J phrases and one liners then . and : can of
course be a bit difficult to read for new beginners.
Beginners are well adviced to begin a more slow adaptation and write
verbs that have more spaces, lines and comments in them.
Individual styles vary of course so it can vary what people find
beautyful.
As time goes by many people tend to try to put more and more stuff on
each line and find beauty in that as well.
Things like @ and & tend to allow people to pack a lot of operations
together.
Not to mention " and [ s well as some other characters.
Whatever people prefer then there is only one engine (JE) but there
are severall user interfaces (JUI).
There is the console (CUI) which is like a text window in Unix or Dos
prompt.
Then there is the old development window (OUI) as two new front ends.
New user interface (NUI) and then the browser front end (BUI).
Besides these you have the option of using the editor of choice and
create and maintain scripts as you like.
It is really the scripts that are important and you can arrange your
verbs any way you want and make your code look nice, easily readable
and easy to maintain.
There are a lot of very good demos, labs and utilities you can borrow
code from and most of it looks very nice.
So J has come a long way and has many faces:
JUI NB. J User Interface
BUI NB. j Browser User Interface
NUI NB. j New User Interface
OUI NB. j Old User Interface
CUI NB. j Console User Interface
Morten Kromberg
> How many more years we have to wait for Unicode stop being a problem
> is hard to say.
There are still a few glitches, but things have improved very
significantly in the last couple of years. Recent versions of Windows
and Linux (the systems that I have hands-on experience with) now
display APL characters correctly (if not "beautifully") using fonts
which are part of the standard installation.
I find that I am now able use APL with "other editors" than the APL
session. I can type APL into Visual Studio, Office products, and I can
not only store but also "diff and merge" APL code using open-source
tools like SubVersion. There have not been any complaints on
forums.dyalog.com recently about readability of the code; even Google
Groups seems to be getting it right more and more of the time.
Typing special symbols is still a bit of a challenge for us to get
right, but the operating systems (and the browsers) are slowly coming
into line and this is a problem that I expect to have solved soon.
Fortunateley, this is a problem that we share with everyone else in
the world who doesn't use a language which is entirely based on US
ASCII. We can use the same tools to develop keyboards that Microsoft
provides for Chinese. We (the vendors) have a bit of a learning curve
but I think we (Dyalog) will get it right in the next iteration (our
current "Windows IME" has a couple of rough edges).
Certainly, I no longer see the TECHNICAL issues as a challenge.
Whether there is a good MARKETING argument for abandoning (or finding
alternatives to) the symbols is a different question. But in that
case, we'd have to go for "CountTo" or "IndexGen" rather than "i." in
order to make a significant impact, I think.
Morten Kromberg
> "my language is better than yours" (which I seldom do, even against
> languages not in the APL family).
> Rather, it was to demonstrate that J is not as unreadable as you made
> it sound. I consider that I have achieved my modest objective.
Yes, I think you have - and I feel that I should apologize for the way
I expressed my own problems with reading J. While I don’t necessarily
LIKE them all, I believe that the choices made in the design of J were
sound, and have been successful in attracting a large body of new
users to J.
> I am surprised that you felt it necessary to define Wh←{⍵/⍳⍴⍵} as a
> subfunction
This was in an attempt to make the J and APL versions of the code more
directly comparable, so it was not skewed the fact that “I.” was
implemented as a primitive in J but not in APL. I was thinking of
calling it “Id”, but without thinking very carefully I decided on “Wh”
instead. Of course, it is a very fair argument that having the
primitive makes the J version “more readable”. We regularly think
about adding I. to APL, at the moment the fact that we recognize the
dfn idiom acts as a bit of an impediment (there would be no immediate
performance gain).
> When J got started in 1989, universal support was the goal, and there
> were no other viable candidates.
> Today, the arguments on the other side would be stronger, but probably
> still not strong enough.
At the time, there clearly were no other viable candidates. As you
point out, support for Unicode still leaves a little to be desired and
does require work. On the other hand, for commercial systems, you now
need the Unicode support for the application data – whether or not you
use it for your code. Source code for all programming languages is
generally stored as UTF-8 or UTF-16 files, so we have to do the work
to support that anyway. The only real “additional” work to support
coding using APL is to provide keyboarding.
> j. is the computation {⍺←0 ⋄ ⍺+0j1×⍵}.
> I spent about 10 minutes trying to find a Unicode symbol for it that
>is as least as good as j., without success.
This is true. (though... what about http://en.wikipedia.org/wiki/File:U%2B2149.svg
– or 2148)?
This is perhaps a slightly unfair example, as we’re looking for a
function which "takes the place of the J" in the notation for complex
numbers… And as an APL vendor, I would probably say that I really
don’t think I need “j.” as a primitive function. That doesn’t mean you
don’t need it in J, which has a “more mathematical focus” (another
vague statement, I know – and one which may not continue to be true in
the future).
> When you see "man", do you see m a n, then go through some sort of
> manipulation that you are conscious of, before you think "biped male"
> (or other similar meaning)?
Despite everything I said so far, I DO hope to reach this level of
fluency with J someday!
> Another experiment: in your "queens" function, there are the keywords
> :For :In :End. (Ha! colons! :-) I doubt that the colons give you
> much trouble, because by now with training and usage you have learnt
> not to focus on them.
This is interesting: On the contrary, I would say that in this
particular case the colons HELP me to focus on them. Words written
using latin letters preceded by a colon stand out like sore thumbs in
modern APL code, especially since the generally occur as the first
word of a line.
Many APLers object to these “alien” tokens and propose ways to express
control structures and other declarations using primitive-like
symbols, but my personal option is that this would be a mistake and
make the code LESS readable (if-then-else is a possible exception,
where a “functional form” feels like it would be good to have - Phil
Last and others have experimented with d-ops to achieve that kind of
effect).
I see control structures and object-oriented incantations like
“:Access Public Instance” as an organizational layer, which organizes
the of execution of “real APL statements” but isn’t actually part of
THAT language. Having very visually distinct “words preceded by
colons” actually helps me maintain this separation.
> If I put in your function
> as is, with :End instead of :EndFor, and exit the editor, it lets me
> exit but silently fails to define the function.)
I can’t reproduce this in any of the versions on my laptop, can you
give me a “build id” (I think we would have had rather a lot of
complaints if this had gone out in a production release, but you never
know).
> Such a utility in Dyalog APL would be non-trivial to write, I believe.
> (e.g. to handle f⍣a b it has to know the nameclasses of a and b, I
> believe.)
Indeed… Parsing APL2 dialects, and Dyalog APL in particular with the
object-oriented extensions, is very hard work. “a.b” could be an inner
product or a reference to the property b of the object a. a could
also be a niladic function which returns an object. In
DateTime.Now.Year, DateTime is a Microsoft.Net namespace, Now is a
function (shared method of the DateTime class, to be precise) which
returns an instance of a DateTime object, and Year is a reference to a
property of that object. A nightmare to parse and execute, but
extraordinarily useful! Hideous from a language point of view, but I
think I would go as far as to classify this as THE most important
feature of Dyalog APL, in terms of securing the long term commercial
viability of the language. When we show this to senior managers in
large corporations, you can see them relax and decide that the rumours
they heard about APL being a closed language we unfounded, and that
using APL does not expose them to the risks that they had heard that
it would. Apart from the difficulty of implementation, I don’t think
it has any really negative consequences IN PRACTICE.
This is the kind of “muddy but useful” feature that I was referring to
when I talked about APL2 as “easygoing”. Strand notation is the really
big "hideous but useful" feature, of course. I’ll try to return to
that discussion soon.
> q has multi-character names
> for primitives (e.g. reverse, raze, group). Some commentators even
> attribute this as one of the key factors in the commercial success of
> q.
I have also heard this, and I think it is likely that it is true.
However, I BELIEVE that the "commercially successful" use of q is
mostly as a high performance SQL dialect (q for query?), rather than
as a general-purpose array language. It is quite common for J and APL
applications to provide an “embedded domain specific notation” like
this that built for specific applications. In Dyalog APL, anyone can
set to work:
plus←+ ⋄ times←× ⋄ etc
… and in APL# we will extend this to operators (power←⍣). This will
allow anyone to experiment with giving “meaningful” names to all parts
of APL, and see if that makes it easier to sell…
Morten Kromberg
> The other objection you cited, "the really big difference",
> is "verb trains" and "tacit forms". From your exposition I
> believe you worry more about tacit forms than hooks/forks.
I expressed my self very poorly in that message, I was not trying to
make another objection at that point, I was trying to point out that
in my opinion, “the emphasis on tacit forms” was the second
significant change when comparing J with APL, with the “emphasis on
rank and the leading dimension” being the first.
I like both of these ideas – and I am also aware that Dyalog APL
already has a number of tacit forms, but I believe it is fair to say
that hooks and forks (plus at, under & friends) “change the emphasis”.
Where tacit forms are a bit of a curiosity in Dyalog APL, they are
almost the bread-and-butter of J.
I know I am being a bit old-fashioned when I worry about them, and
when I say that I feel there is a risk that they will make the
language “harder to read for the simple user”. It’s the same
(pathetic) argument that some C programmers use when they state that
APL is already “hard to read” because there is so much going on in a
single line. Tacit forms add more expressive power to the language and
allow even shorter, “more direct” statements of a problem.
I have similar reservations about dfns in Dyalog APL, although they
have less intense power than hooks and forks: While I am very
comfortable with the use of dfns to express idioms like {⍵/⍳⍴⍵}, when
I put my “application programmer” hat on, I worry about large, multi-
line dfns (and d-ops). For myself, I feel that the readability
benefits of both dfn and tacit notations fade as the size of the unit
grows, and suddenly they reach a point where I can’t deal with the
sheer quantity of abstraction that has been bound together to form a
single unit - and my ability to comprehend the code shatters like a
broken mirror. At some point I feel I need to break down and “go
procedural” - do things one step at a time, and verify my
comprehension - not just during the process of construction, but also
when I return to modify the code a year later.
One of the problems we have with dfns in Dyalog APL is that, because
they started life as a bit of an experiment, they were not given the
same attention in terms of making them easy to trace and debug, as
“tradfns”. Now that they are entering the “main stream” of APL
application development, we are getting complaints about this and need
to make an investment to enhance our debugger, to make dfns first-
class citizens of the debug-able universe. I worry about how to debug
“large” tacit constructs… I don’t know if you will always have to
“grok” the whole thing, or whether it is possible to devise a debugger
which can "trace" its way through a tacit definition? Tricky if the
interpreter is allowed to optimize tacit idioms... Of course, having
hooks and forks doesn’t force programmers to build “monster tacits”, I
know.
I’m not saying we don’t want to do hooks and forks in APL. On the
contrary, we’re trying to make sure that we do not do anything which
makes it impossible to add them when we become comfortable that we can
do it safely (and do not have problems that we think are more urgent).
However, we do worry about the practical and marketing consequences of
making a compact language even more compact – even though I am a big
fan of Arthur Whitney’s “the only program that stands a chance of
being correct is a short one” philosophy.
> (Perhaps I worry too much on your behalf. In order to implement
> "under" and friends you first have to find symbols for them.
> I guess that's enough of a deterrent right there! ;-)
I hope it is correct (that you worry too much)… I don’t think picking
symbols is a big problem, actually :-). There’s LOTS of cool glyphs to
pick from (and some were already picked for us in SHARP APL).
Roger Hui
z←queens n;b;i;t
z←⍪⍳n
:For i :In 1↓z
t←(i-⍳i)∘.ׯ1 0 1
b←~↑{(⍳n)∊⍵+[0]t}¨↓z
z←((+/b)⌿z),n|Wh,b
:End
Roger:
> (BTW, just now I tried to define your "queens" function and
> discovered something "not nice". If I put in your function
> as is, with :End instead of :EndFor, and exit the editor, it lets me
> exit but silently fails to define the function.)
Morten:
> I can’t reproduce this in any of the versions on my laptop, can you
> give me a “build id” (I think we would have had rather a lot of
> complaints if this had gone out in a production release, but you never
> know).
I reproduced the "not nice" behaviour earlier this afternoon
after considerable trouble. I then generated the latest build
(my earlier one was only 2 weeks or so outdated) as the first
step to documenting the failure sequence, and now I can not
reproduce the problem. You have probably heard this before?
I have just now examined the session log and, although it is
not conclusive re the sequence of steps that led to the
failure I described (after all, it does not capture the
paste into the editor and my hitting Esc), does demonstrate
to my own satisfaction that I was not hallucinating.
If I can reproduce the bad behaviour I will report it to
you offline.
Richard Nabavi
particular, he is absolutely right when he says 'human eyes are
trained to interpret these symbols as punctuation or separators, which
means the basic instinct is not to try to form "words" which include
going back hundreds of years, of how punctuation marks are 'parsed' by
human readers as they attempt to scan a line of J.
Sure, it is possible to un-learn these. But that is a massive hurdle,
and most people simply won't bother. At least with APL symbols, they
only have to learn something new, not unlearn the pattern-recognition
rules they've already absorbed.
Essentially, J tries to stuff too much semantic meaning into the ASCII
character set. Of course one understands the motivation for
attempting this. All language design is a compromise, but in this
case there seems to have been an absolute refusal to use keywords,
which has led to the particular design decisions in J, the
disadvantages of which Morten describes so clearly. In my opinion,
the trade-off was not a good one; keywords are bad, but sequences of
dots and colons are worse.
It's ironic that J was created just at the point when the shackles of
ASCII were beginning - at last - to be loosened.
Phil Last
wrote:
I'm not at all sure that my personal difficulty with reading J is
described above. "too much ... meaning into ... ASCII" could well
describe "+/", "-/", "<.>" &c..
Morten and Richard complain that it's difficult to prevent the eye
from seeing dots and colons as punctuation. APLers are used to the
fact that dots and colons, question and exclamation marks are _not_ to
be read as punctuation. In J they (".:") are _much_ more like
punctuation than in APL. They act as qualifiers to the character
before them. Beyond those the only puctuation J has is "()" while APL
exceeds this in "[;]" (and "{}" in Dyalog). All the other stuff is
primitive functions and operators.
My difficulty is in convincing eye & brain that "+." and "+:" are not
of the same order as "+/" "+\". Were I to design a concise notation
for an APL dialect using ASCII, which I imagine will continue to be
the standard alphabet for all other programming languages for the
forseeable future, I should eschew digraphs altogether; take a cue
from the last three horizontal blocks of http://www.jsoftware.com/help/dictionary/vocabul.htm;
and use all 26 upper and lower case alphas each with a single non-
alphanumeric subscript. Choosing the three or four candidates
necessary to give a vocabulary of 150-200 primitive "words" would be a
matter of deciding which characters were best _not_ used as primitives
in their own right. The "." would not be used as is has enough meaning
as both decimal point and name element in most languages.
Tokenising such a notation would present no ambiguities and the only
necessary white space would be after identifiers before other
identifiers, numbers or subscripted alphas.