terminal-auspicious

Topics

programming

php drupal scheme scheming macros design patterns da la

design

design css

random thoughts

scribbles

alter ego

other me 'em that link us my space me linked in

Collections

Programmable web
PHP design patterns

Similar things

  • Random thoughts on web application internals
  • Partial evaluation and generics in php
  • An exercise with continuations, prompts and scheme macros
  • da code scheming
  • Going mad talking about relations
  • Relations and their domain structures
  • Relation modules
  • Relations battle plan
  • Once again relations, or the need to focus on smaller parts of the big picture. A rant.
  • Relations Battle Plan II and first results

guild
Home » blogs » vlado's blog

da code, types of functions

Submitted by vlado on Mon, 2006-04-24 12:33.da code | programming | scheming

I've been reviewing, scratching and descratching the idease for the language core, which for the time being I'll be calling da code.

Everything revolves around a few fundamental questions about functions. What is a function? What is a function behaviour? What is the effect of one function's evaluation(behaviour) on the overall ecosystem of a program?

Function composition

In my head there are two fundamental kinds of function composition - sequential and parallel. It is true that they are redundant, since each of them can be expressed by the other, but in an attempt to provide a relatively brief and expressive language, I will consider both. This should help with intuitive application of different computational schematics.

Function behaviours/process behaviours

Although this usually is considered in the context of processes, and interprocess communication, I think there is merit, in considering synchronicity as a function behaviour or property of that behaviour. So having asynchronous and sychronous functions, or blocking and non-blocking function calls in both the sequential and parallel contexts of function composition. This gives rise to a few strange (at least for me) questions. What should be the interpretation of an asynchronous function call during sequential function composition?

Normal vs Applicative evaluation order, or Lazy vs Eager computation

Again, what is lazy in the parallel case? How lazy? Does it makes real sence?

Now what?

Well, essentially, I will delay decisions, that is the decision is no decision. All of the above must be implemented. Now that poses syntactic challenges.

Function composition. Evaluation of function's arguments is function composition. A block - like (begin ...) //scheme or { .... }//C/C++ are a special, very useful, function composition. Essentially, we can think of them as of a kind of sequencer wrapper function, evaluating all it's arguments in a particular predefined order, and returning some result. Syntactically, as in syntactic sugar, we can get away with using different words, let's say function and process, to designate the evaluation order.

synchronicity Maybe sync/async functions will do the job, something like:
sync function x = ....
ssync function y = ....
will do the trick on definition time.

eagerness/lazyness Lazy by default might make sence, and maybe providing a call time operator like ! to explicitly force the evaluation makes sence.

vlado's blog | add new comment
Home » blogs » vlado's blog

dikini.net

spreading confusion by accident since 1970