@BGB, by the 'same end' i meant tranforming a statement into something that a flow control operator can act on, like if () {...} else {} The domain of the execute operator in APL is quoted strings. I did not mean that the same end was allowing asynchronous execution.

On 6/16/2012 1:23 PM, BGB wrote:
On 6/16/2012 10:05 AM, Randy MacDonald wrote:
@BGB, if the braces around the letters defers execution, as my memories of Perl confirm, this is perfect. With APL, quoting an expression accomplishes the same end: '1+1'


no, the braces indicate a code block (in statement context), and it is the "async" keyword which indicates that there is deferred execution. (in my language, quoting indicates symbols or strings, as in "this is a string", 'a', or 'single-quoted string', where "a" is always a string, but 'a' is a character-literal).

in a expression context, the braces indicate creation of an ex-nihilo object, as in "{x: 3, y: 4}".

the language sort-of distinguishes between statements and expressions, but this is more relaxed than in many other languages (it is more built on "context" than on a strict syntactic divide, and in most cases an explicit "return" is optional since any statement/expression in "tail position" may implicitly return a value).


the letters in this case were just placeholders for the statements which would go in the blocks.

for example example:
if(true)
{
    printf("A\n");
    sleep(1000);
    printf("B\n");
    sleep(1000);
}
printf("Done\n");

executes the print statements synchronously, causing the thread to sleep for 1s in the process (so, "Done" is printed 1s after "B").

and, with a plain "async" keyword:
async {
    sleep(1000);
    printf("A\n");
}
printf("Done\n");

will print "Done" first, and then print "A" about 1 second later (since the block is folded into another thread).

technically, there is another operation, known as a join.

var a = async { ... };
...
var x = join(a);

where the "join()" will block until the given thread has returned, and return the return value from the thread. generally though, a "join" in this form only makes sense with a single argument (and would be implemented in the VM using a special bytecode op).

an extension would be to implicitly allow multiple joins, as in:
join(a, b, c);    //wait on 3 threads
except, now, the return value doesn't make much sense anymore, and likewise:
join(
    async{A},
    async{B},
    async{C});
is also kind of ugly.

in this case, the syntax:
async! {A}&{B}&{C};
although, this could also work:
async! {A}, {B}, {C};

either would basically mean "async with join", and essentially mean something similar to the 3-way join (basically, as syntax sugar). it may also imply "we don't really care what the return value is".

basically, the "!" suffix has ended up on several of my keywords to indicate "alternate forms", for example: "a as int" and "a as! int" will have slightly different semantics (the former will return "null" if the cast fails, and the latter will throw an exception).


but, since I got to thinking about it again, I started writing up more of the logic for this (adding multiway join logic, ...).



On another note, I agree with the thesis that OO is just message passing:

aResult ? someParameters 'messageName' to anObject ?? so, once 'to' is defined, APL does OO.

I was thinking 'new' didn't fit, but

   'new' to aClass

convinced me otherwise.

It also means that 'object oriented language' is a category error.


my language is a bit more generic, and loosely borrows much of its current syntax from JavaScript and ActionScript.

however, it has a fair number of non-JS features and semantics exist as well. it is hardly an elegant, cleanly designed, or minimal language, but it works, and is a design more based on being useful to myself.


On 6/16/2012 11:40 AM, BGB wrote:

I recently thought about it off-list, and came up with a syntax like:
async! {A}&{B}&{C}


--
---------------------------------------------------------------------------
|\/| Randy A MacDonald       | If the string is too tight, it will snap
|\\|array...@ns.sympatico.ca|   If it is too loose, it won't play...
      BSc(Math) UNBF '83      | APL: If you can say it, it's done.
      Natural Born APL'er     | I use Real J
      Experimental webserverhttp://mormac.homeftp.net/
------------------------------------------------<-NTP>----{ gnat }-


_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc



_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc


--
---------------------------------------------------------------------------
|\/| Randy A MacDonald       | If the string is too tight, it will snap
|\\| array...@ns.sympatico.ca|   If it is too loose, it won't play...
     BSc(Math) UNBF '83      | APL: If you can say it, it's done.
     Natural Born APL'er     | I use Real J
     Experimental webserver http://mormac.homeftp.net/
------------------------------------------------<-NTP>----{ gnat }-

_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Reply via email to