Re: To & or not to &

On Tuesday, March 4, 2003, at 05:26  PM, Charles Patterson wrote:

> This is a very interesting subject and I feel behind, because I don't 
> know
> the logic that led up to syntax such as
>
>     int(String) myatoi = atoi(<String> ?)
>
> The String in pointy brackets "<String>" and the question mark are 
> over my
> head.  Hopefully, Dave, you may feel it worth going to the beginning 
> and
> writing your decision tree up to this current problem.  (It would 
> probably
> make a good description in your final design doc, for those who want 
> to grok
> the advanced features.  Odds are, 99% of programs won't touch a 
> function
> pointer.)
>

I posted a message to the list after the '&' post hopefully covering 
all aspects of the HOF syntax . Sorry I didn't do it before the '&' 
post :)

> Until I understand better, I'll try to frame this in a context.
>
> * One of your goals is:  "Safety and Elegance of Java...No direct 
> exposure
> to pointers."  While I'm sure you are mostly fighting pointers from the
> point of memory management and variables, wouldn't it also be a point 
> of
> elegance to NOT have function pointers?

Well, lets be clear, all objects behind the scenes are pointers to 
memory on the heap just like they are in Java. What I don't have is 
direct exposure to pointers, i.e. no pointer arithmetic, no writing off 
the ends of objects or arrays (except through bad casts and that will 
be fixed with inheritance), no need to differentiate between '.' and 
'->' operations because every object is referred to via a pointer 
etc... just like Java

>   Afterall, with variables and
> functions, a pointer is a way to create indirection.  Sure, function
> pointers don't require heap memory, but they are still a way to 
> indirectly
> access a memory location.  There is power in variable pointers and the
> decision has been made to avoid them, perhaps so one can avoid a class 
> of
> common error?  Won't function pointers be complicated and cause errors?
> Perhaps not since they never point out to heap memory.  But perhaps 
> yes if
> you can coerce and Object to a function ptr.

I'm trying not to think of these things like function pointers ... 
Right now they are, but I'm trying to think of them more as 'function 
identifiers' ... with the addition of partial application and anonymous 
functions, closure objects will need to be created dynamically behind 
the scenes. That goes well beyond the power of function pointers.

> Or won't function pointers potntial scare off non-pros that way 
> variable
> pointers might?
>
perhaps ... which is why I'm trying to take out anything that hints at 
their storage from the syntax ... specifically the '&' token

>> The problem with doing away with the ampersand comes up with basic
>> function pointers when we have a function with two forms, one that
>> takes no arguments, and one that takes one or more arguments
>>
>> void func(){ print 3; }
>> void func(int i){ print i; }
>>
>> Object myfunc;
>> myfunc = func;
>>
>> 'func' in the last case has the potential at least to be ambiguous. We
>> could make a rule that 'when multiple variants of a function exist, 
>> the
>> function name alone identifies the zero-argument variant'
>
> What is wrong with the C++ way?
>
>     int (*f) (const char*) = atoi;
>
>     The func pointer is typed.  If there is a match, use it.  If not, 
> throw
> up?
>
Its been close to 6 years since I last programmed in C++ however I have 
a couple issues with what I see above:

1) I don't like the *, I think its unnecessary plus it reminds C / C++ 
programmers about pointers which I want them to forget about in moto.
2) How would I specify a function that returns a function ? In C at 
least I need to use a whole bunch of typedefs
3) In C++ can't functions be differentiated based on the types and 
numbers of arguments they take ? Suppose I had another function 'int 
atoi(float foo)' ... which atoi does 'atoi' refer to ?

>> double(double) square = pow(?,2);
>> double(double) twoToThePow = pow(2,?);
>>
>> Thats pretty darn powerful stuff :) .
>
> (-:  I suppose the rule is that, for each "?" in the declaration a 
> variable
> is required in order?  So if you have
>
>     double(double, int, string) foo = bar(?, 3, ?)
>

It would be:

	double(double, string) foo = bar(?, 3, ?)

since passing 3 for the second input narrows the inputs to bar. In 
other words the result of fixing one input to a 3 argument function is 
a 2 argument function.

> then you require bar to take a double and a string in that order?  That
> makes sense but something feels tingly and out-of-sync here.  I think 
> you
> are going to be able to construct a function that takes a function 
> pointer
> as a parameter, and get ambiguous or impossible situations. But I'm 
> very
> possibly wrong.
>

The biggest ambiguity comes about when I fix all the arguments to a 
function but I still want a function :) as in the following example:

>> Now suppose we have a one arg
>> function with side effects:
>>
>> global int count;
>> void hello(String s ){ print "hello "+s +" "+count++; }
>>
>> Its clear that calling the above function has the side effect of
>> incrementing count. Suppose I want to use the mechanism of partial
>> application to 'fix' the function's one input creating another 
>> function
>> I can call later.
>>
>> void() myhello = hello("Dave");
>>
>> but that won't work because the type of the expression 'hello("Dave")'
>> is 'void' and not 'void()' i.e. the return value of the hello 
>> function.
>
> Are you allowing a function to return a function pointer?  (-:  If 
> not, you
> just know which is meant above because you are trying to assign to a
> function pointer, so you must be expecting a function pointer.  Like 
> C++.

Functions in moto should be able to return other functions.

>
>> I need the '&' to distinguish between a function I'm calling right 
>> away
>> vs a function I'm defining to call later
>>
>> void() myhello = &hello("Dave");
>>
>> Or do I ? With any one of the anonymous function syntaxes I've
>> discussed with people I could accomplish the same thing by doing:
>>
>> void() myhello = <void()>{hello("Dave");} ;
>
> Looks good (except I wish it didn't have the curly braces)

Without curly braces I may be able to turn a single expression into a 
function. But how would I be able to define a function inline that was 
made up of a whole series of expressions / statements one after the 
other ?

> , but will you
> ever need this new syntax when calling the function immediately?  For
> instance,
>
>     Object foo(String s){ return an object that is really a function 
> ptr; }
>
>     void() bar= <void()>{foo("Dave");} ;
>
> hello would return an Object but you know it is really a function 
> pointer
> and want to convert it.

The above example confuses me :)

>
>> What do you guys think ? Should the '&' stay or go ?
>
> You'd probably be better off without it assuming I am wrong on my last
> point.  But you are going to find these situations more and more as 
> your
> language tries to hide specifics in an abstration.  Be it variable 
> pointers,
> function pointers, etc.  Abstractions always leak a bit on the edge 
> cases.
> (-:
>
yep :) damn those leaky abstractions :)

> One last thought.  Could you possibly have a built-in type, "Function" 
> that
> would replace the idea of a function pointer?

Dynamic type definition (see followup message on HOFs) is actually much 
more powerful than calling all functions instances of a Function class 
just like considering int[], char[][] and Object[] as different types 
is much more powerful than considering instances of all of them as 
instances of an Array class (the way things used to work) ... at least 
for type checking purposes.

-Dave

>  This would be kind of like
> how a java object pretends not to be a variable pointer.  "Function"s 
> might
> help to explicitly copy a function (pointer) to another.  For most 
> uses of a
> function pointer, for instance providing a work parameter to a 
> foreach()
> function, this would make functions feel more like java objects 
> (passed by
> reference).
>
> Charlie
>
>
>
>
>