freenode/#lisp - IRC Chatlog
Search
21:17:00
foojin
What features can make programs written in a (hopefully not hypothetical) language easier to extend, given that
21:17:16
foojin
(3) the extensions should take advantage of further upstream improvements by augmenting existing things, not reimplementing them.
21:18:29
foojin
According to the history of Emacs, Stallman admitted to having used dynamic scoping for this very reason.
21:21:49
TMA
foojin: treat every interaction between parts of a system as an extension point; do not use the extension points internally
21:22:08
foojin
Lexical scoping is immensely useful, but anyone, who "fixed" a chunk of closure-heavy JS with a so-called "userscript", would surely admit to having had a hard time working around them.
21:23:35
phoe
CLOS itself is insanely extensible with its BEFORE/AROUND/AFTER methods and ability to define subclasses and new methods on same generics
21:24:29
TMA
foojin: a concrete representation of my advice is: use CLOS, but do not use :before, :around or :after methods yourself to let them be available as the extension points
21:33:06
foojin
phoe, TMA: I've heard a lot about CLOS and MOP, they're the main reasons (besides Scheme's lack of libraries) I once again picked up "On Lisp". But what about a more "fundamental" data type, functions?
21:33:59
foojin
What do you think about an operator that creates a function F as if it was defined where another function G (given as a value) is (yes, it will impede compilation and possibly hold onto objects that no one will ever use).
21:35:48
foojin
That could solve the problem of people stashing too much stuff inside closures, making their functions "unwrappable".
21:39:17
foojin
Bike: That is, in the same lexical context, to make it possible to replicate any closure.
21:40:06
Bike
so it would require having the point at which any function is defined have its entire lexical environment saved along with the function?
21:41:38
foojin
Nothing. I do think that CLOS is a more proncipled and general solution, so the last question isn't related to that.
21:41:48
phoe
instead of saving all the state in a lexical closure, save that state in a CLOS instance and use methods instead of functions
21:42:16
phoe
the "fundamental" data type that you describe will give you more PITA than a CLOS-oriented approach.
21:50:33
foojin
phoe: I see. That seems to even take care of what's in scope, so that whatever the original author used would still be available for the extension code.
21:52:44
MichaelRaskin
foojin: well, if you are ready to do partial recompilation, and to use a powerful enough code walker…
21:54:11
foojin
phoe: And the original author would have to deal with "undercomposition", if someone's extension requires their code to expose a particular point.
21:54:16
aeth
Nearly every time I started out with my own defgeneric/defmethod (as opposed to defining some method to fit someone else's API) I wound up converting it into a defun later.
21:55:39
aeth
(I'm obviously excluding the methods that are generated automatically in defclass, of course)
21:56:24
Bike
i thought you were going to talk about method combinations or something, not the part everyone uses
21:56:46
MichaelRaskin
A tool that allows to traverse the code after it has been written, and maybe even make some changes
22:01:07
Bike
i don't think "i thought i needed methods, but actually i didn't" is a very interesting story
22:01:26
Bike
like if nothing else you should elaborate on the particular circumstances or something
22:01:54
foojin
MichaelRaskin: So it's a interface which can be used by the program to modify itself, relying on the compiler to keep everything available?
22:02:20
foojin
MichaelRaskin: Or did you mean a particular kind of editor that people use interactively?
22:03:04
aeth
Bike: Idk, I think a lot of modern styles (some of which Lisp could do before CLOS even existed) could probably be described as "post-OOP" styles.
22:03:30
MichaelRaskin
Bike: full semantics is not really needed for a code walker, but understanding the general Lisp code structure is a must
22:04:23
aeth
Bike: If anything, I think we might be at the point where OOP is underused in places where it could be used, as a reaction to its earlier overuse.
22:05:47
aeth
Most of the "big" hype in languages these days seems to be people trying to copy and paste Haskell into JavaScript or the JVM.
22:07:11
aeth
Bike: It's not a contradiction because I was talking about my own personal overuse of a CLOS feature before, and now I'm talking about what trends I've observed in programming language hype.
22:08:00
MichaelRaskin
foojin: I would imagine — in Lisp terms — a custom readtable that leads to every form being wrapped in a macro that expands to what was originally written (by default)
22:08:27
MichaelRaskin
But then a user can request some override or ask to inject some code somewhere
22:13:42
MichaelRaskin
And in the repository, there is an example of the crazy wrap-everything trick
22:25:18
foojin
I see. It basically allows one to run arbitrary queries against the source code, check assumptions ... like Coccinelle, which kernel folks use, but for Lisp?
22:27:51
foojin
BTW I wanted to learn Coccinelle to hack on tmux, but there's not much in the way of resources besides a language grammar and kernel-related checks.
22:29:01
foojin
I thought it would make reasoning about C easier, but it turned out to be a PITA in its own right.
22:32:52
MichaelRaskin
(also, it expands most macros, so old indentation is not always even applicable)
22:33:39
Bike
foojin: in lisp we don't usually deal with source code as text/character sequences. metaiconicity and all that shit
22:34:53
MichaelRaskin
I guess some tools from SICL or Second Climacs (primarily by Robert Strandh) could be applied, those do care about text-code correspondence
22:37:20
foojin
Bike: It would come in handy to automatically enforce guidelines, like those used in kernel development. Is it a good idea to make additional context information available for cases like this?
22:41:07
foojin
Say, the indentation level and type, like ((spaces 2) (tabs 3) (spaces 1)). If it's too granular, provide functions to assemble a textual representation based on those cues.
22:43:44
foojin
It would work just fine as-is, for checking code before trying to commit it, but large-scale refactoring would leave a mess instead of formatted code.
22:45:28
Bike
you're thinking in terms of text. text is pretty much a separate question from what a code walker does.
22:45:44
aeth
Comments are the real problem. Most CL code can be restored with *print-case* set to :downcase
22:46:53
aeth
And if you use fancier features so that isn't true then you probably already violate good style
22:49:59
foojin
aeth: In other words it's not a problem, since there is such a thing as _the style_, which this *print-case* is aware of and everyone is encouraged to use?
22:50:31
Bike
not so much as there's a "the style", as that you can write a program that prints code as text in whatever style you want
22:51:16
aeth
Well, my original point is that you can theoretically restore everything but comments easily
22:54:48
foojin
Bike: Which in turn could make use of the code walker to distinguish forms based on their meaning. I didn't think of that.
22:55:37
Bike
beach has a lot of stuff in mind for a really smart editor that uses that kind of knowhow
23:00:27
foojin
Come to think of it, there are actually people out there who make Emacs parse all those programming languages, probably reimplementing sizable chunks of existing parsers.
23:01:07
foojin
I'm still uncomfortable with paredit just reindenting the whole thing after an operation. The author even admits to the shortcomings of this approach in a comment before paredit-convolute-sexp.
23:14:35
foojin
By the way, why do Lispers use ^L in their programs, if not to take advantage of Emacs' narowing/moving functions?
23:28:43
foojin
p_l: I almost thought the reason would be to use it with some kind of tool that expects it. Maybe in Elisp world this is about consistency, seeing as it's used in Paredit, which doesn't seem too old.
23:29:29
p_l
foojin: ^L predates GNU Emacs, and afaik by itself gets hooked into "next/prev-page" commands
0:01:02
DemolitionMan
please how can I encode rfc3339 date time into nanoseconds integer 64? hanks for helo
0:44:18
MichaelRaskin
Of course, nanoseconds eat quite a bit of bits. But 64-bit number should still be able to represent entire 21st century. And 22nd too, if unsigned
0:54:07
MichaelRaskin
I mean, Unix time also doesn't run out in 2038, it's just that some systems store it in a way with not enough space for the next digit
1:22:53
Fare
MichaelRaskin, the problem with nanosecond encoding of something defined up to one-second adjustments is... what happen at leap seconds?
1:24:01
Fare
(That said... it's the time encoding I use in Gerbil's clan/utils/date.ss so who am I to cast any stone?)
5:55:38
loke
;; Compute points to plot for each element of FUN. ;; If no plottable points are found, return immediately from $PLOT2D.
6:00:20
loke
Maxima is really old code, and it's still maintained to support every Lis under the sun. They still maintain GCL compatibility.
6:33:32
blep-on-external
i've finally hit the point where i can write cl-who macros without making mistakes c:
6:34:08
MichaelRaskin
Fare: trust me, the problem also exists when you just use the number of seconds
6:35:23
ealfonso
I was told by someone here that by using cl-json instead of jonathan, I could avoid the hack of adding '("application" "json") to drakma:*text-content-types*... does that person know what cl-json method I should be using?
6:39:09
loke
ealfonso: you do somehting like this: https://github.com/cicakhq/potato/blob/master/src/potato/xkcd-processor.lisp#L17
6:42:13
loke
If the remote server doesn't use the correct content-type, you can always parse it yourself like this:
6:44:39
ealfonso
loke https://sites.google.com/site/sabraonthehill/home/json-libraries this website suggests the hack I've been using. body appears to be some kind of byte array, which "no JSON library knows what to do with it."
6:47:08
blep-on-external
on the topic of json, are there any libraries which decode to hash-maps? cl-json only encodes from hashmaps
6:52:07
blep-on-external
given that getf is symmetrical i'll just use that. thanks for the reccomendation though
7:53:57
beach
DemolitionMan: I find it hard to concentrate on the logic, because I am distracted by the unconventional style.
7:58:20
dim
beach: do you have an opinion on the https://www.cs.umd.edu/~nau/cmsc421/norvig-lisp-style.pdf document?
7:59:16
beach
dim: Yes, I follow it pretty closely. Especially page 13 where they explain how the expectations are violated in various situations.
8:01:13
beach
dim: The authors are very experience programmers and very experienced Lispers. I find it insulting when some much less experienced person claims that their advice is without merit.
8:02:41
dim
DemolitionMan: read the document I've linked and then decide for yourself, the paper is very good at explaining why it's important
8:06:12
dim
there was another document that I liked very much about programming style, from the Erlang community, which insisted on showing your intentions
8:06:55
dim
in the example they gave they ended up with mostly one-line function bodies and very long function names, and reading the code, it was pretty obvious what they wanted to happen
8:08:34
dim
oh apparently there's a whole Wikipedia entry on the topic at https://en.wikipedia.org/wiki/Intentional_programming
8:09:45
dim
oh and I wrote a Common Lisp related blog post about that in https://tapoueh.org/blog/2012/07/solving-every-sudoku-puzzle/ too ;-)
8:13:14
dim
sorry about the self promotion... remembering and finding again writings of 6 years ago doesn't happen a lot to me
8:16:25
dim
beach: yeah, I like it that I've been able to make it all by myself, but it shows and in a bad way :/
8:17:38
jackdaniel
speaking of blogging, a very interesting use of JSCL: http://blog.klipse.tech/lisp/2018/05/07/blog-common-lisp.html
8:17:54
jackdaniel
you can embed executable CL (with some limitations, JSCL is incomplete) in your blogpost
8:18:09
beach
Anyway, I find it, let's say "interesting" when people ask for help with some code, i.e. they want others to read, understand, and help fix it. But then they can't be bothered to respect even the most basic conventions about code layout and other stylistic rules.
8:18:39
jackdaniel
to be fair many newcomers fix the indentation and patiently wait for further advices
8:20:13
beach
dim: Several indentation problems: Body of MAKE-ARRAY in the first example. Argument of POSSIBLE-VALUES.
8:20:19
flip214
dim: find-position-with-fewest-possibilities: how about using (ITERATE ... (MINIMIZE ...)?) Not sure whether LOOP has MINIMIZE, too.
8:20:40
beach
dim: Useless newline after LOOP, probably because you weren't using SLIME-INDENTATION at the time.
8:21:25
beach
dim: The line starting with IN in the LOOP should be indented to show that it is not a separate clause. SLIME-INDENTATION will do that.
8:22:07
beach
dim: Use of (+ ... 1) and (- ... 1) should be replaced by 1+ and 1-. The rule is to use the most specific construct that will work.
8:22:47
beach
dim: I personally never use WITH-SLOTS because I consider slots to be an implementation detail. I use WITH-ACCESSORS instead.
8:24:38
beach
dim: The naming convention for predicates in Common Lisp is to end the name with `P' rather than `?' as in VALUE-IS-SET-P.
8:25:37
dim
beach: normally the indentation is all done with Emacs/SLIME, I rarely overrule it… in the case of the article, I wonder how much of it is a rendering issue
8:26:53
dim
https://github.com/dimitri/tapoueh.org/blob/master/content/post/2012/07/solving-sudoku.md is the source, but well, I can't suppose you'll be interested that much, thanks already for having had a look; also I don't think I'm going to fix it anyway (too many other things to do)
8:28:27
dim
I liked what pjb had to say about that, that 1+ and 1- are very good when used as function arguments, not so much for computation
8:29:59
beach
dim: If you have (- <very-long-expression> 1) you don't see that it is 1 that is subtracted until much later. So the person reading the code must "push that on the stack" until the second argument of #'- is available. If #'1- is used instead, no additional memory is needed on the part of the person reading the code.
8:31:04
beach
The same thing is true for many of the other instances of the rule "use the most specific construct that will work".
8:31:11
dim
I find it so much easier to then hack around when you have off-by-one bugs or other adjustments to make
8:32:05
dim
I feel a little stupid each time I write (+ -1...), but I thank myself each time I have to revisit such written code
8:32:35
beach
dim: Interestingly, that particular version has the same property that I just mentioned about #'1-.
8:33:18
beach
dim: I.e. once you get to the ... part, you already know that 1 is going to be subtracted.
8:34:16
beach
Many non-native speakers of English find the use of UNLESS problematic. That was the case for me in the beginning.
8:35:46
dim
unless has a special place in my mind, because I used to despise those forms in perl and I really like them in lisp, and I did need some thinking to realize that Perl allowing them after the statement is what I don't like
8:37:33
dim
LdBeth: I don't much care about avoiding nesting, let's optimize for code READING, nesting is a good hint; and if you have too much nesting anyway then just split the code into more “units” (functions, usually)
8:40:31
beach
shka: Bah, just do what I do; submit your code here for people to read. You will get ample feedback that way.
8:42:43
dim
in the past by mentioning problems I had with some pgloader code I got enough incentive to rewrite subsystems entirely, which is good already
8:44:43
dim
the new code is at https://github.com/dimitri/pgloader/blob/master/src/pg-copy/copy-format.lisp by the way, much better than before if you can believe that ;-)