donleo has quit [Remote host closed the connection]
donleo has joined #commonlisp
habamax has quit [Ping timeout: 252 seconds]
mgl_ has quit [Ping timeout: 256 seconds]
donleo has quit [Ping timeout: 256 seconds]
habamax has joined #commonlisp
zetef has quit [Ping timeout: 264 seconds]
kevingal__ has joined #commonlisp
green_ has joined #commonlisp
certainty has joined #commonlisp
dnhester26 has quit [Remote host closed the connection]
certainty has quit [Ping timeout: 260 seconds]
dnhester26 has joined #commonlisp
certainty has joined #commonlisp
certainty has quit [Ping timeout: 256 seconds]
masinter has quit [Ping timeout: 256 seconds]
masinter has joined #commonlisp
rogersm has joined #commonlisp
akoana has joined #commonlisp
random-nick has quit [Ping timeout: 252 seconds]
certainty has joined #commonlisp
jmdaemon has joined #commonlisp
certainty has quit [Ping timeout: 276 seconds]
rogersm has quit [Ping timeout: 255 seconds]
<phantomics>
Concerning LW and ACL: SBCL has them beat by a considerable margin in performance, particularly multithreading. April's speed at processing large arrays using them has never come close to what it can do with SBCL
<aeth>
SBCL has always been the number crunching implementation
<aeth>
maybe literally always since it's a fairly new one
habamax has quit [Ping timeout: 255 seconds]
<phantomics>
Also, when I tested under ACL a little under 2 years ago, I found an amusing bug in ACL. Its implementation of (alphanumericp) will return t for any non-alphanumeric character that -isn't- on the keyboard. So for example APL's ↑⌽⊤⎕⍝ and other special characters all return t
<aeth>
ouch
<aeth>
are you trying to get it on the GPU now, btw?
<phantomics>
This catastrophically broke April when I first tried it under ACL, now it uses a specialized function to match valid characters for names
habamax has joined #commonlisp
<phantomics>
Yes, the route I'm now investigating is via SPIR-V
<phantomics>
This will allow for work in ML as well as graphics
<phantomics>
But there's another project coming along as well...
<ixelp>
GitHub - 3b/3b-spirv: SPIR-V assembler with lispy syntax.
<aeth>
I believe I was aware of it at the time. It also went as far as doing the example from the spec (well, I didn't do the example yet, just the smallest SPIR-V shader that successfully validates)
<aeth>
(so that went a bit further)
<phantomics>
Yes, I've built that example with it and also done rudimentary work building my own kernels by extending April thunk methods
<phantomics>
I was experimenting with extending beach's Cluster, but currently it's fairly tightly coupled to a small subset of x86
<phantomics>
Somewhere out there in idea-space is a great general model for generating binary words from series of sexps, but I haven't grasped it yet
<aeth>
yes, I wasn't particularly happy with various ways to represent it yet
<aeth>
though it's just two intermediate representations
<aeth>
ideally there would be at least one above that, and maybe a rework of the higher level IR (basically middle level) that isn't basically just spir-v-in-s-expressions
<phantomics>
So a higher-level representation that could map to a sexp representation of SPIR-V, x86, ARM or others?
<aeth>
minimal Lisp-like language that is exactly as capable as spir-v in types etc. -> structured spir-v -> sxp spir-v instructions -> spir-v binary
<aeth>
as for how to run it on the CPU, there are several options, since I could basically implement any of those four layers in either CL or CL-supported inline asm
<aeth>
and as for the ergonomics of that, even that may be too low level
<phantomics>
My approach to ergonomics has been using APL as the topmost layer
avocadoist has quit [Ping timeout: 255 seconds]
<aeth>
well, this would e.g. not be dynamically typed (but could probably be heavily type inferred instead of using manifest typing) and wouldn't be powerful enough to compile itself and would probably lack a lot of key things like linked lists
<phantomics>
Practically, for parallel ops you want the ability to intelligently compose operations, and APL-driven lazy eval is the best way I can see to do that
<aeth>
(but if you wanted to try to compile a real Lisp to it just to run it poorly on the GPU instead of on the CPU...)
<phantomics>
Practically GPU means using only arrays, and April's lazy system allows for a lot of flexibility with type inference
<phantomics>
For example, you can do 3 ⎕TY (a bunch of code) to specify that the output should have 8-bit integer elements (since 2^3 is 8)
<aeth>
only arrays at run time, anyway... you still have access to Common Lisp at macroexpansion time
<phantomics>
Since it's lazily evaled you can apply that type coercion to all stages of the operation it's applied to
<phantomics>
If someone doesn't understand the typing system they can just not manually apply any types and the system will apply slow but foolproof defaults
certainty has joined #commonlisp
certainty has quit [Ping timeout: 276 seconds]
ronald has quit [Ping timeout: 256 seconds]
ronald_ has joined #commonlisp
rogersm has joined #commonlisp
dinomug has joined #commonlisp
habamax has quit [Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.1.90)]
edr has quit [Quit: Leaving]
dcb has quit [Quit: MSN Messenger 4.1.1]
akoana has quit [Quit: leaving]
ldb has joined #commonlisp
kevingal_ has quit [Ping timeout: 252 seconds]
kevingal has quit [Ping timeout: 252 seconds]
tyson2 has quit [Remote host closed the connection]
waleee has quit [Ping timeout: 255 seconds]
certainty has joined #commonlisp
szkl has quit [Quit: Connection closed for inactivity]
certainty has quit [Ping timeout: 256 seconds]
rogersm has quit [Ping timeout: 264 seconds]
masinter has quit [Remote host closed the connection]
avocadoist has joined #commonlisp
certainty has joined #commonlisp
habamax has joined #commonlisp
certainty has quit [Ping timeout: 276 seconds]
rogersm has joined #commonlisp
habamax has quit [Remote host closed the connection]
rtypo has quit [Ping timeout: 255 seconds]
habamax has joined #commonlisp
Pixel_Outlaw has quit [Quit: Leaving]
habamax has quit [Remote host closed the connection]
habamax has joined #commonlisp
rogersm has quit [Ping timeout: 256 seconds]
<samebchase>
I'm using SLY. How do I configure it to find the SBCL source directory? The one it uses by default is not accessible due to a permissions issue. I have cloned the SBCL repo locally, and I want to point it to that.
certainty has joined #commonlisp
zetef has joined #commonlisp
ldb has quit [Remote host closed the connection]
habamax has quit [Read error: Connection reset by peer]
notzmv has quit [Ping timeout: 256 seconds]
rogersm has joined #commonlisp
jmdaemon has quit [Ping timeout: 255 seconds]
tertek has quit [Quit: %quit%]
tertek has joined #commonlisp
zetef has quit [Ping timeout: 256 seconds]
igemnace has joined #commonlisp
rogersm has quit [Ping timeout: 255 seconds]
zetef has joined #commonlisp
szkl has joined #commonlisp
King_julian has joined #commonlisp
thollief has joined #commonlisp
rgherdt has joined #commonlisp
rogersm has joined #commonlisp
danlitt has joined #commonlisp
_cymew_ has joined #commonlisp
rogersm has quit [Ping timeout: 256 seconds]
attila_lendvai has joined #commonlisp
zetef has quit [Ping timeout: 268 seconds]
King_julian has quit [Ping timeout: 255 seconds]
varjag has joined #commonlisp
danlitt has quit [Ping timeout: 256 seconds]
shka has joined #commonlisp
zetef has joined #commonlisp
King_julian has joined #commonlisp
dinomug has quit [Remote host closed the connection]
attila_lendvai_ has joined #commonlisp
notzmv has joined #commonlisp
attila_lendvai has quit [Ping timeout: 256 seconds]
ym has joined #commonlisp
contrapunctus has left #commonlisp [#commonlisp]
<Alfr>
samebchase, set inferior-lisp-program and you will likely need to set the env var SBCL_HOME appropriately.
<easye>
dnhester26: I think you need to use FUNCALL or APPLY instead of invoking UPDATE-FUNCTION directly, as the compiler doesn't have a function definition at compile time.
<dnhester26>
easye I tried and didn't work... I updated the pastebin https://plaster.tymoon.eu/view/4017#4017 maybe I'm doing it wrong? I did funcall #'update-function
<dnhester26>
but got the same result
<dnhester26>
undefined
<varjag>
don't quote it
<varjag>
(funcall update-function…
amb007 has quit [Ping timeout: 256 seconds]
<varjag>
update-function is a variable that is bound to closure you want to funcall
amb007 has joined #commonlisp
<dnhester26>
ah thanks now it works, varjag I just realized I tried before and I got an error but didn't realize it was a different error of something else not working
<dnhester26>
thanks!
<varjag>
np
flip214 has quit [Ping timeout: 255 seconds]
bjorkint0sh has joined #commonlisp
bjorkintosh has quit [Ping timeout: 268 seconds]
tyson2 has joined #commonlisp
flip214 has joined #commonlisp
King_julian has quit [Ping timeout: 260 seconds]
danse-nr3 has joined #commonlisp
King_julian has joined #commonlisp
green_ has quit [Ping timeout: 260 seconds]
szkl has quit [Quit: Connection closed for inactivity]
_cymew_ has quit [Ping timeout: 256 seconds]
glaucon has joined #commonlisp
bjork1intosh has joined #commonlisp
rtypo has joined #commonlisp
edr has joined #commonlisp
bjorkint0sh has quit [Ping timeout: 260 seconds]
green_ has joined #commonlisp
dnhester26 has quit [Remote host closed the connection]
nij- has joined #commonlisp
<nij->
We have `declaim in common lisp that helps the compiler knows the type of the type signature of a function.
<nij->
However, in reality this isn't as useful as a statically typed language, because the other parts of the code aren't forced to follow this.
<jcowan>
I think that's a research problem, except of course that nobody is researching it. Against all evidence, we are convinced that There Can Be Only One (arch, that is), and for periods of time this is even true, but on the Lisp timescale x86_64 is but a mayfly
<nij->
I wonder if there's any implementation that allows me to enforce it.
<jcowan>
sorry, I was scrolled back; I was talking about code generation.
<beach>
nij-: How would that work? You declaim your ftype, then you compile some code making a call. Then you redefine the function so that it has a different signature. What happens then?
<beach>
nij-: Does the system find all the function calls previously compiled and invalidate them? Does it give an error message for each one?
<aeth>
Common Lisp doesn't work on the function level, but on the compilation-unit (usually file) level and there are edge cases where doing C-c C-c instead of C-c C-k in SBCL already breaks things
rogersm has joined #commonlisp
<aeth>
so clearly you'd just put it all in one compilation-unit (file?)
<beach>
aeth: Right, so then we are back not only in statically typed languages, but also in static languages, where everything needs to be recompiled from scratch after each minor modification.
<beach>
I really think nij- is on the wrong path here.
<nij->
When you redefine the ftype of that function, just let it go, but print out a warning message.
<aeth>
you could also do some tracking at the implementation level (which would also be useful for inline functions and for macros) so C-c C-c recompiles everything that needs to be recompiled (space is cheap now)
<nij->
After the redefinition, if the user compiles the previous code again that violates, then that's an error.
<jcowan>
It's a different path, but not necessarily wrong. FWIU, in SICL compilation will be only minimal compilation anyway.
<aeth>
though this could mean that C-c C-c (or redefining at the REPL etc) at worst case now instead of compiling the form in front of you but literally the entire program
<aeth>
which can take time that you just don't notice because of all of the FASL caching
<beach>
jcowan: Oh?
<nij->
beach This way, you can preserve the joy of flexible programming, but before you "ship" you still need to make everything pass.
<aeth>
s/but literally the entire program/, now literally recompiles the entire program/
<jcowan>
beach: Perhaps I misread something.
<beach>
Yes, I think so.
<jcowan>
nij-: Makes sense to me. Removing flexibility is what compilers *do*.
<nij->
I think there maybe ways to escalate certain warnings to errors in sbcl.
<aeth>
nij-: the end result for that sort of thing is that you have to remember to ,restart-inferior-lisp before any git push so things fail locally and immediately and not in an email whenever the automated test fails
<nij->
But I don't know how to do that to enforce this sense of static typing.
attila_lendvai has quit [Read error: Connection reset by peer]
<aeth>
(though there are already some edge cases where things will go stale and fail in a fresh instance so restarting before any git push is still a good idea)
<aeth>
s/fresh instance/fresh image/
<nij->
aeth - Yes, of course.. before you push to a collab repo you need to do that anyway.
<nij->
What's easier now is that if there's any type error, you know immediately.
<nij->
Otherwise things may break in runtime say 3 months later when your team is busy on other things.
_cymew_ has joined #commonlisp
<nij->
I consider this as a strict enhancement. Especially if you can decide if you want to turn that "error behavior" off whenever you like.
<jcowan>
To use beach's distinction, there are static languages that are dynamically typed, notably ISLisp.
<jcowan>
e.g. there is no EVAL (or COMPILE) and redefining things leads to undefined behavior. However, all ISLisp implementations I know of are in fact dynamic.
HerlockSholmes has joined #commonlisp
<nij->
beach I'm curious what you think.
danse-nr3 has quit [Ping timeout: 256 seconds]
<jcowan>
nij-: I think the phrase "wrong path" is pretty definitive.
<beach>
Yes, I have nothing to add.
<beach>
jcowan: The SICL FASL format is a minimally compiled AST, but it is then processed by a compiler when it is loaded, so that optimizations and such are applied.
attila_lendvai has joined #commonlisp
<nij->
beach: Hmm.. did my proposal resolve your questions?
<jcowan>
Oh, sure. I didn't mean that compilation in the conventional sense is not done at all, just that it is not done by COMPILE.
<beach>
It is done by COMPILE, but not by COMPILE-FILE.
<jcowan>
Ah.
<jcowan>
In principle, however, it could be postponed past load time as well.
<beach>
It could, sure.
<jcowan>
In which case the sort of checking nij- wants would be available. Of course, with the Mythical Code Walker it would be possible to check types offline.
<jcowan>
(as P*thon programmers do, and that's the last I'll say about that)
<nij->
lol
<nij->
p**hon
<bike>
we've been leaning towards late further compilation in clasp, like post load. not ready to go yet, though.
<bike>
also, i don't think anyone has mentioned this, but it's probably worth noting that the lisp type system lets you declare type preconditions that are impossible to enforce, or at least impossible to enforce at the point of the declaration.
<nij->
Why is it impossible to enforce?
<beach>
It smells undecidable.
bonmlp has joined #commonlisp
<bike>
say you have (declare (type (function (integer) cons) f)). it is valid to then have f = (lambda (x) (if (integerp x) (list x) (gods-only-know))) as long as you only call it on integers, since it will return a cons given an integer. but to enforce this the lisp would need to dig into the definition of f, and for a more complicated f it gets undecidable.
dnhester26 has joined #commonlisp
<beach>
Yeah, so then we need to define a decidable subset of the Common Lisp type system. No wait, that's precisely what statically typed languages have to do, thereby severely limiting what can be expressed.
<bike>
indeed.
<bike>
siek's gradual typing solves this in an interesting way. as far as i understand, when you have a declaration like this*, the compiler wraps up f in a checker, like (let ((f (lambda (x) (let ((result (funcall f x))) (unless (consp result) (error ...)) result)))) ...scope of the declaration...) so you will get an error. but the error is a bit later.
<bike>
*siek works in scheme so the syntax is hardly identical
<nij->
The error happens at runtime?
<bike>
when you call f, yes.
<nij->
bike Thank you very much for the example. This is what I need.
<bike>
which of course means among other things that if you never call f you won't get an error, even if f does not match the type.
<nij->
That almost means that in a statically typed language, you can't have if that returns things of different types.
<nij->
Or if you really want, you need to define a union type to start with.
<beach>
nij-: That's right, if by different types, you mean the way types are defined in those languages.
<bike>
but then you are, of course, abandoning static type checks again
danse-nr3 has joined #commonlisp
<beach>
nij-: And that's part of the problem. Statically typed languages claim that their type systems are "normal" in some sense, but in fact there are tons of things they can't express.
<nij->
I appreciate this more. Thank you both.
<beach>
nij-: Like in Common Lisp you have a NUMBER type, but most statically typed languages must distinguish between floats and integers.
dnhester26 has quit [Ping timeout: 260 seconds]
<beach>
So is (defun foo (x) (if <mumble> 3 2.0)) returning an object of a different type depending on the test?
<bike>
there are various other tricky bits. hindley-milner type inference is pretty fast in practice but theoretically exponential. more expressive type systems like F are uncomputable to infer.
<beach>
Plus, the entire idea falls apart for things like division. You can't express the type that is any number except 0.
<jcowan>
which is analogous to Data.Modifiers.NonEmpty.
<aeth>
beach: the type that's not zero is (not (or (real 0 0) (complex (real 0 0))))
<aeth>
for number, you'll add an AND in front
<bike>
i don't think you need to tell beach that.
<aeth>
so iirc should be (and number (not (or (real 0 0) (complex (real 0 0)))))
<bike>
"Type modifiers for writing properties that quantify over commonly used subsets of standard types." what is a property, exactly? this is new to me.
<beach>
aeth: In Common Lisp yes. But I was talking about those type systems that are implemented by statically typed languages.
<aeth>
well, this is fully static (no SATISFIES) so it's just a problem with their type systems, not with static types
<beach>
aeth: It is a problem if you want it to be decidable.
<nij->
Thanks a lot. :) Heading out..
rogersm has quit [Ping timeout: 256 seconds]
<beach>
Let's not have a debate on decidability, please!
<aeth>
but this discussion does seem to nitpick a bit too much... e.g. in practice, when I care about types in gradually typing CL, I care about very specific types like single-float or (unsigned-byte 32)
<aeth>
and I don't really deal with 0 when there's division even though I could in theory put it in there
<aeth>
and it's OK if the type inference doesn't see this, either
<beach>
aeth: "what you care about" boils down to defining a decidable subset of the Common Lisp type system. And I am pretty sure there could be no consensus on any suggestion of that kind.
nij- has quit [Remote host closed the connection]
<aeth>
personally, when I use types in CL, I mostly care about (1) making code faster for almost no additional work (almost always removing bounds checking or removing generic arithmetic so almost always only relevant to numbers or arrays-of-numbers) or (2) catching things earlier and closer to where it happens instead of randomly getting a NIL or other issue 5,000 lines of code and two directories away from
<aeth>
where it was introduced
<aeth>
I don't particularly care about engineering things to be like Haskell just because Haskell is cool
dnhester26 has joined #commonlisp
<bike>
"it's OK if the type inference doesn't see this" this conversation is about requiring type inference to see things.
<beach>
Or at least it was.
<aeth>
Personally, the only time I've experienced "oh, wow, type inference would be handy" is when using specialization-store, which in the state it currently exists in isn't as useful as it could be because it requires a bunch of otherwise unncessary DECLAREs to remove some slow generics and inline or inline-call the proper version. https://github.com/markcox80/specialization-store/
<ixelp>
GitHub - markcox80/specialization-store: A different type of generic function for common lisp.
<aeth>
which, perhaps coincidentally or perhaps not, is only really relevant to numbers or arrays-of-numbers (since it's a type-based generic system and otherwise DEFMETHOD is better)
glaucon has quit [Read error: Connection reset by peer]
zxcvz has joined #commonlisp
glaucon has joined #commonlisp
<aeth>
(the length of a string is rarely a relevant part about the string, but the dimensions are often a relevant part about an array of numbers... so it really is just arrays-of-numbers in particular)
<jcowan>
I think that's because arrays can be used in either of two ways. For example, a VECTOR of length 1048576 is commonplace, but a vector (in the mathematical sense) in a 1048576-dimensional space is a pretty specialized thing.
<jcowan>
P*scal insisted that the length of a string is part of its type, which turned out to be very inconvenient. That's expressible in CL, but not that useful.
glaucon has quit [Ping timeout: 255 seconds]
bonmlp has quit [Ping timeout: 255 seconds]
<jcowan>
Nonsimple vectors are an attempt to split the difference. In Sch*me, strings are not vectors, but it's still kinda useless to have mutable fixed-length strings (especially in a Unicode world).
rogersm has joined #commonlisp
dnhester26 has quit [Remote host closed the connection]
dnhester26 has joined #commonlisp
t400 has quit [Quit: Konversation terminated!]
rogersm has quit [Ping timeout: 264 seconds]
waleee has joined #commonlisp
<aeth>
A VECTOR of length 1048576 seems unusual unless adjustable. There's a decent chance that there has never been a SIMPLE-VECTOR of length 1048576
<aeth>
wait, 2^20, maybe it has existed before.
<aeth>
20 is still an odd size
glaucon has joined #commonlisp
rendar has quit [Ping timeout: 256 seconds]
HerlockSholmes has quit [Ping timeout: 256 seconds]
kevingal has joined #commonlisp
kevingal_ has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
rendar has joined #commonlisp
rendar has quit [Changing host]
rendar has joined #commonlisp
yitzi has quit [Remote host closed the connection]
kevingal_ has quit [Remote host closed the connection]
kevingal has quit [Remote host closed the connection]
kevingal has joined #commonlisp
bendersteed has quit [Quit: bendersteed]
King_julian has quit [Ping timeout: 255 seconds]
jack_rabbit has quit [Ping timeout: 276 seconds]
dnhester26 has quit [Remote host closed the connection]
dnhester26 has joined #commonlisp
dnhester26 has quit [Remote host closed the connection]
rogersm has joined #commonlisp
rogersm has quit [Ping timeout: 252 seconds]
danse-nr3 has quit [Read error: Connection reset by peer]
danse-nr3 has joined #commonlisp
szkl has joined #commonlisp
igemnace has quit [Remote host closed the connection]
dino_tutter has quit [Ping timeout: 255 seconds]
dnhester26 has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
varjag has quit [Quit: ERC (IRC client for Emacs 27.1)]
amb007 has joined #commonlisp
danse-nr3 has quit [Ping timeout: 252 seconds]
waleee has quit [Ping timeout: 255 seconds]
cmack has quit [Ping timeout: 276 seconds]
Guest63 has joined #commonlisp
green_ has quit [Ping timeout: 255 seconds]
yitzi has joined #commonlisp
<jcowan>
aeth: It was a badly chosen number, but my point stands.
rogersm has joined #commonlisp
rogersm has quit [Ping timeout: 256 seconds]
Equill has quit [Remote host closed the connection]
HerlockSholmes has joined #commonlisp
Guest63 has quit [Quit: Client closed]
reb has quit [Ping timeout: 264 seconds]
green_ has joined #commonlisp
green__ has joined #commonlisp
green_ has quit [Ping timeout: 256 seconds]
green__ has quit [Remote host closed the connection]
green__ has joined #commonlisp
danse-nr3 has joined #commonlisp
mgl has quit [Ping timeout: 252 seconds]
<childlikempress>
jcowan: amd64 has been around for 1/3 of lisp's existence
rogersm has joined #commonlisp
rogersm has quit [Remote host closed the connection]
dino_tutter has joined #commonlisp
rogersm has joined #commonlisp
rogersm has quit [Ping timeout: 256 seconds]
tibfulv has quit [Remote host closed the connection]
dnhester26 has quit [Remote host closed the connection]
dnhester26 has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
rogersm has joined #commonlisp
glaucon has quit [Read error: Connection reset by peer]
rogersm has quit [Ping timeout: 252 seconds]
glaucon has joined #commonlisp
reb has joined #commonlisp
rgherdt has quit [Ping timeout: 256 seconds]
certainty has quit [Ping timeout: 276 seconds]
dcb has joined #commonlisp
mgl has joined #commonlisp
green__ has quit [Ping timeout: 255 seconds]
reb has quit [Ping timeout: 276 seconds]
rogersm has joined #commonlisp
certainty has joined #commonlisp
rgherdt has joined #commonlisp
danse-nr3 has quit [Ping timeout: 256 seconds]
<Lycurgus>
not quite;lisp is 74 the first AMD released 2003
<Lycurgus>
*AMD64
certainty has quit [Ping timeout: 256 seconds]
danza has joined #commonlisp
<Lycurgus>
lisp is 67
<childlikempress>
,(- 2023 74)? How do you figure that?
<ixelp>
(- 2023 74) => 1949
<Lycurgus>
enwiki says mccarthy's first lisp was in '58
<Lycurgus>
and that the first released AMD64, Opteron was in 2003
<childlikempress>
he published in 1960. I guarantee you amd was working on its processors for years before they released
<childlikempress>
amd64 is about 20 years old. lisp about 60
<Lycurgus>
the about hedge gives it truthiness
<childlikempress>
what in the world do you expect
<Lycurgus>
vulcan precision
rogersm has quit [Ping timeout: 255 seconds]
<childlikempress>
if we postulate the existance of a global time, then there is but a single instant when 1/3 is exactly correct; and if it's correct when I send the message, it certainly won't be by the time you receive it
<Lycurgus>
amd64 is older than sbcl (but not cmucl)
waleee has joined #commonlisp
scymtym has quit [Remote host closed the connection]
certainty has joined #commonlisp
rogersm has joined #commonlisp
certainty has quit [Ping timeout: 255 seconds]
rogersm has quit [Ping timeout: 260 seconds]
random-nick has quit [Ping timeout: 252 seconds]
dnhester26 has quit [Remote host closed the connection]
dnhester26 has joined #commonlisp
cage has joined #commonlisp
rogersm has joined #commonlisp
danza has quit [Read error: Connection reset by peer]
rogersm has quit [Remote host closed the connection]
random-nick has joined #commonlisp
robin has quit [Ping timeout: 260 seconds]
rogersm has joined #commonlisp
rogersm has quit [Ping timeout: 256 seconds]
zxcvz has quit [Quit: zxcvz]
green__ has joined #commonlisp
certainty has joined #commonlisp
certainty has quit [Ping timeout: 256 seconds]
_cymew_ has quit [Ping timeout: 264 seconds]
robin has joined #commonlisp
rogersm has joined #commonlisp
thollief has quit [Quit: Leaving]
HerlockSholmes has quit [Remote host closed the connection]
<younder>
Intel is older than Common Lisp but younger than Lisp. Though Robert Noice (the founder of intel )did invent the integrated circuit in 1956. 2 years before Lisp. I'll ignorke rikkby and Moore etc
<younder>
Kilby
rogersm has quit [Ping timeout: 256 seconds]
mgl has quit [Ping timeout: 252 seconds]
rgherdt_ has joined #commonlisp
rgherdt has quit [Ping timeout: 256 seconds]
danza has joined #commonlisp
Pixel_Outlaw has joined #commonlisp
pve has quit [Quit: leaving]
tibfulv has joined #commonlisp
danza has quit [Ping timeout: 256 seconds]
glaucon has quit [Quit: WeeChat 3.5]
habamax has joined #commonlisp
yitzi has quit [Remote host closed the connection]
habamax has quit [Remote host closed the connection]
habamax has joined #commonlisp
rgherdt has joined #commonlisp
rgherdt_ has quit [Read error: Connection reset by peer]
certainty has joined #commonlisp
cage has quit [Quit: rcirc on GNU Emacs 29.1]
certainty has quit [Ping timeout: 255 seconds]
_whitelogger_ has joined #commonlisp
_whitelogger has quit [Remote host closed the connection]
rogersm has quit [Ping timeout: 264 seconds]
alfplayer has joined #commonlisp
attila_lendvai has quit [Ping timeout: 264 seconds]
kevingal has quit [Read error: Connection reset by peer]
dajole has joined #commonlisp
mgl has joined #commonlisp
certainty has joined #commonlisp
ym has quit [Ping timeout: 255 seconds]
zetef has joined #commonlisp
certainty has quit [Ping timeout: 260 seconds]
mgl has quit [Ping timeout: 260 seconds]
mgl has joined #commonlisp
scymtym has joined #commonlisp
rakka has quit [Remote host closed the connection]
rakka has joined #commonlisp
ronald_ has quit [Ping timeout: 264 seconds]
<cdegroot>
(1958 is the correct answer, by the way)
anticrisis has joined #commonlisp
<aeth>
if Intel is younger than Lisp then they have no excuse not to have made a Lisp machine instead of whatever they wound up doing instead
<aeth>
though comparing it to x86-64/AMD64 isn't really right because the reason it won is because of its compatibility with the 32-bit x86, which is much older (1978/1985/2003 16/32/64 bits; and was still used throughout the '00s; looks like the 32-bit x86 should've been written with CLtL in mind, though, clearly)
<aeth>
for the most part x86-64 only matters vs x86 in that it increases the size of a bunch of constants (which are usually dependent on most-positive-fixnum as their largest possible value) and makes single-floats unboxed
<cdegroot>
Intel, IIRC, started out making microcontrollers for calculators and it took quite some armtwisting before anyone got convinced that microprocessors were a good idea. By the time that Intel's product line was able to run Lisp at anything resembling a decent speed, the AI winter had already set in.
<aeth>
I suspect that there are two things that are going to last forever in some form, though: Windows EXEs and x86(-64). And the combination, of course. Even if it's just RISC V (or RISC VIII or NeoSymbolics or whatever) running wine on top of an emulated x86(-64)
<cdegroot>
I _think_ that ".EXE" is not a format per se; it changed over the years quite a lot and reasonably often.
<aeth>
.EXE in this case being whatever wine runs, since it will probably outlast Windows itself by thousands and thousands of years
<bike>
the format is called portable executable (PE)
<cdegroot>
aeth: probably.
<bike>
wikipedia says it's not fully backward or forward compatible but does still run as a valid dos program
<aeth>
As far as Intel and the Lisp winter, yes, the timelines simply didn't line up. If you could afford it, 36-bit minicomputers were much better environments than 16-bit or even 32-bit microcomputers/PCs until Intel got so much of an advantage that the extra boxing from having less space for tag bits (e.g. boxing every single-float) was still faster than having enough bits. Idk when that was. Maybe '93? '95?
<cdegroot>
DOS also used EXE. .COM were limited to one segment (64k), IIRC. It's been a while, though :).
<cdegroot>
(COM was pretty much lifted from CP/M, EXE I _think_ an MS addition to have multiple segments defined and that sort of fun. But recollection is vague, it's been a whole bunch of decades since I was deep into MS-DOS)
certainty has joined #commonlisp
certainty has quit [Ping timeout: 260 seconds]
dino_tutter has quit [Ping timeout: 256 seconds]
<aeth>
I don't really think that the 32 bits of x86 are enough bits for CL, though... at least when you do tag bits.
<aeth>
You can definitely, in a lot of different kinds of common usage, reach the numbers 2147483647 or 4294967295 and the tag bits ask you to remove some of that if you want to stay a fixnum. While you only really get to 18446744073709551615 all of the time if you're using integers as 64 1 and 0 bits instead of as a number ime. But, then again, I think Python's most-positive-fixnum for the longest time was
<aeth>
something extremely low like 4 (is it still?) so clearly it wasn't a factor in CL's relative unpopularity.
<cdegroot>
Smalltalk uses tagging on 32 bits, it just morphs into bignums when it runs out of tag bits. So it is possible.
<cdegroot>
(I guess that as Lisp started on a 36 bit system in 1958, that was sort of the hardware expectations from then on?)
<cdegroot>
(whereas Smalltalk started on a 16 bit machine so packing stuff in there was the challenge that got tackled right away)
<gilberth>
Careful: That 36-bit system had 15-bit pointers.
<cdegroot>
I know. I have the manual on my desk :) Fun read.
<cdegroot>
(the shit you find on eBay lol. Had to buy it when I was diving into LISP 1)
<cdegroot>
Was very helpful by the way. The LISP 1.5 manual has some assembly listings and I couldn't make heads nor tails of it. Helpful, of course, if understanding LISP 1.5 is a goal (I'm writing a book on Lisp history)
<aeth>
cdegroot: I think the relevant issue is that various constants are at most most-positive-fixnum, often lower
<gilberth>
Yes, and the later 36-bit systems they used had 18-bit pointers. This being a bit tight gave rise to the CONS and CADR machines. Both of which weren't that much about speed, but rather about space. In more compact code and data (by use of CDR-coding) and in the available size of the address space.
<aeth>
and most-positive-fixnum in turn puts the limit of such constants at most at (1- (expt 2 (- bit-size 2))) if fixnums use one bit tags (which 64-bit SBCL does, but nobody else does, even 32-bit SBCL!)
<gilberth>
The CADR however had a word size of 32-bit, not 36.
<aeth>
(it's -2 instead of -1 because fixnum is always signed)
<aeth>
gilberth: weird, but I guess they had a different way to hardware tag?
<aeth>
it's not like you never run into two billion one hundred forty-seven million four hundred eighty-three thousand six hundred forty-seven
<aeth>
though maybe bignums were OK in all such cases on the CADR
<cdegroot>
LISP 1 didn't even have numbers. Problem solved ;-)
<gilberth>
Lisp on the 704 didn't really use tagging. I have no clue how they did that on the PDP-10. The CADR has proper tag bits.
danlitt has joined #commonlisp
<aeth>
having smaller pointer size also avoids the issue, of course, because then your pointers aren't ever going to use bignums... and actually x86-64 is afaik one such platform (used to be 48-bit memory, now slowly becoming 57-bit memory, apparently)
<aeth>
s/memory/memory address space/
<gilberth>
With LISP atoms were conses whose CAR happens to be the address -1. The CDR then would be the plist.
<aeth>
also you have no issues with e.g. big arrays (because memory is tiny)
<aeth>
in late x86 you're constantly running into 4 GB
<childlikempress>
gilberth: where was the name?
<cdegroot>
relatively tiny. 48k words for the 704 I think? I don't have my notes handy :)
<gilberth>
And only in that plist single tag bit would indicate whether this is a symbol or an integer. There were no fixnums.
<gilberth>
15-bit gives you 32K words max.
<gilberth>
Each being 36-bit and thus are a whole CONS cell.
<gilberth>
That is upto 32K cons cells.
<aeth>
What was the first Lisp that was an acceptable FORTRAN? Common Lisp?
<gilberth>
childlikempress: The name lives on the plist as a property. Just like the value or function.
<aeth>
this oversight to divide numerics and symbolics sadly gave the world two separate programming languages when there could've just been one
<childlikempress>
gilberth: how is it represented?
<gilberth>
childlikempress: The name itself then is a linked list. The CARs would be interpreted as packed characters.
<childlikempress>
packed how?
<gilberth>
IIRC three 6-bit characters for the 18-bits of the CAR iirc.
<childlikempress>
so the gc needs special treatment to avoid treating the cars as pointers and tracing them?
<gilberth>
Yes.
<childlikempress>
eef
<gilberth>
It would need to treat bignums special as well. Which also is a likewise linked list.
<childlikempress>
eef
<gilberth>
I don't remember the exact details. Perhaps the CDR was tagged or something like that.
<childlikempress>
wait so was there a user-exposed integer-plist too?
<childlikempress>
and then could I have two integers which were = but had different plists?
<gilberth>
childlikempress: Depends on what you call "user-exposed". You could invoke CAR and CDR on anything. No type-checking took place.
<aeth>
way more LISt Processing back then
<gilberth>
Whether an integer could have a plist proper is a detail I would need to read up. But I would believe so.
<aeth>
must've been so slow
<gilberth>
Anyhow, for quite some time CDR was the same as SYMBOL-PLIST.
<aeth>
weird how software and hardware were both so much slower back then, though maybe fitting in memory was much more of a concern
<gilberth>
I was puzzled by that. See, you want to do a (symbol-value 'foo). We find that value at some fixed offset in the symbol. Fine. They needed to chase the plist for the property APVAL. But is the latter really slower?
<gilberth>
I figured it is not. Not when you also would want to check for the thing being a symbol. That APVAL property perhaps is the first property in the plist. So you fetch APVAL, fetch another CDR, and have the value. Some mild type-checking came for free. That isn't terrible expensive.
<gilberth>
Especially so when unlike today memory access isn't more expensive than any other instruction.
zetef has quit [Ping timeout: 255 seconds]
rgherdt has left #commonlisp [Leaving]
jmdaemon has joined #commonlisp
<gilberth>
Anyhow, you find all those implementation details with the LISP 1.5 manual.