blackvegetable / rackettypeprovider Goto Github PK

I have been told that macro hygiene can be used to handle the problem where elements and attributes can have the same name. If so, this could be used to remove the ugly $ prefix for attributes and $$ prefix for the content attribute. I'm unsure how much work is involved here. If someone knows more about this topic, please chime in.

Ideally, the Type Provider tool should not be looking for the exact macro call and filepath to perform its work. The Type Provider's use should follow from a #lang declaration. Anyone with some pointers on how to accomplish this, please chime in.

When the Type Provider produces the structs for each element, information about the contents of the edit-time data's field's types could be saved in some fashion. Later, when the auto-complete displays attribute names, it could also display the types that the edit-time file found associated with those fields.

This could be a little tricky if values of different types are found for the same attribute names within different elements of the same name. (This is not a contract violation.) This should be resolved by displaying up to two* types found for that field, or "many-types" for more.

Example:

name : string
salaried : boolean
hired : string or boolean
extra_info : many-types
content : element

Currently, when XML data files are to be used by the TypeProvider, tool.rtk expects them to be in the /Racket folder. This is because the runtime relative path for the GUI is the /Racket folder. (Alternatively, an absolute path could be used to specify the exact location of the file.)

An ideal solution would somehow let tool.rkt determine the runtime path of the file currently being modified and use that for resolving the relative path of the data file.

It would be nice to refactor the existing code base into XML specific Type Provider code and code that applies to all Type Providers. This would allow others to reuse a pattern to construct their own Type Providers to handle any data they'd like. This will likely be a lot of work, but should be very valuable to the language as a whole.

Currently, after the Type Provider hotkey is pressed (F8), the GUI pops up a window which then requires a mouse click to select which autocompletion option to use. If it is deselected, F8 or spacebar seems to work to get the selections to appear again but this should be available without a mouse click at all.

Rather than relying on a filepath for a local resource, both the run-time and the edit-time paths should be allowed to be remove paths. Due to other issues which address improving the edit-time setup, this issue could be satisfied by only changing the run-time functionality. Specifically, it would be simple to add another populate-at-runtime style function named populate-at-runtime-remote that expected a remote path to a server and file and performed the download before doing exactly what populate-at-runtime does.