On Dec 24, Raul Miller <[EMAIL PROTECTED]> wrote:
> Given that all operators in APL are special syntax, I think what
> you mean here is that later enhancements for defining user-defined
> operators did not support anything like user-defined brackets.
No, I was not thinking of user-defined operators in particular. I guess I don't
know exactly what you mean by "all operators are special syntax", think I need
you to define when syntax is "special", and why "all APL operators" are
included in the list. Would any J operators which are identical to APL ones
qualify too? Sorry if this is obvious to everyone else.
>> 'XL' ⎕WC 'OLEClient' 'Excel.Application'
>> XL.({squad}Workbooks).({squad}Sheets).UsedRange.Value2
>
> I do not know how dyalog presents excel spreadsheets to its users,
> and I do not know what squad means, and I do not >know what your
> dot extensions do.
I apologize, I assumed that most readers would be sufficiently familiar with
COM/OLE and the notations used in other (OO) languages to navigate object
hierarchies - or be able to guess what the above would mean based on knowledge
of Excel itself. Dyalog presents Excel, and all other external classes based on
either COM or .NET (this could be extended to Java and other object models,
given time), in the same way as in most other languages: You "dot" your way
into the object hierarchy. The difference being that a VB, Java or C#
programmer would be forced to select a single item in the collections or arrays
encountered "en route". In VB:
XL.Workbooks[1].Sheets[1].UsedRange[1].Value2
... would extract the data in the top left corner of the first sheet of the
first workbook. The expression can be read (from right to left :-) as "give me
the Value2 of the first element of the UsedRange belonging to the first Sheet
of the first Workbook of the XL object.
The Dyalog user has the advantage that at each level of the hierarchy, we can
write any expression - in most other languages you are limited to the name of a
"member" of the relevant object - sometimes you are allowe to index it as
above. These expressions can return and operate on entire arrays of objects.
Monadic squad is an extension to APL2's dyadic squad (the indexing function,
see http://www.dyalog.com/help/html/index.htm), which selects all elements of
the right argument. For arrays it is thus a no-op, but if the right argument is
a reference to an object which is "enumerable", it extracts all the elements
into an array which can be used by the Dyalog user without looping. In our
expression, Workbooks and Sheets are both collections.
The syntax for creating the top level external object is a bit odd for COM/OLE.
With Microsoft.NET framework objects you can just start dotting your way in,
once you have set ⎕USING, as in:
⎕USING←'System'
DateTime.Now.(Year Month Day)
2007 12 24
> However, that nested array functionality in J is not bound to .
> does not seem to be so much a feature as an implementation detail.
> That said, I can easily extract data from J's nested array structures
> using conjunctions like S: (or L:)
As explained above, the dot is used to navigate object hierarchies, not arrays.
The expression on the XL object returns a nested array of depth 4 (depth 3 if
all the cells contain numbers and Value2 is a simple numeric array).
>> From a an array language point of view, OO is obviously an idea which
>> needs to be used sparingly, otherwise you quickly lose sight of the
>> data for all the objects. But as an paradigm for integration, it works
>> extremely well.
>
>I agree.
>
>But I am begining to think I like Arthur Whitney's idea of an "interpeter'
>better.
I can perhaps guess what Arthur is thinking, but I'm not familiar with this
reference. Trying to read between the lines a bit, what I would like to say is
that a bit of focus on packaging and interfacing can DRAMATICALLY increase the
marketability of a language to a larger audience. APL vendors have not done
enough, and the J community seems even less concerned with whether "commercial
users" can be attracted to the language. With the integration of arrays and
objects, we feel that we can deliver our array language interpreter a lot
closer to the doorstep of some important potential users. The support for
arrays of objects means that you can go a lot further before objects interfere
with your array thinking. Interfaces which force you to extract one leaf object
at a time (using VB syntax) make objects very unattractive to the "array
analyst".
>> (I'm not sure exactly what it is that makes syntax "special" - are
>> hooks and forks also "special syntax"?).
>
>I do not think so. However, J's keywords (if. while. ...) are special syntax,
>in my opinion.
I don't think of DFNS as "special syntax" either, although I do agree that
bracket-axis notation IS, I think perhaps because it has no general description.
I actually tend not to think of control structures (except perhaps the "guards"
in DFNS, see http://www.dyalog.com/help/html/guards.htm) as part of the
language at all. Like the special keywords Dyalog uses to declare the
attributes of objects, I think of them as a "wrapper layer" which "organizes"
or "provides access to" the J or APL language statements.
> 3 : does take some getting used to, but I think 3 : offers greater
> flexibility. Also, 3 : does not require special syntax (though it
> does support special syntax, in the form of control keywords within its body).
As I said, I don't think of DFNS as 'special syntax'. And however we decide to
define the term, I think we need to be careful about how scared we are of it,
if a bit of extra syntax improves power and readability. To use 3:, you need to
double up your quotes. You may be comforted by the fact that you are not
technically using 'special syntax', but readability quickly suffers.
Also, I don't see how 3: can be "more flexible than DFNS". I can use execute to
turn a string into a DFN, which surely gives me the same functionality as 3: ?
And, as mentioned above: The guards used for flow control in DFNS have (in my
opinion) a much more "functional" feel to them than control keywords (in either
J or APL). So I maintain the view that DFNS are sufficiently more usable than
3: to place them somewhere in-between explicit and tacit definitions in J, in
terms of power or tools of thought delivered to the people.
> For example, 3 : makes integration of automated code generation rather
> simple, should you have a use for such a thing (macro pre-processors, maybe).
Indeed I do, an indispensible tool!
> That said, I am happy with J's algorithmic punch.
I should hope so, you'd have to be as ungrateful as Scrooge to want more :-)
And on that note, I wish those of you who celebrate Christmas a joyful and
peaceful one in the company of family and/or good friends. To those who don't:
If you are on the northern hemisphere, enjoy the knowledge that the days have
now been growing longer since the day before yesterday. And if you are in the
south, I hope you are able to enjoy the sun :-)
Morten
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
