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.
yes, ok.
just, a lot of this logic is hard-coded into the parser and compiler
logic though, but yeah I think I understand what is mean here.
FWIW, it is possible to use code-blocks at runtime by using the syntax
"fun{...}", which is basically a shorthand equivalent to "function() {
... }" (this will create closures if there are any captured bindings,
but otherwise will create a raw block).
(by default, bindings are captured by identity, and may outlive the
parent scope).
note that, "async{...}" will also work similar to a closure by default,
so that variables will be captured by-reference. technically, it is also
possible to write something like: "async(i){...}" which would capture
'i' by-value (this being because, internally, async is implemented by
calling a closure in a newly-created green-thread, and in the case where
variables are used, they are treated as arguments, with the closure
having a matching argument list).
the reason for this latter form of async is to allow things like:
for(i=0; i<16; i++)
async(i) { ... }
where each would capture the value of 'i' (rather than the variable 'i').
vaguely similar could be possible with closures, say: "fun[i]{...}", but
thus far nothing along these lines has been implemented (and would
require altering how closures work).
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 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
