Functions - Revision history

Adamcolton at 18:10, 26 November 2020

2020-11-26T18:10:26Z

← Older revision		Revision as of 18:10, 26 November 2020
Line 64:		Line 64:

	That said, if I do operator overloading, I want operator categories. For instance, it may be the case that + means either sum or concatenation. But you must choose.		That said, if I do operator overloading, I want operator categories. For instance, it may be the case that + means either sum or concatenation. But you must choose.

			== Simple Model ==
			I keep going in circles on some of the details, so I propose the following simple model as a starting point.

			Function args are structs.
			func Person( name, role string, age int)
			implicitly defines
			{name,role string, age int}

			Functions can be curried with structs
			createAdmin = {role:"admin} @ Person // type func(name string, age int)

	[[Category:Gryphon]]		[[Category:Gryphon]]

Adamcolton: /* Context Struct and Methods */

2020-05-12T02:04:39Z

Context Struct and Methods

← Older revision		Revision as of 02:04, 12 May 2020
Line 48:		Line 48:
	then a method becomes		then a method becomes
	Person.SetName := <[p *Person, newName string]> -> {p.Name = newName}		Person.SetName := <[p *Person, newName string]> -> {p.Name = newName}

			This could be extended to other types like arrays, so sum could be:
			const sum := <[]T/Numeric> -> T {
			sum : T
			for _,v := range ${
			sum += v
			}
			<- sum
			}

	== Operator Overloading ==		== Operator Overloading ==

Adamcolton at 01:43, 12 May 2020

2020-05-12T01:43:21Z

← Older revision		Revision as of 01:43, 12 May 2020
Line 48:		Line 48:
	then a method becomes		then a method becomes
	Person.SetName := <[p *Person, newName string]> -> {p.Name = newName}		Person.SetName := <[p *Person, newName string]> -> {p.Name = newName}

			== Operator Overloading ==
			I'm not even sure I want operator overloading.

			The problem is that I'm conflicted. I like a pure model where operator overloading is only permitted if the arguments and return are of the same type. But the place where I most want it is with vectors. And I like distinguishing vectors and points.

			That said, if I do operator overloading, I want operator categories. For instance, it may be the case that + means either sum or concatenation. But you must choose.

	[[Category:Gryphon]]		[[Category:Gryphon]]

Adamcolton: /* Curry Closures */

2019-10-17T02:38:26Z

Curry Closures

← Older revision		Revision as of 02:38, 17 October 2019
Line 23:		Line 23:
	Instead I want to use currying.		Instead I want to use currying.

	const Add = (a, b int)-->(int){return a+b}		const Add = <{a, b int}>-->(int){return a+b}
	c5 = Add::(5) // c5 is now type (int)-->(int)		c5 = Add::{a:5} // c5 is now type {int}-->(int)

	== Inline ==		== Inline ==

Adamcolton: /* Context Struct and Methods */

2019-10-15T14:13:05Z

Context Struct and Methods

← Older revision		Revision as of 14:13, 15 October 2019
Line 43:		Line 43:

	If we treat func args as a struct, then the order either becomes optional or entirely goes away with named		If we treat func args as a struct, then the order either becomes optional or entirely goes away with named
	square := <x float> -> {<- x*x}		square := <[x float]> -> {<- x*x}
	square{x:10}		square[x:10]

			then a method becomes
			Person.SetName := <[p *Person, newName string]> -> {p.Name = newName}

	[[Category:Gryphon]]		[[Category:Gryphon]]

Adamcolton at 13:34, 15 October 2019

2019-10-15T13:34:07Z

← Older revision		Revision as of 13:34, 15 October 2019
Line 41:		Line 41:
	is		is
	method Bar{ctxIn {f Foo; a,b int}; ctxOut{c int}}		method Bar{ctxIn {f Foo; a,b int}; ctxOut{c int}}

			If we treat func args as a struct, then the order either becomes optional or entirely goes away with named
			square := <x float> -> {<- x*x}
			square{x:10}

	[[Category:Gryphon]]		[[Category:Gryphon]]

Adamcolton at 14:21, 2 October 2019

2019-10-02T14:21:50Z

@@ Line 18: / Line 18: @@
 Assuming Gryphon allows only a single return, then the most common case would be (like Rust) a tagged union with errors. If the errors are specific, we can create a list of all the possible errors.
-== Closures ==
+== Curry Closures ==
-I'm considering not allowing closures. The same thing can be accomplished with anonymous structs:
+I think closures are a bad idea - they are a good source of errors and complicate what data a function has access to.
-So the receiver on a method can accept anonymous context.
+Instead I want to use currying.
 == Inline ==
@@ Line 58: / Line 31: @@
 Of course, a function only called from one place should always be inlined.
 [[Category:Gryphon]]

Adamcolton at 17:40, 23 September 2019

2019-09-23T17:40:43Z

← Older revision		Revision as of 17:40, 23 September 2019
Line 51:		Line 51:
	}		}

	So the receiver on a method can accept anonymous context.		So the receiver on a method can accept anonymous context.

			== Inline ==
			The compiler should be able to make an informed decision about inlining function calls. We may want a compiler flag to help tweak the threshold (setting the desired balance between performance and size).

			Of course, a function only called from one place should always be inlined.

	[[Category:Gryphon]]		[[Category:Gryphon]]

Adamcolton: Created page with "== Basics == A function takes some argument and may return a value (or multiple values). == Multiple Returns == Not sure about these, there's an elegance to only allowing a s..."

2019-09-23T16:08:21Z

Created page with "== Basics == A function takes some argument and may return a value (or multiple values). == Multiple Returns == Not sure about these, there's an elegance to only allowing a s..."

New page

== Basics ==
A function takes some argument and may return a value (or multiple values).

== Multiple Returns ==
Not sure about these, there's an elegance to only allowing a single return type. With the tagged unions, it's not necessary the way it is with go.

== Implicit Attributes ==

=== Pure ===
A pure function has no side effects. A pure function invoked with static arguments can be statically replaced at compile time.

Unsafe libraries can override this. The use cases are logging and memoization.

=== Async ===
If a function can cause a wait operation it is async. This is implicit to avoid the "what color" problem.

=== Error Types ===
Assuming Gryphon allows only a single return, then the most common case would be (like Rust) a tagged union with errors. If the errors are specific, we can create a list of all the possible errors.

== Closures ==
I'm considering not allowing closures. The same thing can be accomplished with anonymous structs:
func curryAdd(a int) func(b int) int{
return func(b int) int{
return a+b
}
}

// explicit
type curryAddStruct struct{
a int
}
func (cas curryAddStruct) add(b int) int{
return cas.a + b
}
func curryAdd(a int) func(b int) int{
return curryAddStruct{a}.add
}

// anonymous
func curryAdd(a int) func(b int) int{
return func(cas {a:a} struct{a int}) _(b int) int{
return cas.a+b
}
}

// very anonymous
func curryAdd(a int) func(b int) int{
return func(a) _(b int) int{
return a+b
}
}

So the receiver on a method can accept anonymous context.

[[Category:Gryphon]]