On 6/16/2012 11:36 AM, Randy MacDonald wrote:
@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.
side note:
a lot of how this is implemented came from how it was originally
designed/implemented.
originally, the main use of the "call_async" opcode was not for async
blocks, but rather for explicit asynchronous function calls:
foo!(...); //calls function, doesn't wait for return (return value is
a thread-handle).
likewise:
join(foo!(...));
would call a function asynchronously, and join against the result
(return value).
async also was latter added as a modifier:
async function bar(...) { ... }
where the function will be called asynchronously by default:
bar(...); //will perform an (implicit) async call
for example, it was also possible to use a lot of this to pass messages
along channels:
chan!(...); //send a message, don't block for receipt.
chan(...); //send a message, blocking (would wait for other end to join)
join(chan); //get message from channel, blocks for message
a lot of this though was in the 2004 version of the language (the VM was
later re-implemented, twice), and some hasn't been fully reimplemented
(the 2004 VM was poorly implemented and very slow).
the async-block syntax was added later, and partly built on the concept
of async calls.
but, yeah, probably a lot of people here have already seen stuff like
this before.
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
|\\|[email protected]| 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
[email protected]
http://vpri.org/mailman/listinfo/fonc
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
--
---------------------------------------------------------------------------
|\/| Randy A MacDonald | If the string is too tight, it will snap
|\\|[email protected]| 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
[email protected]
http://vpri.org/mailman/listinfo/fonc
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
