On 28/02/2012, at 8:33 AM, Michael Maul wrote:
>
> So for say libraries that span multiple files all would be flxl then?
Although I'm not sure about Windows which used to support 3 letter extensions.
> I think something that can more formally define a libraries interface might
> be good.
> So a library a synonym for a class intended for reuse or is a library a
> collection of classes? If it is a collection then what defines membership.
Directory structure perhaps. Also, some relation to packages, i.e. something
to do with the *.fpc database and flx_pkgconfig. And, grammar extensions.
Eg a matrix library (which will happen!) might provide special syntax,
so a library is basically a *domain*. Perhaps domain is a better word?
Another domain that's around is SDL (Simple Direct Media Layer),
which is related to Games. And of course GUI.
And one that already has a Language: databases, and SQL.
At this point, Felix is almost entirely a serial text stream language.
The
include "file";
is a clean looking hack barely better than C's #include facility,
it actually yanks an AST, but that's still pretty low level.
Flxh macro files are yanked as text streams (done by the compiler
with command line switches only).
The important thing technically is always "invariants".
A domain or library must provides some invariants.
> Now suppose we have a file that defines the interface to the library , it
> could also contain the documentation for the exported items.
Yes. Note that I'm not sure we're ready to implement anything, but we're
gradually getting
enough "library code" use cases to think about it.
> You get literate programming, with out all the comments clogging up the code.
> The downside is that you have to maintain a separate interface, but that
> might not be a bad thing as it draws more attention to the interface
> presented by the library and may also help prevent exposing library artifacts
> that weren't meant to be exported.
One of the core concepts of Felix is to do away with *separate* interfaces
and the corresponding maintenance burden. This is particularly important
for inter-class/file type recursion. But note: type classes (those things with
virtual functions in them) are already interfaces.
Also one would like simple enough code that semantics can be learned
by reading the code.
Conceptually, you're correct, but the kind of *interface* I'd be thinking of
is about concepts and domains, not functions: it's more about language.
As an example look in src/tools/pposix.flx and you'll see some "regdef"
and "regexp" stuff... regular expressions are a domain, one related to
strings closely.
I could extend the grammar so instead of "search_and_replace" we had
search s replacing all re with r;
Of course this just calls the search_and_replace function, but it defines
an interface at a high level, as "regdef" does. That's the kind of interface
I'd be thinking about.
> The library definition also opens the doors to separate compilation, which is
> something that could drastically speed up the build times. Currently we sort
> of have something that does parts of this. fpc's. Reworking fpc's to support
> interface definition and documentation might archive some of your aims.
My thoughts: separate compilation at the Felix level is anathema to the whole
idea of a whole program analyser, which is how Felix does optimisation.
I also doubt it speeds up compilation.
In C/C++ separate compilation slows compilation down.
* reprocessing header files repeatedly
* massive link times
* no opportunity for garbage collection of unused functions
Felix is faster. What slows Felix compiles down is compiling
the C++ it generates.[Quite a lot of the optimiser just calls
"scan everything" functions repeatedly because I found it hard
to maintain caches .. the optimiser can be sped up enormously]
The key idea really is caching. Note also a lot of what makes
Felix SO EASY to use is that you can write a function or
define a type ANYWHERE. It just works. No forward declarations.
No interfaces. No problems with type recursion across file
boundaries. Class instances can be defined anywhere.
This "lack of structure" is really important for
rapid prototyping. It gives a feel like "dynamic typing" without
throwing away static typing.
Of course there are limits. We need structural enforcement.
Type classes (classes with virtuals) provide an enforcement
and packaging layer at the low level.
Having said all that Felix was always intended as a library generator
NOT a program generator! That's why it produces shared libraries
by default (I wanted to make sure it would work :)
BTW: when you write Felix programs .. did you know you're abusing
global initialisation? In fact Felix has a main procedure just like C:
proc flx_main() { .. }
and that's where work really should be done. flx_main is invoked
after initialisation is complete.
And there IS an interface specification, the "export" keyword.
This wraps a Felix function into an extern "C" function.
Also you can export types, which is just a typedef:
Binding libary std
binding library std done
Exports = 0
Binding libary posix
binding library posix done
Exports = 0
Binding libary web
binding library web done
Exports = 0
You can see the "exports" being counted here :)
At present the ONLY way to get separate compilation is to build
a C library with export, and then write C bindings to it.
You use dynlink to load the library.
It's pain, that Felix itself cannot generate the bindings,
or bind to raw Felix (without the C).
Note: Felix can also generate Python modules.
The main problem is structurally typed types like tuples.
Felix uses a synthesised type name for them. In another
compile it will use a different name for the same type.
I could use name mangling, but the names could be
THOUSANDS of characters long (because you have to include
all identifying info in the name).
Ideally we'd use C++ templates and let C++ worry about it,
but C++ templates are badly broken: they don't support type recursion
and that's utterly fundamental. I doubt this has been fixed in C++2011
despite template typedefs fixing the "self name not in scope" problem.
Perhaps I'm wrong..
--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org
------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
