functions accepting dynamically typed values

[gavinking]

So the new dynamic blocks let me mix typed and untyped expressions together and can even contain declarations whose type is "dynamic". The way this works is by distinguishing between expressions and declarations which have a type, and expressions and declarations which don't. There's no Dynamic type breaking the whole type system with special-case assignment rules, rather we just accept that we don't know the type, and, because we're in a dynamic block, we suppress the usual errors that would result from that.

For example:

dynamic {
    value x = foo + bar;
    function f() => x;
}

Since foo and bar have no type, x and f() also don't have types. But the syntax of the language gives us no way to do the equivalent thing with a function parameter. So I think we should support the following syntax, only inside a dynamic block:

dynamic {
    value x = foo + bar;
    function f(value z) => z else x;
}

But this does raise the question of whether we should allow toplevel dynamic blocks, in order to have untyped toplevel declarations.

[chochos]

I think the only use for untyped functions is to use them inside the dynamic block and also to pass them to js code such as jQuery; why would we need to have top-level untyped functions?

[gavinking]

This one is implemented. Was rather trivial.

[gavinking]

why would we need to have top-level untyped functions?

Well, if you wanted to have a function you call from methods of several different classes, that all have dynamic blocks. The issue is that dynamic currently limits code reuse. But in fact just allowing toplevel dynamic blocks would not even solve the problem, now that I think about it....

[RossTate]

dynamic {
    value x = foo + bar;
    function f(Object z) => z else x;
}

There's no need to say value z instead of Object z. In fact, they could say Integer z if they wanted and that would let them know that f will only be (successfully) called with integer arguments. It would also let the part after the dynamic clause to know that f is a function from Integer to Integer.

Since foo and bar have no type, x and f also don't have types.

They all have types. dynamic does not mean things don't have types; it only means that operations which static type information cannot guarantee safe will be checked at run time. In particular, in this case we know f is a function, and we can safely use it like so after the dynamic block.

[chochos]

what if it's a function you're planing to pass to a js object? it doesn't need to be typed and could in fact become unusable outside by adding these restraints. I think it's valid to define dynamic parameters.

[RossTate]

You'd just say function f(Anything z) => z else x. This imposes absolutely no constraints on the parameter of f.

[gavinking]

@RossTate Ross this is something we have been discussing, but right now we do not consider a "dynamic object" to be an Anything. That's because Anything is an enumerated type of Object|Null, and a dynamic object is not safely an Object. Now, perhaps @chochos and @ikasiuk can figure it out so that it could be safely assigned to Object but for now it is not.

[gavinking]

They all have types. dynamic does not mean things don't have types

On the contrary, in the JavaScript environment, objects really don't have types! JavaScript is absolutely not Smalltalk/Python/Ruby where things don't have static types but they do have a type you can discover at runtime. In JavaScript they really don't have types.

[RossTate]

That's because Anything is an enumerated type of Object|Null.

If so, then Ceylon is gonna have major problems cleanly interacting with backends. This is where your problem with Singleton(foo) in #604 comes from. There's no real benefit to having Anything be Object? from what I can see, only lots of disadvantages.

As for JavaScript objects not having types, all values have types. These types may not look like what you're used to, but they have types. So, as I say in #604, you could just say that objects with no type tag then have type JSObject.

Lastly, and again, dynamic does not mean JavaScript. dynamic can be a useful feature even in a (typically) statically typed language not compiling to JavaScript or some other dynamically typed back end. It can be used to indicate "Trust me; I know what I'm doing" or "Leave me alone type checker; I'll deal with you later".

[gavinking]

If so, then Ceylon is gonna have major problems cleanly interacting with backends.

I strongly disagree. I don't think we have any insurmountable problem here.

you could just say that objects with no type tag then have type JSObject.

We could do that, and we might eventually wind up doing that, but for now I honestly just don't see enough benefit to doing it.

Lastly, and again, dynamic does not mean JavaScript.

Sure, but it needs to mean something with semantics sufficiently compatible with JavaScript that we can take a piece of code using dynamic and run it portably across both backends.

[RossTate]

Sounds good. The one immediate action item I would say, then, is to make Anything not of Object|Null. That will leave us forwards compatible with the extensions I'm talking about, and anything it breaks should be easily fixable by more accurately stating Object? when that's expected.