From: Libor S. <li...@gm...> - 2008-08-14 22:23:27
|
On Thu, 14 Aug 2008 21:59:01 +0100, Albert Graef <Dr....@t-...> wrote: > Hi all, > > Now that Pure 0.5 is almost done, I've come to consider some (non > backward-compatible) syntax changes that I'd like to do, rather now than > later: > > - First and foremost, I want to see whether I can massage the grammar so > that it becomes possible to write lists of tuples using the special case > syntax [(1,2),(3,4),...]. That's not straightforward because it > introduces ambiguities that I'll have to eliminate somehow, but I think > it's worth the effort, because it sucks having to write > (1,2):(3,4):...:[] all the time. > I agree! I remember finding it quite confusing compared to prolog's lists, where you can easily use the [(1,2),(3,4),...] form. What is more, you can also use the comma as a simple sequencing operator (cf. below), though it does have somewhat different semantics there, of course. I am not entirely convinced that the tuples are even worth having at all. For the minimal (flatness) distinction, they ship in a lot of confusion. Imho it is seldom a good idea having two conflicting mechanisms for doing two almost identical things. > - I'd also like to revise the syntax of 'using' so that the module names > are separated by commas, which is more in line with the 'extern' > declaration syntax which also uses the comma delimiter. (I'd still like > to keep the syntax of operator and 'nullary' declarations, though, > because there whitespace as a delimiter is much easier to read when > listing non-alphanumeric symbols, IMHO.) That sounds OK to me. > > - The discussion I had with Libor about how to implement a sequencing > operator ("first x, then y") also kept me thinking, because the solution > I proposed there is not tail-recursive. To do this in a proper way, we'd > need a built-in sequencing operator (special form). While it's not > strictly needed, it's much more convenient than having to write 'y when > _ = x end' all the time. Good, thanks! > > That sequencing operator should be easy to implement, but how should it > be named? We can't use Q's '||' because that's logical or in Pure, and > we can't use C's ',' because that's Pure's tupling operator. Another > obvious choice would be the Haskell'ish monadic sequencing operator '>>' > but that's currently used for bit shifts (maybe I could rename '<<'/'>>' > to shl/shr, though). Any other ideas? I must say << and >> are so well known that, at least in my mind, they are synonymous with the bit shifts. Given the strong links to C via LLVM, I think that syntactic similarity with C would be good to maintain as much as possible. On the other hand, if Pure is one day to compete with, or even to overtake Haskell, the need to be syntactically compatible with it is less pressing. Have you considered naming the sequencing operator instead? Something like seq or fb (followed by) might do? It seem that the special characters are a valuable 'real estate' in short supply. Especially in view of the fact that the user will want them too for defining operators! It may be worth adopting some convention to distinguish user defined operators (such as all starting with a designated character)? Echoes of APL here.... > > Finally (this is not a syntax change, but it also breaks backward > compatibility), I'd like to revise the script search. Currently the > interpreter always searches the current directory and then the PURELIB > directory. In the case that the interpreter is run with a main script > (pure -x main.pure), I think it makes sense to search the directory of > the main script instead of the cwd (for scripts loaded with a 'using' > clause). That would make it possible to install the main script along > with any other non-library modules it needs into its own directory and > run it from there. This would be useful, in particular, for "shebang" > scripts. No objections to this, sounds good. Regards, Libor |