Re: n+k patterns
I like the capability to redefine syntax.
For example, I would like to be able to define syntax that looks like
EBNF when writing parsers. I would like to be able to write
E = T {(`+`|`-`) T}
rather than
e = concat1 (t,zeroOrMore (concat2 (alternative (lit '+',lit '-'),t)))
Of course infix operators help, but what about nice multiple
token symbols like { } ?
So, minimally, I am in favor of the local redefinition of symbols like
'+' and '=', and think it unfortunate that there is a clash between
the redefinition and treatment of n+k patterns.
This is a vote for dumping n+k patterns, and a wish for more flexible
syntax not hampered by special cases.
Ken
No Subject
Subject: Re: Arrays and general functions Reginald Meeson writes Interesting discussion, but it seems to me that Haskell already provides the best of both worlds, namely a. Efficient implementation of arrays as data objects, with indexing as a projection function; and (Actually, efficient seems a little hopeful here). Rats, my Haskell manual is home, so correct me if the following is wrong... Actually, let me pose this as a question (then I don't have to get so embarrassed later!) Let's say I have an array arr and at some index i I want to update it to be x. That is, I want to define upd arr i x to return a new array equal to arr everywhere except i where the value of the result is x. It seems to me that there is no way to write this function without decomposing arr into a list and rebuilding an array. Am I right? (I will be pleased to be wrong!) From the APL/Nial/Array Theory world, it is a travesty to be forced to perform such a decomposition. There are enough optimization problems without mixing lists into it. This, of course, is not to say that it is not convenient or perhaps necessary to be able to convert lists into arrays. It is very convenient for monolithic array operations, such as building tables for lookup functions, etc, but it also seems like there ought to be some kind of support for incremental array operations, like update. Dave Barton writes: I am interested in how the lack of a distinction gets in the way of your reading and understanding programs, however. (where the distinction is between arrays as rules and arrays as general functions). My apologies for not being more sensitive to your application before my first response. I have an interest in the optimization of incremental array operations (see above) and don't tend to think of arrays as fixed tables. The first area that pops into mind where I am more comfortable with having the distinction is graph theory. Now perhaps it has something to do with the way it was taught to me, but I like thinking of the arrays as data objects rather than functions, and it helps me in thinking about what an algorithm is doing and how much the algorithm costs. On the other hand, I am not sure how important this is or how long it would take me to forget or drop my dependence on the distinction. Ken
Re: Arrays and general functions
David Barton writes: And finally, it makes sense to have separate syntax for arrays and general functions, because different behavior is expected for the two. Here, I may be exposing my cluelessness, but this seems a (search for a better word --- none found) silly statement. There are many cases where we want different behavior to be expressed by the same syntax. Well, perhaps behavior is the wrong word. Also, I find your approach interesting. On the other hand, general functions and arrays are typically mixed in a program. If the distinction between the two is limited to type declarations, then from my perspective it becomes difficult to read and understand programs. The difference between functions as rules and arrays to me is much more significant than the difference between adding reals and adding integers. From your perspective, maybe any distinction gets in the way. In practice, I have not had this problem. Ken
Re: Arrays and general function representation
My humble opinion about arrays and general functions... Arrays and general functions are isomorphic, certainly in theory. In practice, however, they are different and the differences are significant. In general, although the set theoretic definition of a function is a set of ordered pairs, it is convenient to think of a function as a rule. That is, given an input, the rule tells how to compute the output. It may be that for some special functions, we want to encode the rule as a lookup on some table, but in fact this technique is not generally applicable. Why store a gazillion values for + when we can implement the rule in hardware? Typically arrays are boxes which contain values. That is, they are multi-dimensional tables in which values can be looked up. In the imperative world, the lookup cost is typically a constant, guaranteeing timing behavior for various algorithms. In the functional world, nobody has figured out how to get all the practical benefits of imperative arrays, for a variety of reasons. Until these benefits are achieved, functional languages will not be practical for most, if not all, scientific programming applications. (apologies to the sisal community in advance -- my own interest is in lazy functional languages like Haskell, where arrays are in greater disorder). It entirely misses the point of why arrays are hard to say that there are no differences between arrays and general functions. In theory, arrays are a snap. You can have them in a variety of interesting forms, but they don't come with the performance guarantees they have in the imperative world, and that is the problem of arrays in a nutshell. And finally, it makes sense to have separate syntax for arrays and general functions, because different behavior is expected for the two. Ken Sailor [EMAIL PROTECTED]
Re: Arrays and general function representation
My humble opinion about arrays and general functions... Arrays and general functions are isomorphic, certainly in theory. In practice, however, they are different and the differences are significant. In general, although the set theoretic definition of a function is a set of ordered pairs, it is convenient to think of a function as a rule. That is, given an input, the rule tells how to compute the output. It may be that for some special functions, we want to encode the rule as a lookup on some table, but in fact this technique is not generally applicable. Why store a gazillion values for + when we can implement the rule in hardware? Typically arrays are boxes which contain values. That is, they are multi-dimensional tables in which values can be looked up. In the imperative world, the lookup cost is typically a constant, guaranteeing timing behavior for various algorithms. In the functional world, nobody has figured out how to get all the practical benefits of imperative arrays, for a variety of reasons. Until these benefits are achieved, functional languages will not be practical for most, if not all, scientific programming applications. (apologies to the sisal community in advance -- my own interest is in lazy functional languages like Haskell, where arrays are in greater disorder). It entirely misses the point of why arrays are hard to say that there are no differences between arrays and general functions. In theory, arrays are a snap. You can have them in a variety of interesting forms, but they don't come with the performance guarantees they have in the imperative world, and that is the problem of arrays in a nutshell. And finally, it makes sense to have separate syntax for arrays and general functions, because different behavior is expected for the two. Ken Sailor [EMAIL PROTECTED]
