Loading ...
Sorry, an error occurred while loading the content.

Re: Functional Language with Processes

Expand Messages
  • Jack Waugh
    Curses! I thought that space was public just because the server said so! Why didn t I test it? OK, for now, let s try
    Message 1 of 5 , Feb 1, 2004
    • 0 Attachment
      Curses! I thought that space was public just because the server
      said so! Why didn't I test it?

      OK, for now, let's try
      http://membres.lycos.fr/jackwaugh/prog_lang/1.html

      I have to pick a better web space to publish in.
    • Jack Waugh
      I think the original URL is OK now.
      Message 2 of 5 , Feb 1, 2004
      • 0 Attachment
        I think the original URL is OK now.
      • Steven Shaw
        ... What is the rationale for having copyable and non-copyable data types?
        Message 3 of 5 , Feb 8, 2004
        • 0 Attachment
          On Sun, 1 Feb 2004 06:31 am, Jack Waugh wrote:
          > How would you like a language characterized by the operations I
          > describe in
          > http://www.smartgroups.com/vault/waugh/mylang/1.html
          > ? If you can't understand my (quite abbreviated) presentation,
          > please pose questions for clarification.

          What is the rationale for having copyable and non-copyable data types?
        • Jack Waugh
          ... types? One can t so much as calculate factorial without copying a number. The question becomes, then, what is the rationale for having non- copyable data
          Message 4 of 5 , Feb 10, 2004
          • 0 Attachment
            > What is the rationale for having copyable and non-copyable data
            types?

            One can't so much as calculate factorial without copying a number.
            The question becomes, then, what is the rationale for having non-
            copyable data types.

            You definitely cannot copy an oracle. The thing I call an "oracle"
            is really (or contains, among other things) an infinite tree of what
            I'll call "primitive oracles". Primitive oracles are what other
            writers call oracles (e. g., in the Fudgets paper). Each primitive
            oracle "knows" the outcome of one race. The primitive oracle is
            going to be used where that race ends, so you have referential
            transparency. If you had a "function" that returned, say, a list of
            its two arguments, and their order in the list were supposed to be
            the order the arguments were available, the "function" wouldn't be a
            true function because its results don't depend wholly on the
            arguments. But if the function also took a primitive oracle,
            referential transparency would be restored because we can pretend
            that the primitive oracle knows which of the other inputs will be
            available first. If you copied the oracle and used it in two of
            these function applications, the copies would have to be predicting
            the same thing as to whether the first argument or the second
            argument were going to be available first. But that might conflict
            with reality. So you can't go around copying primitive oracles.
            And one of my composite oracles is a tree of primitive oracles and
            if you copied the tree you'd be copying all the primitive oracles.

            Process handles conceptually contain oracles, so they can't be
            copied either.

            By the way, I currently have some design issues with the language.
            One is that I realized I have not made sure that every process
            handle gets drained. They can be destroyed by being acquaintences
            of a process (that is, being in the state of a process) after the
            handles to that process are all drained. I haven't provided for a
            process to be informed when it has becomes garbage (a "finalization"
            path), which could be designed by the programmer to drain any
            uncopyable arcs. A possible solution for this problem is to say
            that the initial behavior of a process gets attached to the
            process's handles not on the input end of the graph of message
            sends, but on the output end at draining. This would imply that
            instead of an operator to split handles, there would be one to join
            them.

            Another issue is oracles may be an unnecessary complication. I came
            across a reference to a paper that is said to explain a way to get
            nondeterministic behavior in a pure functional language without
            oracles. It has something to do with a set type, where each set is
            represented by a single element. I can't find the paper online;
            have to look for it in dead-tree format at my nearest university
            library where they have computer science. The reference is John
            Hughes and John O'Donnell, "Expressing and Reasoning about Non-
            deterministc Functional Programs", in proceedings of the 1989
            Glasgow workshop on Functionl Programming, pages 308 through 328.

            A final issue is how do I assure that someone doesn't stuff a
            noncopyable value into a method and then copy the method? I suspect
            static typing of noncopyable vs. copyable data may make sense, while
            keeping dynamic typing of types within each of those categories. I
            like the dynamic typing in Smalltalk and Self.

            Error handling in general is a question; I have been thinking it can
            be done with an operation, via oracles, that given some graph would
            try to evaluate it but wrap the result in something that says OK or
            error. In the case of error, a diagnostic would be nice; that could
            be contained in the error value.
          Your message has been successfully submitted and would be delivered to recipients shortly.