trylon/Notes at master · stevefolta/trylon · GitHub

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
Field Codegen Bug
	[2007.8.31]

	trylon main

	fields my-field

Classes can see "my-field" (which is correct), but the codegen is a field access, when it should be a send to the "Main" proto.  "emit-c-call:builder:" methods of FieldGetter and FieldSetter need to be fixed.  [Fixed 2007.9.1]

To optimize field access, "MethodContext lookup-function:" would need to explicitly check fields before checking for function calls on "this".  But that's not semantically safe, as a subclass could override the getter and/or setter.

=====

64-Bit
	[2008.10.25]

Can't use setjmp()/longjmp() to pass the exception object, as they only pass an "int", not a "long".  This is easily fixed by only passing 1 there, and using a global to hold the exception value.  That's not thread-safe, but our exception chain isn't thread-safe currently either.

ClassInfo stores size in bytes, rt number of fields.  That doesn't work when the generated C code is moved between 32 and 64 bit platforms.

Int should go to 64-bit on 64-bit platforms... but that probably won't be necessary to make it work.


=====

New Parser Bug
	[2007.10.19]

Current crash is due to a problem with precedence.  Need to separate assignments from other binops:

	foo = quux bar: baz

currently parses as:

	(foo = quux) bar: baz

The old parser doesn't have that problem, but at the expense of not being clean about its syntax.  It ought to be fixed before the Trylon 2 release (assuming we don't switch to the new parser).

New precedence:

	,
	=, +=, etc.
	||
	&&
	!
	keyword:
	|
	^
	&
	==, !=
	<, >, <=, >=
	<<, >>
	+, -
	*, /, %
	unary+, unary-, ~ 	[Used to have !.]
	unary send
	primary

Tests:

	foo: bar && !bar: baz
	foo: x | 0x03


=====

To Do
	[live]

Lambdas.
Field access optimization.  Strictly optional, since even in constructors we can't be sure we aren't dealing with a subclass that overrides the getter and/or setter.  But it might be a helpful optimization for those who know what they're doing.