func aaa(int x) int { ... ref own SomeType st = new # allocates outside of arena (inefficient), (but the compiler could optimize it) ... st.free() ... } # need to know if the arena allocator is shared among threads ("threaded" attribute) # 1. for locking # 2. for optimizing temporary allocations # for number 2 we also need to know if the arena object is aliased ("aliased" attribute)... # # object orientation... it should be possible to assign functions # to types func bbb(ref arena SomeType st) { ... ref SomeType st2 = alloc # allocates in arena (requires SomeType to be public) ref SomeType st3 = .create() # constructor allocates (in arena of st; st is passed a as a parameter) ... } type SomeType = struct { int x } # this function takes an implicit arena parameter. # the identifier created in the typescope of SomeType. func .create() SomeType alloc { ref SomeType obj = alloc obj.x = 123 return obj } # this function takes an implicit "this" reference, which is const (the default) func SomeType.bbb() # this function takes an implicit "this" reference, and may modify the object func SomeType.bbb() var # FIXME how about returns?? func SomeType.bbb() var var OtherType func SomeType.bbb() var -> var OtherType # Have built-in "functional programming" / streaming array/list/iterator operations? # FIXME: consider using a more newbie-friendly syntax, either [2*x for x in src] # or changing the "map" keyword to something more descriptive to newbies? func test(ref [10]int src) -> [10]int { # TODO =/== or :=/= ? bool has_zero = src has (x -> x == 0) return src map (x -> has_zero ? 2*x : x) } # Operations that modify the list size are trickier # FIXME also, having two types of arrays could be confusing for the user. # - can we have built-in types for this instead? func test2(ref Iter src) -> List { # filter is applied first, then map return src filter (x != 2) map (x -> 2*x) } # C compatibility - linknames type SomeType linkname "st_" = struct { int x } # C compatbility - avoiding implicit arena pointer, and managing ownership # C declaration: "struct SomeType *st_new();" func .new() noarena -> own var SomeType # private and incomplete types type SomeType = private type SomeType = incomplete struct { ... } # "virtual" types/parameters? (not related to C++ virtual) #type Lock = struct { ... } #type LockTicket = virtual #func Lock.lock() var threaded -> virtual LockTicket #func Lock.release(virtual LockTicket lt) var threaded # typestates (nicer than virtual parameters) type Lock = struct { ... } typestate Lock { noforget Locked, Available } # only one type state in a typestate group can be active at a time. func Lock.lock() var threaded [[Available]] -> [[Locked]] # it is still a void return type func Lock.release() var threaded [[Locked]] -> [[Available]] # how can we declare that the Lock object should not be left indefinitely in the "Locked" state? # perhaps a virtual variable? but it needs to come from the SAME lock! (or does it?) # - "noforget" states. It is required to, for each code path, to either: # - leave to "noforget" state in the code path, or # - declare the state transition (if the object in the transition is visible to the caller), or # - yield another "noforget" state, and leave the "noforget" in each non-"noforget" state in the same group as the yielded state. # FIXME terminology. # - must Available / must Closed # - noleave Locked / noleave Open (but leave has two meanings in English, to "forget" and to "leave an area (etc.)") # - noforget Locked / noforget Open # Should we require "." in front of things in the typecope or not? # language version specifiers: # (require it at the beginning of each file?) # it serves two purposes # 1. keeping old source files working unmodified with newer compiler versions # 2. detection of usage of new language constructs that are not supported in the targeted version susl 0.1 # translatable code documentation! # (and human-readable translated identifier names?) # codedoc/en.suslcd [func Lock.lock] Name: Lock Description: Locks the lock. Any other threads that try to lock while the lock is locked will wait for the lock to be released, and one at a time they will lock the lock. There is no queue ordering for waiting threads. # codedoc/sv.suslcd [func Lock.lock] Name: Lås Description Låser låset. Eventuella andra trådar som försöker låsa låset under tiden när det är låst kommer att vänta tills låset släpps, och en åt gången kommer få låsa låset. Det finns ingen köordning för väntande trådar. # How to prevent cycling own pointers? or cyclic arena-owner references? # - Require that the new owner is not owned by the object