From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Thu, 3 Aug 1995 04:17:10 -0400 From: Jeremy Fitzhardinge jeremy@sour.sw.oz.au Subject: Alef questions Topicbox-Message-UUID: 1173f122-eac8-11e9-9e20-41e7f4b1d025 Message-ID: <19950803081710.7PI_oX-3UUSojaa81gGjl8Xx-tkjo5YxOWoub6O_JQw@z> Hi philw, all, I've been playing with ALEF lately. I'm finding it very interesting; the new language features look very powerful, and I'm finding more elegant ways of recoding C and C++ code every time I look at the language (using co-routines to replace iterators has been particularly fruitful). I have some questions about the design and/or 8al. I'm using only what came with the PC demo, since I haven't got the real thing yet (BTW, I rang to order it from HB in the US (the locals hadn't heard of it: "Plan 9? That's something to do with the internet, isn't it? Someone else asked about it, but we haven't heard of it officially..." - sigh). The cheery 9AM-in-NY voice told me that I could order Plan 9, but it wouldn't be released until mid August?! Is this right?). Anyway, questions: Is the name 'A' 'L' 'E' 'F' or ? The ',' operator has gone, I suppose because it would be impossible to syntactically disambiguate from tuples. It's not a great loss in general (given that tuples are very useful), but it does make the for() statement less concise. For example, this is pretty common in C: for(i = j = 0; i < 10; i++, j += 4) /* ... */ Is there a new idiom for this kind of thing in ALEF? I've tried to use tuples, for(i = j = 0; i < 10; (i++, j += 4)) /* ... */ but the compiler warns "expression not used" (or something to that effect, I presume about the tuple), and when run the loop never terminates and i and j are always 0. Is this a compiler bug? Numbered break and continue. Why numbered? It seems somewhat delicate (in that it would be easy to introduce cut and paste errors), and inconsistent with goto. My feeling for this is that labelled loops and using labels would be better (goto is goto is goto...). Is the ability to break or continue multiple levels very useful, given that it can be done with goto more clearly? unallocing channels between procs If you have two processes communicating with a channel, and you want to free the channel but keep the procs running, does one end or both have to free it? The old (very old) ALEF ref man suggests that procs may be in separate address spaces, but a light reading of the new ref man says that they are in the same address space. I guess this means that only one proc needs to free it. Similarly, I assume that only one task should free a channel too. alt Is there a way of blocking for input on a set of channels not known at compile time (a library call analogous to poll() or select() I suppose)? Does alt allow for waiting for a channel of a set to become available for sending? Something like: alt { case c1 <-= foo: /* ... */ break; case c2 <-= bar: /* ... */ break; /* etc. */ } It would get around the inherent unreliability of the "can send" operator in many cases... [I haven't looked at alt with varient type channels enough to even formulate a proper question yet; is it some form of dynamic typing? ] initialising and other C differences Why has initialising all but static objects been dropped? I was quite surprised to find it missing, since it's so common in C, and there's no obvious reason for it not to be in ALEF. Is there a subtle reason? (I've also typed "c" "h" "a" "r" almost every time I meant "byte", but that's just me. "byte" is clearly the correct keyword, and will just take getting used to). types The table of basic types on page 4 of the reference gives their sizes in bits. Does this mean that all implementations of ALEF are expected to make the basic types exactly those sizes, or is it just documenting the existing plan9 implementations? In particular it says that channels are 32 bits, and then goes on to say that they're the same size as pointers. It seems likely that the Alpha port, for example, will want 64 bit pointers. On the other hand, having known 8, 16 and 32 bit sizes is very useful... Oh, and the ref says that the ++ and -- postfix operators can only operate on integral typed lvalues, but the prefix versions can take integral or pointer types. I assume this is just a oversight and both forms can take both pointer and integral types. Any particular reason they can't take a float type (not that f += 1.0 is onerous)? Also, the syntax for block statements in 7.3 doesn't allow blocks without declarations... (the yacc grammar does however). Thanks, J