freenode/#lisp - IRC Chatlog
Search
22:13:13
ealfonso
when I saw an array returned from drakma:http-request, I thought it had interpreted the application/json content type and automatically parsed response JSON to an array... I was wrong. apparently I have to add the hack: (push (cons "application" "json") drakma:*text-content-types*) suggested here https://sites.google.com/site/sabraonthehill/home/json-libraries
23:03:24
pierpa
I like CL's punning. The problem only occurs when interfacing with a format that chose a different set of punnings.
23:28:11
antoszka
Is there a reader macro out there for ingesting/operating on IP addresses written in decimal notation? (and keeping them internally as 32-bit integers as they are?)
23:29:58
Bike
not that i'm aware of. i think socket libraries tend to use vectors as addresses, but i could be wrong
23:32:58
antoszka
Bike: oh, okay, any particular socket library you have in mind? Do you think it'd be useful to write a macro like this?
23:34:07
Bike
e.g. (sb-bsd-sockets:host-ent-address (sb-bsd-sockets:get-host-by-name "google.com")) => #(172 217 3 110)
23:34:47
Bike
as for a reader macro, id on't know, i don't deal with that kind of stuff much, but i thought hardcoded ip addresses weren't common
23:53:50
pierpa
There's only a finite number of characters, and very few of them are usable easily. I wouldn't waste one for this macro. And the convenience would be infinitesimal anyway.
0:01:50
pjb
pierpa: notice that with emacs, you can easily bind any unicode character to an easy key or key-chord.
0:04:20
pjb
pierpa: of course, with emacs, you can also have the convenience the other way: display a long-name as a single unicode character (with the compose operator, see eg. https://www.emacswiki.org/emacs/PrettyLambda
0:08:59
Josh_2
It's listed in the SBCL 1.4.6 manual but it isn't being recognized by the SBCL I'm using atm
0:18:59
antoszka
pierpa: guess I can see one piece missing, there are make-inet{,6}-address functions for parsing the string, but there are no equivalent print functions, maybe that could use some work.
0:55:14
ealfonso
I have N long-running threads performing some work. occasionally I'd like to peek into the current state of the work from an event-driven thread. I've thought about having each thread write to a global hash table but is there a better way?
0:58:34
ealfonso
the event requires the long-running thread to stop, compute an serializable state object, then continue altering the state
5:29:59
phoe
Hm. FIVEAM:MAKE-FIXTURE and FIVEAM:MAKE-TEST are exported symbols but have no definition.
6:02:58
blurgh
Would Lisp being tree-based instead of list-based remove the need for CDR coding and other tricks to get it to run on bare metal?
6:05:41
beach
blurgh: Modern processors are perfectly capable of running Common Lisp perfectly well.
6:07:12
blurgh
beach: True, but they're not designed for it. Technically, you could run a truely foreign language like Clean or something based on cellular automata, but would that yield appreciable speed? (OK, maybe Clean would be fast on bare metal given how fast it is already)
6:07:50
beach
blurgh: SBCL is capable of generating very fast native code. I don't know where you get the idea that this is not possible.
6:08:18
phoe
They aren't designed for running Java either which doesn't prevent it from flourishing on x86_64 and more and more optimizations making its way into the JVM all the time
6:08:30
beach
blurgh: Furthermore, there is nothing special about running on bare metal. The same code generator can be used, with only minor modifications.
6:09:27
beach
blurgh: Or, perhaps by "bare metal" you don't mean "without any operating system", and instead you mean "running native code"?
6:10:02
beach
blurgh: If so, then it is already done, and has been for decades. Most modern Common Lisp system generate native code on the fly.
6:10:23
blurgh
phoe: C maps 1-to-1 to a Von Neumann architecture computer with a single core. Even if it's a lie now (multiple cores, parallel stuff, etc), it's still faster than any other language. Lisp can come close to C's speed, but can match it only with judicious use of "call 'dissasemble', optimize by hand".
6:11:43
beach
blurgh: Can you show us some reference to the claim that Common Lisp "can match it only with judicious use of "call 'dissasemble', optimize by hand"?
6:11:51
blurgh
beach: messing around with it, every single benchmark I've ever seen. Lisp /is/ fast, but it's not C.
6:11:56
phoe
Sure thing, but raw machine speed at all costs, including programmer time, debugging convenience, no introspection and memory unsafety isn't what I'm after.
6:11:56
aeth
blurgh: It's easier to write an optimized compiler than to write hardware optimized for a language. So lisp machines arw forever dead, but Lisp runs well on modern architectures without a big mismatch
6:12:32
beach
blurgh: You are making claims about the possibilities, but you only look at existing implementation.
6:12:55
aeth
blurgh: C is fast because tons of money goes into C compilers and because C design chooses a low memory overhead and fast execution speed over literally everything else, including nice things like some degree of safety
6:13:43
beach
blurgh: Furthermore, different languages are good for different things. Try using C for something that requires a lot of memory allocation, and you will see that malloc()/free() is much slower than any modern garbage collector.
6:14:23
blurgh
beach: of course calling disassemble and then optimizing it will result in faster code. Doing this automatically at runtime with a JIT is why Julia is frequently as fast as C. aeth: yes, that's probably true. Stuff like bignums are expensive, but the Right Thing nevertheless.
6:16:30
beach
blurgh: Good. Then you should know that for programs that do roughly the same things in C and Common Lisp, then the speed is also comparable. The problem is that most programs don't do the same thing.
6:19:11
blurgh
beach: Then why is it consistently slower in the Language Shootout and blog post tests?
6:19:21
blurgh
http://jng.imagine27.com/index.php/2009-05-03-195227_i_want_to_believe_in_lisp_performance.html
6:19:37
jackdaniel
you can write code fast in Common Lisp and you can write fast code in Common Lisp
6:20:30
aeth
You can make any language fast with enough money. And what will get the money? Languages used by the industry.
6:21:17
aeth
(The amount of money will vary based on the language, but getting good performance out of CL is probably easier than with JS.)
6:21:36
beach
blurgh: I already told you at least two reasons. A typical Common Lisp program will do more things than a C program because most C compilers exploit the fact that the standard allows them to elide things like boundary checks, whereas most Common Lisp compilers generate checks for such things.
6:21:37
beach
Furthermore, as I told you, the fact that Common Lisp is capable of being as fast, doesn't mean that current implementations (that are maintained by volunteers instead of by big corporations) live up to that capability.
6:21:55
jackdaniel
some adventages become obvious only after program goes above some complexity level
6:22:15
beach
blurgh: Again, you look at existing implementations, but you make claims about what is possible for the language as such.
6:24:38
cess11_
What is "speed"? For whom is numbercrunching throughput the only interesting metric?
6:24:47
beach
blurgh: The real question here is whether it is worth programming in C where the programs are vulnerable to various attacks just to gain a bit of performance, or whether you prefer safe code to make you as a programmer more productive at the cost of a little more execution time.
6:25:01
blurgh
jackdaniel: Yes, it is fast. Being within an order of magnitude of C is very impressive for any language. aeth: That's probably true. Nevertheless, Clean is faster than SBCL and only slightly slower than C, while being a rather general language implementation. STALIN and MLton both beat C, but are impractical. What structural features could be improved in Lisp?
6:25:26
beach
blurgh: Maybe you are just embarrassed about the language shootout? Did someone confront you with it, and you were unable to defend yourself?
6:26:27
blurgh
beach: C is unacceptable as a language for serious projects. That's why Lisp needs to be improved. And no, I'm just mulling over things. I've written my own Scheme and have generally been thinking about doing something new.
6:26:28
beach
blurgh: There are no improvements to Common Lisp required. What we need is more people to improve existing implementations. You keep confusing language and implementation. Maybe I am not being clear enough on that point?
6:28:12
jackdaniel
blurgh: it is covered in one of PG essays – CL has numerous orthogonal features (which are gradually adopted to other languages as well; except maybe macros which are hard for non-sexp syntax) – the structural adventage is that these features support each other and may be used to improve the program
6:28:16
beach
blurgh: You seem to be convinced that Common Lisp needs to be improved, and that is what you also started by saying (tree based instead of list based, whatever that means), but there is no evidence to support this claim.
6:28:18
blurgh
beach: A lot of admirable work has been done in Common Lisp. It's something of a sum of what's been tried and what's failed in Lisp over the years.
6:28:47
cess11_
I look forward to your future achievements, I'm sure you will revolutionise computing science.
6:28:52
jackdaniel
in other languages, where you adopt some feature, it often feels off in it – it may be not well suited for it
6:29:43
jackdaniel
regarding improving Common Lisp – I wouldn't mind if remove-if-not had disappeared ;-)
6:31:40
aeth
jackdaniel: Removing #'remove-if-not requires #'remove-if with #'complement to be optimized
6:33:29
jackdaniel
I hoped that ";-)" will indicate a joke – removing a single symbol from CL standard wouldn't give us anything except rendering wide range of programs invalid
6:34:19
beach
blurgh: Can you define what you mean by a "list-based language" and a "tree-based language". The only thing that is "list based" in Common Lisp is the representation of source code, and that has absolutely no impact on the performance of the generated code.
6:35:44
aeth
blurgh: Lisp isn't LISt Processing these days. It has arrays, structs, CLOS objects, hash-tables, first class functions, etc.
6:36:24
aeth
If you primarily use lists, that might be why you think Lisp is slow. Lists are... slow in Lisp. (Doesn't really matter if it's done at compile time with macros, though. Still compiles way faster than C++)
6:36:52
aeth
You're not supposed to use lists for everything, which is why they're very straightforward without clever optimizations
6:37:12
jackdaniel
blurgh: regarding structural differences: http://paulgraham.com/diff.html ; while PG doesn't like CL anymore many of his essays are good (he is a good writer)
6:37:45
jackdaniel
"revenge of the nerds" has all these points listed in a more elaborate manner I think
6:38:13
aeth
I disagree. I liked his essays back in the day (2012 or so?) but I don't agree with many now.
6:41:56
blurgh
aeth: I know it has other features. Take a look at Refal. Between supercompilation and efficient term-rewriting, it's apparently always been very fast. It's something like a '60s Haskell that ended up on the wrong side of the Cold War.
6:42:37
beach
blurgh: So you are just not going to address the issues with you opinion, nor answer the question we asked, and just keep claiming that Common Lisp needs to be improved in order for compilers to be able to generate fast code?
6:43:29
aeth
blurgh: The core of CL is very efficient. Basic CL is just a bunch of thin macros on top of tagbody and go. It's... very close to how the hardware works.
6:44:15
aeth
loop obscures it a bit more than the other ways to iterate, but dotimes and do are very straightforward if you macroexpand them.
6:44:45
aeth
s/very close to how the hardware works/very close to how the assembly language pretends the hardware works/
6:46:57
blurgh
beach: What question? Why I'm asking this? I showed you 2 straight-up tests, and you said it was as fast as C. I said that it was within an order of magnitude (and that's still very good! It's akin to Java, which has had a lot more work put in) and only matches it with manual trial-and-error optimization.
6:47:24
beach
blurgh: Can you define what you mean by a "list-based language" and a "tree-based language".
6:48:27
cess11_
beach: They mean that building a list from both ends at the same time matters in program efficiency post-seventies, I think.
6:49:19
beach
cess11_: I am specifically asking about the LANGUAGE, i.e. what it means for a LANGUAGE to be list based or tree based.
6:49:19
aeth
blurgh: Optimizing a modern CL AOT-compiled implementation is pretty straightfoward, actually. What fools the type inference is some built-in type-generic functions (not CLOS generic) for sequences and numbers like #'map and #'+ because for the rest, the compiler can usually infer that it's going to either be that type or an error (e.g. #'car or #'maphash)
6:49:48
aeth
blurgh: So when you use something like #'map or #'+, you're probably going to have to declare the type (or, more portably, use check-type) to make sure that the compiler has the information that it needs.
6:50:22
aeth
Oh, and arrays have an additional slowness of bounds-checking that can sometimes be avoided if the full type (which includes the length) is given.
6:50:23
blurgh
beach: a tree-based language is one like Refal - the basic structure is a list which can be built from both ends and pattern-matched down to be reduced by partial evaluation.
6:51:32
blurgh
beach: basically, the compiler already knows the properties of whatever's in the tree beneath a root expression and can optimize from there. There's also the Lorax language (experimental, idk if you can find the paper) which does something similar to generate efficient code.
6:51:35
beach
blurgh: And what makes you think that Common Lisp is "list based" then? More specifically, why do you think the fact that it is "list based" has an impact on performance? Also, what makes you think that it is not possible to use such a data structure in Common Lisp, should that be required?
6:52:20
beach
blurgh: So now you are talking about the performance of the compiler? As opposed to the performance of the code generated by it?
6:53:38
blurgh
beach: In Lisp, you can have a list with a hashtable symbol, a tree symbol, and a graph symbol. Nevertheless, you still have to traverse it with car and cdr ultimately. It makes it much harder to optimize things away, like how many purely functional data structures can be built from finger trees and reduced to a common representation.
6:54:10
beach
blurgh: What on earth makes you think that one HAS TO program with lists in Common Lisp?
6:54:20
aeth
blurgh: https://gitlab.com/zombie-raptor/zombie-raptor/blob/3b9118cc853f5adfed691f50a8537b7687c2509b/util/util.lisp#L308-360
6:54:40
beach
blurgh: Do you seriously believe that the EXISTENCE of lists in Common Lisp determined the result of the language shootout?
6:55:43
aeth
You could probably make a typed cons (for trees) similarly out of that typed list macro fairly easily.
6:55:46
blurgh
beach: basically, alpha equivalence matters is all I'm saying. That allows a lot of funky optimization-by-substitution. Part of the reason why the fastest high-level languages are purely functional is becausing being purely functional lets you close the gap a little more.
6:56:22
aeth
blurgh: Purely functional programming languages are going to be *slower* unless you're dealing with threads, afaik.
6:56:36
beach
blurgh: No, that is not all you are saying. You make sweeping claims that you then are unable to support by evidence, and not even by reasoning.
6:57:06
aeth
blurgh: Or at least enough people didn't buy into functional programming until multithreading took off.
6:57:23
White_Flame
aeth: In theory, a function language with a Sufficiently Advanced Compiler could convert things to mutating behind the scenes and achieve comparable speed
6:58:13
White_Flame
but really, those sorts of optimizations tend to happen at the application level, not the language level, so such a compiler concept is pretty out there
6:58:13
blurgh
aeth: Not true. Implicit parallelism is nice, but by that point, you might as well use C because parallel computations are all about C. The real killer is graph reduction (or closure reduction, which is what I've heard Haskell's STG uses). White_Flame: That's exactly my point. In fact, it's been done before in the '80s. It just required special hardware.
6:58:30
aeth
White_Flame: Yes, and they can for some things, but not for all things. For instance, you probably can't use a functional programming language for gamedev in 2018, even though in theory nothing's stopping you... because game architectures have enough unique requirements that not all of the smart compiler optimizations are there.
6:59:05
aeth
Anyway, nothing's stopping you from making a purely functional language *in* CL, afaik.
6:59:29
White_Flame
blurgh: well, you did say that functional programmling languages are the fastest, so shouldn't "that last bit of speed" already be considered? ;)
6:59:52
blurgh
cess11_: I never made a claim to the contrary. PG talks about how Lisp proves Turing-completeness doesn't mean equality.
7:00:05
aeth
cess11_: Although I think the dividing line is whether or not you're working with registers.
7:01:04
aeth
blurgh: CL's cons and list are not optimized. That doesn't stop you from writing optimized functional lists/trees in CL... probably using structs if you really want maximum performance.
7:01:10
White_Flame
if FP languages truly are the fastest, then game programming would have embraced them 100%
7:01:19
blurgh
aeth: You're right. You could even make Haskell in Common Lisp; I think the earliest implementations might have been that. Does Haskell have macros? Does it have even half the flexibility of Lisp? Is there anything like SLIME for it?
7:01:26
cess11_
blurgh: You'll need to decide whether you believe 'C is the fastest' or 'the fastest are the functional languages'.
7:02:17
blurgh
White_Flame cess11_: I take them as examples of fast high-level languages. Even they're usually 2-3x slower than C on stock hardware.
7:02:35
aeth
blurgh: Well, you can make a language like Haskell or like Python or like Java or whatevever in CL. Actually making an implementation of a specified language in CL, even Scheme, is going to cause problems when there are mismatches (e.g. Scheme has a separate #f and '() while CL doesn't)
7:02:37
White_Flame
"Part of the reason why the fastest high-level languages are purely functional..."
7:03:15
White_Flame
FP compilers, while they are a lot smarter now than they used to be, aren't going to compete for general purpose complexity
7:03:35
White_Flame
because as I mentioned, they don't have access to the level of abstraction necessary
7:05:01
cess11_
I'm still wondering to whom numbercrunching throughput is the only interesting metric. In my experience only those who never write code think it is but I'm sort of a loner amateur.
7:05:02
blurgh
White_Flame: Yes, they do. Haskell is just extraordinarily poorly implemented (monadic IO is an awful idea that should have been replaced by either FRP or uniqueness typing). They all make compromises where they shouldn't.
7:05:44
jackdaniel
I think we got into offtopic – please move it to #lispcafe which is better suited for such disputes
7:05:57
White_Flame
well, you seem to have a hammer that you think will nail the world's problems, without a lot of nuance or breadth...
7:06:39
blurgh
cess11_: I'd really like to see a competitive operating system in a high level language. That requires speed.
7:06:41
White_Flame
and even where there are a lot of FP-in-Lisp programmers here, you're not getting a lot of purcfhase
7:07:12
aeth
blurgh: CL is a practical language. By the early 90s, the Lisp split was pretty clear between the practical/industrial CL and the research-focused, academic Scheme
7:08:12
blurgh
aeth: I suppose you're right. Sorry about bugging you. cess11_: Do I have to say VHLL every time? lol
7:08:22
aeth
cess11_: blurgh means "very high level language", which depending on who you ask either means Prolog/Haskell/etc. or... anything higher level than C++ (anything with a garbage collector?)
7:09:02
cess11_
But I'm all ears, what is the competition you want to tackle with your high performance CL OS? Windows servers? MacOS laptops? Fuchsia phones of tomorrow?
7:10:13
blurgh
aeth: by the time you get to the level of Java, is it worth using anything other than Lisp from a purity standpoint? cess11_: I'd really like to see an alternative to Fuchsia. It looks like a lot more of the "same old, same old" Unix mantras which have led to disastrous hacks and failures.
7:10:48
aeth
blurgh: The answer is, unfortunately, always libraries and size of the development community. Combined that saves a ton of work, probably more than the greatest language can save you.
7:11:02
blurgh
White_Flame: If pointy-headed bosses didn't exist and we had all the libraries we wanted.
7:11:06
aeth
CL is probably the best language for solo projects where a lot of things are written from scratch. That... is not a common thing these days.
7:12:06
aeth
Oh, and this is probably why pg is counter-productive. If you only care about productivity, you *won't* use Lisp, which... is kind of selling people the wrong thing.
7:13:31
JuanDaugherty
ACTION agrees but notes that there really isn't a diff these days, same compiler normally
7:15:23
JuanDaugherty
ACTION has some black beans and tuna and notes yeah it won't work with the kernel build
7:16:57
phoe
Xach: is it possible to get download statistics for the lesser-downloaded Quicklisp projects as well? http://blog.quicklisp.org/2018/03/download-stats-for-february-2018.html ends at CL-ANSI-TEXT and I'd like to see some other things that are below it.
7:17:16
JuanDaugherty
as far as lisp is concerned there was doubtless something interfacing with CLOS before OOP became declasse
9:26:44
blep-on-external
"don't you think it's ironic people talk about static typing in a weakly [sic] typed language?"
9:30:51
beach
makomo: That's a bunch of very smart and very knowledgeable people. That's why I get mildly irritated when some ignorant newbie comes here with claims that are silly and untrue, suggesting changes to the language based on false presumptions and false mental models of how things work.
9:33:03
beach
blep-on-external: It's a war of words. The words "strong" and "weak" have an immediate psychological impact on programmers and decision makers. Therefore, the functional-programming crowd uses "strong" for what they do and "weak" for what we do. We counter by calling it "dynamic" for what we do and "static" for what they do. These words, have the opposite connotations.
9:33:22
makomo
beach: i completely agree and understand. i think learning common lisp was one of the best decision in my life, not only because of the language itself, but because of the whole history behind it
9:33:49
blep-on-external
i'm used to strong/weak being "can i make some value a garbage other value, like C casting?"
9:33:58
makomo
beach: all these papers, stories, posts, etc., truly a goldmine. newbs will be newbs though :^(
9:35:06
blep-on-external
also i think Lisp is still a fantastic FP language -- partly cause it lets you write imperative code easily when needed and still keeping good style
9:35:15
beach
blep-on-external: You will notice this war of words in other contexts too. Scheme, for instance, calls the macro system "hygienic", implicitly categorizing that of Common Lisp as "dirty" or "unhygienic".
9:36:15
pjb
blep-on-external: https://en.wikipedia.org/wiki/Programming_paradigm#/media/File:Programming_paradigms.svg
9:37:00
pjb
blep-on-external: the thing is that lisp is a META-programming programming language (cf /topic).
9:37:21
pjb
blep-on-external: therefore you can modify the language to fit the programming paradygm you need to solve the current problem.
9:37:34
blep-on-external
which brings me to another thing: lisp is reasonably newbie friendly for its complexity
9:38:13
pjb
Yes. So learn lisp, write lisp programs, start up companies using lisp to develop nice products!
9:38:58
blep-on-external
they really really really should have made CL tail recursive, i think things can be better written with recursion
9:39:38
blep-on-external
for example, when i wrote a binary tree using CL structs, i passed around sections of lists using ranges
9:40:32
blep-on-external
tail optimisations wouldnt help, i'm calling make-btree twice and stuff. /rant
9:42:16
beach
blep-on-external: recursion has its place, but pretty much only when tail recursion is not an option. When tail recursion is "natural", usually iteration is even clearer.
9:46:45
blep-on-external
if lisp machines disappeared in the AI winter, why haven't they reappeared now AI is a popular research thing again?
9:47:56
blep-on-external
ACTION sent a long message: blep-on-external_2018-04-29_09:47:56.txt <https://matrix.org/_matrix/media/v1/download/matrix.org/zXQJTcABEKccofNlsknJohdV>
9:51:15
MichaelRaskin
To be honest, I think that the AI directions for Lisp machines are not what the modern AI boom is
9:52:18
beach
blep-on-external: How is that related to Common Lisp? Most modern Common Lisp implementation compile to native code, using the registers of the processor.
9:52:59
beach
blep-on-external: And there is no such thing as "interpreted language". Whether a compiler or an interpreter is used is related to the implementation, not the language.
9:55:44
blep-on-external
a lot of interpreting implementations for languages use stack based VMs. these are simple to compile for cause there's no register trickery needed
9:56:05
blep-on-external
instead of "put 2 in register #1, put 3 in register #2 and add #2 into #1", a stack VM runs "put 2, put 3, add them"
9:57:34
phoe
blep-on-external: if this is what you mean: yes, in theory you can create hardware that is highly optimized for CL
9:58:01
blep-on-external
i'd like an OpenCL version though that automagically converts vectors to OCL arrays and back
9:58:06
phoe
in practice: you'll need a person who'll have enough money, time and people to do it, and it is highly unlikely such a person exists
9:59:36
pjb
The current hardware is highly optimized for lisp, just like for C or any other programming language. Let's say it's a good local optimum.
10:00:06
pjb
It's the fact that you coded the kernel in C, and you have to interface to it and to a lot of userspace libraries written in C.
10:00:33
MichaelRaskin
Per-language hardware optimisation might make sense if there is an actual niche where «twice as fast» is more expensive per-chip than «half as many»
10:01:04
blep-on-external
the machine doesn't have a "symbol" type, "integer" type, "pointer" type or anything
10:01:14
pjb
The solution is to use a kernel written in lisp. cf. Mezzano, Movitz, etc, or participate into beach lisp OS project (planning stage now).
10:05:50
JuanDaugherty
the music on that video about common lisp made it sound like all those people were dead
10:09:40
JuanDaugherty
i have a lisp OS windmill but in my thing, lisp is just a high level thing, a controlling image over a more or less standard linux