libera/#commonlisp - IRC Chatlog
Search
12:25:53
Guest74
The one I really don't understand is the not exporting slots. But, are we really exporting slots? I thought it was all symbols? Maybe those symbols define my protocol? Isn't it only a current implementation detail that they are slots? If I specifiy my protocol and never mention slots, do I need to safeguard against somebody coming along and
12:28:00
pjb
Guest74: indeed, only symbols are exported. But slots are named by symbols. So if you export symbols naming slots, you give access to the client (the code that uses your package) to the slots that should be a private implementation detail.
12:28:36
pjb
Guest74: it should be sufficient to tell the client not to use slot-value on your objects.
12:29:01
pjb
Guest74: but not everybody read the documentation, so in big projects, with lots of people, it is nice to make it harder to use slot-value on your classes.
12:29:36
pjb
Guest74: the problem is that CL is not into BDSM: it doesn't prevent anybody to use anything.
12:31:38
Guest74
i prefer not to jump through hoops to prevent someone else from doing things not as intended. But that's just my take. I'm not big into dictating what others should do.
12:39:06
flip214
You can't (practically) prohibit anyone having code in the same process as your library from getting the address and using FFI to access the low-level data, anyway. So having some kind of protocol should be good enough.
12:44:34
beach
Guest74: I know that Xach (among others I guess) considers any use of SLOT-VALUE and related functions to be "forbidden" by client code. And, yes, if your clients are well trained, that should be enough. The % convention is just a reminder for them, since (as people pointed out) with modern Common Lisp systems you can't really prevent anything.
12:46:15
beach
Guest74: You can also use the structure where the protocol package contains only its exported symbols, as I outlined above. That's a very nice organization, and it prevents any use of SLOT-VALUE automatically, without requiring any naming conventions like %.
12:49:48
Guest74
Sure, I have that for quite a few protocols, most of mine there is no concrete object anyways, which is the purpose of the protocol..
12:51:03
beach
Interesting! Where did you learn that structure? And how do you then define your implementation packages?
12:51:59
beach
I am asking because I know of only CLIM as being a system that requires this structure.
12:52:50
pjb
Guest74: sure. It's a matter of context. Size of the project, number of programmers, who will use it, etc.
12:53:39
Guest74
I can't say I learned it from programming. It just makes sense the way my brain works. Implementations are just methods on the protocol functions. I'm not sure what else you mean?
12:53:46
pjb
flip214: if you build a controlled environment which sicp with it's first time environment will allow and make it usable, you can remove FFI and thus prevent low-level access and such security bugs.
12:54:35
beach
Guest74: If you put the DEFGENERIC in the protocol package, then the protocol package will contain not only exported symbols, but also names of parameters and other noise.
12:55:20
beach
Guest74: Like I said, the proposed structure is to have the protocol package contain only exported protocol symbols, so no internal symbols.
12:55:51
hayley
I wonder if anyone would notice if their "FFI" solution involved compiling C to Lisp code.
12:56:24
Guest74
I'm not sure what the big deal is about args? Most of them are just the name of the protocol anyways(at least in my case)
12:56:27
pjb
hayley: if you compile C to lisp, then you can do ffi staying in the lisp controlled environment: C programs will be safe!
12:57:07
beach
Guest74: It is not a big deal, but you said you often use the structure I suggested, and if you put the DEFGENERIC form in the protocol package, you do not use that structure.
12:57:21
hayley
Else (for some other language) I would have to write a guide like "How to do FFI in language: 1. You don't"
12:57:53
beach
Guest74: So I was asking where you learned the structure where the DEFGENERIC forms are not written in the protocol package, because that structure is highly unusual.
13:06:05
hayley
We have the Vacietis compiler which compiles C to Common Lisp, so I wonder how the compiler fares compiling a SSL library. CL+SSL is the only FFI library I use routinely, so I would basically never have to touch FFI again if this idea works.
13:09:00
hayley
Sure, though I wouldn't mind if the generated CL used Common Lisp objects rather than an octet vector for memory. I believe Iota uses the latter, which is still better for compatibility.
13:11:08
Guest74
Beach: Perhaps I misunderstood you, but you said contains only its exported symbols and I must have easily confused that with only exports symbols naming the protocol, which is the only thing I do intentionally. now would not having these args in the package hinder debugging? ...seems something keeps kicking me off the network.
13:11:12
froggey
iota is definitely a crude hack, but definitely designed to be fairly compatible with existing C code
13:11:23
hayley
So I'd prefer the Zeta-C-ish approach that Vacietis uses, I think. But if you say it's a hack, I'll see how it fairs.
13:13:13
beach
Guest74: I see. Debugging would be done by the author of the module, who obviously uses internal symbols in the module, so I see no impact on debugging.
13:13:15
hayley
I also have to wonder how much software written in C breaks in practise, if you use bignums for char, int, long, etc. It would help if I could pick a MAX_INT perhaps.
13:13:45
froggey
something that does away with the big byte vector for memory would be nice, but gets surprisingly close to the pointer provenance problem
13:14:14
froggey
I thought about it a bit, but always ended up with a fairly exotic memory model which I'd guess most C code won't like
13:16:16
Nilby
hayley: There's quite a lot C software that relies on integer size, wrapping, truncation, etc. Maybe more than not.
13:39:57
lisp123
I was speaking to one of my old friends after many years and I mentioned I started using CL
13:40:29
Nilby
dlowe: Vacietis has a fair bit of a libc in CL, iota too has a bit of a Mezzano specific libc
13:43:41
Guest74
beach: So you write the generics in a package, then create a separate package just to import/export the symbols naming the generic functions? I'm guessing maybe mcclim is doing that because it both creates and implements the protocol in the same space?
13:46:03
jackdaniel
Guest74: we are a bit smarter, the implementation package "uses" the protocol package
13:47:27
froggey
Nilby: the iota libc is mostly portable common lisp. though it needs nibbles and some float stuff to actually work, but there are portability libraries for that
13:48:56
Nilby
froggey: Thanks. Now that I'm looking it might help me finish my Mezzano portability layer
13:49:26
beach
Guest74: No. The package system allows you to do thing the other way around. You write your package definition (say) (defpackage #:api ... (:export #:fun1 #:fun2)).
13:50:17
beach
Guest74: Then you write your implementation.lisp file like this (cl:in-package #:api-implementation) (defgeneric api:fun1 (...)).
14:00:14
Guest74
beach: do you have a specific example to look at? Did you really mean defgeneric and not defmethod in your example? This constant kicking isn't helpful.
14:03:03
Guest74
So implementation doesn't mean implementation of the protocol, but definition of it?
14:04:03
Guest74
any code that defines it? or that actually implements it as in has defmethod etc...
14:09:02
Guest74
Ok, I'm getting how you do it. And what are the benefits to this uncluttered namespace?
14:10:14
beach
The one benefit that made me tell you about it was that the code in the implementation package now needs to respect no naming conventions, in particular %. Client code does not have access to any symbols except the protocol symbols.
14:11:08
beach
One where a module contains code, some of which is exported, like functions, classes, etc.
14:12:43
jackdaniel
isn't that rather cosmetic separation? if someone uses "protocol package" in uncanny way, then nothing prevents them from using the "implementation package"
14:13:35
beach
jackdaniel: *sigh* we have already been through this. Nothing prevents anybody from doing anything in Common Lisp. It's all about conventions.
14:14:50
jackdaniel
beach: you seem to argue, that there is some benefit to the client code from a separate package that has interned only symbols that are part of the protocol; so I'm asking what's the practical purpose of this convention? i.e if you don't export X, then using foo::x or foo-internal::x doesn't make much difference
14:15:15
Guest74
and I'm still not sure what this gets me over just defining a protocol in a protocol package which wouldn't have things like slots because it's a protocol and not an implementation.
14:15:17
beach
Guest74: Call it what you want. It is a separate package containing (so to speak) all code.
14:15:27
jackdaniel
and if you specify, that accessing slots is violating the protocol, then using slot-value disregarding the package should not happen
14:15:55
beach
Guest74: The concept is used informally in the literature. I formalized it a bit here: http://metamodular.com/protocol.pdf
14:19:30
mfiano
I just don't understand the reasoning for having only a package, without defgenerics for the implementation to conform to. It seems odd defining them in the implementation. I could see another parent node in between, but in the implementation? If this is only to avoid things like %-prefixing slots, I think it is quite an odd decision to conflate the API of the implementation with the
14:20:16
beach
Well, I need to get back to work. I am obviously not doing a good job today. Sorry about that.
14:22:56
beach
jackdaniel: There are no benefits to the client. I think the only benefit I mentioned today is that the -code (I wouldn't dare say -implementation again) package does not have to use any particular naming convention for slots.
14:23:09
Guest74
Well, I still don't see the benefit of separating the symbols of the protocol from the definition of the protocol, except it would satisfy some deep ocd corner of my brain.
14:23:26
jackdaniel
it doesn't have to do that either way (if we agree, that accessing slots directly is against the protocol)
14:26:38
jackdaniel
I'm not sure what I've already ageed upon, but since we all give up, then I'll make a coffee :)
14:26:51
Guest74
maybe it will make sense when I make a protocol for a purpose other than uniting objects from different libraries.
14:28:13
mfiano
Then why go to this much effort to try explaining an architecture that is useful to you?
14:29:38
mfiano
I wouldn't say that. I would just say that IRC is not the best medium where code examples and terms need to be cited as in a paper.
14:30:13
mfiano
I am still interested. I just don't think this forum is doing a good job of helping me understand.
14:45:04
jackdaniel
sometimes it is hard to set apart preferences from convictions; it is related to a set of cognitive biases, i.e anchoring and false consensus; I suppose these two are culpirts that often prevent seeing the other side argument
14:54:40
Guest74
now it's nice if you can just pass an object that contains your favourite dictionary, knows your preferred phonetic alphabet etc..., but what if you just want to change one setting for one call?
14:58:22
Guest74
or for vector graphics &key style (stroke (stroke style))(fill(fill style))(miter...
14:59:42
mfiano
If Uncle Bob is to be taken seriously, anything more than 2 or 3 arguments should be rolled into a "parameter object"
15:15:25
Guest74
I think there's a bot here that dislikes me asking what it thinks are stupid questions like 'why can't I name my function p(a|b)' and it kicks me.
16:07:45
mfiano
ACTION wonders how long it takes to use a real client with a real nick for someone very active on IRC
16:13:11
mfiano
Anyone with a Guest* nick, which are reserved for unregistered users on this network.
18:54:14
Bike
given that the web client you're using is presumably also not written in lisp, i don't see the relevance, though.
18:57:46
Guest74
bike: I'm not sure anybody uses those given that cl-irc is inflexible in the way it handles certain responses. Unless everybody just did what I did and change parts of cl-irc.
19:08:03
scymtym
my issue was that it does too much at a time (blocking) and too much on its own (via pre-registered handlers)
19:08:09
Guest74
but besides it not making space in some destructuring-binds for some extra stuff sent by libera I'm still using it. Just had to change stuff.
19:14:13
scymtym
i'll keep that in mind. maybe i should move the GUI code into a separate repository
19:16:30
Guest74
I don't currently use any of the other networks you support, but a more rounded out backend would be nice.
20:07:59
phoe
(also I see that this was already linked earlier, apologies for a very belated response)
20:11:56
pranavats
That Latex Parser is for LaTeX 2.0.9, has support for only a handful of LaTeX2e macros, and doesn't support the documentclass macro in particular. These can be fixed though.
20:15:06
scymtym
pranavats: https://github.com/scymtym/dpans-conversion/tree/online-lisp-meeting/code/parser (background: https://techfak.de/~jmoringe/presentation-dpans-conversion/slides.html ). but again: that is not a generic TeX parser