freenode/#clim - IRC Chatlog
Search
4:34:28
beach
I am not sure why I am having such a hard time with my Earley parser for lambda lists.
4:44:34
beach
Part of my problem is (or rather WAS) that I wanted to add the possibility of having optional and repeated grammar symbols in the right hand side of a rule. But I think I figured out how to handle those.
4:46:27
beach
So that I can say (required-parameters <- (* required-parameter)) and (ordinary-lambda-list <- required-parameters (? optional-parameters) (? rest-parameter) (?key-parameters) (? aux-parameters))
5:19:39
nyef
Mmm. I'm having a similar problem with the NQ-CLIM II Specification. I've finally determined that it needs to be written before I make much (if any) more progress on NQ-L
5:28:20
nyef
Probably fairly similarly, at least to start, especially since it wouldn't contain anything after about chapter 13 for the initial versions.
5:34:55
nyef
I guess one question is, should I be using LaTeX, texinfo, just plain TeX, HTML, org-mode, just plain text, or something else entirely?
5:36:04
nyef
Given that I've named six, I don't find it at all difficult to believe that there could be another four.
5:38:42
beach
Maybe we should work on this one first: http://metamodular.com/doclang-requirements.pdf :)
8:32:06
splittist
beach: what needs to be done to move doclang (or whatever better name) forward? I don't actually care about maths or bibliographic stuff, but I do care about documents. More than I care about X clients and servers...
8:35:32
beach
splittist: I guess a way to view a document. Either by generating some output file such as PDF, or by defining a CLIM application to view it.
8:35:54
beach
splittist: I was going to use the simple serialization technique I always do for saving a document.
8:40:11
splittist
I have to say, whenever I start pondering this stuff I keep thinking about objects rather than protocols. I would it were the other way around...
9:07:09
jackdaniel
so doclang would be a kind of intermediate format which requires compiler (source-text -> doclang) and printer (doclang -> visible representation), is my understanding correct?
9:09:59
beach
You can imagine a GUI editor for the format so you don't need any particular source language.
9:11:06
beach
And I wouldn't call it "intermediate" format, because that suggests that the important part is the input and the output.
9:12:28
beach
But you are right in that it would be advantageous to have parsers for various markup languages that will generate this internal data structure.
9:12:31
jackdaniel
I think it is important - input format (be it gui editor or source text) is a surface encountered by the documentation writer and output is what the end user sees. I like the idea of uniform structure for documents
9:13:51
beach
You are right, of course. I just prefer to emphasize the aspect that is new with this proposal, namely that the internal format is documented and can be customized and adapted to the needs of the client.
9:15:17
beach
All other systems discuss only input and output, and there is nothing you can do with the intermediate form, probably because they are written in a static language, there is nothing useful that the end-user can do, modulo getting the source code and modify it.
9:15:45
jackdaniel
yeah, I can imagine (given we have markdown->doclang->pdf pipe) someone saying: but we already have markdown->pdf rendersrs
9:22:23
beach
splittist: A back end is more urgent than a front end. It would be possible (though a bit painful) to generate the serialized form of the data structure using an editor like Emacs.
9:23:58
beach
Painful, because I want each individual word marked, such as [doclands:word :text "hello"] so that words can be turned into presentations, so that they can be spell checked, and specialized into index entries, etc.
9:24:48
beach
Do the math! :) It's not big by today's standards. And the serialized format will compress very very well.
9:28:12
beach
I just wanted to avoid a debate like the ones we often have about SBCL executables costing several cents of RAM (should the entire code every always be in RAM at the same time).
9:32:17
splittist
For those interested in the real Word xml: https://en.wikipedia.org/wiki/Microsoft_Office_XML_formats#Word_XML_Format_example . You will see that the bulk of it is metadata, instructions for the GUI, and physical formatting information.
9:32:54
jackdaniel
yeah, I've heard they put there some calls to internal word implementation (in format), so it's harder to reimplement
9:35:36
splittist
Nevertheless, there are folks using lisp to generate Office XML successfully, and since that's what the real word (: runs on, it would make a good, eventual, additional, doclands target.
9:41:38
splittist
Should doclands itself be concerned about what a word is, or should that be up to the renderer? (referring to words-as-presentations in a clim editor)
9:45:50
beach
I think the initial solution would be to make a "word" whatever is surrounded by whitespace in western text.
9:46:18
beach
The problem is that there are words in western languages that consist of two or more such units, but that are not juxtaposed.
9:47:30
beach
But I think it would be acceptable to stick spaced in a word. For example in a Vietnamese text, that could be very useful.
9:50:45
splittist
Perhaps these smarts should be in the parser (or whatever you call the thing that turns the input format into the doclands document) and/or the renderer and/or a semantically-aware thing that transforms one doclands document into another.
9:51:29
beach
Yes, maybe so. I am not going to let that detail become a major obstacle to progress at this point, though.
9:52:16
splittist
I see it as clearing the way to progress - the dumber the base functionality is, the easier it is to implement (: