[erlang-questions] Ideas for a new Erlang]

[Darren New]

Sven-Olof Nystr|m wrote:
> If you want to keep track of outstanding requests, you can do it
> without selective receive.

True. For that matter, you never need selective receive. You can always
receive everything, and write your own selection code, which is
basically how selective receive is implemented in the C implementation
of Erlang. I mean, heck, you don't need Erlang to do *any* of the tasks
it does conveniently. The trick to arguing for a change is to find
situations where the change will actually make things unambiguously
better, often by comparing "the usual way" with "the new way" directly.

BTW, the selective receive isn't what's keeping track of the outstanding
requests. But since I'm actually trying to communicate rather than
merely prove you wrong, I'll instead read what you had intended to
communicate. See?

>  > All that would be the same code, with the same constraints needing to be 
>  > solved.
> 
> I don't think so. In Erlang, there are better ways to solve the
> problem you're sketching.

No doubt better in some ways, yes.

>  > That Erlang has dynamically-sized message buffers doesn't mean that a 
>  > bounded buffer example is nonsensical. It just means you use it for 
>  > something other than what Ada et al use it for.
> 
> As I said, show us.

NMJ. Unless you want to supply the hardware.

If you can't envision how the situations I described (imprecisely) could
match the (incomplete) code snippet, and you need a full-fledged Erlang
program including hardware drivers and UI to understand the description,
then you'll have to look elsewhere for that.

-- 
Darren New / San Diego, CA, USA (PST)
  Helpful housekeeping hints:
   Check your feather pillows for holes
    before putting them in the washing machine.