Style guide for std.<language>?

[dospunk]

A style guide for implementing the standard library would be helpful, especially specifying a way to make variables and functions that are not currently in std.c or std.go.

For example, I'm working on a TypeScript backend right now. One thing I'm working on implementing is the ability to choose between printing with console.log or printing to an HTML element. Right now I've implemented this by putting these lines at the top of std.ts

const OAK_TS__PSEUDO_CONSOLE = document.getElementById("oak-out");

function OAK_TS__PRINT(x: any){
	if(OAK_TS__PSEUDO_CONSOLE) OAK_TS__PSEUDO_CONSOLE.innerHTML += x;
	else console.log(x);
}

I guess this is also my proposal for naming these functions/variables. OAK_<file extension of the language>__<name of function or variable>

[adam-mcdaniel]

Writing a document on implementing the standard library is a great idea. I have plans to start writing one within the next day or two. Until then, you could look at this example if you want to see how to use foreign functions not provided by the Target implementation. In short, if you use the extern flag to specify the foreign file you want to include, you can call a foreign function by calling the function as if it were a regular Oak function, but with an ! symbol after the identifier. So, calling a foreign function test would look like test!().

[dospunk]

I could implement printing to an HTML element as an external library, but my concern is that that would make code written for the TypeScript target incompatible with other targets, and code written for other targets much less useful when built with the TypeScript target.

[adam-mcdaniel]

An external library would probably be the way to do it. Then, you can use an Oak file with conditional compilation to guard against using the function without the TS backend.

[dospunk]

That would fix the first problem, but the second problem still stands. To get output displayed on the page for any Oak program not written specifically for the TS target, one would either have to

• redefine console.log in their JavaScript
• redefine the standard library print functions in Oak
• or modify the file to use the new external function instead of Oak's print functions

None of these are particularly desirable solutions

One possible solution would be an option to mark a target as Graphical, so that the standard library could be kept consistent and a new standard graphical library could be created that only needs to be implemented for Graphical targets. That might get into the realm of scope creep though.

[kevinramharak]

Hm, i don't fully understand the problems here. All the stdlib spec has to do is define a function that allows the programmer to print to stdout. Your standard library then implements this by appending the output to an HTMLElement right?

[dospunk]

That's my current implementation, and it works pretty well so far. My original request was for a standard way of naming variables/functions in std.<targetlang> that are meant to be helper functions only used within the standard library because my current implementation benefits from them. I believe what Adam was suggesting was that I implement printing to an HTMLElement as an external function instead of including it in the stdlib, since conditionally printing to a graphical component or the console is nonstandard behavior for the print functions in the stdlib (prn, prs, prc, and prend) and it would remove the need for the helper variables/functions. My concern is that this would limit the portability of Oak code between the TypeScript target and console-based targets, and vice-versa. @adam-mcdaniel please correct me if I've misunderstood.

[kevinramharak]

Hm, how would that limit portability? I think it all depends on what the program intention is. If i write a program and stdlib spec says that print prints to stdout, i would expect it to print to the the console in a javascript environment. Unless ofcourse your target specificly states that it uses a different kind of stdout.

For example lets assume the oak stdlib has the following function:

fn print(str: &char) -> void;

An oak program uses that function as followed:

fn main() {
     print("hello world!");
}

Then it is up to your implementation to define what stdout is and implement the print function. If your implementation defines an html element as stdout that should be fine. If it defines stdout as the stdout in a command line that is just as correct.

// implementation detail
function print(str: string) {
   console.log(str);
}
// implementation detail
function print(str: string) {
   const el = document.querySelector('#console');
   el.innerHTML += str;
}

Tough if the Oak program specificly wants to write to an HTMLElement than an external function that implements an interface for this would be more appropiate.

[dospunk]

Whoops, didn't mean to close this.

I guess it does make sense to just choose one or the other as stdout. Thanks for the feedback!