http://docs.google.com/viewer?url=http%3A%2F%2Ffactorcode.or...

Good introduction to the language for beginners.

I noticed the 'pipeline' vs 'function call' equivalence a couple of months ago and I'm still working out all the implications of it.

It may be that stack oriented languages and functional languages are a lot closer to each other conceptually than you'd normally think they are and I think the pdf you linked here illustrates that nicely.

Also there is some equivalence between a process pipeline and either of these two. (for instance 'cat file.txt | grep x | wc').

Even if it uses a series of inter-process communication the effect is much the same. In factor that you could code up words for 'cat', 'grep' and 'wc' and then it would probably look something like this:

  :cat (filename -- lines) ascii file-lines;

  "file.txt" cat
  x grep
  wc

Yes. In fact, here’s something to think about.

Imagine a dialect of lisp where every function takes a known number of arguments. You could hard-code this per function, for example saying that + always takes exactly 2, or you could do it by keyword args, or you could make every function take a quoted list, or maybe some other ways.

In this lisp dialect, parentheses would be superfluous (except to specify quoted lists).

If you wrote it backwards, it would be a forth.

For example, let’s say * and + take exactly 2 args each.

    (* 3 (+ 1 2)) ; lisp
    * 3 + 1 2     ; trivial variation if arity is always known
    2 1 + 3 *     ; valid in almost every forth dialect, RPN calculators, etc.

    cat --file=foo sort -n head

    cat foo | sort -n | head

Basically, if you don’t use assignment, you can chain things up however you please. If your syntax chains in one direction, you’re arguably writing some kind of bastardized lisp; if it goes the other way, it’s arguably a forth dialect. This is why I capitalize Perl and Python but not forth and lisp ;).

For a 'lisp' like structure you'd need at a minimum enough storage to get all the way to the innermost expression before you can start to interpret the data.

Normally not much of a problem, but if you were to make a fabric that consists of little processors stuck together with comms wires the forth way of doing it could be an advantage.

http://searchyc.com/submissions/factorcode.org

So many languages, so little time...

There is SIMD support in the language as well which supports most of SSE4.2, check out http://docs.factorcode.org/content/article-math.vectors.simd...

You may also want to use SSE2 for saturated scalar additions or prefetches.

Very few people have x86 processors that don't support SSE2 these days. In our tests at IMVU, I think less than 1% of our customers didn't support SSE2, and it was only that high due to the Athlon XP.

In short: when starting a project targeting x86 today, default SSE2 on.

The optimizer will choose when and how to make use of the SSE and SSE2 instructions when /arch is specified. SSE and SSE2 instructions will be used for some scalar floating-point computations, when it is determined that it is faster to use the SSE/SSE2 instructions and registers rather than the x87 floating-point register stack. As a result, your code will actually use a mixture of both x87 and SSE/SSE2 for floating-point computations. Additionally, with /arch:SSE2, SSE2 instructions can be used for some 64-bit integer operations.

In addition to using the SSE and SSE2 instructions, the compiler will also use other instructions that are present on the processor revisions that support SSE and SSE2. An example is the CMOV instruction that first appeared in the Pentium Pro revision of the Intel processors.

There are pros and cons to both compiling at load time or run time; one of the disadvantages of the former is less flexibility when it comes to using CPU-specific features.