Alef questions

[philw@plan9.att.com philw@plan9.att.com]

>Is the name 'A' 'L' 'E' 'F' or <hebrew squiggle I can't generate
>under Unix>?

ALEF is the name because we run <hebrew squiggle I can't generate under Unix>
on unix systems as well as plan 9.

>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?

comma is gone because it cant live with tuples.

It might be considered a bug - I did know about it. Tuples are
evaluated by generating the address of the lval and then evaluating
each member directly into the destination. If there is no lval the
expression is thrown away.

>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?

If you cut random lines of program and paste them around the chances
are your program will not work. I've heard this argument lots and just
don't buy it.

I find that I often want to break from combination for/switch:

		for(;;) {
			c = getc();
			switch(c) {
			case EOF:
				break 2;

This is worth having. You might argue I could have chosen a differnt
keyword, a break from loops and a break from switch. break n seemed simpler.

>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.

Channels are just data structures (In fact just fancy rendezvous) it
was generated from a malloc and needs to be unalloc'd just once. If you
try and free a channel DURING a communication the process performing
the free will block until the communication is complete. This is
implementation detail in the runtime and not defined by the language -
maybe it should be.

Channels and process are not really connected as resources. The channel
is just a data structure processes might use. The process who created is
no more connected to it than any other.

>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:

You need to build a multiplexor using co-routines.

>[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? ]

Yes, this release of the compiler has lots of dynamic typing.

>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?
no subtle reason. I find code written that way hard to read. I
am so anal I sort the lengths of all automatics into a ski run,
go figure.

>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.

They are supposed to be minimum sizes.

>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)?

Thats a mistake in the manual. the float pre/post inc seemed of limited use.

>Also, the syntax for block statements in 7.3 doesn't allow blocks
>without declarations... (the yacc grammar does however).

Another mistake.

philw