jello_pudding has quit [Ping timeout: 240 seconds]
X-Scale has joined #commonlisp
X-Scale63 has quit [Ping timeout: 260 seconds]
jello_pudding has joined #commonlisp
X-Scale81 has joined #commonlisp
X-Scale has quit [Ping timeout: 260 seconds]
NicknameJohn has quit [Ping timeout: 252 seconds]
nij- has joined #commonlisp
asarch has joined #commonlisp
mingus has joined #commonlisp
epony has quit [Remote host closed the connection]
kevingal has joined #commonlisp
kevingal_ has joined #commonlisp
mingus1 has joined #commonlisp
mingus has quit [Ping timeout: 260 seconds]
mingus1 is now known as mingus
asarch has quit [Quit: Leaving]
epony has joined #commonlisp
waleee has quit [Ping timeout: 248 seconds]
Lord_of_Life has quit [Ping timeout: 255 seconds]
Lord_of_Life_ has joined #commonlisp
Lord_of_Life_ is now known as Lord_of_Life
czy has quit [Remote host closed the connection]
X-Scale81 has quit [Quit: Client closed]
dcb has quit [Quit: MSN Messenger 3.8]
kevingal_ has quit [Ping timeout: 250 seconds]
kevingal has quit [Ping timeout: 250 seconds]
nij- has quit [Ping timeout: 255 seconds]
hineios has quit [Ping timeout: 265 seconds]
bilegeek has joined #commonlisp
hineios has joined #commonlisp
jonlevin has quit [Ping timeout: 265 seconds]
bilegeek has quit [Ping timeout: 248 seconds]
djhas-kin has quit [Ping timeout: 248 seconds]
bilegeek has joined #commonlisp
jonlevin has joined #commonlisp
bird_ has quit [Ping timeout: 260 seconds]
djhas-kin has joined #commonlisp
bilegeek_ has joined #commonlisp
nij- has joined #commonlisp
bilegeek has quit [Ping timeout: 268 seconds]
bird_ has joined #commonlisp
bilegeek has joined #commonlisp
bilegeek_ has quit [Ping timeout: 265 seconds]
jeffrey has quit [Quit: Client quit]
bilegeek_ has joined #commonlisp
bilegeek has quit [Ping timeout: 255 seconds]
bilegeek_ has quit [Ping timeout: 248 seconds]
hirez has quit [Quit: Later]
hirez has joined #commonlisp
czy has joined #commonlisp
zyd has joined #commonlisp
kenran has joined #commonlisp
rgherdt has joined #commonlisp
shka has joined #commonlisp
azimut has quit [Ping timeout: 255 seconds]
<beach>
Here is a project suggestion for someone interested: Create a library of all the functions in the Conses dictionary of the standard, excluding CAR, CDR, CONS, RPLACA, and RPLACD. It is not as trivial as it might seem because there are some nontrivial compiler macros that should probably be included.
<beach>
The library should be usable both as an intrinsic and as an extrinsic library.
<beach>
By "intrinsic", we mean that it will then serve as the only implementation of the Conses dictionary in a particular Common Lisp implementation.
<beach>
And "extrinsic" is the opposite, i.e., it should be possible for an existing Common Lisp implementation to load the functions in the library and use them independently of its native functions.
<beach>
It should provide great documentation strings, of course. Unlike (say) the documentation for CAR in SBCL: "Return the 1st object in a list."
epony has quit [Remote host closed the connection]
rgherdt_ has joined #commonlisp
rgherdt has quit [Read error: Connection reset by peer]
epony has joined #commonlisp
nij- has quit [Ping timeout: 265 seconds]
rgherdt_ is now known as rgherdt
<splittist>
An etymological dictionary of common lisp would be interesting. "CAR. Appears in the first LISP ... Inherited from IBM 704 macro assembler... Stands for 'contents of the address part of register number'. See also CDR." (Actually, this is a silly example. Something teasing out the history of the various MAPs would be better.)
<semz>
beach: sounds fun; what kind of compiler macros are you think of though?
<beach>
For MAPCAR etc, with a fixed number of lists. It gets messy to handle an arbitrary number of lists.
<beach>
Actually, I'll probably start this library myself. I just had an idea on how to improve error messages from functions like CADADR without forcing the user to decipher an error message from CAR or CDR.
<splittist>
"Warning: using CADADR - are you sure you want to destructure like this?"
<beach>
Fair enough. Make that SECOND then.
<semz>
fair warning tbh
morganw has joined #commonlisp
dieggsy has quit [Quit: You have been kicked for being idle]
random-jellyfish has joined #commonlisp
random-jellyfish has quit [Quit: Client closed]
pve has joined #commonlisp
shka has quit [Ping timeout: 250 seconds]
random-nick has joined #commonlisp
repeter has left #commonlisp [ERC 5.4 (IRC client for GNU Emacs 28.1)]
notzmv has quit [Ping timeout: 265 seconds]
cage has joined #commonlisp
kenran has quit [Remote host closed the connection]
jeosol has joined #commonlisp
X-Scale has joined #commonlisp
jeosol has quit [Quit: Client closed]
dipper has joined #commonlisp
fe[nl]ix has quit [Remote host closed the connection]
fe[nl]ix has joined #commonlisp
jeffrey has joined #commonlisp
McParen has joined #commonlisp
McParen has quit [Remote host closed the connection]
McParen has joined #commonlisp
Guest86 has joined #commonlisp
notzmv has joined #commonlisp
jmdaemon has quit [Ping timeout: 248 seconds]
dipper_ has joined #commonlisp
dipper has quit [Ping timeout: 265 seconds]
kenran has joined #commonlisp
jeffrey has quit [Ping timeout: 252 seconds]
kurfen has quit [Remote host closed the connection]
<ixelp>
Constrictor/accessors.lisp at master · robert-strandh/Constrictor · GitHub
azimut has joined #commonlisp
McParen has quit [Remote host closed the connection]
attila_lendvai has quit [Quit: Leaving]
<_death>
I'm not sure I get the use of inline-notinline.. also, won't this result in many unnecessary type checks? and what about a macro to generate these similar definitions?
<beach>
The inline/notinline is from the standard.
<beach>
With path replication, I don't think there will be any additional type checks.
<beach>
I macro could indeed be a possibility.
<_death>
I see, it retains the definition so that you can later declare them inline locally.. ok
<beach>
Yes, that's the idiom apparently.
<_death>
maybe I'd have an nthcdr with a suitable compiler macro for small integers
<beach>
Sounds good.
dipper_ has quit [Ping timeout: 276 seconds]
attila_lendvai has joined #commonlisp
lucasta has joined #commonlisp
<jcowan>
In addition, NOTINLINE allows you to suppress inlining for debugging and tracing purposes.
<jcowan>
Which is why it is a declaration that must be applied.
<beach>
Right. I think what I came up with gives maximum flexibility for the client.
<beach>
... while retaining the best performance when the client decides not to inline.
<beach>
But the best part is that error messages are signaled by the function that was really invoked by client code, and not just by CAR and CDR.
<random-nick>
why are all these ca...r functions written out instead of generated by a macro?
<beach>
Because I couldn't come up with a macro right away. Plus, I am not so sure it will be more readable with a macro. I might be wrong of course.
<beach>
Documentation strings will have to be included as well. That might be tricky with a macro.
<_death>
the docstrings will probably be similar as well
<beach>
Sure.
<beach>
"This function is equivalent to (CAR (CDR LIST)), except that error messages are reported directly from this function and not from CAR or CDR."
<splittist>
Ha.
<beach>
make that "... errors are signaled directly by this function, rather than..."
<_death>
for clarity, it depends on the macro.. it could be a macro that generates all the definitions at once, or a macro that generates a single definition.. often I find the latter (which results in repeated macro forms) to be clearer, and possibly define a macro of the former kind that expands to the latter
<splittist>
It seems to me worth having this stuff written out in case one finds patterns in documentation/errors that are more complex than a tractable macro could handle.
<splittist>
These are functions that only exist because someone came up with a clever macro to write them.
* _death
wonders, where is NTHCAR? :)
dcb has joined #commonlisp
X-Scale has joined #commonlisp
<random-nick>
also, is LIST the correct name for the parameter? it's not necessarily a list
<random-nick>
CLHS uses X, but that's not very descriptive
<_death>
what is it if not a list?
<random-nick>
hmm actually, I was thinking about list meaning proper list
<random-nick>
but if "list" is understood to include improper lists then it is always a list
<random-nick>
_death: cons tree?
<_death>
(car nil)
nij- has joined #commonlisp
<random-nick>
_death: fair point, any atom can be a tree but only the atom NIL can be a list
<nij->
I'm trying to use https://sr.ht/~shunter/posix-shm/ but quickloading it has an error: "Couldn't execute "c2ffi": No such file or directory"
<ixelp>
posix-shm: POSIX shared memory bindings for Common Lisp
<nij->
c2ffi doesn't seem to be a standard thing out there either.. any thoughts?
<_death>
random-nick: you can represent non-tree structures as well
<_death>
nij: at least it's a searchable term
<random-nick>
nij-: it's a separate C or C++ program you have to install
<beach>
LIST is the type that means (OR CONS NULL), and the parameter is named after the type.
<random-nick>
one of the binding generators uses it, forgot what it's called
<nij->
edwlan Oh I see. I don't have to install it as a library.
Gleefre has joined #commonlisp
lucasta has quit [Quit: Leaving]
<cdegroot>
Question - my other favorite language (Elixir) has a thing I love: a default, everybody uses it, gorgeous documentation creation tool (hexdocs.pm). I've been digging around in CL land, and as usual "There's Way More Than One Way Of Doing It" :-) (https://cliki.net/documentation%20tool). Is there a tool that stands out and - dare I hope - people are converging on? I find that creating nice docs is a self-reinforcing mechanism: you want to create more of
<cdegroot>
beach: it's CL's biggest weakness, that "let's settle on good enough" is never good enough - thanks for the link :)
<beach>
cdegroot: But we are (slowly) working on a tool for creating documentation. I seriously doubt that it will create some kind of consensus.
edgar-rft has quit [Quit: Leaving]
<cdegroot>
I think the last time that consensus happened was in 1994, when X3J13 published their work. I'll go through that list and find something to my liking or create a new tool myself, then :)
<beach>
cdegroot: Common Lisp is a standard with multiple implementations. I don't know whether Elixir has a standard and/or multiple implementations. But it is hard to compare a language with multiple implementation to a single implementation. In the latter case, often no consensus is required, because there is only one thing to choose from.
<random-nick>
but I don't know if its internal representation is flexible enough for the various input and output formats out there
<_death>
if hexdocs.pm is so great, why not have it support CL?
<beach>
random-nick: As it turns out, it was not quite what I was asking for, but I don't remember the details right now.
<cdegroot>
beach: not necessarily, of course. I mean, Java is a good example (and I think set the way for a lot of later work) by coming with good source code documentation tools out of the box and that set expectations. Everybody had the same tool, everybody started using it for their own code (as it was pretty much part of the language), and that example (I think it's the earliest one I remember) got followed by others. If a second implementation of Elixir
<cdegroot>
would happen, it would support the doc standard.
<beach>
cdegroot: Java does not have a standard.
<cdegroot>
De facto, it does. Javadoc tags are what you use.
<cdegroot>
_death: that'd be a niche of a niche. Also, relying on Elixir to create CL docs? Fun experiment, but I don't think it's gonna gain traction lol
<beach>
cdegroot: When I say that a language has a standard, I exclude the case where the same organization controls the definition of the language and the main implementation of it.
<beach>
Especially if that organization is a commercial company.
<_death>
cdegroot: so hexdocs.pm is quite a limited tool that you like but not enough to extend to make it work with your favorite language?
<cdegroot>
That is pretty much every language, then. Python has a de-facto standard; Perl has (had for ages?); Java, Elixir, I'm sure I can come up with more examples. The point is not that whether the standard got created by a commercial entity of a person hacking alone or an ANSI committee - the point is that these are de facto standards that were good enough that people converged around them, and I think in each case, that hugely helps the ecosystem. Anyway, I
<cdegroot>
didn't want to turn this into a discussion about what the CL community should do, it was just a question about what the community is doing.
<cdegroot>
_death: that's not fair, of course. Software built for a specific purpose and being good at it is often sufficient. Heck, hexdocs barely supports Erlang (Elixir's "parent" language) as that was never the goal, it's now slowly moving there. Integrating documentation markup with language conventions is not easy.
<cdegroot>
I would still qualify it as a very successful piece of software regardless.
morganw has quit [Remote host closed the connection]
slyrus has quit []
<_death>
cdegroot: as you noted there are several projects aimed at helping produce documentation.. in a bottom up ecosystem, the way to a de facto standard is creating a tool that satisfies the desiderata of a critical mass of users
<cdegroot>
yup. So my question was pretty much about whether one of the many tools available has started going there.
<jcowan>
_death: Well, that's one way. On the other hand, one can also be a tool that rises to leadership of the world while satisfying the desiderata of just one person
<_death>
I don't have any statistical summary for that unfortunately.. I do know mgl-pax has more than a single user (as Kenny Tilton once speculated, that may be considered a success in the lisp world :) .. for my own stuff I use texinfo w/ a somewhat modified sb-texinfo.. there was also a system called helamdap that I don't see on cliki
<_death>
jcowan: that's why I mentioned "bottom up"
<jcowan>
Fair enough.
<cdegroot>
Yeah, I think I'm gonna hone in on anything with a texinfo backend, given that it produces decent HTML these days. No need to reinvent wheels there.
<edwlan[m]>
I use quickref occasionally
<edwlan[m]>
I’d prefer the documentation to be built on swank/slime rather than be some sort of statically generated artifact.
<edwlan[m]>
Or, really, in some tool designed for generating live documentation of the currently loaded code.
<_death>
edwlan[m]: for that there's slime-doc-contribs and manifest, at least
<markasoftware_>
How do you emulate Python's @classmethod in cl? That is, a method which follows the same inheritance rules as a class, but doesn't require an actual instance of the class?
<markasoftware_>
in cl for any non-instance method I would just pass the symbol of the name of the class as the first argument, but then you don't get inheritance
<edwlan[m]>
You can specialize on eql to a symbol and then call the generic function with (class-prototype (find-class sym))
<ixelp>
fwoar.lisputils/patmatch.lisp at 5e0d458a4d70e35fea74ecc1edc3352d26b2b74e · fiddlerwoaroof/fwoar.lisputils · GitHub
<edwlan[m]>
The prototypes of builtin classes aren’t useful, so you have to special case things like vector, though
notzmv has quit [Ping timeout: 248 seconds]
kurfen_ has joined #commonlisp
kurfen has quit [Ping timeout: 255 seconds]
phantomics has quit [Ping timeout: 255 seconds]
d0g has joined #commonlisp
monoidog has quit [Ping timeout: 276 seconds]
phantomics has joined #commonlisp
d0g has quit [Quit: Leaving]
<pve>
markasoftware_: You could emulate it by defining an additional class (like a "metaclass", but still a standard-class in this case) for each class you define. You would then specialize your class methods on these "metaclasses" and they would follow the same class hierarchy as the regular classes, only on the metaclass side. Only one instance of each "metaclass" would need to exist.
<markasoftware_>
It does seem like class-prototype would do the trick here. Thanks edwlan[m]!
karlosz has quit [Quit: karlosz]
<jcowan>
In a sense, every objects is an improper list: thus 5 is an improper list of length 0
<_death>
jcowan: not in CL sense
<jcowan>
No.
<jmercouris>
I don't get it, how is 5 an improper list of length 0?
<jcowan>
Not if you define the length of a list as the number of times you can apply "cdr" to it (or to put it another way, the number of conses it has)
<_death>
without the parenthetical remark, NIL has an indefinite length :)
<jcowan>
so if (1 2 . 3) is an improper list of length 2, then (2 . 3) is an improper list of length 1, and 3 is an improper list of length 0, analogous to proper lists (1 2), (1), and ().
<jcowan>
_death: Well, that's Interlisp for you
<jcowan>
the rule that (car nil) = (cdr nil) = nil is borrowed from Interlisp
Noisytoot has joined #commonlisp
<_death>
but does interlisp have this definition of length
<_death>
hmm I'm abroad and I don't have my lisp manuals directory on this laptop :(
amoroso has joined #commonlisp
amoroso has quit [Client Quit]
dilated_dinosaur has quit [Ping timeout: 264 seconds]
<masinter>
jcowan if you "borrow" something, you're saying you intend to give it back
<jcowan>
Not if you're a linguist.
<masinter>
Interlisp isn't defined by the manual, it's defined by the implementation. The manual describes the implementation
<masinter>
like in english, unlike french, there is no Acadamie Anglais
<jcowan>
Sure. But l'Academie doesn't define French either.
<jcowan>
However, here's Milton in 1649: "It is not hard for any man, who hath a Bible in his hands, to borrow good words and holy sayings in abundance; but to make them his own is a work of grace only from above."
<masinter>
well, it tried to, at least, that's what Nunberg was saying
<masinter>
he was usage editor of the American Heritage
<ixelp>
GitHub - mbattyani/cl-pdf: CL-PDF is a cross-platform Common Lisp library for generating PDF files.
<masinter>
how much do I have to do to get that to run?
<jcowan>
In 1398, we have "The mone hath no lyght of herself, but borowyth and takyth of the plente of the sonne." The same applies to "borrowing" in subtraction. The OED explains: "The essential notion of borrowing originally was the security given for the safety of the thing so taken: the essential notion now is that the thing is the property of another and liable to be returned, the only security given being often the undertaking, formal or
<jcowan>
implied, that it shall be so returned when we have used it."
<_death>
masinter: (ql:quickload "cl-pdf") works for me
<masinter>
no quikload
<_death>
what about asdf? you can (asdf:load-system "cl-pdf") and it'll work if you have it and its dependencies somewhere asdf can find them
<_death>
otherwise you'll may resort to writing a load script based on the system definition
<masinter>
well, the repo has a lot of .lisp files. I imagine i need to load them
<masinter>
it's just the order?
MajorBiscuit has joined #commonlisp
<masinter>
so, line 1. What is #:pdf?
<yitzi>
inside IN-PACKAGE?
<_death>
cl-pdf.asd contains a system definition.. first you need to look at its :depends-on section and load the dependencies (they too have system definitions).. then the :components section contains a representation of a dependency tree for the files
<_death>
(a polytree in the general case) in this case a root is defpackage.lisp that defines the "PDF" package
dilated_dinosaur has joined #commonlisp
NicknameJohn has quit [Ping timeout: 255 seconds]
attila_lendvai_ has joined #commonlisp
attila_lendvai has quit [Ping timeout: 248 seconds]
<_death>
(correction: it's a dag of course, not sure why I limited to polytree)
<masinter>
why do you need a #:pdf when you could just use :pdf?
<_death>
it's a style decision.. in general so it wouldn't unnecessarily clutter the keyword package (thereby making autocompletion less useful)
<masinter>
it seems un-lisp-like to have this separate declaration
<masinter>
and autocomplete should be driven off actual use, not what things happen to be interned
<_death>
well, I do use M-/ (dabbrev-expand) a lot.. but sometimes want to expand say :i-f-n-e .. if someone had :i-forgot-nothing-easily it would just interfere
<masinter>
The idea is to use Interlisp-style file manager for common lisp
<masinter>
if you want a flat listing you export
<_death>
not sure I understand what you mean
<_death>
do you mean that the defpackage form is unlispy?
<masinter>
defpackage is ok
<masinter>
i suppose
<_death>
you'd rather use the export function?
<masinter>
i used to know a lot about common lisp
<masinter>
not so much about packages
<_death>
well, you could use the export function and so avoid keywords/uninterned symbols/strings, just do something like (export '(foo bar)) within the package
<masinter>
incremental development meant you could define things before you had decided what you had to export or not
<_death>
sure, you still do that..
<masinter>
now the README says to edit config.lisp
<masinter>
and there are a bunch of #+ and #-'s at the head
waleee has joined #commonlisp
<masinter>
and its defining +EXTERNAL-FORMAT+
<masinter>
what's with the +plus+ +signs+ ?
<_death>
right, using nonstandard extensions..
<_death>
some people use +foo+ to designate constants.. although in this case, it shouldn't use a constant but a special variable
<masinter>
external format is a stream property, not a global
<_death>
well it's passed around by cl-pdf when opening streams
<masinter>
so what's (defconstant +external-format+..) doing?
<masinter>
so implementations have only one external-format supported?
<_death>
no, cl-pdf has some with-open-file forms where it passes the value of +external-format+
morganw has joined #commonlisp
notzmv has joined #commonlisp
<masinter>
common lisp is chock full of implementation-dependent things
<_death>
sure
<masinter>
like the value of the :external-format parameter
cage has quit [Quit: rcirc on GNU Emacs 28.2]
<_death>
I guess in this case it's a good thing that it was not defined by CL standard
<masinter>
there's no good reason why :an external-file-format-designator should be implementation dependent
<masinter>
we were clueless
<yitzi>
I don't think you can look at one lisp system and conclude that CL is full of implementation specific code. In my experience one does not need to use conditional compilation for most systems.
<masinter>
i'm looking at CLHS
<masinter>
i can say with some authority that X3J13 never really considered interoperaibility without conditional compilation to be a criteria
<masinter>
a criterion
<_death>
that way CL standard doesn't need to play catch-up with unicode and other standards, just implementations
<masinter>
i was on the extended charset committee
<_death>
well, what would you have standardized instead?
<yitzi>
masinter: I don't understand what you mean by "without conditional compilation to be a criterion."
<masinter>
There are good standards and bad ones
<masinter>
One of the criteria for a good standard is interoperability
<masinter>
when two implementations are conforming, they work together
<jmercouris>
I will still need to convert to vector...
<jmercouris>
Hm, really wants a stream ideally
<_death>
right, I think the way is (format (socket-stream socket) "foo")
<_death>
usocket is weird like that
<_death>
usocket:with-client-socket does the connect and binds a stream
<jmercouris>
yes probably
<jmercouris>
let me give it a try
dcb_ has joined #commonlisp
dcb has quit [Quit: MSN Messenger 3.8]
dcb_ is now known as dcb
dcb has quit [Quit: dcb]
dcb has joined #commonlisp
<jmercouris>
why is this API so bad?
<jmercouris>
is there a layer on top of this I can use?
<_death>
why do you consider it bad?
<jmercouris>
I don't know, just seems obtuse, I wish there was some simple thing like (write-string "address" "port" "message")
<_death>
well, didn't you just write such a function?
<jmercouris>
anyways, I guess I'll just deal with this API, I got it to work, so that's what counts
<jmercouris>
I will write such a function
<jmercouris>
sorry, yes, wrong tense
<jmercouris>
*wrote*
dcb has quit [Client Quit]
kenran has quit [Remote host closed the connection]
dcb has joined #commonlisp
<_death>
I don't often use usocket, so I have to figure it out every time
<jmercouris>
that's precisely the problem, it should be more easy
<jmercouris>
how often do you think I use it? this is probably like the fourth time ever
<edwlan[m]>
usocket is supposed to be pretty low-level
<_death>
there are other designs that are easier for me to "figure out", either because they're more like the C API (sb-bsd-sockets) or they have a simple and more limited interface (say gbbopen sockets support)
<edwlan[m]>
I’ve never found its API bad, it just forces me to think about things I don’t have to think about often.
<edwlan[m]>
But, I think you can use write-sequence or with a string if you declare the element type correctly
<edwlan[m]>
But it’s been a while since I’ve tried
lucasta has joined #commonlisp
<jmercouris>
well, maybe the API isn't bad, but I'm not exactly a "novice" programmer, and I still spent like 15 minutes on this nonsense
<jmercouris>
imagine a new programmer, they would probably spend like hours reading the source code to accomplish this task
<edwlan[m]>
usocket isn’t really supposed to be for novice programmers, though
<edwlan[m]>
How many novice programmers are expected to write apps for raw sockets?
<zyd>
CIEL looks similar to what's been some people's approach to Emacs lately: building "distributions" or "starter" kits on top of plain Emacs. See Doom Emacs, Prelude, Spacemacs, Better Defaults and so on. These are all still Emacs except varying degrees of configuration done for you and sometimes quite complex ways of configuration that differ from plain Emacs (Spacemacs, Doom Emacs).
<zyd>
Also makes me think its goals align with roswell.
<edwlan[m]>
I don't understand what these things are supposed to give me
<edwlan[m]>
Why make a whole new bundle instead of saying "load this with quicklisp to get hash-table literals"
<edwlan[m]>
Or whatever the new feature is
<remexre>
new users don't know what all the things they might want to load are
<edwlan[m]>
But you can just tell them in your introduction to lips
<zyd>
To provide someone with a set of "defaults" or a configuration they can use, I think. It's different than just recommending libraries, its a more opinionated set of usability features. That's how I think of it. Like, I wouldn't ever use it because of what you said. Same reason I use default Emacs. I can make my own configuration. Thing is, at least from my perspective, Emacs has bloomed in popularity due to things like this. Common Lisp could p
<edwlan[m]>
"Setup instructions: add (ql:quickload '(:alexandria :serapeum)) to ~/.sbclrc`
morganw has quit [Remote host closed the connection]
<masinter>
I want pathnames based on URLs
<edwlan[m]>
Yeah, I was thinking awhile ago that Java's URL system isn't half-bad
Alfr has quit [Ping timeout: 276 seconds]
<edwlan[m]>
It is a bit annoying to work with, but you could develop some of its ideas into a nice successor to CL's pathnames
<masinter>
i'd use curl
<edwlan[m]>
I don't know how curl works internally
<masinter>
humongous library
<edwlan[m]>
But Java lets you add new URL schemes, etc.
<edwlan[m]>
And allows the user to extend the interpretation of URLs in a consistent fashion
epony has quit [Remote host closed the connection]