freenode/#lisp - IRC Chatlog
Search
7:51:29
beach
kuribas: So is there a CLOS-like system in the Scheme standard these days? I haven't been following the evolution of the Scheme standard for some time.
7:53:58
jackdaniel
beach: there is tiny-CLOS developed in Xerox by Gregor Kiczales, it is part of many scheme implementations
7:54:18
jackdaniel
racket built on top of that library called swindle (which is a tiny-CLOS superset)
7:56:33
mange
I'm pretty sure there's nothing CLOS-like in the Scheme standard. I haven't looked at it for a while, but I think I would remember that.
7:59:42
jackdaniel
given the context these pointers were relevant though, because kuribas was talking about de-facto state of scheme ecosystem
7:59:57
jackdaniel
just as we claim that CL may be used with threads (though they are absent in the standard)
8:02:39
beach
For example, if you can add a slot to an instance at run-time, then essentially a slot lookup must always go through a hash table to check whether the slot exists.
8:03:44
beach
But then, there are compilation techniques that make the (usually correct) assumption that instances are basically class-based.
8:04:14
beach
jdz: Yes, and the Self people proved that prototype-based languages can be compiled efficiently.
8:05:15
beach
shrdlu68: So the Common Lisp creators carefully avoided mechanism that were not sufficiently investigated at the time. These days, we could probably push the envelope a bit more if we wanted to.
8:09:01
xificurC
it's a question of what the goal is though, right. If you don't care about speed you don't have to think about whether the implementation will have a chance to compile into something fast.
8:09:38
xificurC
TCL was never meant to be a general purpose language AFAIK, just a glue like shells
8:10:10
beach
xificurC: Right. That's how I characterize "scripting languages" when I talk to industry. They are languages that are basically designed to be slow, sometimes because the creator knew nothing about language implementation.
8:12:15
beach
xificurC: So here is my favorite typical scenario: An application is developed using a static language such as C++ "for speed". Then some configuration or scripting capabilities are needed, so they add a slow implementation of a dynamic language, like TCL. Then the advanced users can only program using that language, so there is now a lot of code that is slow, for a combined slow application.
8:12:38
on_ion
i think of it like textual config file formats became more complex and turned into scripting langs
8:13:12
beach
And that's even worse, because then no real thought was put into the design of the language.
8:16:02
p_l
(using s-expressions cheats around it by pretty much removing the need to write a parser)
8:16:14
xificurC
beach: of course misusing the language will cost you. If you write a bash script that launches a program and does some pre/post-processing you haven't done much harm. If you write the whole thing in bash you might have
8:17:11
p_l
(also, bash ranks pretty high when compared to "random arse language somebody hacked up for their application")
8:17:11
xificurC
UNIX is based on having many small C programs, which are often glued together with a shell script
8:20:17
xificurC
beach: how much are you aiming for speed with SICL? Do you want to be competitive with SBCL?
8:21:57
p_l
Genera at some point added more "interface" in the form of Command Processor (which survives in CLIM Listener)
8:22:48
xificurC
p_l: write your own functions and call them directly doesn't sound much different than bash
8:24:58
shrdlu68
xificurC: As I understand, there were no interrupt-style system calls. It was all like one large CL system.
8:26:39
p_l
older lisp machines would be like booting into full-screen REPL with basic windowing system
8:27:54
p_l
early lisp machines had very simple GUI - you had the basics that were afaik taken from older MIT PDP-10 TV system (reflected in the package name "TV")
8:31:42
p_l
but remember that early lisp machines (CONS) were I think mid-70s, CADR was I think late 70s? got commercialized in first few years of 1980s
8:32:46
p_l
if you run SBCL directly on bare metal (nyef experimented with it) you'd have essentially the same case for GC
8:33:35
p_l
what LispMachines had extra was support for directly typed memory as well as things like forwarding pointers and advanced (comparatively) MMU
8:35:35
p_l
there were microcode assists on 3600 for GC, but overall it was less "GC is built into hw" and more "hardware is built for high-level language including hw-level typing"
8:38:09
kuribas
this is mostly irrelevant today, as special purpose cpu's don't have the speed advantage.
8:44:25
beach
xificurC: I am definitely aiming for speed. But I am more concerned about safety and debugging, so there might be situations where I can't compete. For example, SBCL trusts the programmer to supply correct DYNAMIC-EXTENT declarations. I don't think I want to do that.
8:46:33
beach
shka: Possibly not much. Perhaps I will attempt to prove it correct only if it is explicitly given. But I haven't made up my mind.
9:41:52
jdz
In the presence of random bit flips in memory I trust my run-time type checks more than the static ones.
9:48:54
beach
kuribas: The kind of safety I was referring to was more about de-allocating live objects, not de-allocating dead ones, de-referencing pointers to dead objects, etc.
9:49:59
jdz
What I personally would like is all the statically compiled binaries not throwing away all the type information done at compile time.
9:50:46
jdz
kuribas: If a function expects a number, and gets a cons cell, the type check will fail, and an error will be signalled.
9:51:07
beach
kuribas: A tag would be corrupted only if the implementation is buggy. I would fix that problem by fixing the bug.
9:55:13
beach
kuribas: In a typical static programming language, you can't define a type that is "any integer except 0", so you get crashes when you divide by 0.
9:57:20
beach
kuribas: Either way, the additional type safety offered by static programming languages comes at a price. There are certain programs you can not express that way, and I myself believe that there is a price to pay in terms of development time.
9:57:52
beach
kuribas: The Common Lisp language does not specify it, but good implementations definitely do it. In particular SBCL.
9:58:36
kuribas
beach: I think otherwise, there is nothing that you cannot express in a static programming language with a sufficiently expressive type system. I find the development time shorter, because I get immediate feedback in my IDE.
10:00:01
jdz
Anyway, I'm programming in dynamic programming language and am not giving up any safety.
10:00:43
kuribas
jdz: I don't know about CL, but I programmed in Python, and getting crashes and weird error messages is quite common.
10:01:39
beach
kuribas: A good Common Lisp implementation should not "crash" unless you lie to the compiler.
10:01:47
jdz
Interesting. So why are you discussing this here if you have not done any programming in CL?
10:04:41
xificurC
(defun x (y) (+ 2 y)) (x "foo") <- kuribas is talking about these crashes, which won't compile in e.g. haskell
10:15:33
dxtr
So is there a way of converting dates in the format "Fri May 04 18:54:24 +0000 2009" to ISO8601?
10:32:18
jackdaniel
dxtr: local-time has some parsing functions and functions to print dates in different formats
10:47:26
jmercouris
Xach: I have a brief question about skippy, can you pass a list of "make-image-data" into :image-data for "make-image"?
10:47:42
jmercouris
I'm trying to render many squares at once instead of a single square per "frame" of the gif
11:31:56
shrdlu68
I know it's not popular here, being a pre-standard work, but I thoroughly enjoyed reading CLTL, and I've seen others echo the same sentiment here.
11:42:06
jackdaniel
I don't know why internal CMU/SBCL compiler architecture comes over and over again
11:55:12
p_l
you have the mess of special cases known as CPython, and a bunch of projects that try to run the same stuff
12:17:48
xificurC
kuribas: I know PCL (practical common lisp), LoL (Land of Lisp), another LOL (let over lambda), On Lisp, Lisp in Small Pieces, PAIP you mentioned, AMOP (the Art of the MetaObject Protocol). Surely there's more. I started with PCL which was recommended to me, I think here in IRC. I also enjoyed LoL. The others are probably not written as a guide to
12:39:46
kuribas
is "Paradigms of Artificial Intelligence Programming: Case Studies in Common Lisp" a good book?
12:45:55
shka
https://upload.wikimedia.org/wikipedia/commons/thumb/2/20/Peter_Norvig_speaking_at_University_of_California%2C_Berkeley.jpg/1200px-Peter_Norvig_speaking_at_University_of_California%2C_Berkeley.jpg
12:48:07
beach
kuribas: Most people here would probably recommend PCL for someone in your situation.
12:50:09
beach
kuribas: I am unaware of a reference other than the Common Lisp HyperSpec. But CLtL2 is a good book. You just have to be careful about stuff that did not end up in the standard.
12:50:26
Xach
kuribas: not really. the hyperspec isn't something to start with to learn, but it's a very good reference.
12:52:43
jackdaniel
kuribas: if you are interested in single pdf version of the standard, you may find it here: http://cvberry.com/tech_writings/notes/common_lisp_standard_draft.html
12:54:10
White_Flame
um, if you haven't done so yet, don't click that link. and someone with ops should ban them
13:23:59
White_Flame
finally got around to doing the equivalent of ieee-floats with an sb-alien union instead. was pretty simple
13:28:15
White_Flame
ends up being 46 asm instructions, mostly fiddling with the foreign stack pointers, no subroutine calls
13:56:20
p_l
varjag: uhh, I think I've seen few examples in the past, but I'm not really involved in macOS world :/
14:01:31
varjag
so wonder if i should try build on that or just run some separate service in another language
14:31:31
jmercouris
Xach: I have a brief question about skippy, can you pass a list of "make-image-data" into :image-data for "make-image"?
14:36:31
Xach
jmercouris: If I was going to do that, I would make a canvas, draw the rectangles with fill-area, and make an image from that canvas.
15:05:22
jdz
https://github.com/sharplispers/parse-number/commit/eee12e439de688021e6c6245841e127dc8ac8c0d