<beach>
The DEFPACKAGE macro essentially expands to a bunch of function calls, of which USE-PACKAGE is one.
<knusbaum>
I'm trying to figure out some subtleties in symbols.
<knusbaum>
It *looks* like a symbol's package is set at read time - that is, unqualified symbols get the package name of the current package when they are read. Is that right?
<beach>
Yes.
<beach>
READ calls INTERN which either returns an existing symbol or creates a new one with the package being the current package.
<knusbaum>
Perfect. I'm writing a lisp and trying to figure out how to model symbol ownership. That's roughly how I did it too, but trying to figure out how to handle odd things.
<beach>
Why are you writing a lisp?
<vitovan>
knusbaum: Ah, you are pursuing your own happiness.
<knusbaum>
beach, because it's fun :)
<vitovan>
> Lisp is like happiness, everyone has their own #lisp
<beach>
vitovan: Are you new here? I don't recognize your nick.
<vitovan>
but I do not talk too much, because I know too few, and my English sucks.
<knusbaum>
(assuming we start in cl-user) One might expect that to define bar in package foo, but since bar is read in cl-user, it ends up as (defun cl-user::bar ...)
<beach>
knusbaum: Yes, that won't work as some people intend, since the entire PROGN form is read before anything is executed.
<knusbaum>
Right, exactly.
<knusbaum>
This was a weird consequence I discovered in my own lisp. I observed the same behavior in CL and wanted to make sure I was understanding the reason. I know why *my* lisp was doing it.
<knusbaum>
Glad to hear my reasoning about CL is correct.
<vitovan>
beach: > since the entire PROGN form is read before anything is executed.
<vitovan>
beach: this is helpful, thank you.
<beach>
Sure.
<knusbaum>
It's also odd to me that you can define functions in other packages.
mxmkm has joined #commonlisp
<knusbaum>
Like I can (defun foo::bar () ...) while in package cl-user
<beach>
And that is very helpful, and it works because the package system is not a module system.
<knusbaum>
Seems like the package I'm in really just affects the default package that the reader assigns to symbols.
<knusbaum>
beach, right.
<beach>
Exactly.
newb710 has joined #commonlisp
<knusbaum>
Are there any other direct effects of the current package?
<grolter[m]>
About PROGN - one could use the the "go-fast operator" [ a reader macro ] and do stuff like (progn #.(in-package #:foo) (defun bar () 10) #.(in-package #:cl-user)) ; defines bar::foo
<knusbaum>
grolter[m], ahh, yeah I didn't think about that. That makes sense.
<grolter[m]>
* foo::bar
<beach>
knusbaum: Here is how we sometimes use this possibility: We define a "protocol package" that has only #:EXPORT stuff. No code is written with an (IN-PACKAGE <protocol package>). Then we have an "implementation package" that may or may not :USE the protocol package, and that's where definitions are made.
fiddlerwoaroof_ is now known as fiddlerwoaroof
<knusbaum>
beach, and the implementation package explicitly does (defun protocol-package:whatever ...) ?
<beach>
If the protocol package is not :USEd, yes. But we use package-local nicknames of course.
habamax has quit [Ping timeout: 264 seconds]
<beach>
... like PROTO:WHATEVER.
<knusbaum>
Oh, weird. So if you :USE a package, those symbols are still the ones intern'd from the original?
<beach>
Yes.
<knusbaum>
So if I :USE :cl and then defun over something belonging to :cl, that actually redefines the binding in the cl package?
<knusbaum>
(if the package isn't locked or whatever. SBLC seems to have restrictions)
<beach>
Yes.
<knusbaum>
neat.
<knusbaum>
beach, And the benefit of this is that you can choose among multiple implementations to load, while the consumers of the protocol can always use the protocol package. Is that the goal?
<beach>
That is one benefit, yes.
<knusbaum>
I'm learning a lot.
<knusbaum>
Thanks.
<beach>
But these days, we often do multiple implementations using a CLIENT argument to protocol generic functions.
<beach>
That way, multiple implementations can co-exist in the same image.
<knusbaum>
Makes sense. Generic functions sort of solve that.
newb710 has left #commonlisp [#commonlisp]
newb7100 has joined #commonlisp
newb7100 has quit [Client Quit]
<beach>
Indeed.
<knusbaum>
Cool. I'm still heavily developing my lisp. I've been doing it for years at this point in my spare time.
<knusbaum>
I think I'm close to having something worth sharing.
<beach>
What is your implementation strategy? Interpreter?
<knusbaum>
Yeah, it's an interpreter. I've designed it so that I can shift to a bytecode at some point.
<knusbaum>
Right now it's just executing an AST more or less directly.
<beach>
And what language do you use for the implementation?
<knusbaum>
Although arguments and call frames do exist on a "stack"
<knusbaum>
beach, Writing it in Go. Really nice because I can reuse the GC and it's cool to have easy Go interop.
<beach>
I see. Once you have gained some experience, you can help out with SICL.
<knusbaum>
Sweet!
<beach>
I need to start planning for the end of my remaining life expectancy.
<knusbaum>
I wrote a lisp in C a while back, with a threaded bytecode VM. The GC I never got 100% right. I would get occasional bad accesses but could never track them down. It was like once in 20 minutes of heavy CPU usage it would segfault.
<vitovan>
beach: I just found our conversation back in 2016, you freaked me out with your sharp words.
<ixelp>
Creating a Common Lisp implementation (Part 1) - Online Lisp Meeting #4, 06.07.2020 - YouTube
<knusbaum>
Thanks beach.
<beach>
Essentially, I am saying that if you write a Common Lisp implementation using the typical bootstrapping strategy, i.e., starting from a "core" implementation in some other language, you will invariably get maintenance problems.
<vitovan>
Yes, thanks beanch.
<vitovan>
knusbaum: have you checked npt? it's in C and seems to have a proper GC.
<knusbaum>
beach, What's the alternative? Bootstrap from another CL?
<beach>
... which is why SICL code is written in Common Lisp using the full Common Lisp language.
<knusbaum>
My current lisp is not meant to be a Common Lisp. It's a Lisp-1 for starters.
<knusbaum>
But I do want to take a lot of inspiration from CL.
<beach>
You will still have the same problem.
<vitovan>
knusbaum: OK, I get it.
<knusbaum>
beach, I'll watch the videos.
<beach>
knusbaum: Essentially, the order in which your different modules are added matters, and the code for a particular module can not use features defined in modules loaded later.
<knusbaum>
Right.
<beach>
So each module must be written in some subset of the final language. And that's where the maintenance problems come in. The code will be ugly and artificial.
<knusbaum>
I'm starting with just a core of basic functionality I'm calling the "prelude"
<beach>
That's exactly what I mean.
<knusbaum>
Yeah, I see the problem.
<beach>
Even an implementation written mostly in Common Lisp, like SBCL, has this problem, because they load CLOS very late.
<knusbaum>
Sure, so none of the core SBCL code can use CLOS
<beach>
Er, even some implementations written mostly in Common Lisp, like SBCL....
<beach>
But SICL can.
<knusbaum>
Hmmm... Doesn't that mean it would have to start out as a lisp image and slowly replace the "host" lisp?
<knusbaum>
In order to use its functionality as it's being built?
<beach>
No, it just means that a host Common Lisp implementation is used to produce an executable file.
<beach>
The host features are used only during bootstrapping.
<knusbaum>
I see. Because it's CL, the host can compile the files.
<beach>
Yes.
<beach>
And we use first-class global environments to isolate the host code from the target code.
<knusbaum>
How does it generate the core image, though? I don't know much about this in CL. My expecience has been that you basically save a running image with a startup function as an executable.
<knusbaum>
Or you compile lisp files into .fasl's
<knusbaum>
Never seen it generate a brand-new executable.
<beach>
We don't create an executable yet, but it just write bytes. Like I said, there is no trace of the host Common Lisp system in the final executable.
<knusbaum>
Right, that's the magic I'm wondering about. I get how you can compile the source, but all source compilation I've seen turns that source into fasl files.
<beach>
A mirror of the final memory contents is kept in the host during bootstrapping, and that mirror is turned into bytes in the final executable.
<knusbaum>
Ok. So the compiler itself builds a memory image *in* the host image, and then writes it out as an executable.
<knusbaum>
hmmm. interesting.
<beach>
Yes.
<knusbaum>
So do you use the host's assembler capabilities? Or do you have your own assembler, etc?
<beach>
Or, rather, it first represents the machine code as host byte vectors, and those are later written to the mirror.
<knusbaum>
I guess you must. Assuming SICL is self-hosting after bootstraping
<beach>
Everything is SICL specific.
<beach>
Yes.
<knusbaum>
very cool.
<beach>
Thank you.
<knusbaum>
I've written an assembler and linker recently too. amd64 is a nightmare.
<beach>
It is.
<beach>
Our assembler is Cluster, and it has no surface syntax. It's input is a a bunch of instances of standard classes.
<beach>
But for x86, the complications are still there.
<beach>
The main complications are in the register allocator, though.
<knusbaum>
oh really?
<knusbaum>
Just because of the reg-specific instructions?
<beach>
And the restrictions like sharing one argument with the destination.
<knusbaum>
right.
<beach>
I am looking forward to RISC-V.
<knusbaum>
Mine hoists that responsibility on to the user. The assembler is basically a set of types and APIs, including a register allocator.
<knusbaum>
But you can allocate "virtual" registers by size if you don't care.
<beach>
I see.
<knusbaum>
Then if you need a specific register you can request it, and if it's occupied the assembler will output instructions to move it.
patrix has quit []
<knusbaum>
Possibly pushing onto the stack if there's no free regs.
patrix has joined #commonlisp
<knusbaum>
Not the most efficient, but it works.
<beach>
I wonder whether that strategy is good enough for generating optimal code.
<knusbaum>
It generally tries to allocate the R* registers first though. In general I see few inefficient moves like that.
<beach>
Interesting.
<knusbaum>
I think if there are a lot of local virtual registers you'd see thrashing, but usually I don't have too many virtuals.
<knusbaum>
Usually the virtuals are just used to host intermediate results, though. So there are a lot of allocing followed by de-allocing.
<beach>
Basically a non-moving collector for objects shared between threads and old objects, and a sliding collector for the per-thread nurseries.
<beach>
We suspect there will be too many per-thread collections due to object promotions, so we are still working on how to fix that.
<beach>
Initially, I think I will go for just the non-moving common heap.
<beach>
It won't be optimally fast, but it will work.
<knusbaum>
For the 'Requesting roots' stage, how is the communication done? Are there safe-points where the mutators are interrupted?
mxmkm has quit [Changing host]
mxmkm has joined #commonlisp
<knusbaum>
Ahh, there's more here in the PDF
* knusbaum
reads
Guest45 has joined #commonlisp
Guest45 has quit [Client Quit]
<knusbaum>
Nice. The call site descriptor and trace map are great.
<beach>
Thanks.
<knusbaum>
I was wondering if you went conservative or if you actually did precise root analysis.
<beach>
I would never do conservative.
<knusbaum>
It never works out very well.
<knusbaum>
I mean I've used bohm before. That's what I started out with with my C lisp.
<knusbaum>
But obviously... there are issues.
<knusbaum>
haha
<beach>
But I think more important than the final strategy for garbage collection is that the bootstrapping strategy allows us to create SICL from a bunch of implementation-independent modules that we are systematically creating, like Clostrum, Trucler, Predicament, Khazern, Constrictor, Iconoclast, Cyclosis, etc.
<beach>
Any new (or existing) Common Lisp implementation can use those modules, but, of course, they use the full language, so either they use the SICL bootstrapping technique, or they must implement a restricted version first, and then load the final module later.
<knusbaum>
Right. That's a really neat approach. Is it novel? I don't think I've seen it before.
<beach>
I suspect every existing Common Lisp implementation has its own code for most of the modules defined in the standard.
<knusbaum>
Go bootstraps itself with a minimal implementation in C, and then does several more bootstraping phases to get the complete language available.
<beach>
That sounds like Go must have the same problems as I mention in my videos.
<beach>
Like, every time you do that, you must write your modules in a subset of the final language.
<beach>
I started out with that idea for SICL, but quickly realized that my brain is too small to keep those subsets in memory.
<knusbaum>
True, but that's a moving slider. I do expect that it requires more maintenance though, as you say.
<beach>
And if I myself can't handle it, how can I communicate it to others who want to help?
vitovan has quit [Ping timeout: 246 seconds]
<knusbaum>
Like, the compiler, up to version go1.17 had to be compilable by go1.4
<beach>
So now, the strategy is to define independent modules, that can be maintained independently.
<knusbaum>
Then the newer ones have to be compilable by go1.17.
<beach>
Oh dear!
<beach>
I ran into those problems for my PhD.
<knusbaum>
So to bootstrap go1.20, you have to start with C -> go1.4 -> go1.17 -> go1.21
<beach>
Errors would propagate several generations, so I had to keep many old versions around.
<beach>
That's why SICL is defined to use only a conforming Common Lisp implementation, plus CLOSER-MOP.
<knusbaum>
Right. You need to keep the chain intact so you don't destroy your language. Always need to be able to bootstrap from nothing.
<knusbaum>
But that go1.20 bootstrapping is only if you need to bootstrap on a system with *NO* Go. Otherwise you just grab the latest running version and build the new one.
<knusbaum>
I think maybe the bootstrapping problem isn't as bad in compiled languages as in CL?
<knusbaum>
Because while I can't use the latest features if I'm building the next version, I can use the full previous-version language. It's not like SBCL where they can't use CLOS because it's loaded later.
<hayley>
I'm conflicted to how sophisticated our "bootstrap" interpreter (for another language) needs to be.
<beach>
Common Lisp is a compiled language.
<beach>
... or, rather, compilation is not a matter of language.
<beach>
What you are describing is precisely the bootstrapping problem I want to avoid.
<hayley>
My implementation of pinning (for the incremental compactor of the garbage collector for SBCL I'm writing) pins entire pages, which is very needlessly imprecise, but it doesn't seem to matter much.
<hayley>
(The collector is parallel, generational and mostly non-moving.)
shka has joined #commonlisp
<beach>
knusbaum: I think we are lucky that the Common Lisp specification does not evolve, so I don't have to specify which language version is needed to bootstrap SICL.
vitovan has joined #commonlisp
pranavats has left #commonlisp [Error from remote client]
<hayley>
There was some weird phase ordering bug, where the garbage collector would not log pointers (needed by the incremental compactor) because I hadn't yet set up the set of pages to compact. And I couldn't set up the set of pages, because I hadn't found all the conservative roots to pin yet. In hindsight I don't get the issue.
<hayley>
We can't move those objects anyway, after we pin the pages, so it shouldn't matter that the objects aren't logged.
<hayley>
Hmm. I would need to compute the set of pages to compact after scanning conservative roots (which get pinned), but before scanning precise roots (which can be fixed).
mariari has quit [Ping timeout: 264 seconds]
mariari has joined #commonlisp
<knusbaum>
beach, indeed.
<knusbaum>
beach, Wonder why mature implementations like SBCL haven't gone the completely self-hosted method. Now that they have a working CL, they could do what you're doing and rewrite their system entirely in CL with the full features.
<knusbaum>
Anyway, I'm off for now. I'll pop in maybe tomorrow. Thanks for all the conversation!
* knusbaum
waves
edgar-rft has quit [Quit: Leaving]
<beach>
knusbaum: They absolutely don't want SBCL to be required for bootstrapping.
<beach>
knusbaum: Take care!
<beach>
... so they can't rely on any SBCL implementation details for the bootstrapping procedure.
<beach>
If they did rely on SBCL for bootstrapping, they would have the exact problems I mentioned before with different versions, just as Go must have.
vitovan has quit [Ping timeout: 240 seconds]
pfdietz has joined #commonlisp
vitovan has joined #commonlisp
mingus has joined #commonlisp
abrantesasf has quit [Remote host closed the connection]
amb007 has quit [Ping timeout: 246 seconds]
amb007 has joined #commonlisp
pfdietz has quit [Quit: Client closed]
vitovan has quit [Quit: leaving]
rgherdt has joined #commonlisp
rtypo has joined #commonlisp
igemnace has joined #commonlisp
msavoritias has joined #commonlisp
easye has joined #commonlisp
euandreh has quit [Ping timeout: 250 seconds]
Inline has joined #commonlisp
Inline has quit [Remote host closed the connection]
<beach>
renatoathaydes: I think the declaration identifier is FTYPE.
semz has quit [Quit: ZNC 1.8.2+deb2build5 - https://znc.in]
<renatoathaydes>
I did use ftype
<beach>
Oh, you used FTYPE. Sorry.
<renatoathaydes>
if you have a link to some example, that would be really helpful. My example causes a warning which pretty much says the type was "clobbed"
euandreh has joined #commonlisp
semz has joined #commonlisp
<beach>
Try the proclamation before the DEFGENERIC, maybe?
* beach
is still puzzled by the obsession with type declarations.
<beach>
I have no explanation for those messages. Sorry.
euandreh has quit [Ping timeout: 252 seconds]
<beach>
Why do you want to proclaim the type of your function?
rainthree3 has quit [Ping timeout: 250 seconds]
<beach>
I sometimes use type proclamations for ordinary functions as a sort of "forward" declaration to avoid warnings about undefined functions. But for generic functions, the DEFGENERIC for is perfectly fine as a "forward" declaration.
<renatoathaydes>
I want the types to both document what classes implementing those methods need to return, and to make sure errors are caught (preferrably at compile-time, but runtime also works)
<beach>
Oh, but that's not what declarations and proclamations do in Common Lisp.
<renatoathaydes>
Well it works on functions.
<jackdaniel>
such declarations could potentially speed up unsafe code and catch issues in safe code
<beach>
They are promises to the compiler. And if you get it wrong, the consequences are undefined.
<beach>
renatoathaydes: It doesn't "work" in that Common Lisp is not defined by the behavior of a particular implementation.
<renatoathaydes>
The functions I've "declaimed" catch errors at compile time on SBCL at least.
<splittist>
renatoathaydes: you have declared the function to take anything and a string and return a string. Then you have declared a method that takes anything and anything.
<Equill>
Ah, so they're more like "the" declarations, than assertions?
<renatoathaydes>
And they show in the docs, so what do you mean by "that's not what they're for"??
<jackdaniel>
splittist: the pasted code is incorrect, but sbcl adds a proclamation even when method has a matching signature (and the returned value is known)
<splittist>
I will stay silent (:
<jackdaniel>
no no, your remark was spot on :)
<renatoathaydes>
Incorrect in what way?
<jackdaniel>
renatoathaydes: (format t "foo") will return NIL
<beach>
renatoathaydes: Like I said, in Common Lisp, type declarations are promises to the compiler, and the consequences are undefined if they are violated. There is no guarantee that they will be checked.
<jackdaniel>
not string
<renatoathaydes>
oh right, should be nil, but I guess you know what I meant :)
euandreh has joined #commonlisp
<renatoathaydes>
So SBCL correctly told me my function got the return type wrong :D that's great.
<renatoathaydes>
I don't know what error I had earlier with my "actual" code but looks like this should work... thanks.
<jackdaniel>
you will get the same warning either way
<renatoathaydes>
I might move to Calton (the Haskell-like CommonLisp language) though as CL types are pretty awkward to use.
<renatoathaydes>
I didn't get any warning after fixing it.
<jackdaniel>
that's weird, but good for you then
<beach>
renatoathaydes: My advice is to avoid type declarations.
<jackdaniel>
renatoathaydes: I take that you mean coalton
<renatoathaydes>
Coalton yeah
<beach>
renatoathaydes: Because you will introduce promises that you often then can't keep.
<renatoathaydes>
anyone using that?
euandreh has quit [Ping timeout: 260 seconds]
Brucio-61 has quit [Remote host closed the connection]
Brucio-61 has joined #commonlisp
habamax has joined #commonlisp
Krystof has quit [Ping timeout: 250 seconds]
<beach>
renatoathaydes: I think if you want static typing, it is probably best to use a statically typed programming language.
Brucio-61 has quit [Ping timeout: 260 seconds]
<jackdaniel>
coalton is statically typed
<beach>
Yes, I know.
<jackdaniel>
I see
<jackdaniel>
I think that gradual typing is a fine idea too and sbcl ebraces that to some extent if I recall correctly
<jackdaniel>
fast generic functions created by heisig also introduces the notion of sealed domains that falls in that category
<jackdaniel>
embraces*
<beach>
Oh, sure, if renatoathaydes wants to program in SBCL, that's fine too.
<beach>
.. rather than in Common Lisp, I mean.
<jackdaniel>
if the program is correct (and having an implementation that enforces such correctness), then it will work on other common lisp implementations too
<jackdaniel>
the part in parenthesis was not very intelligible, was it? :)
<jackdaniel>
I mean "having an implementation that helps enforcing some quality does not make the program itself incorrect"
<jackdaniel>
or not portable common lisp
<jackdaniel>
just as relying on superior debugger in sicl to spot issues does not render the code itself "not common lisp"
<renatoathaydes>
I really enjoy CommonLisp... but I want to be able to define "protocols" and was hoping to use CLOS for that, with some "ftype" declarations to help clarify those protocols. Also, when you (describe) something, don't you think seeing the lambda-list with proper types instead of `(T T T) T` is helpful?
Brucio-61 has joined #commonlisp
<jackdaniel>
you may always document these things
<jackdaniel>
type declaration is not a good form of documentation
<renatoathaydes>
with declaim, precisely.
<renatoathaydes>
why not?
<jackdaniel>
because it is part of code
<renatoathaydes>
even better.
<jackdaniel>
it is as if you had said: the code is the documentation
<jackdaniel>
if that suits you then sure, just saying that not many people will recognize this as a protocol or documentation; it is basically saying "my code does what it does[*].. [*] with annotations"
<beach>
renatoathaydes: I use the type name as a parameter name in the DEFGENERIC form, which is why I always try to use explicit DEFGENERIC forms, even for slot accessors.
Brucio-61 has quit [Remote host closed the connection]
Brucio-61 has joined #commonlisp
<beach>
Except when the parameter is a list or a vector, I use the type of the elements, in plural form.
<renatoathaydes>
jackdaniel: I would say most people will recognize type declarations as documentation because the CommonLisp stdlib does it everywhere.
<beach>
renatoathaydes: What is the "CommonLisp stdlib"?
<renatoathaydes>
Do you ever (:use :cl)?
<renatoathaydes>
That's stdlib for you.
<hayley>
It does?
<beach>
How does the COMMON-LISP package "recognize type declarations"?
<renatoathaydes>
(describe) something and you will see the types for most things.
Brucio-61 has quit [Ping timeout: 260 seconds]
<beach>
renatoathaydes: That would be specific to a particular implementation, and it is not the language Common Lisp.
<hayley>
But that behaviour isn't specified by Common Lisp.
Brucio-61 has joined #commonlisp
<Equill>
That's not documentation. It's a source of information, sure, but that isn't the same thing.
<jackdaniel>
documentation is a vague word so they may recognize that as documentation;; but I think that not many people will share the sentiment that the code is the documentation (and tools to extract data from the runtime)
<renatoathaydes>
how many people consider types to be "not for documentation"??
<jackdaniel>
that said if we insist on "that's not what is specified in common lisp" then we can give up on threads, networking and oh so many things, so let's not go there :)
<jackdaniel>
"being for" and "being /something/" are two different things
<Equill>
jackdaniel: exactly that.
<renatoathaydes>
what's the point you're trying to make? That types cannot help a developer who's trying to use an API or that they just aren't strictly "documentation" according to your definition of "documentation"?
<jackdaniel>
my point is that providing hints to the compiler by adding declamations, proclamations, declarations and such does not constitue proper documentation or protocol description (in my personal definition of "documentation")
<jackdaniel>
if you want to provide the documentaiton, then grab a keyboard and write it
<jackdaniel>
(that said, I think that adding declarations that are in line with documentation may be very useful, especially if the implementation helps to enforce them in the safe code - that is, as noted above, not guaranteed by the standard, but it is not forbidden neither)
Lord_of_Life has quit [Ping timeout: 250 seconds]
Lord_of_Life_ is now known as Lord_of_Life
karlosz has joined #commonlisp
karlosz has quit [Remote host closed the connection]
lucasta has quit [Remote host closed the connection]
splatt990 has quit [Remote host closed the connection]
gin has joined #commonlisp
gin has quit [Client Quit]
renatoathaydes has quit [Ping timeout: 250 seconds]
therepl has quit [Changing host]
therepl has joined #commonlisp
renatoathaydes has joined #commonlisp
renatoathaydes has quit [Ping timeout: 240 seconds]
LispTyro has quit [Quit: Connection closed for inactivity]
renatoathaydes has joined #commonlisp
rainthree has joined #commonlisp
<jcowan>
the problem with type declarations is that compilers may use them to pessimize your code
Gleefre has joined #commonlisp
AkashaPeppermint has joined #commonlisp
<jackdaniel>
jcowan: could you provide more context please?
<jackdaniel>
(i.e how and why)
<jcowan>
I'll try to find the example
<jackdaniel>
OK, thank you
renatoathaydes has quit [Ping timeout: 245 seconds]
<jcowan>
Sorry, I can't find the reference. Clearly when such things get reported, implementers treat them as bugs (even though technically they are not). I *think* the example I saw had to do with the compiler being able to infer a better (faster, smaller) machine-level type for a variable than the declaration provides for.
srji has joined #commonlisp
<srji>
hello
<jackdaniel>
I see
<jackdaniel>
srji: hey
<jackdaniel>
jcowan: I can imagine a compiler that ignores the inference result in light of a declaration, but technically speaking it could either take the inference as a better result, or (if it trusts declarations), us the declaration to narrow it further (and <inferred> <declared>)
<jcowan>
AAbsolutely.
<jcowan>
My recollection is that such compilers have existed, and my suspicion is that some existing compilers will misbehave in particular cases.
<jackdaniel>
fair enough
<jcowan>
IWBNI there was a portable way to distinguish between declarations that are assertions and ones that are assumptions, between "check this" and "you need not check this".
<jackdaniel>
iwbni?
renatoathaydes has joined #commonlisp
<jackdaniel>
urban dictionary says ¯\_(ツ)_/¯
<hayley>
It would be nice if
<jackdaniel>
ah, thanks
<jackdaniel>
well, there is: (declare (integer foo)) and (check-type foo integer)
renatoathaydes has quit [Remote host closed the connection]
renatoathaydes has joined #commonlisp
renatoathaydes has quit [Ping timeout: 250 seconds]
renatoathaydes has joined #commonlisp
rainthree has quit [Ping timeout: 264 seconds]
tibfulv has quit [Remote host closed the connection]
tibfulv has joined #commonlisp
random-nick has joined #commonlisp
tyson2 has joined #commonlisp
mm007emko has joined #commonlisp
rainthree has joined #commonlisp
<beach>
srji: Are you new here? I don't recognize your nick.
syaglo has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
StanislavYaglo[m has joined #commonlisp
<knusbaum>
beach > If they did rely on SBCL for bootstrapping, they would have the exact problems I mentioned before with different versions, just as Go must have.
<knusbaum>
Don't they have that problem anyway? You can't use "new" features of SBCL in its implementation if you're bootstrapping off of another system, right? Same with SICL I would think? Or do you load the SICL into the host lisp and use it during compilation?
<beach>
That is not true.
splittist has quit [Server closed connection]
splittist has joined #commonlisp
<beach>
SBCL does not execute any SBCL code in the host. It just compiles everything into FASLS that are then basically concatenated, so that the top-level forms are then executed outside the host.
<beach>
With SICL, we compile SICL code using the SICL compiler, and we can execute SICL code in the host, so we can load any SICL code that is not present in the host. Luckily, because the entire SICL CLOS implementation is different from that of the host.
rgherdt has quit [Read error: No route to host]
rgherdt has joined #commonlisp
<knusbaum>
I see. But the SICL compiler then at least needs to depend on the host? Since you can't compile and load SICL until the compiler is present?
<beach>
The SICL compiler is written in portable Common Lisp + MOP, so it can execute anywhere.
<knusbaum>
right, cool.
<beach>
That's the point of using a standardized language. You don't depend on features of your own system for bootstrapping.
<beach>
knusbaum: I am guessing Go does not have that luxury because: 1. It doesn't have a standard. 2. Even if it did, there is (I am guessing here) only one implementation of it. 3. The language implemented by the implementation evolves.
<beach>
With Common Lisp, we have several implementations that are very close to conforming, and they all conform to a single standard that does not evolve.
agm has joined #commonlisp
<agm>
in ANSI CL, type declarations are promises and it is undefined behavior if they are broken. SBCL often treats declarations as assertions (even checking them at runtime) but this is buggy according to the manual https://www.sbcl.org/manual/#Declarations-as-Assertions
<ixelp>
SBCL 2.3.5 User Manual
<beach>
Why do you say that?
Equill has quit [Ping timeout: 240 seconds]
<agm>
me?
<beach>
Yes.
<beach>
If the standard says that it is undefined behavior, a conforming implementation is obviously allowed to define that behavior.
<beach>
I mean, the implementation will behave in *some* way anyway.
<agm>
i didn't argue against that
<beach>
Then what?
<agm>
well, i think that I hit some of those bugs in the past, when I relied on type declarations (as assertions) to aid in debugging. at least that was my impression
<splittist>
I'm not agm, but the SBCL manual says, regarding declarations as assertions, that this can cause undefined behaviour "These are important issues, but are not necessarily easy to fix, so they may, alas, remain in the system for a while." I think "buggy" is an acceptable one-word summary of that.
<beach>
Oh, so the argument is that SBCL the implementation does not correspond to its own documentation? Sure, that can be the case.
<beach>
Or, worse, it does correspond to its documentation, and using declarations in SBCL can not be relied upon.
habamax has quit [Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.0.92)]
kar7hik has joined #commonlisp
kar7hik has quit [Client Quit]
<beach>
Yes, I think I understand.
liminality has joined #commonlisp
<liminality>
hi everyone
<beach>
Hello liminality.
<liminality>
i've setup a function that funcalls a passed func, though i want to pass a func from another package. passing #'the-package:the-func doesn't seem to work, i get an error that it can't find the-func in cl-user.
<liminality>
hi beach~
<beach>
That should work.
<beach>
You must not have had the right current package when you defined the function.
<liminality>
hmmm
<liminality>
ah
<liminality>
you're right
<liminality>
it does work, i just had a typo in the function name
Brucio-61 has quit [Ping timeout: 260 seconds]
Brucio-61 has joined #commonlisp
karlosz has joined #commonlisp
Gleefre has quit [Ping timeout: 246 seconds]
morganw has joined #commonlisp
thollief has joined #commonlisp
Brucio-61 has quit [Ping timeout: 260 seconds]
Brucio-61 has joined #commonlisp
syaglo has quit [Remote host closed the connection]
agm has quit [Ping timeout: 240 seconds]
thollief has quit [Quit: Leaving]
jurassic has quit [Ping timeout: 252 seconds]
thollief has joined #commonlisp
thollief has quit [Remote host closed the connection]
thollief has joined #commonlisp
Lycurgus has joined #commonlisp
zacque has joined #commonlisp
rainthree has quit [Read error: Connection reset by peer]
<scymtym>
i expected parts of compound literals that EQ in the source code to be EQ in the compiled code
<scymtym>
the fact that the property holds in one case but not the other two is also strange
<_death>
they all show as EQ here.. but I evaluated each form one by one (C-M-x) .. do you mean with compile-file?
<scymtym>
the complete SBCL call is in the first annotation. is the annotation not displayed by default?
<_death>
oh, I didn't notice there was an annotation
<_death>
ok, I see what you mean now
Krystof has joined #commonlisp
<_death>
clhs 3.2.4.4
<scymtym>
right, i was going to say, i believe this behavior violates "The file compiler is required to preserve eqlness of substructures within a file. Preserving eqlness means that subobjects that are the same in the source code must be the same in the corresponding compiled code." in https://novaspec.org/cl/3_2_Compilation#sec_3_2_4_4
<ixelp>
3.2 Compilation | Common Lisp Nova Spec
<_death>
I tend to agree
semz has quit [Quit: ZNC 1.8.2+deb2build5 - https://znc.in]
<scymtym>
thanks
semz has joined #commonlisp
msavoritias has quit [Remote host closed the connection]
ec_ has joined #commonlisp
ec has quit [Ping timeout: 240 seconds]
ec_ has quit [Ping timeout: 240 seconds]
thollief has quit [Quit: Leaving]
scymtym has quit [Ping timeout: 264 seconds]
Brucio-61 has quit [Ping timeout: 260 seconds]
scymtym__ has joined #commonlisp
cage has quit [Quit: rcirc on GNU Emacs 28.2]
scymtym__ has quit [Ping timeout: 264 seconds]
ec_ has joined #commonlisp
Brucio-61 has joined #commonlisp
jmercouris has quit [Server closed connection]
jmercouris has joined #commonlisp
Devon has quit [Ping timeout: 252 seconds]
dipper has quit [Ping timeout: 245 seconds]
shka has quit [Ping timeout: 240 seconds]
gxt__ has quit [Ping timeout: 240 seconds]
gxt__ has joined #commonlisp
puchacz has quit [Quit: Client closed]
rgherdt_ has joined #commonlisp
rgherdt has quit [Ping timeout: 250 seconds]
jeosol has quit [Quit: Client closed]
kevingal has joined #commonlisp
rgherdt_ has quit [Ping timeout: 264 seconds]
pve has quit [Quit: leaving]
LispTyro has joined #commonlisp
karlosz has joined #commonlisp
tyson2 has joined #commonlisp
alcor has quit [Remote host closed the connection]
defaultxr has joined #commonlisp
rendar has quit [Ping timeout: 264 seconds]
dino_tutter has quit [Ping timeout: 252 seconds]
random-nick has quit [Ping timeout: 240 seconds]
Kongo04 has joined #commonlisp
edgar-rft has quit [Ping timeout: 240 seconds]
edgar-rft has joined #commonlisp
syaglo has joined #commonlisp
phantomics_ has joined #commonlisp
rtypo has quit [Ping timeout: 250 seconds]
lonjil has quit [Read error: Connection reset by peer]
bitblit1 has quit [Ping timeout: 255 seconds]
Duuqnd has quit [Ping timeout: 255 seconds]
habamax has joined #commonlisp
therepl has quit [Ping timeout: 255 seconds]
surabax[m] has quit [Ping timeout: 255 seconds]
lonjil has joined #commonlisp
bitblit1 has joined #commonlisp
phantomics has quit [Ping timeout: 256 seconds]
karlosz has quit [Quit: karlosz]
m5zs7k_ has joined #commonlisp
syaglo has quit [Remote host closed the connection]