freenode/#clim - IRC Chatlog
Search
0:46:10
nyef`
trinque: OTP is "one-time programmable", EPROM is "erasable" PROM. These things do not go together.
0:48:40
nyef`
(Okay, "PROM", "EPROM", "EEPROM", and "FlashROM" are not, technically, "ROM", since they can be written, but they aren't "RAM", either, because writing them can be a pain (although the pain tends to decrease as you move along the spectrum from PROM to FlashROM).)
3:25:29
nyef`
... And now I have a hash collision between the children's book "Goodnight, Moon" and the old-school Lisp hacker.
3:31:55
nyef`
Maybe Moon did the initial version, and Stallman did the consolidation of different versions?
3:34:56
beach
I recently learned that the first Emacs implementation written in Lisp was NOT Multics Emacs, but some Lisp Machine implementation of it (ZMacs?).
3:37:23
nyef`
The impression I get is that ZMacs comes from when "they" were using Zeta as a prefix for some of the LispM stuff.
3:38:38
nyef`
Plausibly a derivative of ZWEI (ZWEI Was EINE Initially, a successor to EINE Is Not Emacs).
3:39:16
nyef`
... And now I'm reminded of INTERCAL, which stands for Programming Language With No Pronouncable Acronym.
3:41:38
nyef`
This would also be the programming language with the COME FROM statement, and some variants include the "computed" COME FROM, and the multi-threaded version where multiple COME FROM statements that come from the same place is used to spawn threads.
7:23:06
manny8888
I have been looking for documentation on how mcclim interfaces with backends. I have found nothing save for 1 page in the manual, and obviously reading through the code.
7:28:07
beach
I so wish we could eliminate this markup-language conundrum so that we could start uniformizing the documentation. Not any time soon, I fear.
7:33:04
beach
So your solution to the problem that we have too many markup languages and that, because of that, any particular choice is rejected by 90% of developers, is to suggest yet another markup language?
8:12:26
manny8888
s/markup language/programming language/standard/any bit of technology.../mcclim backend???/
8:15:11
beach
And I do have a solution to the markup-language problem. I just haven't had time to work on it yet.
8:34:51
loke
It supports using markup in the messages, so I have a parser that parses the necessary syntax into a Sexp form.
8:35:16
loke
...which I then transform to either HTML or JSON, depending on whethe rit's used by the web frontend or the mobile application.
8:40:09
beach
ACTION contemplates creating MAML, the mother of all markup languages. It will obviously be superior to all existing ones.
8:40:52
loke
Mine is almost identical to CommonMark though. It's just that there was no acceptable parser in Lisp for it.
9:06:15
beach
Because there are too many markup languages and it is impossible to agree on a choice. And I currently do not have time to work on my suggested document protocol and an implementation of it.
9:08:59
loke
beach: I believe the reason for that is that the kind of markup languages that people want are incredibly difficult (if not impossible) to formalise.
9:09:37
loke
Every single parser out there (including mine) is a hodge-podge of ad-hoc regexes in an attempt to make them do kinda-sorta what users expect.
9:10:16
loke
Once you try to formalise things (which I have tried), you end up with users complaining that things are "strange" in whatever edge-case they seem to always run into.
9:11:10
beach
You may be right, which is why I suggest getting around the entire markup problem by not specifying a markup language, but instead a Common Lisp protocol for manipulating the documentation in memory.
9:11:27
loke
beach: yes. I agree. A standard intermediate format that contains structure, useful. My parser does that, although that format is used by exactly zero other people.
9:12:07
loke
So something like “foo _bar_ hello” becomes (:paragraph "foo " (:underline "bar") " hello)
9:14:32
jackdaniel
I wonder if providing extensible protocol would solve the problem - people usually look for off-the-shelf solutions, and that's what markup language gives them
9:15:29
beach
jackdaniel: And for implementers of systems for displaying and searching documentation.
9:15:44
loke
(and by "higher level" I mean that the document should be able to specify the structure of these things)
9:15:45
jackdaniel
so the selling point for end-users always will be markup - easier to write - better
9:18:30
beach
loke: I can't describe what I am thinking of yet another time on IRC. You need to read chapters 2 and 3 of the PDF document I gave a link to. Good news: They only contain 2.5 pages.
9:19:33
jackdaniel
other thing is that such protocol would be volunerable for incompatible extensions if it's not ~complete for 80% of foreseeable cases (or disallow 3rd-party extensions and hold firm grip on the central repository)
9:21:01
beach
jackdaniel: By specifying a trivial internal I/O format for the protocol classes (like what I often do, i.e. [package:class-name :initarg1 form1 ...]) I think we can get the benefit of having the documentation in internal protocol form without committing to a markup language. It will still be useful for browsing, using a very simple CLIM application.
9:22:31
beach
jackdaniel: I agree. I must either make it fairly complete, or make sure there is a smooth path for adding to it, leading to a complete system.
9:23:22
loke
beach: OK, I checked your document. Have you given any thought to an actual format to use?
9:24:35
beach
The minute I do that, it will be rejected by 90% of all potential users, as I have stated in the past.
9:25:25
beach
The entire idea is to avoid specifying such a syntax, possibly allowing every person to parse his or her favorite markup language and create the internal document.
9:25:30
loke
beach: True, but that doesn't preclude you having given it some thought? I guess I'm merely asking what kind of markup you personally prefer. Its viability in the real world nonwithstanding.
9:26:47
beach
I would be much more inclined to write myself an interactive CLIM application for updating it.
9:27:32
beach
Well, that's basically the reason I started thinking of something we *COULD* agree upon.
9:28:46
loke
beach: I don't think there is anything controversial in your document (since, as you say, you never touch on the bikeshedding topics). Most existing markup languages don't have a structure anyway.
9:29:47
beach
Exactly. And that's a huge mistake. Probably due to the fact that the languages the markup language parsers are written in are not expressive enough.
9:30:23
beach
Everyone is brainwashed by the Unix "philosophy" of taking a stream of bytes as input and producing a stream of bytes as output.
9:30:58
beach
So basically, there is nothing a user can do to a document, other than translating it so some other form.
9:31:29
beach
It is not possible to write a little routine to search for things, to reorder things, etc. Because there is no documented internal format.
9:32:26
beach
Only possibility is to write your own parser for this (largely undocumented) markup language, re-create the structure that the standard processor uses, but differently and in a different language, and then write some output bytes.
9:33:15
beach
Imagine the kind of interesting documentation processor we could create if we had an internal protocol for that kind of stuff. A few lines of Common Lisp code could do interesting things to the document.
9:34:46
loke
I'm not sure the developer community as a whole would see the benefits of structured information.
9:35:16
beach
Now, if the #clim channel were logged in a useful way (i.e. not click on an arror for every 12 hours) I could figure out who wanted to work on this.
9:36:36
loke
jackdaniel: That's part of it. The problem was that the library in itself replicates a few characters of native javascript code. It's lik eme looking for a library on QL in order to convert a string to a symbol.
9:37:04
loke
jackdaniel: The problem with the removal was one aspect, but it was just highlighting the utterly dysfunctional NPM community as a whole.
9:37:27
loke
You are aware, I presume, of the existant of a library in NPM called isArray. Which does exactly what you think it does.
9:38:42
jackdaniel
and as far as I can tell, there is quite a lot of such systems (serapeum, clack - just grepped through my quicklisp/dists/quicklisp/software)