Failed to use source built-in methods after calling method that uses source

[vitoyucepi]

Describe the bug
After calling methods that uses source as argument such as source.id methods of source become unavailable.

To Reproduce
Code sample

def test(src)
	sourceId = source.id(src)
	src.on_track(fun(metadata) -> print(metadata))
	print(sourceId)
end

generates error

Error 5: this value has no method on_track

But this is valid

def test(src)
	src.on_track(fun(metadata) -> print(metadata))
	sourceId = source.id(src)
	print(sourceId)
end

Expected behavior
No error dependent of function call order.
Btw, I've find out that I can call src.id() and there will be no errors.

Version details

• OS: ubuntu:20.04 in docker
• Version: 2.0.0-beta.3

Install method
Deb package from liquidsoap releases at github

Common issues
N/A

[toots]

That's definitely another type inference issue here. Let me try to explain.

Since 2.0.0, sources have methods, so here's a typical type for a source:

# s = single("/tmp/bla.mp3");;
s :
  source(audio=?A, video=?B, midi=?C)
  .{
    time : () -> float,
    shutdown : () -> unit,
    fallible : bool,
    skip : () -> unit,
    seek : (float) -> float,
    is_active : () -> bool,
    is_up : () -> bool,
    log :
    {level : (() -> int?).{set : ((int) -> unit)}
    },
    self_sync : () -> bool,
    duration : () -> float,
    elapsed : () -> float,
    remaining : () -> float,
    on_track : ((([string * string]) -> unit)) -> unit,
    on_leave : ((() -> unit)) -> unit,
    on_shutdown : ((() -> unit)) -> unit,
    on_metadata : ((([string * string]) -> unit)) -> unit,
    is_ready : () -> bool,
    id : (() -> string)
  }

Now, it can happen that those methods can be "lost", for instance by adding type annotation:

# s = (single("/tmp/bla.mp3"):source);;
s : source(audio=?A, video=?B, midi=?C)

You will notice that, in the first case, the source s has a id() method. In the second case, that method is lost.

However, the method is still available internally so it is technically still possible to get the source's id, which is why (for now), we are keeping the source.* operators. Here's the type for source.id:

# source.id;;
- : (source(?A)) -> string = <fun>

So, the idea is to use this operator when you are dealing with sources with no methods.

However, this creates an annoying situation in case of type inference. Indeed, if you look at the function:

1: def test(src)
2: 	sourceId = source.id(src)
3: 	src.on_track(fun(metadata) -> print(metadata))
4: 	print(sourceId)
5: end

At line 2, src is inferred to be of the type source('a), that is a source with no method. Then, line 3 gives the expected error.

On the contrary, with:

1: def test(src)
2: 	src.on_track(fun(metadata) -> print(metadata))
3: 	sourceId = source.id(src)
4: 	print(sourceId)
5: end

At line 2, src is inferred to be any value with a method on_track and, on line 3, this value is inferred to be a source('a) and it works.

Another way to write this function that works with both lines would be:

1: def test(src)
2: 	src.on_track(fun(metadata) -> print(metadata))
3: 	sourceId = src.id()
4: 	print(sourceId)
5: end

This will work even if you switch the lines around.

I'll leave this open to see if @smimram has some ideas about how we could make this better.

[vitoyucepi]

radio=single('sample.ogg')
air = input.harbor(someSettings)
full = smooth_add(p = 0.15, normal = radio, special = air)

print(full.remaining())
print(source.remaining(full))

-2.26757369615e-05
inf

[toots]

radio=single('sample.ogg')
air = input.harbor(someSettings)
full = smooth_add(p = 0.15, normal = radio, special = air)

print(full.remaining())
print(source.remaining(full))

-2.26757369615e-05
inf

The value discrepancy was just fixed with: e9adaf1 😅

[smimram]

Another solution consists in explicitely stating that src is a source with the usual methods (it has the type source_methods). This works fine:

def test((src:source_methods))
	sourceId = source.id(src)
	src.on_track(fun(metadata) -> print(metadata))
	print(sourceId)
end

[toots]

Thanks @smimram. I'm moving this to a discussion since it seems that we won't be making any change based on it for now.