How to extend known global records?

[qEagleStrikerp]

Hi there,
I'm currently working on a Teal script for Final Fantasy XI's Windower. Most things have worked so far, however, Windower globally extends the Lua coroutine module, and I haven't figured out how to declare this in Teal yet.

From the Windower Wiki:

Furthermore, two functions are added to the coroutine table:

coroutine.schedule(fn, time)

• fn function - Function to be scheduled
• time number - Time in seconds when fn is supposed to be run

Executes fn delayed by time seconds. Returns the scheduled coroutine.

coroutine.sleep(time)

• time number - Time in seconds

Sleeps the current evaluation for the given period of time.

I tried declaring it in windower.d.tl like so:

global record coroutine
    schedule: function(fn: function, time: number): thread
    sleep: function(time: number)
end

but unfortunately, Teal does not recognize the functions this way. What is the correct way of declaring them?

Thanks in advance!

[lenscas]

You can't really extend one type like this. See #532 and #1104

What you should be able to do is disable the entire STD and then load a .d.tl file which defines everything again, including the changes you need.

[qEagleStrikerp]

You can't really extend one type like this. See #532 and #1104

What you should be able to do is disable the entire STD and then load a .d.tl file which defines everything again, including the changes you need.

@lenscas Thanks for linking the appropriate PR. Unfortunately, I haven't gotten it to work yet and it seems I'm missing something trivial. I recompiled the current Teal repo and can confirm via command line that the --no_stdlib option is available now. I then copied the contents of tl/teal/default/stdlib.d.tl into my windower.d.tl. Now it seems there are some issues related to the prelude:

./windower.d.tl:79:34: unknown type metatable<T>
./windower.d.tl:82:27: unknown type userdata
./windower.d.tl:90:33: unknown type metatable<T>
./windower.d.tl:98:47: unknown type userdata
./windower.d.tl:382:34: unknown type metatable<T>
./windower.d.tl:415:33: unknown type metatable<T>

Did I miss something? From reading the PR comments I thought that the prelude is always loaded, even with the --no_stdlib option turned on.

Edit: Hold on a minute. It may be possible I broke tl.exe when compiling it myself. I'm gonna try re-compiling it under WSL this time and check back.

Edit 2: Alright, I re-compiled it under WSL, still getting the same error. There seems to be a bit more going wrong though. Setting no_stdlib = true in tlconfig.lua causes Teal to behave strangely, e.g. require("some_file") doesn't do anything anymore, even if the prelude and the stdlib are completely copy-pasted into the global declaration file. Maybe some core feature isn't being loaded?

[mbartlett21]

You can do it through a macroexp, so that the final output uses your global, but the teal input is still named something else:

global record coroext
    schedule: function(fn: function, time: number): thread = macroexp(fn: function, time: number): thread
        return (coroutine as {any:function}).schedule(fn, time) as thread
    end
    sleep: function(time: number) = macroexp(time: number)
        return (coroutine as {any:function}).sleep(time)
    end
end

local th = coroext.schedule(print, 1234)
coroext.sleep(123)

=>

...
local th = (coroutine).schedule(print, 1234)
(coroutine).sleep(123)

playground

[qEagleStrikerp]

You can do it through a macroexp, so that the final output uses your global, but the teal input is still named something else:

@mbartlett21 Thanks for the idea, that's certainly a good workaround.

I also found another workaround that makes use of a re-export of coroutine to add the additional methods:

windower_coroutine.lua:

return coroutine

windower_coroutine.d.tl:

global record WindowerCoroutine
   type Function = function(any...): any...

   close: function(thread): boolean, string
   create: function(Function): thread
   isyieldable: function(): boolean
   resume: function(thread, any...): boolean, any...
   running: function(): thread, boolean
   status: function(thread): string
   wrap: function<F>(F): F
   yield: function(any...): any...

   -- Windower specific
   schedule: function(fn: Function, time: number): thread
   sleep: function(time: number)
end

return WindowerCoroutine

Then, in main.tl (or wherever you want to use it):

local w_coroutine = require("windower_coroutine")
w_coroutine.schedule(print, 30)
w_coroutine.sleep(30)

Since coroutine is re-exported by windower_coroutine.lua, we can name it however we want now. I'll probably stick with that solution for now since I like it more than redefining the standard library.

Still, I'd be interested to know if the manual re-defining of the standard library approach works if anybody has gotten it to work.

[Aire-One]

The way intended to use the --no-stdlib flag to extends the global standard library is to combine it with the --global-env-def option.

From main branch after sudo luarocks install tl-dev-1.rockspec, tl --version yields 0.25.0-alpha+dev:

-- main.tl

print("Hello, World!")

coroutine.sleep(5)

-- windower-std.d.tl

local record StandardLibrary
   print: function(any...)
end

global print <const> = StandardLibrary.print

global record coroutine
    schedule: function(fn: function, time: number): thread
    sleep: function(time: number)
end

