Re: modifying array access syntax



randerson110@xxxxxxxxx wrote:

Let me say a few words about my design thoughts here, and maybe people
can help me see a better direction.
[...]

One issue is always how to access an element in an array of which the
dimensionality is general.  For example, I may have an expression to
average neighboring elements in a computational "i" direction.  Here's
the fortran code for 1d, 2d, 3d:

1D: 0.5*(a(i) +a(i+1))
2D: 0.5*(a(i,j) +a(i+1,j))
3D: 0.5*(a(i,j,k) +a(i+1,j,k))

What I need is a notation which says "shift the i index by one and
default the rest to unshifted" which then expresses all three
possibilities above.  CL's apply seems the way to approach this.

But big expressions with "apply" is really quite far from how you'd
like to express yourself in a notation that is close to the domain
here.  What I had in mind is something that resembles standard notation
for the field in question, which is a subscripted notation.

There is a difference between having your concepts close to the problem domain and having your syntax close to the problem domain. In my opinion, and I can safely assume that most Lispers agree here, the concepts are much more important than the notation.


The "standard" notation has been developed to optimize usage on paper. That's why there are lots of special symbols and lots of subscripts and superscripts because it's much more efficient to write these things down with pencil and paper. On a computer, this doesn't buy you much. The important point here is that the notation is not in any way "natural", it's just optimized towards a specific kind of use, and people have just learned to accomodate themselves to that notation. People are very flexible in that regard, so they also shouldn't have a problem to adapt to different kinds of notations. Recall that for beginners in mathematics, the notations typically used in mathematics are by far not obvious.

So I think the basic tradeoff is as follows: If your interest is to develop the code for your own experiments, it's probably more effective to invest some time into learning the Lisp syntax in order to forget about syntactic issues altogether in the long run. If your job is to provide an input format that is acceptable by some clients of yours, consider either training them, or else writing a separate parser that translates a concrete syntax to Lisp s-expressions, and then continue from there. The Lisp reader macros are good for doing minor tweaks with your syntax, but if you want your syntax to look very different from s-expressions then this is probably not the right tool.

Now you're probably screaming in horror at the infix notation in the
subscript.

No. This idea is brought up regularly by newbies, and apparently this is a "tradition" that goes back to the very beginnings of Lisp. John McCarthy himself has suggested an alternative syntax for Lisp, called M-expressions that is much closer to mathematical notation than to s-expressions. It's also a "tradition" that regular users of Lisp don't care because such alternative syntaxes don't solve a real problem.


There is even a section on this issue in the paper about "The Evolution of Lisp" by Richard Gabriel and Guy Steele. See http://www.dreamsongs.com/Essays.html

Well, tough.  That's how people write these equations on
paper and that's how they should be able to write them in code.  If
this means translating behind the scenes into prefixed lisp, so be it.

This is just scratching the surface, but there's a flavor.

There is an infix package somewhere on the net that you can download and use that probably already provides what you want.



Pascal

--
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++
.



Relevant Pages

  • Re: Why is lisp so weird?
    ... I've gotten a book on lisp, and I must say lisp is the ugliest ... > looking language syntax wise. ... here you have two lists, ... These things are all just lists, but the notation varies. ...
    (comp.lang.lisp)
  • Re: Why is LISP syntax superior?
    ... mathematical notation, when it is really related to the own LISP ... have some kind of prefix-based syntax for handling declarations, ... once you have a language defined entirely by this prefix ...
    (comp.lang.lisp)
  • Re: Why is LISP syntax superior?
    ... Firstly, as others have pointed out, Lisp operators are not all binary. ... Using Cambridge prefix notation, the expressions can use the same ... Mathematicians and scientists work with very long expressions without ...
    (comp.lang.lisp)
  • Re: How Lisps Nested Notation Limits The Languages Utility
    ... These included the COND notation for conditional expressions which leads to an unnecessary depth of parentheses, and the use of the number zero to denote the empty list NIL and the truth value false. ... Besides encouraging pornographic programming, giving a special interpretation to the address 0 has caused difficulties in all subsequent implementations. ... "Another reason for the initial acceptance of awkwardnesses in the internal form of LISP is that we still expected to switch to writing programs as M-expressions. ... The project that I am aware of that is closest to bringing the same level of syntactic flexibility as Lisp with a more "traditional" syntax is the Intentional Programming approach devised by Microsoft, but they don't seem to be getting anywhere (except to outer space, that is. ...
    (comp.lang.lisp)
  • Re: modifying array access syntax
    ... >>> possible performance drawbacks for a moment, Common Lisp appears to ... Only horrendous if you don't appreciate what function this notation ... That is, at some level, the difference between an array and a function is ...
    (comp.lang.lisp)