Thursday, April 22, 2010
#
Since the
graphviz site no longer hosts a public webdot server, we can now make use of another AT&T hosted
service.
Sunday, February 07, 2010
#
Somehow, the Bigloo R5RS macro expander is defective. Most advanced applications that extensively use the
hygienic macros advocated by R5RS (e.g., SSAX-SXML, Kanren) do not work directly with Bigloo.
No need to shy away from Bigloo though - it boasts an excellent multi-platform compiler (running natively on Unix, Windows as well as on JVM and .NET), and is amendable for extension. An obvious candidate is the Alexpander from Al Petrofsky, which implements R5RS macros (as well as as a couple of extensions).
The following code appears to "just work" with Bigloo in an interactive mode via $bigloo -eval '(define *user-pass* *alexpander*)' -s -i command. For now, it doesn't support the compilation mode, but its on the way...
(define *store* (null-mstore))
(define occurs? (lambda (s l)
(cond ([pair? l] (or (occurs? s (car l)) (occurs? s (cdr l))))
(else (eq? s l)))))
(define *first* #t)
; Somehow these ones need to be defined *inside* the compiler,
; not inside the generated code...
(define _eqv?_17 eqv?)
(define _cons_31 cons)
(define _append_32 append)
(define _list_33 list)
(define _vector_34 vector)
(define _list->vector_35 list->vector)
(define _map_36 map)
(define (*alexpander* c)
(begin
#;(with-output-to-file "/dev/stderr" (lambda ()
(display "|")
(display c)
(newline)))
;
; declare-library! being a Bigloo specific form
; can not be handled by alexpander properly
;
(cond
([and (pair? c) (eq? (car c) 'declare-library!)] c)
(else (let ([C (expand-top-level-forms! (list c) *store*)])
(begin
#;(with-output-to-file "/dev/stderr" (lambda ()
(display ">")
(display C)
(newline)))
(if (pair? C) (car C)
; since there is no way to insert new forms
; after the one that Bigloo read (the procedure
; must return a form, not a list of forms), we
; rely on the library provider to add the forms
; from null-output manually to library.init file...
#;(if [occurs? 'module c] (case *first*
([#t] (begin
(set! *first* #f)
null-output))
(else '()))
'())
#f)))))))
Tuesday, December 01, 2009
#
Here is another Wiki based code repository, this time with the goal of creating a
programming chrestomathy
Monday, November 30, 2009
#
Some time ago I've found a curious picture in an otherwise very interesting report that depicts the ratio of usage of natural resources versus availability/exploitation of resources by various countries of the world.
Guess which country is the least distorted by this transformation? You bet - its Cuba;-)
Judge for yourself in the Living Planet Report 2006:
Friday, November 27, 2009
#
Its very revealing to finally read a reasonable assessment of the role of USSR with respect to
USA in "improving" the situation in Afghanistan, especially from this US newspaper
article.
This, I think is the viewpoint of many Afghans, not only the Taliban:
Portraying Americans here as the new Soviets, of course, forms the very foundation of the Taliban world view. "Both superpowers wanted to impose by force their alien ideologies on our country -- the Soviets socialism, and the Americans this strange phenomenon they call liberal democracy," Mullah Wakil Muttawakil, foreign minister of the Taliban government that was deposed in 2001, said in an interview. "These are outside ideas. And anything coming from abroad is resented and rejected here."
Americans supported the very people they are fighting against now: fundamentalists, even after the collapse of the USSR. And I'm afraid thats actually a majority of the population in Afghanistan. Another quote:
The reconciliation appeal went nowhere. Aiming to trap the Soviets in a Vietnam-like quagmire, the U.S. and an unlikely alliance ranging from Pakistan to Egypt to China to Iran rolled out a huge program to arm, finance and train the mujahedeen.
Also note how the article puts the blame of destabilizing the situation on USA and allies:
Against all predictions, after the last Soviet soldier left in February 1989, Mr. Najibullah's government, instead of collapsing, went on the offensive. Scoring key victories against the rebels, it outlived the Soviet Union, unraveling only when Russian-supplied food and weapons ran out. Absent continuing American aid for the guerrillas, it could have remained in power much longer, many former mujahedeen say.
But then again, with no USSR to counteract the peace enforcement by USA & allies (like what the USA did in the 80s to counteract the peace enforcement by the USSR), the current campaign of USA & allies is probably doomed to success. However, the article is a little more pessimistic on that one:
Few in Kabul expect the Karzai government would display similar longevity should Western forces go home. "Najibullah had the support of a strong and well-equipped Afghan army, air force and intelligence, and of a strong party," said Mohammed Mohaqeq, a powerful former mujahedeen commander who is a parliament member and a Karzai supporter. "I don't think we can even compare these two governments to each other."
Wednesday, November 25, 2009
#
It turns out that all currently existing edge types in LIME can really be derived from just two basic blocks:
- real-dependency edge (regular), having signature OutPort=>InPort
- anti-dependency edge (inplace), having signature InPort->OutPort
The data sortof flows on the regular edge, from left to right, no problems here.
The inplace edge, on the other hand, specifies that the output port depends on the input port (which clashes somewhat with the semantics of an actor). But if we give this the semantics that it maps both input and output ports to a single computer resource, a number of interesting consequences follow.
First, this is actually the same as anti-dependency in ISAs: the memory is shared between InPort and OutPort; the schedule of operations with these Ports can not be shuffled freely, since these "state" ports specify strictly sequential access pattern: ... => InPort -> OutPort => InPort -> OutPort => ...
- "fifo", which is just a:OutPort=>b:InPort, a regular stateless port of a
- "inplace", which is just a:InPort->a:OutPort, a regular shared-memory port of a, which can modify it in-place
- "init_fifo", which is b:OutPort==>a:InPort, c:OutPort=>a:InPort, scheduling dependency: b sends data to a, before c can
- "deinit_fifo", which is a:OutPort=>b:InPort a:OutPort==>c:InPort, scheduling dependency: b receives all remaining data in the fifo after c can no longer receive any
- "state", which is a:OutPort=>a:InPort->a:OutPort, a stateful port of a
- "init_state", which is b:OutPort=>a:InPort->a:OutPort=>a:InPort, scheduling dependency: b constructs state of a, and has to run first
- "deinit_state", which is a:OutPort=>a:InPort->a:OutPort=>b:InPort, scheduling dependency: b destructs state of a and has to run last
However, this will probably require us to introduce additional attributes for completeness: the potency (how many time an actor can fire a port) and priority (which actors fire first, depicted above as edge length), since here we have multiple edges per port, which is not good if you've read the previous post;-)
But also here we should probably start using Haskell (as the notation above already shows;-)
The reason is simple: you can't give precise semantics if you connect e.g., a:x->b:y and c:z->b:y. When b reads from y, which value does it get? Is it a:x or c:z? Maybe both? In order or simultaneously?
We get out of these nasty problems by modeling the behaviour of b:y.
In fact, there are three common cases:
- both a:x and c:z are passed separately, and simultaneously. This is modeled using the type of b:y, namely the anonymous struct type containing x and z elements
- a:x and c:z are combined using an associative operator, modeled using anonymous union type for b:y, containing x and z elements
- either a:x or c:z are passed, which is modeled using variant record type for b:y, which is a struct containing an enum tag and a struct for x and z. You can have deterministic behaviour, where the tag is controlled by a special node in the graph, or non-deterministic behaviour, where the tag value is determined from data/space availability on x or z ports.
Other special behavioral patterns should probably be specified in a language like Haskell...
My first
entry is in there! Check it out, if you're interested in Concurrent, Multi-core, Parallel or Distributed programming using Data-flow paradigms.
Saturday, November 21, 2009
#
Lazy evaluation (call-by-need) is often contrasted to Eager evaluation (call-by-value) in functional programming, or, more generally, in applicative systems. Even in C, you can pass variables by value (eagerly) or by pointer (lazily) using the prefix "*" declarator, and then force the pointer to yield a value by applying the prefix "*" operator. C++ also has a half-breed called "proper reference" (&), which does not require one to use the any operator for the reference to yield a value, much like how evaluation happens in Haskell.
In DataFlow, on the other hand, we have "data-driven" scheduling vs. "demand-driven" scheduling. With data-driven scheduling, the nodes that have acquired all needed inputs can produce values as soon as possible. The firing is driven then by availability of input data (as in KPN). The order is strict: first, the inputs are acquired and only then the outputs are released.
With demand-driven scheduling, execution of nodes is triggered by the need to fill available space, possibly already after some outputs have been produced. The order is non-strict: release of outputs or acquisition of inputs can happen any time, as required by the algorithm.
In effect, the firing sequence is turned inside-out. So, instead of the following Data-driven snippet:
val in = source()
val datum = process(in)
val out = sink(datum)
we get the following Demand-driven snippet:
sink(process(source()))
It looks like data-driven is exactly the same as eager evaluation and demand-driven is exactly the same as lazy evaluation.
This means that we can model both scheduling types in a functional language with corresponding evaluation strategies.
Thursday, November 19, 2009
#
While reading this introduction to monads (and remembering one of the Oleg's statements that
all I/O is monadic) this following idea came to me: why don't people model DataFlow as a monad?
All different forms of DataFlow contain state of one form or another. Certainly, if you start optimizing
any DataFlow graph (for size, for speed or parallel efficiency) you'll end up introducing memory that is shared either
among:
- instances, i.e., shared state/variables (for improving throughput) like tuple space of Linda
- activations, i.e. actor local state/variables (for improving latency) like register allocation and caching
And monads were supposed to encapsulate and abstract state...
Isn't it possible to model all edge types and node types and roles (which are now just strings in LIME) within a Monadic Framework and finally have a model for these things in LIME?
Some time ago I found this innovative wiki in which you can put your literate programs, have it weaved and tangled on the server, and then retrieve (almost) executable result.
I think I'll have a good use for that service soon!
Monday, November 16, 2009
#
Obviously, I can not really document everything I'm doing in my research right here, so this lime.wiki shall serve as a store for LIME - the research project I'm working on as well as other related stuff such as logic, relations and functional programming.
In case you didn't know, LIME stands for Less-Is-More Expressive/Effective/Efficient (so, LIMEEE is probably a better name;-)
Less-Is-More the only minimalist design principle by which beautiful software can also be made functionally useful. The project has resulted in the first prototype that proves that Less is More Expressive: using minimal number of concepts the process of software design for embedded multi-core systems is greatly simplified.
My current focus is on Effective: I want to improve the design process of LIME itself using techniques from LIME itself, possibly extended with methods from Logic and FP domain. In the future, LIME shall also cover Efficiency, thereby competing with other similar solutions.
I am fed up with the process of recollecting stuff I've thought about, or saw somewhere on the internet.
Here shall be the place to put links to these and preserve them for posterity!