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