Alef questions

Alef questions

[Jeremy]

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 <hebrew squiggle I can't generate
under Unix>?

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

Alef questions

[bobf]

> How different is the plan 9 compiler from the Unix one.  Is it for V10 
> only?  Is it available?

it is almost identical.  it only works on sgi machines running irix 5.2
or higher.  we cross-compile it from the plan 9 source to create
an irix executable and its libraries.  at the moment, it is specialized
for the sgi unix machines in our center.

we currently have no plans to make it available.

Alef questions

[Christopher.Vance]

Christopher.Vance@adfa.oz.au wrote:
|  How different is the plan 9 compiler from the Unix one.  Is it for V10 
|  only?  Is it available?

I meant I've got the plan 9 alef compilers on the July CD-ROM, can I get 
one for Unix too?

-- Christopher

Alef questions

[Hans-Peter]

Take a look in http://plan9.att.com/plan9/vol2.html.
	...
 	Alef User's Guide
	Bob Flandrena
	A tutorial introduction to the concurrent programming language Alef.
	...
-hp

Alef questions

[Christopher.Vance]

philw@plan9.att.com wrote (in the darkest depths of early August):
|  ALEF is the name because we run <hebrew squiggle I can't generate under Unix>
|  on unix systems as well as plan 9.

How different is the plan 9 compiler from the Unix one.  Is it for V10 
only?  Is it available?

-- Christopher

Alef questions

[philw]

>If it's not a bug, it's very surprising.  Even if you throw away
>a value, you expect the side-effects to happen.  I was kind of
You might, I don't. I think the comma operator was a mistake
in C, making it possible to duplicate its effect in ALEF was not
appealing. You are not the first person to suggest this.

Alef questions

[Jeremy]

philw@plan9.att.com:
> 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.

If it's not a bug, it's very surprising.  Even if you throw away
a value, you expect the side-effects to happen.  I was kind of
expecting it to work, since it would effectively recover the comma
operator: you get the general form where you can use or throw away
any of the expressions.

	J

Alef questions

[philw]

>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