1 Feb 01:45 2015

### Re: [felix] packages


On 01/02/2015, at 10:56 AM, Ryan Gonzalez wrote:
>
> By consulting the history, the build date can be translated to the packages
> internal "version".
>
> Is this required for packages, or is it optional? Personally, I like the major.minor.fix scheme better.

It's just an idea. the major.minor.fix scheme has advantages, and on many
Linux (and other Unix) systems, it is enforced by the way links to
shared libraries are maintained.

The problem is that there is no coherent way to interlink such packages.
If packages depend on major.minor, then patches are irrelevant:
packages can be upgraded in isolation.

With major.minor the assumption is you need the same major (no other
will do) but any minor greater or equal to the specified one.

It's all a nice idea. But the reality of the world is continuous ad-hoc integration
and in that scenario the categorical distinctions of the package numbers
are useless UNLESS some human comes along and organises the
dependencies. This works with that, this can replace that, etc etc.

This is what Debian and Ubuntu and ArchLinux and all the other
package managers do and it is a HUGE effort which typically fails
most of the time. The last Debian release took over 2 years to get out.

Using a date YY.MM.DD defines your whole system with a single
number. Packages are comparable by date. They're NOT comparable


1 Feb 00:48 2015

### packages

The idea of third party packages is that you can install them
independently of the core.

the packages should continue to work in particular
you may need to hand configure packages and it is really
horrible having to edit the configuration every time a
new Felix core install clobbers it.;

Of course packages themselves may need to be upgraded because

(a) new core felix isn't compatible with them
(b) the underlying C/C++ package has been upgraded

Most packages of most package managers have versioning.
On Linux a crude method:

major.minor.patch

is often used. This means:

* changes in patch fix bugs and don't require recompilation
* changes in minor
generally the same as patch
significant changes in algorithms
* major
interface changes


27 Jan 06:44 2015

### Gui support and packages (part 1)

I am making some tests in the tutorial for the Felix GUI.

Yes, Felix has a GUI "built in".

Currently you can run "make guitest", be aware some
of the tests are interactive and require a response.
It's the nature of GUI's I'm afraid.

These tests currently run directly out of the repository,
not the build copy of the test harness. however they use the
gui in the build. This may change a bit later.

For these tests to work on your system you MUST have installed

SDL 2.x.x (Simple direct media layer)
TTF 2.x.x (true type font binding)
IMG 2.x.x (image handling)
freetype 2 (true type font renderer)

and on Linux

libjpg
libpng
.. (other image libraries)

Image handling is built-in on OSX so these libs aren't required there.
Note, you MUST use SDL version 2.

In addition you may need OpenGL support.
Note I cannot run these tests on the server:


14 Dec 17:27 2014

### generators

Take care!

There is a bug in the compiler causing

test/regress/rt/generators-01.flx

to fail. When I looked at the test I saw the problem instantly.
Here's the code:

///////////////////////////////////////////////////////
//Check generators

var cheat : int = 0;
gen f():int = {
++cheat;
//print "Generator "; print cheat; endl;
return cheat;
}

print "F 1="; print$f(); endl; // 1 body """ static int x = 0; int g() { ++x; return x; } """; gen g : 1 -> int; print "C 1="; print$ g(); endl; // 1



7 Dec 15:38 2014

### unions

So, we know the standard representation of a sum type is:

struct _uctor_ { int variant; void *data; };

which is layout compatible with

however there are various special representations. For example
if a variant has no argument, it's just represented by the "int" tag.
Safe, since proper use shouldn't fetch the data field for that tag.

Another special one is for a form where there are exactly two
variants, the first having no argument, then we just use

void *data

will NULL being the first variant, and a non-null address being
the address of the second one. This is efficient but it was chosen
for a more fundamental reason than performance: it means any
"possibly NULL" C pointer has a natural representation in Felix
as a union:

union maybe_ptr[T] = Null | Ptr of T;

In other words, a possibly NULL C pointer can not only be
considered logically equivalent to an option type with
type T a pointer, it is layout compatible with one.

Another example of this is


7 Dec 14:34 2014

