Comments (4)
So here's what I was thinking for how one would bridge untyped function references (i.e. funcref
) and typed function references.
First, have an instruction like get_callee $ct : [funcref] -> [(ref (func (param ti*) (result to*)))]
, where call_tag $ct : [ti*] -> [to*]
. This takes a funcref
and returns the typed function reference it would call if given call tag $ct
.
Note that, with func_switch
(I renamed dispatch_func
, and I'm still open to suggestions), the typed function reference resulting from get_callee
might not be the same reference as the untyped function reference. And with the ability to define a function with no call tags, it might not make sense to expect typed function references to have a corresponding untyped function reference (if someone makes a funcref
using its index, the engine could just provide some singleton funcref
that always traps). Plus, even without call tags, we already know that an indirect call to a typed function reference might not succeed even with the signature of its type.
These observations suggest to me that typed function references and untyped function references are distinct kinds of values, and consequently there's no subtyping relationship between these types. This observation is in line with the research on mixing sound typed and untyped functions. It also means that a typed function reference can be simply a pointer to assembly code that expects arguments of the given type and returns values of the given type.
from call-tags.
Ok, makes sense. It looks like the main difference is the broader question about function reference subtyping.
from call-tags.
Possibly. As I said, you can have both if you really want to.
from call-tags.
Hmm, I came across another way to look at the difference between rtts and call tags.
Rtts are positive tags whereas call tags are negative tags. That is, the differ in who first commits to choosing what the cast should be and who can switch on that choice. With rtts, the castee first commits, and the caster can switch on that choice. With call tags, the caster first commits, and the callee can switch on that choice.
Interestingly, since most types are positive, it seems to turn out that positive tags are the better fit for most data. But as functions are negative, it seems to turn out that negative tags are the better fit for them. I can't explain why that is, but it's an interesting observation.
Either way, this suggests that rtts and call tags really are distinct concepts, which makes me concerned that attempts to combine them into one will not fair well.
from call-tags.
Related Issues (4)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from call-tags.