freenode/#lisp - IRC Chatlog
Search
15:23:20
Xach
Hmm, can you think of a big-ish library or application in Quicklisp that isn't super platform-dependent?
15:23:48
Xach
(trying for something physically big, or with a lot of deps, to test out performance on validating tarballs and such)
15:29:46
dim
but I don't have a windows setup, so it's been broken at times, and also you need freetds.dll (protocol implementation for MS SQL Server) which I don't know where to find for windows
15:43:58
stylewarning
stassats advice is often poor, only good if you manage to convince him your problem matters/is interesting, and you frame your question to his satisfaction
15:47:16
capitaomorte
but that was the hardest ever bug I had to report yet, and it seemed pretty easy
15:47:27
stylewarning
Shinmera: this is assuming he has communicated something that, given sufficient time, can be understood to be something reasonable. This can be true but is often not.
15:48:00
stylewarning
I'm just happy he takes care of SBCL, so I don't care if he's immediately helpful to folks', including my, problems.
15:50:03
capitaomorte
Shinmera: that put a smile on my tired-of-bug-reporting face, go to go now, thanks
15:58:39
pjb
Xach: you would have to define "super platform-dependent". You may have systems that run only on a single platform, but that would require only adding a single line to make it run on another platform. On the other hand, you may have systems that run on half a dozen platforms, but to make it run on another platform you would have to touch every lines of source and the asd files!
16:00:57
stylewarning
I like how when a Lisper doesn't know the answer to a question, he/she just retorts with another question indicating the original question was far too underspecified, and if only it were more specified, the purported answerer would be able to share his/her answer.
16:08:59
whyNOP
I'm being stupid, ignore that lol just replying to stylewarning about specifications.
16:10:01
beach
whyNOP: I thought you were just giving an example of what stylewarning said, so I gave one more.
16:10:25
jasom
stylewarning: to be fair, pjb pretty much always claims the question is underspecified, even when he knows the answer to the question.
16:10:27
stylewarning
whyNOP: Xach asked a perfectly fine question, only to be rebuffed by pjb asking for all these terms to be defined and such. But the fact of the matter is that even if the terms were defined, pjb probably could not offer a sensible answer, unless it is a part of his own collection. ;)
16:12:30
jasom
JuanDaugherty: I've not had the chance to see that yet; it's the play that made Williams famous though
16:18:53
JuanDaugherty
nice if there was a lisp matrix thing ( https://en.wikipedia.org/wiki/Matrix_(communication_protocol) )
16:23:27
emaczen
beach: that is what I thought, but for some reason my program seems to get hung up there
16:24:02
beach
It is possible that your implementation has a particularly bad NCONC, but it is unlikely.
16:27:25
pjb
Do you really want to destructively concatenate them? This will often lead to infinite loops and other hang ups.
16:28:02
pjb
There's a faster way to concatenate lists… Assuming you can and want to do it by mutating them, you just need to keep references to the head and tail of the list. Then it can be done in O(1).
16:28:51
beach
emaczen: Clearly, pjb is right in that the time is proportional to the length of the first list.
16:28:55
emaczen
pjb: Yes I have my own linked-lists built that will concatenate in O(1) maybe I'll look into that in a second if this doesn't get any better
16:30:59
emaczen
pjb: Yep, those nconcs have messed me up subsequently (probably infinite circular lists) after I stopped the program and tried something else
16:33:46
beach
emaczen: That is exactly what pjb warned you about. If there is shared structure between the two lists, it can become very messy.
16:43:17
JuanDaugherty
turned out apparently there isn't a lisp matrix anything, it's too new I guess
16:50:11
dim
it would be possible I guess to offer a pgloader with only MySQL or only MS SQL support, from the same sources?
16:50:57
dim
pjb: my basis for popularity of pgloader is number of stars on github and frequency of bug reports
18:20:46
Fare
dim: process data it knows nothing about? Oh no, is it an AI trying to replace human programmers?
18:37:02
Fare
and if you need a lot of append's, single-linked lists are not the correct data structure
18:38:19
Fare
ACTION is reminded of how ASDF 1 was O(n^3) or O(n^4) on large flat systems... and exponential on deep systems using conditional dependencies.
19:40:12
dim
Fare: data loader tool for PostgreSQL, input are csv, dbf files, sqlite, mysql, mssql databases, target is end users, not programmers
19:40:40
dim
no AI, but still processing data it knowns nothing about, and data the developer knows nothing about
19:47:41
Xach
heh, testing SBCL vs CCL in a quicklisp dist that enables full pgp signing of metadata and SHA checks of downloads.
19:48:12
Xach
ccl turns out to be way faster on a big system because although its crypto verification is slower, its compiler is way way faster.
21:11:35
jasom
which version of sbcl? It has improved compile times in the past year somewhat IIRC, but yeah ccl is a much faster compiler in general
21:27:04
didi
So, fun times. (defun foo () ...) (defun bar () (flet ((foo () ...)) (mapcar 'foo ...))). I wanted to call FOO from `flet', but instead I was calling FOO from global.
21:30:10
Shinmera
I feel like exactly this has been discussed at least four times in the past two weeks
22:07:18
didi
mfiano: The difference between #' and ', specially where it matters, isn't much clear to me yet.
22:08:51
mfiano
I always use #' to be explicit in my intent, so this rarely comes up for me, but I was aware of it.
22:20:46
pjb
didi: flet is a lexical binding, it doesn't touch the symbol-function of the function name.
22:28:08
didi
pjb: oic. So in the `mapcar' case, it has more to do with `mapcar' coercing a symbol than `flet'.
22:45:00
pjb
didi: notice it's not mapcar or in general the other HOF functions that resolve the function designator, but APPLY (FUNCALL calls APPLY theorically).
2:05:50
aeth
The only Lisps I know that have users are Common Lisp, Scheme (and Racket if you count it separately), and Clojure.
2:06:43
mr_yogurt
i guess the question then becomes which of those three is closest to common lisp, then
2:07:45
aeth
There are a bunch of minor, barely-alive Lisps, but they're mostly "hey, let's express <language> in s-expressions"
2:17:55
aeth
The problem with Lisps is that it's really easy to make your own, but really hard for it to be more useful than Common Lisp.
2:23:52
Petit_Dejeuner
mr_yogurt: You can do this without shadowing your functions (let ((max (max stuff)) (length (length other-stuff))) ...)
2:23:52
minion
Petit_Dejeuner, memo from pjb: re-indent the Common Lisp from your programming language class to make it pretty!
2:25:14
Petit_Dejeuner
It turns out it's pretty convenient to not have to think of a new name and which is which is pretty obvious from context.
2:25:37
aeth
mr_yogurt: One way to avoid name collisions would be to use many packages instead of one core CL package. But CL doesn't do this.
2:27:06
aeth
You can have a type foo defined by the function foo, and give it the variable name foo when you use it.
2:29:14
aeth
and when you have name collisions you have to keep the scope in your head. Maybe it's okay to call something list locally if you're not going to call the function list, but then you have to be aware of that
2:29:55
Petit_Dejeuner
ACTION doesn't really notice one being significantly better than the other. Lisp-1 is more elegant, but lisp-2 is more practical.
2:30:18
aeth
On the other side of the argument, you can just do things like (mapcar + (list 1 2 3)) or (lambda (x) (x 42)) if it's a lisp-1
2:32:52
aeth
(let ((foo (foo 42))) (declare (foo foo)) ...) is actually a quite elegant thing you can do with multiple namespaces
2:37:38
Petit_Dejeuner
That's one of the things that annoys me about Racket. The types are in the same namespace as everything else.
2:38:02
pjb
mr_yogurt: why don't you just read http://www.nhplace.com/kent/Papers/Technical-Issues.html instead of bothering us with those sterile questions?
2:39:35
Petit_Dejeuner
I'm pretty sure I've gotten a bug before because I used muh-record as a variable name and then tried to use match with muh-record.
2:42:44
aeth
just like there's a *read-default-float-format*, why not have a *lisp-n* and settle the debate forever? :-p
2:53:49
aeth
Petit_Dejeuner: immutability vs. mutability, higher order functions vs. equivalent macros, compile time vs. runtime, dynamic vs. static, typed vs. untyped, etc.
2:56:37
jasom
does anybody know if cl-autowrap works with C++? I know c2ffi does, but it's unclear to me if cl-autowrap can do anything with c2ffi's output from cl-autowrap
2:58:39
aeth
well, probably no optimization in the standard Python implementation, which is one of the slowest languages that's not compiled to that machine that runs in Game of Life
2:59:53
aeth
Pretty much two things from python would be cool. sequence comprehensions (because list comprehensions just aren't good enough) and tuples/named tuples.
3:00:13
aeth
I say sequence comprehensions because that would be the CL-idiomatic way to do it, support both common sequence types
3:00:33
pjb
Notice how CLHS doesn't say symbol names are not mutable, but that it's not conforming to mutate them!
3:01:33
Petit_Dejeuner
aeth: There's no standard way to represent sequences in Common Lisp, is there?
3:02:14
aeth
There's also no standard accessor to indexable things, although elt is generic over sequences.
3:02:47
Petit_Dejeuner
It wouldn't be hard to write a loop that generates sequences if there was a standard sequence to generate.
3:03:49
Petit_Dejeuner
aeth: Not really much to do about it. There aren't any other standardized high level languages with several compilers.
3:04:01
aeth
pjb: You can add anything to any language, but some things require compiler support to be added efficiently unless the language is as basic as C
3:05:26
pjb
You can't rely on CL compiler macros since they're not necessarily used. You have to implement your own with macros, if you need them.
3:07:00
Petit_Dejeuner
I don't even think it's an implementation problem. If you extend too much, you have to write a new standard.
3:07:58
pjb
No. A new documentation. Standards are processes involving a lot of resources and people. That's the point: you can make your lisp evolve without a standard.
3:08:08
Petit_Dejeuner
Once you start writing replacements for things like 'defun', 'defvar' 'defclass', and 'let', the language stops being Common Lisp.
3:09:16
Petit_Dejeuner
Yeah, but the language is also the conventions and idioms the programmers know. If the language changes too much, then those no longer apply.
3:14:50
Petit_Dejeuner
The worry is that if you extend a language through the language to the point where you start masking or replacing built-ins, then your language starts to stop working well with other code.
3:15:31
Petit_Dejeuner
It'll work, but the core benefits won't extend to code that's written closer to the base language.
3:16:33
pjb
When you add your bills, that doesn't prevent you to use the same mathematical language to compute black hole structures.
3:16:39
Petit_Dejeuner
I can write a lazy sequence object and replace loop and other constructs with versions that can support lazy sequences, but people who aren't using my library won't create libraries that support it unless I'm really clever with how I shadow the standard values.
3:17:49
aeth
Iirc, someone here is writing a library that has type-generics rather than class-generics. It's only portable to a handful of implementations.
3:17:56
Petit_Dejeuner
Tokenizer and parser are working. Now I can just play with Lisp in Small Parts.
3:18:16
aeth
But, anyway, you'd need a lot more control over efficiently abstracting over types in order to heavily customize CL
3:20:45
Petit_Dejeuner
imho, common lisp doesn't need to be extended all that much to be better than a great many other languages
3:20:53
Zhivago
petit: CL was designed as a compatibility layer, like posix, rather than as a fundamental language.