limbo

limbo

[Shon]

Roger Peppe wrote:
>after browsing the limbo documents, i've got a few questions.
>i hope nobody objects to these being raised on the 9fans list.

Good question.  *Should* Limbo questions be posted here?

Shon Frazier

limbo

[^*_*^]

philw@plan9.BEll-labs.COM wrote:
>
> >when will we have the Limbo compiler and the inferno envir. for x86 and
> >solaris available (for eval)?
> 8/1
hav'nt seen anything yet! (in the page which says Download Inferno)
--
_______________________________________________________________________________
;-Balaji Srinivasa - Platinum Technology/Aston-Brooke Lab - balaji@platinum.com

limbo

[^*_*^]

philw@plan9.BEll-labs.COM wrote:
>
> >when will we have the Limbo compiler and the inferno envir. for x86 and
> >solaris available (for eval)?
> 8/1
hav'nt seen anything yet! (in the page which says Download Inferno)
--
_______________________________________________________________________________
;-Balaji Srinivasa - Platinum Technology/Aston-Brooke Lab - balaji@platinum.com

limbo

[Alexandre]

howard@plan9.BEll-labs.COM (Howard Trickey) writes:

>> would it be possible to implement a qsort replacement in limbo ?
>
>It is possible, but the answer is so ugly that the real answer is "no".
>
>(The caller could pass in a channel, and then be willing to answer
>questions like "is element 5 greater than element 3" over the channel;
>the answer could be an array of element indices in their sort order.  Channels
>of ascii can be a universal way around type checking.)
>
>So, for instance, there is a module for sorting directory entries (in various
>ways), but no general purpose sorting module.

  This answer seems rather strange to me, I think that Limbo already has
sufficient features for implementing general sorting module.
  General sorting module (let's call it Sort) needs two external functions:
one to compare elements of array (taking two integer indices and producing
integer -1/0/+1 result) and another - to exchange them (again, taking their
integer indices).
  Indeed, the question is how to give Sort access to user-supplied Compare
and Exchange functions. It can be done as follows: the user must supply
*implementation* of module which has a fixed name, say, Sort_User and the
fixed declaration:

  Sort_User module {
    Sort_Compare:  fn (first_index: int, second_index: int) : int;
    Sort_Exchange: fn (first_index: int, second_index: int);
    };

  I see no obstacles for user-supplied implementation of Sort_User module
to access an array to be sorted.
  Then, one of the arguments for the actual sorting functions of the Sort
module must be *path* from which these functions should *load* proper
Sort_User implementation. So, Sort module can call user-supplied Sort_Compare
and Sort_Exchange functions because:

1) the name of Sort_User module is fixed
2) the path to Sort_User module is known to the Sort when it is called
3) the declaration of Sort_User module is fixed and contains declarations of
   functions Sort_Compare and Sort_Exchange.


Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

limbo

[philw]

>when will we have the Limbo compiler and the inferno envir. for x86 and
>solaris available (for eval)?
8/1

limbo

[Balaji]

philw@plan9.BEll-labs.COM wrote:
> 
> I think the volume in the list is small enough
> that people would prefer to look in one place
> for related information - ask away.
when will we have the Limbo compiler and the inferno envir. for x86 and
solaris available (for eval)?
-- 
_______________________________________________________________________________
;-Balaji Srinivasa - Platinum Technology/Aston-Brooke Lab - balaji@platinum.com

limbo

[Howard]

> would it be possible to implement a qsort replacement in limbo ?

It is possible, but the answer is so ugly that the real answer is "no".

(The caller could pass in a channel, and then be willing to answer
questions like "is element 5 greater than element 3" over the channel;
the answer could be an array of element indices in their sort order.  Channels
of ascii can be a universal way around type checking.)

So, for instance, there is a module for sorting directory entries (in various
ways), but no general purpose sorting module.

Actually, the thing that bugs me more is the need to write what should
be generic list functions (e.g., rev, nth) for each element type.

Limbo currently doesn't have polymorphism or (discriminated) union types
because of the tradeoff decision about usefulness vs implementation cost
(the garbage collector would need more in the presence of the above).
But the language isn't embalmed by a standards committee yet...

Howard Trickey (Limbo programmer and language design kibitzer)

limbo

[Roger]

> I think the volume in the list is small enough
> that people would prefer to look in one place
> for related information - ask away.

i did...

would it be possible to implement a qsort replacement in limbo ?

limbo

[Rogers]

>>after browsing the limbo documents, i've got a few questions.
>>i hope nobody objects to these being raised on the 9fans list.

>Good question.  *Should* Limbo questions be posted here?

If I could take a moment to be self-promotional here, there is an Inferno
mailing list at majordomo@interstice.com. The full details are at
http://cruel.com/vanni. That might be a better place for it.

Rogers Cadenhead

limbo

[philw]

I think the volume in the list is small enough
that people would prefer to look in one place
for related information - ask away.

limbo

[Roger]

after browsing the limbo documents, i've got a few questions.
i hope nobody objects to these being raised on the 9fans list.

is there a security reason why limbo doesn't support any sort of
polymorphism at all, even unions ?

it seems slightly surprising, as Alef seemed to provide quite a
nice form of polymorphism which looked as if it might adapt quite
well to a language such as limbo; it could also provide a nice
mechanism for dealing with variable argument lists.

also, what's the reason for '.' binding tighter than '->' ?
m->(Module->Type).function() seems rather contrived; the second
reference to the Module type is surely unnecessary because Type
has always got to be declared at the top level within m, so
m->Type.function() is unambiguous (and seems more intuitive, to me
at least)

flames to me only, not to the list, please.

  cheers,
    rog.