freenode/#lisp - IRC Chatlog
Search
4:15:36
LdBeth
Is it possible to specify type for certain symbols, e.g. for symbol 'YES and 'NO, they have type 'Y-OR-N
4:29:57
LdBeth
I want to write a TCG card game, there’s certain attributes I want to check if is valid at runtime and retain the ability adding new attributes
4:57:20
beach
And I guess I don't see the purpose of the new metaclass, but that's probably normal, since I don't understand what the code is doing.
5:03:20
LdBeth
beach: I use metaclass because I want to avoid introducing a lot of global variables. That additional slot of metaclass stores allowed content
7:55:58
jackdaniel
from the "under the hood" perspective it is different. clrhash mutates hashtable object, while creating fesh hash-table constructs whole new one
7:56:31
jackdaniel
also if you have more references to that hashtable in your program, then clrhash will clear all of them
9:49:24
jmercouris
rather, has anyone in this channel done so, or know of a guide illustrating how to do so?
11:42:55
flip214
does somebody know of a higher-level interface to Ethereum than https://github.com/tsikov/ethi? something like https://web3py.readthedocs.io/en/stable/contracts.html or so?
13:11:47
jmercouris
when we assign a variable to a symbol, are we instantiating a new object of the class symbol?
13:12:30
jackdaniel
built-in class means: we pretened it is a class, but in fact it is internal datatype with shoehoerned aspects allowing dispatch on it
13:14:46
phoe
the first element of that list is the symbol DEFUN that was not created, because it is already present in the CL package
13:15:03
phoe
the second element of that list is the symbol FUNK that is not standard, therefore it could have been created automatically at read-time
13:15:32
phoe
so you get a data structure after read-time - a list containing symbols, lists, whatever else
13:16:58
Bike
if you have, say, (defun funk (x) x), the symbol X probably exists at runtime only for debugging reasons. The actual code doesn't need it.
13:17:03
beach
jmercouris: The function may not be pointed to by the symbol, and the symbol may not have a slot containing such a pointer.
13:17:27
beach
jmercouris: As long as your implementation answers correctly to (symbol-function <symbol>) it can do what it wants.
13:17:56
jmercouris
so basically what jackdaniel said right? the implementation has latitude to implement the "symbol class" however it likes
13:18:48
Bike
there is an API. the API says you can use symbol-function to get the function named by the symbol in the global environment. the API does not say anything at all about how this is accomplished
13:21:22
beach
jmercouris: And, in fact, in SICL, the association between function names and functions is stored in a first-class global environment. That way, this association can be different in different environments.
13:28:11
phoe
jmercouris: beach made a thing where you can have two different global environments. in each of these environments, you can DEFUN a function with the same name, but two different bodies.
13:28:14
beach
The Common Lisp HyperSpec mentions the "null lexical environment" also known as the "global environment".
13:29:06
beach
jmercouris: In SICL, I generalized this idea so that these environments are represented by first-class objects, making it possible to have several simultaneous but different instances of global environments.
13:29:10
jackdaniel
the practical gist of it is being able to have two different versions of the same library
13:29:39
phoe
disposable environments for compiling and building stuff and running pure-CL CI and other stuff
13:29:55
beach
jmercouris: Yes, multiple versions of a library, sandboxing, bootstrapping, cross compilation, etc, etc.
13:32:05
beach
jmercouris: There is a lot of stuff in the literature about modules for Lisp-like languages. A module is similar to an environment in that it is a mapping from names to values, as opposed to a package which is a mapping from symbol names to symbols.
13:33:22
jmercouris
and it is saying that the car of the first element is the symbol equal which has 5 slots
13:34:03
Bike
i mean, it kind of depends. there's no technical guarantee that a cons has to have any slots either, it just needs to have an accessible car and cdr. but it's convenient to graph it like that.
13:34:10
beach
jmercouris: Correct. And in SICL, symbol-plist is not in the symbol either. That too is in the environment.
13:34:32
jackdaniel
I like to think about symbols as of strings with strings attached (pardon the pun)
13:34:35
Bike
The basic thing to understand is that Lisp doesn't make any guarantees about pointers or whatever. It's just not part of the semantics
13:35:18
beach
jmercouris: Putting symbol-plist in the environment was natural once I decided to use first-class global environments.
13:38:13
beach
jmercouris: In fact, the definition is (defclass symbol (t) ((%name :initarg :name :accessor name) (%package :initarg :package :accessor package)) (:metaclass built-in-class))
13:40:18
Bike
what jackdaniel meant is that you can't do things with a built-in-class that you can do with a standard-class. for example you can't subclass it.
13:42:37
jackdaniel
I think you meant this quote: "< jackdaniel> built-in class means: we pretened it is a class, but in fact it is internal datatype with shoehoerned aspects allowing dispatch on it"
13:44:40
jackdaniel
my point was to emphasize that some parts of "everything is a class" is very artificial to keep the model consistent (especially when we talk about built-in classes). but now I regret I've shared that opinion (because it seems to bring a lot of confusion)
13:45:23
beach
jmercouris: You really really need to start thinking in terms of protocols (or APIs if you want).
13:46:01
jmercouris
which is an instance of #<SB-PCL:SYSTEM-CLASS COMMON-LISP:FUNCTION> on my implementation
13:47:22
phoe
jmercouris: the implementation creates instances of that class for you when you, for instance, (lambda () 42)
13:49:01
phoe
it grabs the LAMBDA *form* and returns an instance of a function based on the contents of that form
13:49:20
beach
xificurC: In most implementations, that bootstrapping process is very messy, either for historical reasons or because the system is built in a different programming language.
13:49:46
jackdaniel
jmercouris: it lambda essentially creates a function. since "everyting has a class" in common lisp, such function is an object of a certain built-in class
13:50:35
jmercouris
jackdaniel: so, lambda makes an instance of the function class? or did I misread?
13:50:40
jackdaniel
there is not much more into it, the only practical aspect is that you may specialize method on its class
13:51:00
phoe
the special operator FUNCTION grabs things and returns functions based on these things
13:51:35
beach
xificurC: In SICL, on the other hand, I use ordinary forms like DEFCLASS, DEFGENERIC, and DEFMETHOD to create this entire hierarchy: http://metamodular.com/CLOS-MOP/graph.png
13:51:39
jackdaniel
as I said, some "closiphology" is artificial. function is a function. to keep model consistent each function has a class associated with it
13:51:54
jmercouris
xificurC: I'm read Common LISP: A Gentle Introduction to Symbolic Computation, already read PCL, did a bunch of lisp programming
13:51:58
beach
xificurC: I can do that because I bootstrap using a full Common Lisp implementation, and I use first-class global environments.
13:53:49
phoe
.................why did I totally expect you to have a whole file dedicated just for that
14:06:35
makomo
you've probably seen it already, but appendix c deals with some of the circularities/bootstrapping problems
14:06:53
phoe
shka: beach: you both are right, I just wanted to write it for the sake of writing it. :D
14:08:05
xificurC
makomo: yeah, not sure if I'm gonna finish the book though as I haven't done much CLOS in order to fully understand and appreciate what lies underneath it
14:08:57
makomo
also, i realized yesterday that 3-lisp was the author's phd thesis and the first formalization of the concept of reflection
14:10:11
makomo
i've heard that sonya keene's clos book is a good introduction to clos itself. what do others think of it?
14:20:23
beach
makomo: Probably because it used examples that I either could not appreciate, or that required non-standard functionality.
14:22:56
beach
makomo: If I were to write a book like that, I would probably use more mundane examples like people, companies, employees, countries, etc.
14:23:50
makomo
beach: that's something that i wanted to comment on. aren't such examples better than the washed-out examples of animals, shapes, etc.?
14:24:20
makomo
i've seen one review where someone says that the book does actually go over the canonical animal/shape example, but that there are actual "industrial" examples afterwards
14:26:14
makomo
yeah, i don't think i do either, but i also don't recall ever seeing such a thing used in an OO introduction
14:27:59
beach
I mean, as if a person who happens to be a student is always going to remain a student and has always been one.
14:28:50
makomo
sometimes it just seems to me that more elaborate examples would be much better than the usual "we'll skip this, because it would take too much time" or w/e the usual "excuse" is
14:28:57
beach
I think that's the error in most books. They make class hierarchies that would absolutely not work in a real application.
14:30:07
beach
I guess that *is* an advantage of Keene's book. The examples are real, from real situations.
14:36:17
makomo
beach: do you plan on SICL supporting stuff like threads and other usual extensions? even if you don't, how would you go about implementing these since SICL is implemented in CL?
14:38:00
makomo
it might not matter that it is implemented in CL, as you said before (and the same thing goes for the LOOP macro that you implemented in CL), but if you for example relied on SBCL's threads or FFI how would you ever get rid of that dependency once you've bootstrapped
14:39:20
beach
makomo: I would just make sure there is a bunch of functions that interface to the system calls of the operating system.
14:39:24
makomo
or would there have to be a part written in C for example to interface with the platform you're running on?
14:41:48
beach
makomo: Because SICL is the basis of a planned Lisp operating system, and that operating system will not have any libc.
14:42:45
makomo
so you would basically roll your own implementation of threads? i guess that makes sense if you're writing your own OS
14:44:23
makomo
aha, right. the lisp OS would be a separate project, but it would rely on SICL for most stuff i guess?
14:44:51
beach
SICL with first-class global environments would be the basis, since it would already be a multi-user Common Lisp system.
14:45:07
random-nick
why not have a macro for syscalls? glibc has a function that lets you call any linux syscall
14:45:15
warweasle
makomo: If someone makes a lisp os, they really should use the linux kernel for drivers. Even if they have to convert them to lisp.
14:45:58
beach
random-nick: It is not as simple as that for Common Lisp. You have to define what kind of Common Lisp data structure will be used for the call that normally accepts C structures, and then translate.
14:46:34
Bike
Ukari: "no values" is implicitly turned into NIL anywhere expecting one value,which is basically everywhere
14:47:14
Bike
Ukari: one exception is you can do (multiple-value-list (values)) => NIL versus (multiple-value-list nil) => (nil)
14:47:47
makomo
beach: and the point that warweasle makes about portability? is writing a whole kernel and all the different device drivers something that's part of the plan for the lisp os or?
14:49:33
Bike
it's really incredible how annoying it is to tell asdf where to get files. no wonder central registry is still around
14:49:38
makomo
that's what my question is. is the planned lisp os going to reuse the linux kernel or create its own
14:50:07
beach
makomo: Contrary to other people, I consider the "running on bare metal" to be less important, but a cute thing, of course. I would be happy to run it in a Linux process to start with.
14:50:09
makomo
and if the answer is the latter, isn't that a huge undertaking and something one wouldn't really want to do
14:50:16
beach
makomo: Also, people assume that I want this thing to be widely used. That would be great but I doubt it will happen.
14:50:18
beach
makomo: I am a researcher. I just want to show that we can do better than what we are currently doing, and what we have been doing in the past. But I don't have great hopes that many people will be bother.
14:51:01
random-nick
and talking to a kernel like Linux requires most of the difficult parts of a FFI
14:55:19
warweasle
I posted this to the other channel but I will here too: http://wiki.c2.com/?SynthesisOs
14:55:41
beach
I think it would be a great exercise to see whether CLOS could be used to create a better hierarchy of device drivers than what C would allow.
14:56:36
beach
Such a hierarchy *might* take some inspiration from I/O Kit, but not too much, of course.
14:56:45
makomo
beach: so in the context of SICL running as a linux process, supporting threads within such an implementation would require calling into libc right? how would that be done if SICL is written using CL?
14:56:58
beach
warweasle: Oh, I am not talking about speed. I am talking about maintainability and, yes, security.
14:57:30
makomo
warweasle: interesting. i heard something similar a while ago, something about recompiling the code of the filesystem i think?
14:58:10
beach
warweasle: I would like to see whether it could be advantageous to use CLOS to write such a collection of drivers.
14:58:52
makomo
beach: ok, but i think the question of "how would it be done within CL?" still stands. how would you connect assembler and CL?
14:59:35
Bike
the first research paper i ever read was an operating system based on having objects with jit compiled methods for syscalls. that was neat
14:59:43
beach
makomo: There is always a little machine code or "assembler" in a complex system like Common Lisp. The code generator of a compiler for instance. And there would have to be a few lines of such assembler to implement a Common Lisp function such as POSIX:OPEN.
15:00:14
warweasle
beach: The problem is OO requires the language or runtime to do things for you. In kernel space you don't have that luxury. If you take the runtime away, you just have structures.
15:01:08
beach
warweasle: Are you talking about a typical Linux-like kernel or about a new LispOS kernel?
15:02:38
on_ion
we are running countless OSs in virtual machines, virtualbox or qemu etc, why not just accept SBCL or emacs et.al for another VM? why a bare metal machine OS?
15:04:17
warweasle
It's a microkernel. That didn't seem to work out. I don't believe smaller will make it work any better. There has to be communication between pieces. And then you have a kernel again.
15:04:58
warweasle
You *could* implement lisp on top of forth and get something like you are thinking, but it's a very bare os.
15:04:59
on_ion
like they designed an implementation where the pieces cannot talk, warweasle ? =) there was just not that many people working on HURD
15:05:30
phoe
random-nick: AFAIK yes, except the user normally does not have raw access to memory like in TempleOS
15:05:48
beach
warweasle: You seem to be assuming a traditional OS with separate processes for each running program, requiring address remappings and hence communication by copying bytes between kernel and applications.
15:05:58
on_ion
people have been writing some interesting software for TempleOS. build it and they will come
15:07:14
random-nick
but user code would still be able to access all of the system's objects, right?
15:07:30
phoe
random-nick: depends if these are objects are present in that code's global environment
15:08:01
beach
warweasle: I think you need to read the design document. Otherwise, I am afraid I am going to end up re-typing it here in its entirety.
15:08:14
makomo
beach: i still don't understand how that would be done for a CL implementation written in CL. i'm ignoring the lisp OS thing for a now and focusing just on SICL being a CL implementation that i can run for example on linux. how would it implement these syscalls if it only has CL to work with? would you use some non-standard stuff from SBCL? would part of it be implemented in C or assembler? how would it work?
15:09:55
on_ion
warweasle: beach mentioned it is like Genera, but with safety and multi-user environment. if you dont know genera, how to continue the conversation ? i point this out because edging close to misunderstandings or misinterpreted idea[l]s
15:10:09
phoe
the basic means of communicating with it is executing the interrupt 0x80 CPU instruction
15:10:24
beach
makomo: SICL is (going to be) bootstrapped on a Common Lisp implementation. An executable file will be created. That file contains machine code. Some of that machine code will be the implementation of the function POSIX:OPEN. During bootstrapping, that function will be defined to execute the machine instruction for making a system call. That's all it takes.
15:10:27
phoe
which is the part of the libc syscall() instruction that actually passes control out of the process and into Linux.
15:11:00
phoe
either you link against linux's libc that contains syscall() and you call it, or you reimplement its functionality in whatever you want and then interrupt the OS manually.
15:11:38
makomo
beach: oh hmm. so the creation of this executable will be part of the bootstrapping process?
15:12:16
beach
warweasle: Unfortunately, most of the OS literature also assumes a Unix-like kernel. A better thing to look at would be Multics. And of course, Genera.
15:12:35
phoe
DOS is actually nice enough to allow you to erase it from memory and replace with anything else you'd like
15:12:53
beach
warweasle: So it is very likely that, despite your having read most of the existing OS literature, they haven't told you everything.
15:17:28
phoe
flip214: you know how the saying goes: if all you have is a DOS, everything looks like kernel space (:
15:18:41
loke
warweasle: Windows 3.1 was _not_ OK. I firmly believe you are wearing rose-coloured hindsight glasses.