### Re: [felix] Composition


On 07/12/2014, at 10:27 PM, srean wrote:

> This is neat. Does the dot operator and |> do the same thing ?

Sure, but the precedence is different, operator . is high precedence,
operator |> is low precedence. Similarly operator whitespace
is high precedence, operator $is low precedence (however,$ is
right associative).

Apart from trying to remember them all .. having many operators
makes remembering the precedences almost impossible.
I'm a bit slow .. I can't even remember them for C, which I've
been writing for several decades :)

--
john skaller
skaller@...
http://felix-lang.org

------------------------------------------------------------------------------
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE

7 Dec 08:52 2014

### Composition

Felix has a forward composition operator:

(f \circ g) x = f (g x)

There's no reverse composition operator, because I can't think of
a suitable symbol. Operator dot (.) was used before and leads
to a nice notation:

x . (f . g) = (x . f) . g

but it doesn't work because f. g means application of g to f.
can get it confused, and polymorphism really screws it up.
I could use

x . (f \cdot g)

[\cdot is a fat centred dot in TeX] although the precedence isn't clear!
Consider also:

f \circ g \cdot h . x

to see: where do the parens go?

Anyhow, i have one more thing to do in the wrapping stuff, actually
lambda lifting:

f \circ g --> fun x => f (g x)

Now the projections work, Felix can finally express properly what C++ can't:


2 Dec 22:26 2014

### Re: [felix] projections

OK, next commit should handle all kinds of
function like things passed as arguments and have
test cases named wrap-*.

I have yet to verify/get working projections of pointers to products
passed as arguments. Simple enough, just a swag more tests and
some copy/paste polymorphism.

Eventually the old wrapper generator will be deleted. For now it still
runs but shouldn't do anything except mark closures as Heap_closures.

--
john skaller
skaller@...
http://felix-lang.org

------------------------------------------------------------------------------
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE

30 Nov 14:03 2014

### wrappers

OK, I have the new wrapper generator working for primitives, struct and cstruct
constructors, and non-const union variants.

However there's a problem with projections. For a struct or record v you can write

v.fieldname

or equivalently

fieldname v

and also this works for a pointer. However this should work and
name the projection:

fieldname of (T)

where T is the struct or record type but it doesn't. For tuples that would be
quite weird:

1 of (int * long)

would be the name of the second projection. I know why it doesn't work:
the lookups only work in an application  f(x). So for the moment you will
have to manually eta-expand, that is, write the wrapper by hand like:

struct X { x:int; };
fun x_value_projection (X:a) => a.x;

The lookup code in the compiler (src/compiler/flx_bind/flx_lookup.ml) is
extremely complex and fragile. Each context is handled separately,


16 Nov 17:41 2014

### wrappers

Felix currently allows certain non-functions to be used "as functions".

For example:

fun f: int -> int = "$1"; is a primitive function like thing, but it is NOT a Felix function which fun g (x:int) => x; actually is. When you apply these entities: println$ f 1, g 1;

this involves terms:

apply (f, 1)
apply (g, 1)

and the compiler knows that f and g are different applicable things
and uses the appropriate code to apply them: for f we get

1

by substitution and for g we get

g->apply(1)

[although inlining me simplify that]. No consider the function



11 Nov 17:09 2014

### Futures

the implementation of futures relies on a hack/implementation detail
which I have disturbed reorganising the compiler.

Here's the problem: I have implemented futures by spawning an fthread
(fibre) which sends  the result down an schannel. To get the result you
read the schannel. More precisely you call a function which checks
if the result has been fetched already, if not it reads the schannel
and caches the result.

This is a "perfect" implementation of futures, however it isn't legal
aren't allowed in functions (or generators). They're only allowed in
procedures (and ones not nested in functions).

However Felix has some optimisations, including the ability to
convert a function

fun f(x:D):C = ...

into a procedure equivalent to:

proc f' (p:&C, x:D) { *p = f x; }

where the code of f is inserted rather than calling it.

That means if f is called in a procedure f' is called instead
and as long as that procedure's ancestors are procedural,