-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
client side construction of l:href and l:action #1134
Comments
As @slindley pointed out one perfectly rational reaction to this issue is to say let's just get rid of the l:attribute stuff (or at least, make it a run-time error to do the above strange things so that unwary users know that they are intentionally not supported.) I don't mind that but it would then be nice to port the examples and tutorial programs that use l:attributes to use something else, e.g. MVU. In my somewhat limited experience, the existing l:attribute stuff, albeit clunky, looks familiar enough to students already familiar with conventional web programming that they can get going fairly fast, even if there are nontrivial limitations on what you can do. |
Following #1133 we can now place client and server annotations on local functions, but this does not seem to suffice (or if it does, it is masked by another bug). Here is a simpler example that does not rely on non-local variable references in functions:
This works correctly (after clicking on the link/button added by replaceNode, the value 42 appears). However, if we move the snippet functions into
yields the same "before server is ready" error. |
Hmm. I wonder if the problem may be something like this. In jslib, when a function call is encountered the following gets run: Lines 1675 to 1685 in 0605152
so, when a function call is being sent to the server, any function not marked server gets treated as a client call. I think this may be happening with the local functions introduced by l:attribute calls, which may be being placed somewhere different when the snippets are local functions vs. when they are top-level ones, since the local functions occur syntactically within a top-level client function, even if they are then nested inside a local function that's marked server. Presumably after closure conversion and lifting, these additional local functions become unmarked top-level functions. So perhaps explicitly adding server annotations to them in desugarLAttributes will fix this.
|
Well, looking at desugarLAttributes it seems that the local functions created during desugaring for l:href and l:action are already being tagged as server functions, so there must be some other problem. |
As mentioned in
desugarLAttributes.ml
(written around 7 years ago):handling
l:href
andl:action
in client-side XML is not thought to work. This issue was tripped over in other places (#219) where it originally seemed to be related to a problem withreplaceNode
, but that problem now seems to have been fixed by fixing client-side closure calls. The following example illustrates that desugaring of these attributes on the client side does not work properly:since if the l:action or l:href bodies are called (after first replacing the content so they appear in the web page) you get an error like this:
which I think is happening because the local functions constructed after are not marked
server
and so the client is sending a request to perform a client-side function to the server as a continuation, which does not work since the web page and (new) client environment isn't initialized yet.However, by manually eta-expanding, lambda-lifting, and hoisting the computation of the first argument of
replaceNode
to top-level functions the desired behavior can be made to work:Hoisting to the toplevel is necessary because currently in Links client and server annotations are only allowed on top-level functions, and there is no way to directly provide the local functions that gets created when
l:href
orl:action
are desugared, but ensuring that they are desugared inside the body of aserver
function seems sufficient. However, it may be possible to do this more directly, by modifyingdesugarLAttributes.ml
so that the local functions created during l: attribute desugaring inherit the server environment.The text was updated successfully, but these errors were encountered: