freenode/#lisp - IRC Chatlog
Search
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
10:10:43
blep-on-external
i have a portable lisp interpreter kernel thingamabob which runs on Linux, C64 and DOS
10:13:11
pjb
You mean the sicp lectures? https://www.youtube.com/watch?v=2Op3QLzMgSY&list=PL8FE88AA54363BC46
10:15:02
JuanDaugherty
sorry, thought it was one you posted, dunno where but it was obviously in last hour or so in some freenode channel
10:15:03
pjb
It was 30 years, they were in their 30s, so they're all retired now. Berlin wall wasn't down yet!
10:16:53
MichaelRaskin
JuanDaugherty: is your windmill a pure windmill or are there any ideas I have a chance to grab for my layered system with Lisp for high-level control?
10:19:01
JuanDaugherty
i am refactoring, leveraging off of existing code, one CLOS app which shall remain nameless in particular
10:20:28
MichaelRaskin
I currently use Lisp to do the root-level control, and then I have some integration with StumpWM and I definitely embrace having multiple Lisp instances with different lifetimes and different OS privileges
10:21:30
MichaelRaskin
So if you are refactoring some preexisting CLOS application, maybe we have started from complementary directions anyway
10:22:25
JuanDaugherty
well the core of my OS concept is to make a single system image using 9P stuffs
10:24:01
MichaelRaskin
In my case it would probably go from the other direction: if I use OS-provided jails and multiple interacting processes for everything, is there that much difference that some of them are not even local…
10:25:46
JuanDaugherty
first expressing an idea in a publicly logged channel is a kinda virtual NNDA
10:28:21
JuanDaugherty
since I'm mostly refactoring and integrating it's not as quixotic as it might sound. I will make code available in my git repo to authenticated users of my domains
10:32:16
JuanDaugherty
pjb, what percent of those people at the X3J13 meeting would say are in fact retired?
12:19:44
pjb
JuanDaugherty: well, they look like they're between 27-35 so most of them would be today between 57 and 65. Furthermore, they're all american or live and work in the US, so retirement is more flexible, so I would say that none of them are retired yet. A few of them are already dead. Others are still working. Perhaps 30% are planing to retire in a couple of years, and the rest later. Now of course, you could use google and wiki
12:19:44
pjb
to get more information about the group, their age, and the current status. It would be more interesting to write an AI to do it for you. You could try wolfgan alpha on it perhaps?
12:38:27
scymtym_
phoe: you asked about let-plus. i did some maintenance work under the sharplispers organization. the improvements should be in quicklisp
12:41:45
makomo
pjb: it would be interesting to find the full list. i've recognized 3 people so far -- steele, kiczales and pitman
12:47:13
beach
makomo: Very impressive! From where do you recognize them? Of the three, I have only met Pitman, but I am not sure I would recognize him in the video.
12:49:35
makomo
beach: the internet, i've yet to meet another lisper in real life :-). both kiczales and pitman have a picture on their sites
13:10:33
JuanDaugherty
no doubt the thing is coming, prolly available to some extent and even google does pretty well if you have super chops for it
13:23:07
p_l
MichaelRaskin: one thing you need to take into account is that processes being remote *does* matter - you get to deal with network that might be much less perfect that intra-computer IPC
13:28:15
MichaelRaskin
p_l: depends on how remote. And I build everything around «experiment anyway, it's no problem if something crashes», which means that local IPC is also slowly adjusting the expectations
13:41:15
Xof
user-defined method combinations, with :generic-function, possibly (particularly when used with user-defined generic function classes)
13:42:36
pjb
JuanDaugherty: for example, if you say that the sum of the angles of a triangle is π radian, then you're wrong. On Earth, it's greater, in general. Locally it can be smaller.
13:43:38
pjb
You would have to quote your axioms and your inference rules with all your sentences, to be able to say true tautologies.
13:44:37
pjb
Bookmarked https://www.youtube.com/channel/UChkEqt6l4gwfoyJPPS7OTiA/videos ; I'll watch it later.
13:54:01
Xach
phoe: http://report.quicklisp.org/2018-04-28/failure-report/gamebox-math.html#gamebox-math
14:39:00
makomo
a very interesting video: "Why Black Boxes are so Hard to Reuse, lecture by Gregor Kiczales", https://www.youtube.com/watch?v=5l2wMgm7ZOk
14:41:38
pfdietz_
Xof: it used long form define-method-combination, but not :arguments or :generic-function. Although looking at those, I could see them being useful in my specific case.
14:50:34
phoe
Is it wise to (defmacro bar ...) (setf (macro-function 'foo) (macro-function 'bar)) to have the same macro definition under two distinct names?
14:51:25
phoe
" The consequences are undefined if environment is non-nil in a use of setf of macro-function."
15:15:22
pfdietz_
The method combination is called randomized. It invokes a random applicable method. The methods have weights that control their relative likelihoods.
15:27:03
pfdietz_
If I want a method to be able to fail and reinvoke the generic function, that would be a use case for the :generic-function argument (as I understand how that works).
15:28:13
pfdietz_
Yes. Or if I wanted to have some control over the random number generator, there could be extra arguments to do that.
15:33:27
Xof
hey, pfdietz, that's a "fun" ansi test: check that defining a method combination with a :arguments &key foo clause doesn't cause that keyword to be accepted by the generic function
15:33:51
Bike
i was going to say you could expand into (tagbody top ...however you choose... (call-method method (make-method (go top)))) to do "failure" by call-next-method, but the make-method form is evaluated in a null lexical environment
15:36:05
pfdietz_
The methods always know the name of their generic function, so unless the failing is occuring in the method combination's glue code that use isn't a very good one.
15:38:29
Xof
I wanted to implement a finite state machine method combination, using qualifiers as state labels
15:39:13
Xof
but again it's not quite right, because the qualifiers are for compile-effective-method-time and the methods' return values are effective-method-run-time
15:40:01
Xof
so far the most promising use of :arguments (for me) is information to affect the combination passed as an extra keyword argument
15:40:54
pfdietz_
Method combination for constraint satisfaction, where each superclass is a different kind of constraint.
15:59:25
Bike
pfdietz_, Xof: https://gist.github.com/Bike/5ca14ba142f3ca3fc65e4c912f4cde9f now if you'll excuse me i need to escape my volcano lair before it erupts
16:00:21
pfdietz_
Method combination for implementing simulated annealing, where temperature is an argument.
16:00:49
pfdietz_
Method combination for executing methods in separate threads, where max # of threads is an argument.
16:07:28
wooden_
i'm doing ncurses development, so running sbcl in another window and slime-connect'ing to it. i would like to use log4cl, but in addition to printing in the slime repl, it prints to the sbcl window as well, messing up the ncurses display. can i disable output to the sbcl repl? if so, how?
16:10:29
scymtym_
wooden_: (log4cl:remove-all-appenders log4cl:*root-logger*) (log:config :stream SLIME-STANDARD-OUTPUT) where SLIME-STANDARD-OUTPUT is just *standard-output* if you execute the forms in the SLIME repl
16:14:45
Bike
i forgot you can't have multiple methods in the same group if they have the same level of specialization, which makes the whole exercise even mroe pointless than it was already
16:43:59
orestarod
my question regards cl-yacc and I want a clarification regarding whether it is possible to state precedence for prefix operands in my grammar
16:49:23
scymtym_
orestarod: not sure if this is what you need, but for infix operators in esrap grammars, maybe have a look at https://github.com/scymtym/parser.common-rules/#infix-operators . it can handle some common cases
16:54:01
orestarod
scymtym_: I would need to rewrite my grammar in your parser. If I see no light from cl-yacc, I will switch to your work and maybe consult you after reading the docs. Thank you nonetheless! :)
16:55:30
Bike
eight lines to cover basic arithmetic seems a lot more convenient than yacc, though maybe it's hard to do in addition to non-expressions or something
16:56:50
orestarod
What I am trying to do is more complex than simple arithmetics,though not too complex. I will provide the grammar if you wish to check for yourself and maybe tell me a few tips.
16:56:57
Bike
minion: message for scymtym: in the parser.common-rules readme, the link to architecture.builder-protocol in the "infix operators" section is a little messed up.
16:56:58
minion
message for scymtym in the parser.common-rules readme, the link to architecture.builder-protocol in the "infix operators" section is a little messed up: An error was encountered in lookup: Parse error:URI "http://www.cliki.net/message%20for%20scymtym%20in%20the%20parser.common-rules%20readme%2C%20the%20link%20to%20architecture.builder-protocol%20in%20the%20\"infix%20operators\"%20section%20is%20a%20little%20messed%20up?source" contains illegal character #\" a
16:57:35
orestarod
THe problem is the grammar is inherently ambiguous, and needs proper operand precedence to solve that
18:12:53
mfiano
Oh, nevermind. I thought you were the maintainer of McCLIM. Sigh, I am getting really confused lately.
18:31:26
mfiano
Likewise, but moreso that something like this could be created in a such a short period.
18:34:51
phoe
People can prepare their libraries in advance, but they start coding at a given hour of a given day and they must finish coding before a given hour of another day.
18:36:14
mfiano
jackdaniel: Thanks for the excellent work in McCLIM if I never thanked you (and all the other contributers too).
18:39:53
mfiano
Some months ago I saw that my pngload library was forked in preparation for the mezzano port, and I'd like to know if that ever got anywhere
18:40:34
jackdaniel
well, as far as I know it works just fine on mezzano, I think he needs to tie some loose ends here and there and it will be merged upstream
18:41:02
jackdaniel
he was a little blocked by me, because I was refactoring mirror class hierarchy until two weeks ago
18:43:10
mfiano
After the jam deadline (tonight/tomorrow depending where you live), everyone will have 4 days to play and then rate their favorites, so stop by again then :)
18:44:46
jackdaniel
but that will have to wait until I'm done with things (now I'm hacking on ECL and I'm learning Forth)