Martin hit some of the best points I had to make on Haskell, so I  
will just add a very few things there and answer the leftovers...

On Aug 31, 2006, at 2:40 AM, skaller wrote:

> What's point-free style?

Here is another example:

getSongFiles :: Plist -> [String]
getSongFiles = pTypeListToStrings . songFiles . onePDictToMap . tracks

Each of those things after the = are functions;
as you can see from getSongFiles's type signature, it takes an  
argument "Plist," but that isn't stated in the function, for example:

getSongFiles pl = pTypeListToStrings . songFiles . onePDictToMap $  
tracks pl

As for readability, just from reading across the line you know the  
inputs and outputs and the operations in the middle (assuming that  
you know what those other functions do).

>> The
>> downside is that everyone may freely create new operators (operators
>> are simply infix-functions) so you may see all kinds of crazy stuff
>> and even overlap between modules.
>
> You can in Felix too: it's stronger than Haskell, in that
> in Haskell you have to use typeclasses to overload.

Haskell only has very weak overloading through typeclasses; that is  
not what typeclasses are for.  When you think "typeclasses" think Set  
Theory, not Inheritance and OO.  For the operators I mentioned, this  
is a namespace problem.  For example:

Data.Map has an operator (!)
Data.Array also has an operator (!)

if I want to use both Data.Array and Data.Map, I have to import it  
into my program (at which point I may rename how I import it to make  
my job easier later on):

import Data.Map as Map
import Data.Array as Arr

Then when I use the (!) in a function I have to specify the name to  
avoid ambiguity:

-- essentially the same operation as array[1] in C
getItemAtArrayIndex :: Array Int String -> String
getItemAtArrayIndex arr = Arr.(!) arr

getItemAtMapKey :: Map Int String -> String
getItemAtMapKey mp = Map.(!) mp

Note that I could have written either (or both) of these functions  
without the variables, but it wouldn't have been as clear in the  
example:

getItemAtMapKey = Map.(!)

> If your definition is that it supports functions as values,
> then C and C++ are also functional.
>
> C function pointers are first class values, and support
> currying.

It might be better to say that C and C++ may be used functionally but  
since neither is designed to be functional, they are not.  Since we  
are talking about programming languages, argument I am making is a  
linguistic one.  Whatever the actual underlying implementation may be  
what the programmer uses to "say" something in the language is the  
point of reference.

Function pointers in C are variables, they are not values.  In C,  
variables are something that may reference a value and functions are  
things that may accept variables as parameters or return values as  
results.  In C you cannot return a _new_ function as a result, so  
functions in C cannot be values.  Even more to the point, values have  
types--variables only have the type of their value.  In C function  
pointers do not have the type of their arguments--you cannot take a  
function pointer tell the compiler (or programming system) to operate  
on it in a particular way--if you incorrectly apply a function  
(including one pointed to) you will not get a compiler error, you  
will get a runtime error.  In Haskell you may (linguistically)  
evaluate a function, as in the point free style example, above.  More  
concretely, functions are values with an evaluation type, minimally:

* -> *

where the * is an existential quantification, here "(for All x) (x ->  
x)."
--you can actually analyse this type--but that is not my point:  
generally functions, data constructors and all things that have at  
least this type are evaluators which may be passed around freely,  
fully or partially applied, and even evaluated.  When you are done,  
if you have made a mistake you will get a compiler error, not a  
runtime error.

Using a type system may not be the best reasoning mechanism for a  
compiler but it is a very easy system for a programmer to think about  
and type systems allow you to evaluate functions.  For an excellent  
example of some of the capabilities a truly functional language  
offers (that C and C++ do not), take a look at the discussion about  
Djinn, at http://lambda-the-ultimate.org/node/1178 .  Djinn is a  
prototype that reasons about data types and infers function  
definitions (the actual procedure statement) from the type of a  
function declaration--this is a very Lispy thing to do, considering  
that Lisp programmers have been creating functions on the fly (beyond  
a mere lambda application) for 20 years.

Incidentally, for Haskell assembly code (currently only in GHC), the  
underlying Cmm (C--) implementation allows functions (procedures) to  
return tuples as results:

int2Integerzh_fast
{
    /* arguments: R1 = Int# */

    W_ val, s, p;       /* these are parameters to the function */

   /* perform lots of operations */

    /* returns (# size  :: Int#,
                         data  :: ByteArray#
                      #)
    */
    RET_NP(s,p);
}

Now that is a different kind of implementation.

> BTW: closure == function value.

In Felix this is true.  In Haskell closures are a kind of memory  
object, which may include evaluators of type (* -> *).

> BTW: Felix can do this now:
>
>       var s : string = f"%d" 99;
>
> The LHS term is a 'printf' style literal which acts as a
> formatter function.

This is actually a hard thing to do in Haskell.

> So is Felix functional?

Yes.  Being able to return a type of int->int, for example.  There  
are things I can "say" easily in Felix that I simply cannot in C.

> That is, the correlation [between coherent extendability and  
> functionalism] is incidental, not causal.
>
> The root causation is the desire to have a language
> one can reason about -- that is, program compactly and
> expressively with good correctness assurances.

Well said.

>> I agree.  I have followed F# a bit.  It's the general C# syntax and
>> the .NET system I hate.  Programs should be stand-alone, leaving the
>> operating system to manage resources.
>
> .NET is an operating system.

Maybe our definitions of "operating system" differ.  I would  
characterise .NET as a runtime system since it does not manage all  
computer resources from bootup--I am calling a "kernel" and  
extensions related directly to the kernel an operating system.

> So too is Felix! The driver, 'flx_arun', really IS an operating
> system! It has a scheduler for fthreads(fibres). It even has
> system (kernel) calls .. they're termed 'service calls' after some
> archaic operating systems I once used.

I have been calling such things runtime systems.  What makes it more  
than a runtime system?

>> SDL is great for games, but you would essentially have to write your
>> own GUI library to work with it.
>
> Exactly :)
>
> All the other GUI's are screwed. Felix GUI wants a (f)thread
> for each object .. not a callback.

This is very true but as a developer I find myself in the unfortunate  
position of having to offer customers a "native look and feel":  
something I cannot do unless I write a special GUI for each OS and  
that is (for me) simply impossible for time, if for no other reason.

> If Felix had a .NET binding it might help with the Windows GUI.
>
> A .NET binding seems quite possible .. I just don't have the
> expertise.

Unfortunately, neither do I. 

-------------------------------------------------------------------------
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