Hi Vincent Thank you for your reply and your encouragement which is very much appreciated.
My first impulse would be to write the document DSL or DSLs as a Scribble > dialect. Scribble allows you to freely insert code in text documents and > enables PDF rendering. I'm not sure if there is a best practice for writing > Scribble languages, but I've found that it's easier to start from an > existing, simple Scribble dialect and add/remove some functionality to get > a hang of it. It could also handle the "general Documents language": most > Scribble dialects inherit functionality from scribble/base, so there's a > parallel. > Certainly I agree that using Scribble syntax is a good way to go. I've looked into that, and noted that I can choose a different control character. The "@" character is used quite frequently used in business documents, so I was thinking of using "~" or something like that, as that is less frequently used. In terms of actually using a Scribble dialect, is it possible to *fully* control the LaTeX output? My letter format would be quite a departure, I imagine, from the existing template. As for the records and reports: if I understand correctly, you don't want > separate DSLs for these, but you want to be able to create these from > within a "#lang documents/..." file? For instance so that an administrative > employee can schedule a meeting directly in the invite, keep contact info > in correspondence in sync with records, and so on? > Yes, I envision that "records" would be business information embedded in documents. They would not require their own DSLs. Really the motivation is to avoid duplication. What happens now, for example, is that an employee writes a note of a telephone conversation on the file *and* a separate entry in the calendar software. This requires keeping two systems in sync with all the problems that entails. > I'm pretty sure you can write a Scribble-based language so that you get > side effects when you run programs written in it, so executing the document > could read/write from/to a database and connect to an email server or web > server. I guess you'll still want to review any documents even if the > syntax is valid, so posting a preview document to a company-internal web > server or sending a preview email, possibly with a link to send out the > document definitively and something to roll back/permanently record the > changes made to the database are all options. > In terms of database requirements, I was simply planning to create tools to scan documents (written in my #lang document/... languages) and run the desired queries etc. Each user could then keep them in folders and organise them as required. It would be outside the scope of my program, but git or some other file sharing application could then be used for the users to synchronise the documents. I think that such a system would be avoid the need for side effects. There could then be a caching system where when a report was run against a folder a hidden file saved the output. On future runs, it could read the cached version if no files in that folder had been modified. In terms of getting the records "out" of a document, I was planning to simply use "provide" and then "dynamic-require" to obtain them. I'm sure others know more how the technical details would work, but it > sounds like a fascinating project. I can't commit to anything right now, > but it'd be great if you could keep us posted. > Many thanks Richard -- Redwood Legal r...@redwoodlegal.co.uk Office: 01157 323277 15 Clarendon Street, Nottingham, NG1 5HR This firm is authorised and regulated by the Solicitors Regulation Authority (SRA ID 637939) -- Redwood Legal r...@redwoodlegal.co.uk Office: 01157 323277 15 Clarendon Street, Nottingham, NG1 5HR This firm is authorised and regulated by the Solicitors Regulation Authority (SRA ID 637939) -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
