[CCC DEV] Concerning commit 6894(ish)

[Michael Pirrone-Brusse]

Hey Adam,
    Thanks for the info. I was unaware FUNCTIONs were supposed to be actual
mathematical functions. That's pretty neat.

    Means that, in getting wiring.module keen in occam, there are going to
be a lot of breaks from their API which... Yeah. Not a bad thing. It does
raise for me, again, the question of whether it's worth maintaining a
C(ish)-like alternative to the plumbing library. But that's a discussion
that can be had at a later date.

    Best,
        -Drew


On Tue, Jul 20, 2010 at 6:10 AM, Adam Sampson <ats at offog.org> wrote:

> Michael Pirrone-Brusse <pirronm at allegheny.edu> writes:
>
> > It would be a break from the wiring API to not do that in
> > wiring.module, but I'm starting to think keeping to the wiring API
> > isn't so much worth it.
>
> Yes -- you'll have to change stuff in the Wiring API that isn't doable
> in occam. Global variables and functions that aren't functions will be
> the two big changes. (It's also worth noting that Wiring is not exactly
> a shining example of good C++ API design!)
>
> The reason global variables aren't permitted is that, in the original
> implementation of occam on the Transputer, a program might be running
> across several physical processors that don't share memory -- so there's
> nowhere to put changeable global variables, even if the compiler could
> prove you were using them safely.  You can get the same effect by
> passing the variable explicitly by reference to the PROCs that need it:
>
>  PROC set.verbosity (VAL INT level, INT verbosity.level)
>    verbosity.level := mangle (level)
>  :
>
>  PROC show.message (VAL []BYTE message, INT verbosity.level)
>    ...
>  :
>
> VAL INT is passed by value, so you can't change it; just INT is passed
> by reference, so you can.
>
> (It's worth noting that if you just need a global-ish variable for a
> program you're writing, rather than for things you're exposing from a
> library, you can use nested PROCs to give you an explicit scope for the
> variable:
>
>  PROC my.program ()
>    INT counter:
>
>    PROC do.something ()
>      SEQ
>        ...
>        counter := counter + 1
>    :
>
>    ...  other PROCs
>
>    SEQ
>      counter := 0
>      do.something ()
>      ...
>  :
> )
>
> In occam, a FUNCTION should be a function in the mathematical sense --
> when called with the same parameters it must always return the same
> value. It's quite legitimate for an occam compiler to optimise:
>
>  x := read.port (42)
>  y := read.port (42)
>
> into:
>
>  x := read.port (42)
>  y := x
>
> when read.port is a function. The current compiler will go some way
> towards trying to ensure that this is the case, but it's not very smart
> about use of FFI calls or PORTs.
>
> This means that most C "functions" that return a value should be
> translated into PROCs with a RESULT parameter:
>
>  PROC read.port (VAL INT port, RESULT BYTE value)
>    ...
>  :
>
>  read.port (42, x)
>
> You can see other examples of this in the POSIX bindings in file.module,
> and anything generated by SWIG (e.g. occSDL.module).
>
> --
> Adam Sampson <ats at offog.org>                         <http://offog.org/>
>
> _______________________________________________
> developers mailing list
> developers at concurrency.cc
> http://unhosting.org/mailman/listinfo/developers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.concurrency.cc/pipermail/developers/attachments/20100720/110f3e23/attachment.htm>