tl check --no-stdlib --global-env-def windower-std main.tl
========================================
Type checked main.tl
0 errors detected -- you can use:

   tl run main.tl

       to run main.tl as a program

   tl gen main.tl

       to generate main.lua

or with a tlconfig.lua file:

-- tlconfig.lua

return {
   no_stdlib = true,
   global_env_def = "windower-std",
}

Note: This is a minimal example, you'll have to copy/port more (all?) of the teal/default/stdlib.d.tl definitions to the custom windower-std.d.tl in order to make the full standard library available to teal.

[qEagleStrikerp]

Note: This is a minimal example, you'll have to copy/port more (all?) of the teal/default/stdlib.d.tl definitions to the custom windower-std.d.tl in order to make the full standard library available to teal.

@Aire-One that's exactly what I did. I copied the whole contents of teal/default/stdlib.d.tl into windower.d.tl. However, as described above, when configuring tlconfig.lua with no_stdlib = true and global_env_def = "windower", the prelude is not loaded anymore. Also, other things break such as require. See this earlier post

[Aire-One]

@qEagleStrikerp Yeah, it does seem like a broken build. Prelude should be part of the final build result and is always loaded regardless of the no-stdlib parameter. I can confirm copying the full stdlib.d.tl and adding the extensions from first post works as expected on my side.

What was your build and install steps? Maybe you can try to completely uninstall teal and reinstall using luarocks and the development rockspec with sudo luarocks install https://raw.githubusercontent.com/teal-language/tl/refs/heads/main/tl-dev-1.rockspec

[qEagleStrikerp]

@Aire-One

For building the Windows executable, I did (on WSL):

git clone https://github.com/teal-language/tl.git
cd tl
chmod +x extras/binary.sh
./extras/binary.sh --windows

I installed in on Linux with luarocks just like you described. This is what's currently happening:

Windows executable:

• prelude is not being loaded
• require breaks

Linux via luarocks:

• prelude is being loaded properly
• require still breaks

Regarding require: It literally has no effect anymore. So, any file that has some requires at the top that were working properly before, now throws errors due to missing definitions. Commenting out those requires produces the exact same errors so it's as if the lines with require are being ignored completely. Setting no_stdlib to false reverses those problems.

[hishamhm]

[on Windows] prelude is not being loaded

Not sure what's going on here 🤔

require still breaks

@Aire-One Looks like we need to factor out the set_special_function calls out of environment.construct? At first glance, it looks like we will need something like a --std=<module> that requires the module and applies the "special function magic", instead of just reusing --global-env-def.

[holy-filipp]

[on Windows] prelude is not being loaded

Not sure what's going on here 🤔

require still breaks

@Aire-One Looks like we need to factor out the set_special_function calls out of environment.construct? At first glance, it looks like we will need something like a --std=<module> that requires the module and applies the "special function magic", instead of just reusing --global-env-def.

Hello, now I'm encountered a same problem. When no_stdlib is set to true in tlconfig.lua, standard require function is completelly broken.

[Aire-One]

[on Windows] prelude is not being loaded

Not sure what's going on here 🤔

require still breaks

@Aire-One Looks like we need to factor out the set_special_function calls out of environment.construct? At first glance, it looks like we will need something like a --std=<module> that requires the module and applies the "special function magic", instead of just reusing --global-env-def.

Hello, now I'm encountered a same problem. When no_stdlib is set to true in tlconfig.lua, standard require function is completelly broken.

Yeah sorry about that. I confirm this is an issue with the current implementation. My bad. I haven't managed to free enough time to work on it.

[holy-filipp]

[on Windows] prelude is not being loaded

Not sure what's going on here 🤔

require still breaks

@Aire-One Looks like we need to factor out the set_special_function calls out of environment.construct? At first glance, it looks like we will need something like a --std=<module> that requires the module and applies the "special function magic", instead of just reusing --global-env-def.

Hello, now I'm encountered a same problem. When no_stdlib is set to true in tlconfig.lua, standard require function is completelly broken.

Yeah sorry about that. I confirm this is an issue with the current implementation. My bad. I haven't managed to free enough time to work on it.

I’d be delighted if you could find the time to look into teal. I wanted to write some code in teal for cc: tweaked, but I found that the types in the standard os library override the os types from cc: tweaked, which are specified in the .d.tl file.

[holy-filipp]

Is it possible to implement type merging in Teal, as in TypeScript?

Example in TypeScript:

declare global {
  interface String {
    reverse(): string;
  }
}

export {};

[qEagleStrikerp]

Is it possible to implement type merging in Teal, as in TypeScript?

That would actually be the most elegant solution, in my opinion. No re-export of the standard library necessary, and there's more than a few libraries out there who extend types like this:

function string.contains(str, sub)
    return str:find(sub, nil, true) ~= nil
end

This is currently impossible to properly implement in a d.tl file because this is a script that you load with require("strings") so changing the standard library with a global declaration file is actually incorrect since these extension methods only are available if you require them.