I already have an implementation for this, so it’s not urgent. What is the best way to specify the library of built-ins for some language L?

1. In the easy case L has something struct-like and imports and one can declare the built-ins as a library that gets automatically imported. The drawback is that unless the compiler actually needs this for code generation it is cumbersome to always have this standard library available. It’s also unclear whether one could import this source file from the compiler archive (jar) without requiring it locally in the project.

2. Many languages, e.g. GM, have neither imports nor structs. How do we specify libraries for these languages?

2a. In GM i use the task-match mechanism to match for built-in functions with an API example like this:

	signature constructors
	
	  BuiltInArgTypes: Relation	
	  BuiltInTypeOf: Relation
	  
	rules
		
		gm-task-match:
		  (BuiltInArgTypes(), lookup@(type, graph-ty, name)) -> <builtin-arg-types> lookup
		
		gm-task-match:
		  (BuiltInTypeOf(), lookup@(type, graph-ty, call-args, name)) -> <builtin-ret-type> lookup
		  
		
		builtin-arg-types:
		  (type, graph-ty, name) -> arg-ty*
		  where
		    arg-ty* := [ [] ];
		    fail
		
		builtin-ret-type:
		  (type, graph-ty, call-args, name) -> return-ty
		  where
		    return-ty := [];
		    fail

And a concrete example:

  builtin-arg-types:
    (NodeTy(_) , DGraphTy(), "NumInNbrs") -> [ [ ] ]
  builtin-ret-type: 
    (NodeTy(_),  DGraphTy(), [], "NumInNbrs") -> IntTy()

This works very well in terms of the type system but is lousy in terms of editor services. For example completions and resolutions are not working.

2b. An alternative would be to specify things are implicitly defined in NaBL. This is:
(a) very verbose
(b) required in two places (implicit definition & references)
(c) completions would work
(d) resolution would be weird (maybe resolution should be disabled for implicits anyway?)
(c) suspect tricky to express overloaded built-in functions because the NaBL rules have to be mutually exclusive
(d) probably even trickier to express the priority of coercions in the choice of the overloaded function

So, how should built-in things be specified?

Submitted by Vlad Vergu on 11 July 2013 at 19:29

2a. Thanks to multi file support, you can have standard libraries in a separate file, but need some syntactic extension to get them into global scope. This approach is clearly limited and I don’t like it.

2b.
(b) Definitions should be sufficient, if you merge them into regular namespaces.
(d) please make a separate issue (valid, independent point)
(c) you can have multiple implicit definitions in one rule. The approach here is probably to have all built-ins implicitly defined in global scope or at the outermost scope level.
(d) should be as tricky as for non-built-in functions.