freenode/#lisp - IRC Chatlog
Search
5:56:21
beach
Python is a pure interpreter, which means you can't really get any performance out of it, unless you write your code in C.
5:56:44
beach
Most Common Lisp systems compile on the fly, so you can write all your code in a truly high-level language.
5:57:21
beach
Furthermore, Python is not homoiconic, so you can't really do any metaprogramming in it, like macros.
5:57:50
White_Flame
each languages seems to have its own definition of "metaprogramming". For python, it seems to be adding hooks on object methods
5:58:29
beach
White_Flame: Thanks. I am not following the Python terminology, so I appreciate the information.
5:58:41
Dizidentu
I would stay but I just got back and I want to catch this flight into slumber land while I still can :|
6:01:17
beach
And, no, I think the purpose of Python is as a "scripting language", whereas Common Lisp is a general-purpose programming language.
6:05:50
White_Flame
because most people don't actually do core programming anymore, but rather call libraries (iow scripting)
6:07:51
beach
drmeister once showed us a site that gave the cost in electric power per computation unit for various languages, and Python is really bad.
6:16:24
parjanya
mornings! Is there a function, or an easy test... to check if an object can be printed readably?
6:24:35
beach
The answer would be influenced by things like methods on PRINT-OBJECT, and the existence of reader macros.
6:29:18
White_Flame
(handler-case (let ((*print-readably* t)) (write-to-string <item> nil)) (t (t) t))
6:31:10
White_Flame
actually, (ignore-errors (...try to print readably...) t), returning NIL if it isn't readable, is easier
6:33:53
parjanya
ah, very good idea, thanks! I tried finding a way to chase the method for printing, but no luck
7:04:16
White_Flame
I just tested with function objects, and those blew up when *print-readably* was set
7:10:23
White_Flame
if you truly do want to prune the values, then (values (thing-that-returns-multiple-values...)) does only return the first
7:18:23
White_Flame
"If printing an object readably is not possible, an error of type print-not-readable is signaled rather than using a syntax (e.g., the ``#<'' syntax) that would not be readable by the same implementation."
8:58:33
xificurC
yesterday someone pointed out I can define a package local nickname for a package, where can I do that? I don't see this option in the defpackage clhs page
9:06:18
xificurC
I'm really glad this is getting implemented, it's a huge boon in the lisp that doesn't like to get discussed here (or even be called a lisp)
9:13:00
beach
xificurC: There is widespread agreement, even among the commercial Common Lisp vendors to implement package-local nicknames. But how does the implementation of package-local nicknames for Common Lisp benefit "other lisp"?
9:15:40
xificurC
I'm saying I've been using local nicknames (aliases) in clojure and am happy I can use them in CL now as well
9:16:11
xificurC
I mentioned it because I thought it might have been an inspiration to finally implement it
9:18:42
xificurC
the last thing I'd like is for `(i:iter (for i from 1 to 10) (collect i))` work. But the reader screws me over, even though `iter` could resolve `for` and `collect` during macroexpansion
9:23:36
beach
LOOP can do it, so I don't see why ITER could not. But it would likely require a radical restructuring of the code.
9:24:49
beach
xificurC: It is a simple matter of using the names of the symbols involved instead of the symbols themselves.
9:25:00
flip214
xificurC: how about i::(iter (for i from i to 10) (collect i))? but then the symbol "i" would be in the iter package...
9:25:14
beach
xificurC: But I am guessing that FOR is a local macro introduced by ITER, and that would have to change.
9:26:24
beach
xificurC: It is possible that ITER can do some things that LOOP can not, but the fact that ITER is not standard is an argument against it, especially since LOOP can handle most situations.
9:27:03
beach
xificurC: The argument that people use in favor of ITER and against LOOP is often that "LOOP is not Lisp-y", which is silly of course, since it is part of the standard.
9:27:13
xificurC
mfiano why shy away? I don't find it much harder to read or understand than loop. Are there some inherent flaws in its implementation?
9:28:36
xificurC
beach I thought the main argument is that an external package can extend iter, e.g. a database library exposing a cursor can plug it into it
9:28:47
beach
xificurC: An external library that may or may not be maintained in the future, and that does little more than a standard facility should be given some thought before being used.
9:28:52
heisig
xificurC: It is a question of the amount of 'vocabulary' that I need to know to read your code. LOOP is (for good or for bad) part of the vocabulary we all know. ITER isn't.
9:29:12
mfiano
It's not standard Lisp which everyone is familiar with, it can have its forms broken up and spread out, it is often used like it is standard with use-package.
9:30:20
flip214
heisig: but the same argument applies to lparallel, cl-who, alexandria, and so on and on.
9:31:12
xificurC
beach I was showing the simplest example, not a real one. At this point in time I'm not using anything that loop doesn't handle, so it's easy to switch back
9:31:25
heisig
flip214: It is a difference whether you introduce functions or macros. And even with macros, there is a difference between introducing an obvious WITH-* macro, or an entirely new control-flow construct.
9:31:38
beach
xificurC: So in that case, use LOOP for everything that does not require an extension.
9:32:31
mfiano
In 15 years I have not needed LOOP to do anything else. One has to be careful about shiny things, features you think you might need, or think they will benefit you, but in turn do more harm than good.
9:32:32
xificurC
this is the lisp schizofrenia I never understood - an infinitely extensible language that nobody wants to extend
9:32:47
flip214
beach: I don't think that's a good argument. If something is being used often, it becomes mainstream - and then you'll see it so often that you'll just know it.
9:33:12
flip214
so your argument sounds to me like "something must be used everywhere to be used everywhere", which is loopy ;)
9:33:40
beach
xificurC: It is extended most often on a per-application basis. That's the beauty of it.
9:33:40
xificurC
that was a reaction to "It is a question of the amount of 'vocabulary' that I need to know to read your code"
9:35:27
beach
xificurC: Applications introduce new vocabulary in the form of functions, macros, classes, etc. That vocabulary becomes specific to the application and its domain.
9:36:13
heisig
xificurC: Extending Lisp is just something that shouldn't be done lightly. If you are working with music, this is a good reason to introduce custom notation. But 'I don't like LOOP' is not a very good reason for introducing custom notation.
9:37:42
beach
"The argument that people use in favor of ITER and against LOOP is often that "LOOP is not Lisp-y", which is silly of course, since it is part of the standard."
9:37:53
mfiano
The flexibility of Lisp allows you to use iterate or extend the language with new syntax of your own. This is why Lisp suffers from NIH, being so flexible and thus designed for small teams, makes it often more desirable and easier to re-implement a piece of software yourself, than to try to understand someone else's code. After all, code is just a projection of your mind, and trying to understand
9:37:55
mfiano
someone else's moulding of the language for a particular domain usually doesn't map too well.
9:43:11
xificurC
mfiano "In 15 years I have not needed LOOP to do anything else" - I find this thinking backwards. LOOP was chosen and implemented by a committee. That committee could have accepted SERIES just as well. Or it could have accepted none of them and we would be writing mapcars and the like. In that world if a user comes asking about LOOP, which is now a
9:43:11
xificurC
library, would the argument be "In 15 years I have not needed LOOP because mapcar and friends can do everything LOOP can"?
9:43:56
mfiano
xificurC: If we had series for decades of widespread use I would have "thought forward"
9:47:05
xificurC
I only picked up 2 dependencies so far. I see iterate is not, ehm, famous around here :) The second is trivia. Is trivia OK?
9:47:20
heisig
xificurC: I think I know how you feel about LOOP. It is not that I haven't used ITER myself because it is more powerful and flexible. But here I am, back to using LOOP. And why is that? Because having a powerful iteration construct is really not that important.
9:48:07
mfiano
When I first began using Lisp I too used iterate for a short while, but I couldn't agree more with heisig.
9:48:12
flip214
heisig: and ITER isn't as readable as LOOP? Which difference (apart from the parens) do you see, in typical use?
9:48:16
xificurC
heisig so you're saying in the years you programmed you find LOOP more readable than ITER, is that correct?
9:49:17
flip214
another feature of ITER is that the clauses like COLLECT can be used in subforms as well - LOOP requires them at the loop-level, which is awful sometimes
9:49:36
heisig
xificurC: 100% of the Lisp programmers know about LOOP, but only at most 60% (at most) know about ITER. That settles it for me.
9:50:33
mfiano
LOOP only cares about the symbol name for LOOP keywords. Iterate requires you to modify symbol property lists for synonyms.
9:53:43
flip214
heisig: 10% of programmers know Java, but only 1% of programmers know Lisp. How is that an argument against Lisp? (numbers invented)
9:55:10
flip214
of course, there's no reason to invent new code-flow macros all the time - but a nearly 1:1 translation of a construct defined in the standard is on the safe side, me thinks.
10:01:15
heisig
flip214: I think the benefits of using Lisp over Java are greater than those of using ITER over LOOP. But even then I occasionally choose Java or Python over Lisp for some projects, because it is more accessible for the target audience. (Not often though, and not gladly)
14:08:20
dim
I didn't follow closely and am wondering if ABCL is relevant to this Java/Common-Lisp discussion
14:16:54
xificurC
can someone enlighten me how to correctly generate unhygienic code here? http://ix.io/2M0v . `aif` is just an example
14:17:07
heisig
We recently had a project where we needed a computer algebra system in Scala. Our solution was to load ABCL into the same image, and to use ABCL to load Maxima.
14:19:21
heisig
xificurC: Your code is unhygenic, but you are in the wrong package. You pollute c::it, but write a cl-user::it.
14:20:33
xificurC
heisig being unhygienic is the point in this case :) The fragment generates `C::IT` but I want to generate `IT` for whatever package is using the macro. Does that make sense?
14:21:00
beach
xificurC: Symbol names are handled at read time. At macro-expansion time it's too late.
14:21:25
heisig
xificurC: Be careful what you wish for :) I would suggest having the package C export IT, and to have other packages import it.
14:21:45
heisig
But if you really want to capture all kinds of IT, you need a substituting code walker.
14:22:19
xificurC
I don't remember Paul Graham talking about this stuff in On Lisp. Was he just avoiding this whole topic by not using any packages?
14:22:29
beach
xificurC: Also AIF is really strange, since it handles general values as if they were Booleans. You are much better off without it.
14:22:49
Xach
xificurC: paul graham did not document all the features of common lisp. packages are not discussed in detail.
14:23:32
heisig
xificurC: If you really want to try this, use a code walker like https://gitlab.common-lisp.net/mraskin/agnostic-lizard and have AIF replace all symbols named IT with C::IT.
14:24:05
xificurC
so let me rephrase to see if I understood this: to use unhygienic macros across packages one would need to use a code walker
14:25:33
beach
xificurC: In fact, most of the anaphoric macros are weird and should probably be avoided altogether.
14:26:30
beach
It's a cute exercise in how the macro system can be used, but not particularly useful, and not particularly conform with other software-engineering practices.
14:28:14
heisig
xificurC: Here is one more solution: Your AIF macro could intern the name "IT" into the value of *package* that is used at macroexpansion time. But that would also violate some assumptions that readers of your code might have.
14:34:47
xificurC
as I said `aif` wasn't the particular example. This one was http://ix.io/2M0x . It's similar to what is in LOL but closer to a clojure-like anonymous function definition. I find the shortcut useful and code written with it clearer. However it doesn't work across package boundaries, just like any unhygienic code doesn't seem to
14:37:32
xificurC
looking into the LOL codebase I see the same issues, the unhygienic symbols `a1` `a2` etc don't solve this issue. I wonder why are these books given such high praise then, when you take some code from it and use it in a standard way, failing immediately
14:40:12
beach
xificurC: On Lisp is good for things like computations done at macro-expansion time, but not for anaphoric macros.
14:51:41
xificurC
mfiano the book went really hardcore into some custom closure-based OO design and I didn't really understand why would one want to do that instead of using CLOS. The macros were interesting and the sorting networks too
14:53:07
_death
xificurC: I would advise not using such macros in CL.. but in your particular, the issue likely stems from interning symbols in the current package where the reader macro is expanded (which is likely what you want) but the expansion refers to symbol (% %1) interned when the reader macro is defined.. so you should use the ones you interned instead
14:55:12
frodef
maybe for very application-specific things, where words have very particular meanings.
14:57:39
heisig
ACTION sees Clouseau's representation of complex numbers and goes on to rebind `C-c i'.
14:58:17
xificurC
I guess the number of APL fans here is very close to 0. Anything that allows expressing yourself more concisely is worth consideration
15:03:13
mfiano
It's mostly a book about "Hey, look at what macros can do", but the very opinionated coding style that ignores conventions and the use of anaphors make it very rare you will ever see code like this in the real world.
15:07:16
xificurC
like this? https://github.com/thephoeron/let-over-lambda/blob/master/let-over-lambda.lisp :)
15:11:54
aeth
xificurC: Lexical closures are the only true way of doing encapsulation that's not just by convention (I say this, but now someone might think of something more obscure). Lexical scope is so encapsulated that lexical variables might not actually exist for things like debuggers without (optimize (debug 3))
15:12:16
aeth
xificurC: So you could probably come up with a very niche situation where you need to do that. Very niche.
15:15:51
xificurC
aeth I actually loathe enforced encapsulation that cannot be broken. In the few years I work on the JVM there have been several bugs in 3rd party libraries that I was close to unable to overcome because of it. I think we're all adults and know the risk of using internal, subject-to-change parts of a library.
15:20:50
heisig
shka_: I am still experimenting. I will post my solution here as soon as it is presentable.
15:28:07
scymtym
heisig: one piece of the puzzle will probably involve updating the content of a persistent inspector window. one way to do that is (defvar *inspector* (nth-value 1 (clouseau:inspect INITIAL-VALUE :new-process t))) and later (setf (clouseau:root-object *inspector* :run-hook-p t) NEW-VALUE)
16:17:09
heisig
shka_: Here is my first draft: https://gist.github.com/marcoheisig/ddf35ad94e51fe9c3e5980759ef0fb70
16:22:22
heisig
scymtym: Yes, there are plenty of potential tweaks. Also, I should overload more than just `C-c i'. But that was already enough of a digression for one day.
16:24:51
heisig
Also, I am not exactly proud of referencing a symbol from clim-internals. Is there a better way to check whether a frame is still alive?
16:51:57
scymtym
heisig: maybe http://bauhh.dyndns.org:8000/clim-spec/28-5.html#_1560 ? the states are defined at the top of the page
17:11:22
adlai
Oh boy, here I go bearing bad news again! ... if anyone both industrious and stupid wants to volunteer to maintain yet another library slipping towards gitrot, it appears that Anaphora has been soft-abandoned.
17:12:00
adlai
[ as hinted by the maintainer, at https://github.com/tokenrove/anaphora/pull/10#issuecomment-757917329 ]
17:13:41
adlai
ACTION has anaphoric macros all over scalpl, even occasionally wrote a few of his own, although already has the volunteer hands more than full with wondering wtf to do about chanl's brokenness, an issue that blocks returning scalpl to official inclusion in various automated distributions.
17:16:37
adlai
while we're on bad news of abandonment: Henry Baker's paper archive has gone offline, apparently along with the entire webserver that hosted it. Wikipedia is already linking to https://web.archive.org/web/20200212080133/http://home.pipeline.com/~hbaker1/ although I do wonder whether anyone has available an archive of just the signal, to save others the trouble of sifting through HTML noise.
17:31:52
jackdaniel
you know what would be cool? displacing (unsigned-byte 8) array to (unsigned-byte 32) so first four elements in the former go through the first element in the latter
17:36:24
aeth
Another thing CL is missing that implementations could add is optimized heterogeneous 2D/3D/etc arrays.
17:37:03
aeth
so e.g. an array where every row looks like: single-float (unsigned-byte 8) double-float (unsigned-byte 32)
17:37:50
aeth
If it could reasonably be done as an extension, it would be compatible with portable CL since it'd just be a regular T array for those other implementations
17:38:59
jackdaniel
I'm rewriting McCLIM clx renderer to always use xrender extension: https://i.imgur.com/3Kb4gmH.png ; that's why I've asked (I can't simply "cast" array even when I know that bytes are in correct order)
17:41:44
adlai
however, provided that the array is an unboxed array of structs with unboxed immediates, that could have quite low overhead, if you have lots of state per cell.
17:41:48
aeth
adlai: you can get close if you put a bunch of different homogeneous arrays inside of a struct
17:42:57
aeth
adlai: you can't have an element type of a struct, that's just going to be T, and semantically speaking, it's not going to work to have an array of a mutable element like a struct work in a specialized way.
17:43:31
aeth
Whereas what I described would basically be like structs if you wrote the right kind of accessors, but without the semantic problems, although it would kind of mess with the concept of initial-element
17:45:48
aeth
An array row of (single-float (unsigned-byte 8) double-float (unsigned-byte 32)) is an array row of things that can all be an upgraded-array-element-type in arrays in reasonable implementations, just not all in the same array at the same time.