On Tue, 2006-09-05 at 11:07 -0400, Peter Tanski wrote:
> On Sep 4, 2006, at 6:38 AM, skaller wrote:

> This entire list construct should be scrapped.  Felix is literally  
> compiled into std C++; translate a "list" into a C++ list<> if Felix  
> lists have no other evaluation advantages (i.e., they are not lazy  
> lists); then push and pop values.

This is not possible for two reasons.

First, C++ container cannot hold Felix objects,
because the garbage collector cannot trace into them.

Second, C++ list is a mutable, doubly linked list,
whereas the Felix list is an inductive singly
linked, persistent, sharable data type.

Felix list is not defined in C++, it's defined in Felix
library in one line:

  union list[T] = | Empty | Cons of T * list[T];

which generates an optimal, garbage collected,
inductive data type. [The garbage collector itself
has a significant overhead but that's another issue:]

There's no such thing as a 'lazy' list, lists are
intrinsically eager. A 'lazy' list is actually a stream,
and you may note Erick is proposing one right now:

http://www.felix.cybercloud.net/wiki/index.php/Streams

Technically, Felix schannel[t] IS already a mutable
stream (that is, stream destructors cause persistent
damage).

A more functional stream, eg one with an interface
like:

        str,data  = read str

which is of course just <head,tail> is probably also
possible for 'forward' iterators.

You have to remember that in Haskell, laziness is coupled
with the purely functional thing. Therefore the same closure
can be evaluated multiple times and must give the same result,
so you can even cache the result as an optimisation.

Since Felix isn't purely functional, a host of difficult
questions arise.

To see this in 'reality' you may look at the streams interface
provided in Ocaml 'extlib'. These streams are supposedly lazy and 
combinatorial, however they also handle mutable streams
(input iterators) and the result is, IMHO, a mess semantically.

C++ does not make this mistake, it distinguishes iterator
kinds .. Haskell CANT make this mistake, because it can't
define I/O streams in the first place (in general: it 
can probably provide a monadic context to defeat the 
need for purity .. which also assuredly defeats
laziness, since I/O is intrinsically eager).

More precisely, I probably mean 'ordered' rather than 'eager',
whereas 'lazy' means unordered.

Anyhow, the point is: lists are not something recognized by the
compiler. The translation is determined by the library interface.
A more efficient list is not possible, except in that a specialisation
with which the garbage collector cooperates MIGHT avoid some of the
garbage collector overhead (6 words, or 48 bytes on 64 bit machine
at the moment .. :)

The list syntax you see is a mess for the simple reason there
is no compiler support for it. Everything is done in the library.

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Felix-language mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/felix-language

Reply via email to