constants and functions without arguments

[Andreas Leitner]

This is a multi-part message in MIME format.
--------------9A5E4CE57464CF0630C36C5F
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Pledger wrote:
> 
> Andreas Leitner writes:
>  :
>  | Given a lazy pure functional language do we need to differntiate
>  | (in syntax) between constants and functions without agruments? And
>  | if we don't need to, does Haskell make a difference?
> 
> Haskell always treats a declaration of the form
> 
>     foo = ...
> 
> as a pattern binding, not as a function binding.  Sections 4.4.3 and
> 4.5 of the Haskell 98 report give more details.
> 
> So, in that sense, every function in Haskell takes an argument.
> There's nothing to prevent you from adding a dummy parameter to turn a
> constant (i.e. a simple pattern binding) into a function.  The only
> reason I've heard for doing so, is to work around the monomorphism
> restriction.

Exactly thats' the reason for my question: Overcome ther monomorphism.
I come from an Eiffel background and there we have the uniform access
principle, which is a very important thing in that world. It means
that you access an attribute just like a function with no parameters.
This is actually a form of information hiding as you can change the
underlying implementation (an attribute to a function and vice versa). 

The classic examlple for this is class POINT, which has an interface
like that:
--
POINT
        -- group 1
        x: DOUBLE
        y: DOUBLE
        -- group 2
        rho: DOUBLE
        abs: DOUBLE
--
Now, you can choose to either implement group 1 as attributes, or
group 2 and calculate the other one. With the uniform access
principle, which says that accessing attributes and functions with no
arguments happen in the same syntactic way, you can change the
implementaion without notice. No user of this class needs to know.

I am to new to FP to say whether this is equaly important in
FP-languages, since the semantics are different (constants vs.
attributes and immutable values vs. objects), but for now I am just
currious wether it is possible theoretically.

I mean couldn't one say that there are no constants, just functions
with no arguments or the Void/Unit argument that return an expression.
Since we have lazy evaluation, there won't be a problem at runtime,
but would the type system allow such a thing?


tia,
Andreas
--------------9A5E4CE57464CF0630C36C5F
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

X-Mozilla-Status2: 00000000
Message-ID: <3AC45E6E.AC2DC3C2@sbox.tu-graz.ac.at>
Date: Fri, 30 Mar 2001 12:22:38 +0200
From: Andreas Leitner <nozone@sbox.tu-graz.ac.at>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Pledger <Tom.Pledger@peace.com>
Subject: Re: constants and functions without arguments
References: <3AC368A9.5BE8721F@sbox.tu-graz.ac.at> <15043.46052.112130.797961@waytogo.peace.co.nz>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Pledger wrote:
> 
> Andreas Leitner writes:
>  :
>  | Given a lazy pure functional language do we need to differntiate
>  | (in syntax) between constants and functions without agruments? And
>  | if we don't need to, does Haskell make a difference?
> 
> Haskell always treats a declaration of the form
> 
>     foo = ...
> 
> as a pattern binding, not as a function binding.  Sections 4.4.3 and
> 4.5 of the Haskell 98 report give more details.
> 
> So, in that sense, every function in Haskell takes an argument.
> There's nothing to prevent you from adding a dummy parameter to turn a
> constant (i.e. a simple pattern binding) into a function.  The only
> reason I've heard for doing so, is to work around the monomorphism
> restriction.

Exactly thats' the reason for my question: Overcome ther monomorphism.
I come from an Eiffel background and there we have the uniform access
principle, which is a very important thing in that world. It means
that you access an attribute just like a function with no parameters.
This is actually a form of information hiding as you can change the
underlying implementation (an attribute to a function and vice versa). 

The classic examlple for this is class POINT, which has an interface
like that:
--
POINT
	-- group 1
	x: DOUBLE
	y: DOUBLE
	-- group 2
	rho: DOUBLE
	abs: DOUBLE
--
Now, you can choose to either implement group 1 as attributes, or
group 2 and calculate the other one. With the uniform access
principle, which says that accessing attributes and functions with no
arguments happen in the same syntactic way, you can change the
implementaion without notice. No user of this class needs to know.

I am to new to FP to say whether this is equaly important in
FP-languages, since the semantics are different (constants vs.
attributes and immutable values vs. objects), but for now I am just
currious wether it is possible theoretically.

I mean couldn't one say that there are no constants, just functions
with no arguments or the Void/Unit argument that return an expression.
Since we have lazy evaluation, there won't be a problem at runtime,
but would the type system allow such a thing?


tia,
Andreas

--------------9A5E4CE57464CF0630C36C5F--