On 14/10/2013, at 3:40 PM, srean wrote:
{be good support if you post to the list not me personally .. never know
someone else might chime in or get encouraged }
> ok :) you convinced me to build again, but there is flux and there is
> Flux, it seemed a lot changed in the last few das so was waiting to
> grab the full stuff.
Very little changed. Some internals of the compiler changed,
a switch got added to a tool to improve development process.
Realise that I'm experienced with compatibility issues, having
learned all about it over 10 years or more serving on the C++
committee.
Compact linear types only work with Felix's anonymous sum
types, the only one of which anyone uses regularly is bool.
And I may have to change that so Felix bool is C++ bool
so it is always addressable.
If you're using native arrays the index will also be a compact linear
type, for example:
var x = 1,2,3,4;
is type
int ^ 4
and the 4 is compact linear (the cyclic group Z4 more or less).
So very little is impacted. Most code uses varray or darray
which are dynamic.
There IS a change coming up that will impact you.
Originally, Felix parser translated
a + b --> add (a,b)
but I decided to get smart and change it to
a + b -> + (a,b)
i.e. to allow "+" as an identifier. The idea was to save people having
to learn that + got translated to add.
The problem is that + is both infix and prefix and seeing
+ (a,b)
you cannot tell if that's adding a to b, or +'ing the tuple (a,b)
(whatever that might mean).
Same for - and *: they're both prefix and infix. I have to do something
about this because it turns out to cause problems with type classes.
So I may revert to add and sub, etc. There are a couple of options.
If you're defining a numeric class, eg matrix, this will impact you.
You may have to change a couple of lines of code.
>
> BTW once u are done with that would like to pick your brain about the
> webserver. Want to understand that code.
So do I :) Some of the code behind that is a mess. I've been refactoring
it occasionally, on and off, for some time.
Part of the problem is the utterly incompetent design of sockets and TCP/IP.
Sockets don't follow any sane protocol. So its hard to abstract them.
> Have questions : why are
> there classes when nothing is virtual ? etc. etc.
Classes are just namespaces, possibly polymorphic.
Hmm..
Alrigtht, lets try a C++ answer: a class is a collection of templates.
An instance is a collection of specialisations.
If the templates are parametrically polymorphic, you don't need any
specialisations.
Lots of classes don't need any specialisations: list, string, almost all
data structures are either monomorphic (and hence can't be specialised
because they're already maximally special), or, the polymorphism is
parametric, and there's nothing special for any particular type (by
definition of "parametric").
--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
