freenode/#lisp - IRC Chatlog
Search
13:07:28
reepca
for example: (defparameter test-array (make-array 10 :adjustable t :fill-pointer 0 :element-type '(unsigned-byte 8)))
13:07:51
reepca
(let ((*print-readbly* t)) (print test-array)) => #A((10) (UNSIGNED-BYTE 8) 0 0 0 0 0 0 0 0 0 0)
13:13:44
pjb
reepca: but you cannot use print, because it is not specified whether print uses print-object or not, and you cannot define print-object methods on standard classes such as array.
13:16:03
bitmapper
debugger invoked on a COMMON-LISP:UNDEFINED-FUNCTION in thread #<THREAD "main thread" RUNNING {10005084C3}>: The function SB-C::%MORE-ARG-CONTEXT is undefined.
13:19:11
boeg
I am trying to build a piece of software (the next browser) but it seems a common lisp error happens and it errors out. I get the error message thats put into the Makefile to make sure i have the xclip binary installed as well as developer files for sqlite and fixposix which I have in /usr/bin and in /usr/lib and /lib. I'm not sure if it's not able to find one or all of them or if something else goes wrong. Would anyone mind
13:19:11
boeg
look at the output from make and see if they can figure out what is wrong? It's here: http://ix.io/27sw
13:24:12
galdor
the error is The value "The root of all modes." is not of type LIST also called "do not use crappy stuff such as cl-annot which is dead, repo archived and unmaintained (and useless to start with)" or "test your code"
13:51:32
seok
if the complexity of gethash is O(1), isn't it better than arrays or lists in all cases for large dataset?
13:53:45
seok
phoe: so would that mean arrays are better in smaller sizes but hash better in larger ones?
13:54:09
Bike
you're not always using them for the same things, so comparing them may not be sensible
14:01:33
Nilby
Amortized O(1) + C is slower than exact O(1) + 0, especially when C is related to (length key).
14:15:04
pfdietz
Had a case recently where using string-case was much faster than intern, on a set of common symbol names.
14:15:06
pjb
seok: and here, you have integers as keys… Any other object would take a lot more time to hash.
14:15:55
pjb
pfdietz: you can usually exclude a case on 1 char=, and there are a finite number of cases, so you can select the right branch in basically O(1).
14:16:49
pfdietz
And you can play games with multiple character comparisons using (logior (logxor ...) (logxor ...) ...), which string-case does.
14:30:33
Nilby
Thinking about readably printing arrays made me try this experiement. Is there anything I missed? https://termbin.com/82c2
14:35:33
Bike
if you have two arrays displaced to the same array and you have print-circle you can reconstruct their sharing
14:36:33
_death
Bike: but then you want an actual displacement reference, rather than printing the data again
14:36:45
Bike
also if it is displaced you don't need the data. course you might have to recursively total-array-whatever-print the underlying array
14:42:34
_death
in reepca case it was also strange because he has an octet vector.. which usually don't have fill pointers, and usually are printed/read as octets..
14:46:03
reepca
fill pointer + adjustable was because there isn't a non-blocking way to read more than one byte at a time in usocket
14:50:37
_death
for adjustable, usually you know (or arrange to know) the size before-hand... for fill pointer, it makes sense, but for octet vectors I would consider having it separate so that you have a simple-array
14:51:28
boeg
How does it work when you have function with an argument list like `(defun aname (a (&rest argv) &body body) ()`? Doesn't &rest and &body kinda do the same?
14:53:15
Bike
it means it takes at least two arguments. the second argument is a list and fills argv, while any further arguments fill body.
14:56:45
p_l
I think it would look in use somewhat like (aname first-arg (argv list goes here) body...) ?
14:57:19
pjb
Nilby: note that if there's a displacement, you will want to have *print-circle* set to t, and deal with references.
15:01:25
pjb
Also, it looks like adjusting a displaced array to another displaced array so that there is a circle leads to an infinite loop.
15:05:03
pjb
Nilby: The problem is if you want to read back the printed-readably structure. If you just want to describe the structure, you can give all the information (a copy of it). But if you want to load back, you'd have to identify existing objects that are referenced. You get the ORM or OORM problem, with caching, identification of objects, etc…
15:21:57
pjb
Well, I'm not sure if it's completely specified. But basically, it assumes the current readtable. So if you print a symbol, you might not be able to read it in a different readtable, because it's not printed fully qualified and cased |FOO|:|BAR| would be the most readably. However, since again it depends on the readtable, it depends on the reader macro that could exist on #\|.
15:22:21
pjb
So something printed readably is not really stand alone. You must specify along the readtable.
15:26:40
_death
with-standard-io-syntax binds *package* and *readtable* .. though that wouldn't solve all issues of course
15:33:48
pfdietz
I would like to see similar tricks used for intern itself, at least for standardized packages or packages that import from them. Perhaps even dynamic code generation there.
15:38:00
pfdietz
The special case being keywords are printed with : even if the current package is the keyword package.
15:44:02
pfdietz
I now am trying to remember if symbols in other packages can be imported into KEYWORD.
15:49:32
pfdietz
Does importing a symbol into a package count as "interning" it? From glossary: intern v.t. 1. (a string in a package) to look up the string in the package, returning either a symbol with that name which was already accessible in the package or a newly created internal symbol of the package with that name.
15:50:06
pfdietz
But this does not happen in SBCL when a symbol belonging to another package is imported into the keyword package
15:50:27
pjb
pfdietz: yes, in one case: "If any symbol to be imported has no home package (i.e., (symbol-package symbol) => nil), import sets the home package of the symbol to package."
15:51:37
pjb
This is why the homeless symbol imported into keyword becomes a symbol. (symbol-value (find-symbol "FOO21312" "KEYWORD")) #| --> :foo21312 |#
15:51:40
pfdietz
The standard makes a distinction between being interned in a package, and having a package as the symbol's home package.
15:53:55
pfdietz
No. Simply importing a symbol into a package counts as interning it in that package.
15:56:53
pjb
And when those homeless symbols are imported into keyword, they must become symbols (bound to themselve, become constant variables, exported from keyword). If the implementation doesn't do that in this case, it's a conformity bug.
16:00:09
pfdietz
What should happen is that the symbol becomes a keyword. For example, it should become a constant that evaluates to itself.
16:04:46
Nilby
Sadly, this is why my sbcl version will always come up as dirty: https://termbin.com/2i8d
16:05:01
Xach
pfdietz: i could see an argument that the magic of intern happens in the "or a newly created" branch
16:05:47
pfdietz
But "intern" as a verb includes both cases. So I don't see how that inrepretation is consistent with the standard.
16:11:42
Xach
pfdietz: intern is approximately (or (find-symbol name package) (let ((sym (make-symbol name))) (import sym package) sym))))) - you're arguing that the find-symbol step should also include the work of making the symbol constant, self-valued, and external, if it isn't already?
16:15:02
pfdietz
Regardless, SBCL fails to do the special keyword processing even if one subsequently calls intern to get that symbol.
16:16:04
Xach
it's kind of regardful, because to get that behavior you'd need to do a lot more work in the find-symbol branch
16:19:09
pfdietz
"unintern removes symbol from package. If symbol is present in package, it is removed from package and also from package's shadowing symbols list if it is present there."
16:19:39
pfdietz
This implies being present in a package means the symbol is interned in the package.
16:20:47
pfdietz
As opposed to being accessible merely by means of inheritance from another package via use-package.
16:22:21
pfdietz
So there's an inconsistency here between intern and unintern. A symbol could continue be returned by intern even if unintern had been called.
16:24:18
pfdietz
In any event, even if we take the more restricted defn of interning, that it doesn't include accessible but not present, there's a bug here.
16:27:40
Nilby
I'm thankful they could agree on the flawed package system so at least we're not stuck with problems like Elisp.
16:38:29
Nilby
Another example you've probably considered is implementing something like Emacs's buffer local variables in the CL package system.
16:42:54
beach
It appears to be a widespread sport to find flaws in the standard, and to wish for the standard to be updated. However, most of the suggestions are made by people (not targeting you Nilby) who know nothing about language design, so they do not know the consequences that their suggestions might have. And they certainly don't know the constraints in the form of historical decisions and time pressure the committee had to deal with.
16:44:59
aeth
As far as finding flaws in the package system (or anywhere), I'd look at hacks that people do to work around the lack of features which they wish they had. For packages, I think what's missing is hierarchical packages because the foo/bar naming idiom is so common. This would not be easy to design and add, though.
16:46:11
Nilby
beach: I agree. Every *read-X*, *print-x* variable has consequeces, problems, and trade offs that are difficult to understand.
16:55:05
pjb
Nilby: HOWEVER, those variables, the printer and the reader, must be understood as development tools, to help debugging (and basically implement the REPL, the debugger, and inspect). They are not industry streight tools to use in your applications. For your application, it is understood that you will have to implement your own I/O and validation functions!
16:56:25
beach
aeth: So for example, the existence of all those people who wish that SYMBOL-VALUE, EVAL, etc. had access to lexical variables would indicate a flaw in the standard. And we should fix it, thereby making compilation of Common Lisp essentially impossible.
16:58:45
beach
All I am saying is that there is often more to it than just lamenting the lack of a particular feature.
17:02:28
ralt
I often have this snippet in my projects for package aliases... https://www.irccloud.com/pastebin/yjVAmMZI/
17:05:14
beach
Package-local nicknames solve a real problem. But that does not imply that the standard is flawed.
17:07:22
beach
ralt: Exactly. And that is particularly clear when you notice that people use languages on a daily basis that don't even HAVE a standard.
17:08:36
ralt
something that _is_ a bit odd with Lisp, is that as opposed to many languages, anything can be outside of the standard. In many languages, if it's not supported by the language, you're SOL, so there is often a strong argument to put that in the main place. Not so for Lisp.
17:10:19
Xach
pfdietz: if you define an "interned symbol" as one that was created through the intern process I think you can rationalize the current behavior.
17:12:06
beach
_death: I must be tired (after a long day), but I don't know what joke you are referring to.
17:14:37
_death
beach: it's US-centric joke.. in the US "chapter 11" means bankcruptcy.. the CLHS Packages chapter is chapter 11.. during the package flamewars associations were made
17:17:26
beach
So anyway, there are very few things in the standard that prevent me from doing my work, and those that do are easy to get around. At the same time, there is a lot of work to be done with what the standard provides.
17:39:37
pfdietz
There are problems with the standard, but you have to have some experience to find the real ones.
17:42:29
pfdietz
Another large class of problems are things that are problems, but not significant ones. Edge cases that language lawyers enjoy but that have little practical importance.
17:46:57
pfdietz
If I had to choose between "fixing/expanding the standard" and "fixing/expanding available libraries", I go with the latter in a heartbeat. Admittedly, the boundary is a bit blurry.
17:52:56
galdor
do you consider introducing packages that all implementations implement the same way "expanding the standard" ?
17:53:44
beach
No, that's just "widely agreed-upon libraries". There are plenty of those, and they are good.
17:53:48
galdor
if you take bordeaux threads, I find it curious to end up with a library instead of having implementations follow the bordeaux thread pseudo standard, which would allow every one to use, e.g. threads:make-thread without having to import a library
17:55:14
beach
galdor: It is much easier to use a library than to convince all the maintainers of all the implementations to add the same thing.
17:55:54
Shinmera
not to mention convincing them to possibly change an interface if they already have users for it.
17:56:21
pfdietz
That's the blurry part. Are de facto standard libraries part of the standard? I'll go with whatever answer makes things easier.
17:56:53
pfdietz
Having a better social process for creating standard libraries, now that's interesting and useful.
17:56:57
Shinmera
galdor: I'm sure people would prefer it if all implementations offered all of the possible features.
17:57:36
pfdietz
Having better use of standard libraries (for example, encourage explicit import rather than :use) would be valuable.
17:58:10
galdor
in practice, the thing is that the vast majority of implementations won't change anything because they are in low maintainance mode and won't ever evolve
17:58:50
galdor
but at some point, who cares if only 2 or 3 implementations do the work, others are dead anyway
17:59:49
Xach
the conditions for change vary but I don't think it's the case that they won't change anything.
17:59:51
pfdietz
They keep extending C and C++ even though each of those has large numbers of effectively dead compilers.
18:00:47
Shinmera
For example, I think by now only Allegro is lacking PLNs (and hasn't announced adding them)
18:03:27
galdor
as for Allegro and LW, I'd honestly love to know at which point they actually have a tech roadmap on their implementations or if they just rack up license fees with old clients (not that there is anything wrong with that)
18:16:07
p_l
galdor: Franz is actively doing a second-hand lisp business in the form of selling stuff built on top of AllegroGraph
18:20:29
pfdietz
the interesting question is to what extent Franz depends on external libraries that may stop working for them because of PLNs
18:30:04
galdor
if I look at the first repository, imap, it's essentially unmaintained and clearly Allegro only
0:12:44
aeth
beach: The problem with the lack of hierarchical packages leading to the foo/bar package name idiom as a convention to work around that isn't the same class of problem of "add it and then the language can't be compiled". It's more likely to be in the class of problem of something that probably didn't exist back in the early 1990s so no one even thought about it.
0:14:32
aeth
In 1995, I don't think large projects with hierarchical packages were a thing in many languages, even if possible. When I think about that, I think about Java (which is possibly the most rigid enforcing of this sort of thing, definitely not something to emulate) or Python (which definitely existed, but wasn't popular until the 2000s)
0:15:02
aeth
Both Java and Python afaik tie this sort of thing to the directory structure of the program, which is kind of a non-starter for CL.
0:16:59
phoe
yeah, ASDF's bundle-op would give you a really weird look if you tried to do that same thing
0:21:04
aeth
And beyond that, the further back you go, I'd bet you'd observe that a CL project is more likely to be just all at the top level with one package, i.e. foo/*.lisp whose sole package is foo/package.lisp
0:23:36
HiRE
What is the (:use :cl) used for defpackage? I mean, I would assume it means "use common lisp" but I find the notation funny since it's being written _in_ common lisp
0:24:13
aeth
e.g. the initial McCLIM git repo (probably converted from CVS/SVN/etc.) from as recent as 2000-06-08 didn't have subdirectories for the core *.lisp files: https://github.com/McCLIM/McCLIM/tree/3cb03ba6a0bfbd54e5076b20b627905d5517f043
0:25:05
aeth
I mean, oh wow, 1164 clim-package.lisp that's mostly just one giant defpackage. https://github.com/McCLIM/McCLIM/blob/3cb03ba6a0bfbd54e5076b20b627905d5517f043/clim-package.lisp
0:26:16
aeth
So, I mean, 1990s CL is very stylistically different than 2010s CL, which is why you don't really see the need for hierarchical packages... just have one giant package.lisp contain everything with one giant defpackage > 1000-lines
0:27:05
aeth
These days I'm guessing you'd want at least 10 packages with a top package that does something like uiop:define-package's use-reexport instead of having a giant 1000+ line defpackage.
0:27:13
Xach
reminds me of how one of the clisp maintainers complained that quicklisp cluttered up the system by adding too many packages.
0:29:11
aeth
Xach: It is a fairly valid complaint, however it's worse to have a 1000-line DEFPACKAGE. Hierarchical packages means you get the best of both, needing to only expose one or a few top-level packages while still being able to, well, read any given DEFPACKAGE.
0:29:44
pjb
HiRE: you don't necessarily write Common Lisp code to run on a Common Lisp implementation!
0:29:45
aeth
ASDF these days sort of strongly encourages a multi-package design to be FOO/BAR which is just a hack to only somewhat polute the package namespace, in a way that's very unlikely to collide
0:30:28
pjb
HiRE: so for example, when you write a CLIM application, you don't use CL, you use CLIM instead. You don't get the same defclass and defmethod macros amongst other changes.
0:30:57
HiRE
Interesting. That's good to know. It was sort of given matter-of-factly in PCL so I was curious
0:31:11
pjb
HiRE: or you can run LISP 1.5 code from 1962: http://informatimago.com/develop/lisp/com/informatimago/small-cl-pgms/wang.html
0:31:18
aeth
A clever specification of hierarchical packages could probably define it in a way that's compatible both with unmodified CL implementations and extended ones, but then it would assign semantic meaning to / in the name of a packags.
0:31:57
pjb
HiRE: this is why any criticism of Common Lisp is usually untimely, since you can just define your own lisp package and use it instead of CL.
0:33:26
pjb
In 1990, you wouldn't fetch thousands of libraries from the Internet… Software Engineering of CL software has much improved during the last 20 years, only thanks to asdf, quicklisp and the Internet.
0:33:30
aeth
hmm, actually you could define separator characters in hierarchical packages and so if you want #\\ or #\. or #\/ then no matter what you can have it.
0:34:33
aeth
HiRE: as far as (:use :cl) goes, you could e.g. (:use :r7rs) and get R7RS Scheme with symbols such as |car| and |cdr| and |list| instead of CAR and CDR and LIST
0:35:04
aeth
CL has always been a language for writing languages. It would be far easier to do something like JS's TypeScript in CL than it is in JS, and it would be "built-in" rather than an additional compilation step
0:35:23
HiRE
thats so interesting. I guess thats the power of lisp. Makes sense, just mindboggling coming from a professional programming life of if you write it one language everything must be in that language
0:36:04
aeth
As far as doing something like TypeScript in CL, it's almost an introductory project to do a type-declared DEFUN macro. There are probably like 50 of those. There's at least one that's fancier than that and tries to do a fancier ML-style type system, though.
0:37:15
aeth
HiRE: Scheme, not CL. The author of JS was originally going to implement a Scheme, but that was rejected based on the syntax. Not much was borrowed from Scheme, although since idk 2007 or so people have been adding parts of Scheme to JS to try to justify the origin myth.
0:37:47
aeth
So at this point "JS is inspired by Scheme" is probably true, even though it was once false.
0:37:56
HiRE
oh I didnt even realize it was at least a partial truth. I figured it was just another jab using greenspun's 10th rule.