remexre has quit [Remote host closed the connection]
Fare has joined #commonlisp
remexre has joined #commonlisp
ldb has quit [Quit: ERC 5.4 (IRC client for GNU Emacs 28.1)]
Fare has quit [Ping timeout: 260 seconds]
ec_ has quit [Remote host closed the connection]
Fare has joined #commonlisp
waleee has quit [Ping timeout: 252 seconds]
Fare has quit [Ping timeout: 260 seconds]
bilegeek has joined #commonlisp
NotThatRPG_ has joined #commonlisp
NotThatRPG has quit [Ping timeout: 265 seconds]
NotThatRPG_ has quit [Ping timeout: 264 seconds]
Oladon has quit [Read error: Connection reset by peer]
nij- has joined #commonlisp
Oladon has joined #commonlisp
varjag has joined #commonlisp
varjag has quit [Ping timeout: 260 seconds]
Lord_of_Life has quit [Ping timeout: 260 seconds]
ec_ has joined #commonlisp
Lord_of_Life has joined #commonlisp
varjag has joined #commonlisp
varjag has quit [Ping timeout: 248 seconds]
booaa has joined #commonlisp
<nij->
Can I enable a readtable for a specific package?
<nij->
I don't want to "pollute" other part of my system.
Fare has joined #commonlisp
<beach>
What does it mean to "enable [it] for a specific package"?
<beach>
You can bind *READTABLE* around a function that reads a file.
bilegeek has quit [Quit: Leaving]
<nij->
For example, after I `(ql:quickload :rutils) (in-package :rtl-user) (named-readtables:in-readtable rutils-readtable)`,
<nij->
even with `(in-package :cl-user)`, the reader is changed.
<beach>
I don't know how named readtables work. I just know the standard mechanism. Sorry.
Fare has quit [Ping timeout: 256 seconds]
ec_ has quit [Remote host closed the connection]
ec_ has joined #commonlisp
jeosol has quit [Ping timeout: 260 seconds]
<beach>
Oh, I think I see.
<beach>
It is probably not supposed to be used interactively.
<beach>
Functions like COMPILE-FILE and LOAD bind *READTABLE*, so during compilation or loading, even if you alter the readtable, its old value is restored after compilation or loading.
<beach>
And, no, there is no mechanism to change the readtable according to the current package. There are two different variables: *PACKAGE* and *READTABLE*.
Oladon has quit [Quit: Leaving.]
<nij->
I see. Yeah after playing it more, I almost came to the conclusion that it's not meant to be used interactively.
<nij->
So if I only want a specific readtable to be enabled for a file,
<nij->
I just add (setq *readtable* my-readtable) in the beginning of the file, and (setq *readtable* *old-readtable*) in the end of the file?
<nij->
In any case, I don't want other files to be affected.
<beach>
You don't have to set it back. Like I said, COMPILE-FILE and LOAD do (LET ((*READTABLE* *READTABLE*)) ...) around the reading of your file.
<beach>
So when the operation is complete, the value is automatically restored.
<beach>
Just like *PACKAGE*.
igemnace has joined #commonlisp
<nij->
beach, sorry, do you mean (let ((*readtable* *my-readtable*)) <insert the codes in the file>)?
<beach>
No.
<nij->
Hmm..
<beach>
Check this example: (defparameter *x* 10) then (let ((*x* *x*)) (setf *x* 20)) then *x*
<beach>
That is what COMPILE-FILE and LOAD do, so you can safely assign to *READTABLE* in the file.
<beach>
It will be restored automatically.
<nij->
Yeah, there's a new *x* in the let form.
<beach>
Yes, so if you assign to it in the LET body, it's no problem.
<nij->
so do you mean (let ((*readtable* *readtable*)) (mutate *readtable*) <insert the codes in the file>)?
<beach>
I mean, COMPILE-FILE and LOAD do the LET for you.
<beach>
So when your file is read, *READTABLE* is already bound like that.
<nij->
I use asdf without touching compile-file and load. But lemme do a quick experiment. Thanks :D
<beach>
Therefore, it is safe to assign to *READTABLE* in the file, just like you do (IN-PACKAGE...) in the beginning of the file.
<beach>
ASDF calls COMPILE-FILE and LOAD.
<nij->
Indeed! That's awesome!
<nij->
Thank you, beach.
<beach>
Pleasure.
azimut has quit [Ping timeout: 255 seconds]
nij- has left #commonlisp [Using Circe, the loveliest of all IRC clients]
rgherdt has joined #commonlisp
jmd_ has quit [Ping timeout: 265 seconds]
rangahy has joined #commonlisp
pranavats has left #commonlisp [Error from remote client]
pfd has joined #commonlisp
varjag has joined #commonlisp
Guest965 is now known as Sauvin
varjag has quit [Ping timeout: 256 seconds]
varjag has joined #commonlisp
thuna` has joined #commonlisp
varjag has quit [Ping timeout: 265 seconds]
Cymew has joined #commonlisp
varjag has joined #commonlisp
varjagg has joined #commonlisp
pve has joined #commonlisp
varjag has quit [Ping timeout: 260 seconds]
varjag has joined #commonlisp
frgo has quit [Ping timeout: 260 seconds]
szkl has quit [Quit: Connection closed for inactivity]
<Josh_2>
For once it actually is morning when I say that
rangahy has quit [Ping timeout: 265 seconds]
varjag has joined #commonlisp
varjag has quit [Ping timeout: 265 seconds]
varjag has joined #commonlisp
varjag has quit [Ping timeout: 252 seconds]
rangahy has joined #commonlisp
varjag has joined #commonlisp
varjag has quit [Ping timeout: 248 seconds]
varjag has joined #commonlisp
varjag has quit [Ping timeout: 268 seconds]
frodef has joined #commonlisp
varjagg is now known as varjag
rogersm has quit [Quit: Leaving...]
<Shinmera>
It's always morning when you say that.
<Josh_2>
Yes because when I sign on I say good morning :P
<Josh_2>
regardless of the time of day
<hayley>
minion: Tell Josh_2 about universal greeting time
<minion>
Josh_2: please look at universal greeting time: It is always morning when a person enters a channel, and late night when they leave. You may want to read http://www.total-knowledge.com/~ilya/mips/ugt.html for further information
<Josh_2>
Exactly
random-nick has joined #commonlisp
ec has joined #commonlisp
ec_ has quit [Ping timeout: 255 seconds]
scymtym has quit [Ping timeout: 265 seconds]
Brucio-61 has quit [Ping timeout: 260 seconds]
pranavats has joined #commonlisp
Equill has joined #commonlisp
Equill has joined #commonlisp
pranavats has left #commonlisp [Error from remote client]
_cymew_ has joined #commonlisp
Brucio-61 has joined #commonlisp
scymtym has joined #commonlisp
Krystof has quit [Ping timeout: 268 seconds]
rainthree has joined #commonlisp
pillton has quit [Remote host closed the connection]
pranavats has joined #commonlisp
random-nick has quit [Ping timeout: 260 seconds]
rangahy has quit [Ping timeout: 246 seconds]
pranavats has left #commonlisp [Error from remote client]
rangahy has joined #commonlisp
<Josh_2>
Programming is like a cake
frgo has joined #commonlisp
<hayley>
I overcooked my program somehow?
frgo has quit [Remote host closed the connection]
frgo has joined #commonlisp
thuna` has quit [Remote host closed the connection]
<Josh_2>
you can auto identify in ERC using auth-source
<lisp123>
yeah I know. I
<lisp123>
I'm on hexchat and haven't got around to figuring out the settings
<Josh_2>
Well then, should use ERC :P
<lisp123>
indeed
lisp123 has quit [Ping timeout: 256 seconds]
thuna` has joined #commonlisp
<Equill>
Good point with the cake analogy: maybe what this thing needs is some brandy. I mean, what's the worst that can happen?
<Josh_2>
The more brandy the better
<Josh_2>
Until the next day that is
<hayley>
"By now, my remaining readers are wondering what I’ve been smoking. Well, I don’t smoke, but red wine is good for you."
<Equill>
Oh man, I've had that moment. Reading through some old code and thinking "was I *drunk* when I wrote thi... oh crap, now I remember. Yes, I was."
<jackdaniel>
to the lispcafe off you go, thsi doesn't have much to do with common lisp
nij- has joined #commonlisp
<nij->
I heard the following: C is a lingua franca, so being able to FFI with C makes CL able to communicate with almost all langs.
<nij->
However, as far as I understand, CL's CFFI works by loading C as shared libraries.
Guest2929 has joined #commonlisp
<nij->
That makes C an "inferior", in the sense that C has not much freedom to do whatever it wants, including talk to the third language X.
<nij->
In the case where the thid language X is embedded in C (e.g. X = Python), it is easier to let CL and X communicate.
<jackdaniel>
usually a ffi has two aspects: calling foreign functions and creating callbacks that may be called by foreign functions
<nij->
But other languages do not necessarily embed in C. I thus wonder how we can use CFFI to do FFI with other langs.
<jackdaniel>
when you want for some c function to call your cl function, you define a ffi callback and pass it to the foreign world
<jackdaniel>
C ABI is omnipresent, that's why having FFI allows you to interact with other programs exposing C ABI (be it a program written in C or in Python) - ABI is mostly about how to call things and retrieve values
<nij->
But for C to work in CL, it basically got embedded as a process in CL. In this case, even if lang X has a nice CFFI, it cannot embed the same C process in itself.
<nij->
That makes the communication model asymmetric.
<jackdaniel>
you may compile CL to a shared library (be it ecl or sbcl recently) and export an interface following the C ABI convention
<jackdaniel>
then some program (i.e written in FOOLANG) may load that shared library and call functions exported using that interface as if these were C functions
<jackdaniel>
or pass callbacks to them, so the shared library may call us back
<nij->
Oh I see. So first have CL load a C shared library. And compile this into another shared library to be loaded by X?
<jackdaniel>
I don't know what you want to achieve, but it may be that you have compiled CL library to a shared object, you dlopen it from FOOLANG program and call the function cl_load_ffi, and then that CL library dlopen's libraries it uses itself
<jackdaniel>
is that the thing you are asking about?
<nij->
Oh, this works too. Yes.
<nij->
With this method, to let CL and FOOLANG interopt, one needs to write many C wrappers, and the CL objects and X objects should be translated via the semantics of C.
azimut has joined #commonlisp
MajorBiscuit has quit [Ping timeout: 260 seconds]
<beach>
nij-: What prompted your question in the first place?
<nij->
I'm trying to understand all possible ways that let multiple langs communicate.
<beach>
I see.
<nij->
Seems that we have FFI, RPC, and same-target compiler.
<nij->
And hopefully to get a better sense in the advantage of each method.
<nij->
For example, clasp interopts with C++ by both being compiled to LLVM.
<nij->
But then I wonder if interopting with C++ is the final purpose, why not just use FFI, and why bother creating a whole new implementation in the first place?
<Josh_2>
isn't FFI with C++ a bit of a PITA?
<beach>
There is a lot more to it than just both using LLVM.
<nij->
Josh_2 yeah, but I mean CL--C--C++, as mentioned above.
<nij->
beach, I would love to know
<beach>
nij-: In the case of Clasp, drmeister had a large number of existing C++ libraries he wanted to use from Common Lisp.
<beach>
I think either drmeister or Bike could tell you more.
<jackdaniel>
nij-: kind folks on #clasp already explained to you why CL--C--C++ is suboptimal
<jackdaniel>
beach: that conversation already took place, only the listener did not listen
<beach>
Oh, OK. Thanks for letting me know.
<nij->
jackdaniel - During the last time I was there, at the end we got an inconclusive answer, no?
<jackdaniel>
no.
<nij->
---
<nij->
me like a C++ wrapper. In both approach, some wrappers must be
<nij->
written. And whats good about clasp is that the wrapper you need
<nij->
nij- > If I may continue, here are some more. -- seqan.cc looks for
<nij->
to write is much smaller and more easily to maintain than C
<nij->
wrappers?
<nij->
drmeister> nij-: I believe so.
<nij->
---
<nij->
(Sorry multiple lines...)
<nij->
jackdaniel I may lack experience or high IQ to understand immediately, which may resulted in that you think I wasn't listening, but by all means that's not the case.
<nij->
Anyway, if asking very stupid question is frowned upon in any channel, please feel free to let me know. I will confrain myself. Sorry about that.
<beach>
I suspect the main difficulty with making different languages collaborate is not to have them communicate, but to resolve semantic differences.
<jackdaniel>
person asking the same (suggestive) question a few times despite being explained that this is not the case is a red flag to me ,)
<nij->
I think in that conversation one thing is clear to me: There are many ways to achieve the goal, and clasp chooses one based on drmeister's experience. I have failed to understand a concrete reason, jackdaniel
<jackdaniel>
one from many reasons mentioned during the conversation back then is defining common lisp classes that are seen by c++ as c++ classes and vice versa
<jackdaniel>
that can't be done with a wrapper or a bridge
<nij->
"seen by"?
<nij->
It can't be done with however many wrappers?
<hayley>
I agree, "CL objects and X objects should be translated via the semantics of C" takes much effort, and I do not like the semantics of C very much either.
<jackdaniel>
it can't, that's one of these semantic difference beach mentioned above - you can't represent a common lisp class with C semantics
<jackdaniel>
(unless the common lisp system is written in c itself of course)
<hayley>
What do C semantics mean here?
<nij->
And what does "seen by" mean here?
<jackdaniel>
I'm not interested in this discussion enough to spend time on it, sorry
<nij->
At the end everything is 0 and 1. I can't imagine why an approach will never work to create the abstraction that makes C++ classes be "seen by" CL classes and vice versa.
<hayley>
For (defstruct foo bar) I wouldn't expect struct foo *f; ... f->bar; unless we are using SBCL bootstrapping magic.
<nij->
jackdaniel one thing I'd like you to acknowledge is that the conversation may be clear to you but may not be clear to someone that's dumber than you
<hayley>
Because, actually, when it comes to C++ and CL, both systems deal with objects that are more complicated than 0s and 1s.
<nij->
so if I may ask some patience from you that'd be awesome. Thanks.
<beach>
nij-: Here is an example: The Common Lisp implementation may have a copying garbage collector. If Common Lisp moves an object, how is the other language supposed to be informed about that?
<hayley>
Any correspondence is an implementation detail; which is why I don't like the "C as lingua franca" argument.
<jackdaniel>
nij-: I'm not insisting on that you should understand something or not, I'm insisting that asking the same question that was answered as if the answer has never been given is not right
<nij->
beach By hacking the garbage collector and making it inform whatever it does?
<nij->
jackdaniel to you it's answered, to me it hasn't been.
<nij->
completely, at least
<beach>
nij-: Informing the other language would require scanning all objects allocated by that language and updating pointer fields. That in turn requires knowing how the compiler does layout of objects in that other language.
<hayley>
In reality perhaps the ABI used by your system is a common language, but hardly an expressive one, and indeed it does not cover other things like memory management.
<hayley>
How do you do that in a modular way, without having to hack every implementation for every other?
<beach>
nij-: It also requires the Common Lisp implementation to know how the other compiler allocates registers and stack slots.
<_death>
beach: there's no need to inform, if there's an indirection
<beach>
Here we go again.
<_death>
beach: I guess you gave it as an example of something that needs to be accounted for, and may not be interested in a particular solution.. but the question was loaded
<hayley>
Do we really want to spend an indirection?
<nij->
beach I see. So with FFI approach it's very complicated, nearly impossible?
<beach>
nij-: I need to be quiet. I am sure _death can tell you more.
<nij->
Thanks for sharing.
<nij->
_death If you may, could you tell me more about 'indirection'?
<nij->
But I may have to leave soon.. Sorry for bringing up a slightly negative conversation.
<_death>
if I refer to "where nij lives" by the name "1", that reference can still be valid if nij moves to a different address
<beach>
nij-: I think it is an important one. But I didn't know that it had partially taken place in #clasp already.
<_death>
some table can be maintained that associates the name "1" with the current address
<beach>
_death: Do you seriously think that "explanation" will make nij- understand the issue?
<nij->
beach it's fine.. though I may come back again with the "same question" in the future
nij- has left #commonlisp [Using Circe, the loveliest of all IRC clients]
sbenitezb has joined #commonlisp
frgo has quit []
jmpeax has quit [Quit: leaving]
pranavats has joined #commonlisp
taichi has joined #commonlisp
chrcav has quit [Ping timeout: 268 seconds]
chrcav has joined #commonlisp
mariari has quit [Ping timeout: 264 seconds]
nij- has joined #commonlisp
<beach>
nij-: I think #clschool might be a better forum for this kind of discussion.
<nij->
beach I think so too. Will move there.
<dirtcastle>
I'm planning to read On lisp right after ansi common lisp. Will I be fine? I heard on lisp focuses so much on functional programming and macros. I'm interested. So I wanna read only these 2 books.
pranavats has left #commonlisp [Error from remote client]
taichi is now known as mariari
<beach>
dirtcastle: That should be fine. But you should know that macros are not used very much in Common Lisp programming. Of course when you need them, it is good to know how to write them. Also, macro functions is one domain where functional programming is appropriate.
<beach>
dirtcastle: The other thing is that Paul Graham uses a style that is not what most Common Lisp programmers use.
<Josh_2>
Most macros are basic syntax abstraction ie with-* macros
<Josh_2>
These are pretty trivial to write
MajorBiscuit has joined #commonlisp
Bung has joined #commonlisp
<Josh_2>
But more advanced macro writing macros come along sometimes but they are pretty rare in my experience
<Josh_2>
pretty cool when you find the use for one though
<mfiano>
Macros are strictly for syntactic abstractions and deferring evaluation in various ways.
<Josh_2>
The macros in a book like Let Over Lambda are pretty insane, can't say I've ever used one in practice though
<Josh_2>
Also the author seems to be a Perl user, so perhaps he just likes making his life difficulty :joy:
dider has joined #commonlisp
<mfiano>
The only CL book author I know that doesn't use a crazy language now is phow, who is still with us, I hope.
<mfiano>
phoe*
<Josh_2>
Yep
<Josh_2>
There is cl-cookbook author
<Josh_2>
Not sure if that is published though
<Inline>
it is
<Inline>
i got both books via apress
<Inline>
the one is about the exception system the other is the cookbook
<mfiano>
The cl cookbook is not common lisp recipes
<Inline>
oh wait
<Inline>
no i just have the recipes
<mfiano>
Yeah, Edi doesn't use CL anymore.
<nij->
Some talks on getting rid of monads popped out to me recently (on StrangeLoop?). Seems that some of them want to get rid of monads..
<Inline>
switched to python ?
varjag has quit [Quit: ERC (IRC client for Emacs 27.1)]
<nij->
one speaker removed monads by generating code that does what a monad should do
<mfiano>
I haven't heard from them since I emailed them a few years ago. I don't know if they are particularly active in computer programming these days.
<nij->
I wonder if it could be done better in a lisp language.
morganw has joined #commonlisp
<mfiano>
His profile says: "Professor (math and CS), formerly freelance coder (mainly Common Lisp)". so I guess that answers the active part.
<jackdaniel>
I think that formerly applies to "freelance coder", not "Common Lisp"; I think that I saw recently a tangram clim implementation of his (in lw clim)
pfd has quit [Ping timeout: 260 seconds]
<mfiano>
Ah ok, nice.
<Inline>
edi has a youtube channel with several cs and math vids
<Inline>
i got hist differential curves book too
<nij->
Who is edi?
<Inline>
edi weitz
<jackdaniel>
wow, so many people closely acquainted with prof Weitz :)
<mfiano>
Edmund Weitz. He only used the name "Edi" for CL related stuff. I don't know why.
<Inline>
right
Bike is now known as Bike
<dirtcastle>
beach: maybe he uses that style in the book for didactic purposes?
<dirtcastle>
I read through all the messages. thanks peeps. atm I'm just curious abt macros and functional programming and just generally trying to understand why lisp way of doing things is better. I plan to learn object oriented programming too and I heard it is taught in On lisp book. so I think I'll learn all important paradigms by reading ansi common lisp and on lisp I hope. correct me if I have wrong assumptions.
<jackdaniel>
dirtcastle: it is a good choice, especially if you are interested in functional programming and macros
<beach>
On Lisp does not teach object-oriented programming as fas as I can remember.
<mfiano>
I wouldn't exactly choose those as my first Lisp books, but I hope you enjoy them.
<dirtcastle>
what would you choose instead?
nij- has quit [Remote host closed the connection]
<mfiano>
minion: tell dirtcastle about pcl
<minion>
dirtcastle: please see pcl: pcl-book: "Practical Common Lisp", an introduction to Common Lisp by Peter Seibel, available at http://www.gigamonkeys.com/book/ and in dead-tree form from Apress (as of 11 April 2005).
nij- has joined #commonlisp
<dirtcastle>
I heard pcl is for ppl who already know some programming language and want to learn common lisp quickly.
<beach>
Oh, Common Lisp is your first language?
<mfiano>
I would say otherwise. I started without any real programming experience.
<dirtcastle>
I'm pretty much a noob to programming. I can do loops and condition statements. but yet to have a clear understanding of functions, scope etc
<mfiano>
I read half of PCL before I was writing libraries, and later a few others.
<dirtcastle>
wow
<mfiano>
So I don't buy that argument. If I can do it, anyone can. No programming experience needed. Just some practice, and lots of questions.
<dirtcastle>
what did you do for practice?
<mfiano>
The book has "practicals" where you build and tinker with real applications.
<nij->
I think PCL is pretty awesome as a noob too.
<dirtcastle>
ok. When I first wanted to learn common lisp I picked pcl and went through cd database part. My problem was I was learning so much very quickly. It felt like a info dump. like they are using so many new words without going in detail and claim they will go in detail later. I was worried if they keep this up I'll be just learning abt new stuff over and over without understanding anything properly and end up understanding nothing.
<mfiano>
Infact, I would argue that it would be easier learning Common Lisp if you exclude some mishaps of history with "programming experience"
<dirtcastle>
maybe my view is wrong.
<beach>
dirtcastle: Feel free to ask for clarifications in #clschool.
<morganw>
As a beginner, I thought "Common Lisp: A Gentle Introduction to Symbolic Computation" was pretty good for getting started. I read PCL second but found that more a model for how to build something.
<mfiano>
That means you are going too quickly, not pausing to absorb the material and clarify with questions on IRC, and tinker with the snippets provided on your own.
<mfiano>
It's not a race to read the book. No book is going to teach you how to program. It will guide you on a nice learning path though.
<dirtcastle>
noted.
<_death>
I think one good thing about ACL is that it has exercises, which you should do
<dirtcastle>
I think I should re read the cd database part over and over before proceeding
<dirtcastle>
_death: thanks for pointing that out
azimut has quit [Remote host closed the connection]
azimut has joined #commonlisp
<dirtcastle>
I discovered emacs. and then I discovered nyxt browser. I wonder why every app isn't written in Lisp :P
<dirtcastle>
I tried to use selenium and python for web scripting. but it just doesn't feel right when compared to running a function in emacs.
NotThatRPG has joined #commonlisp
rangahy has quit [Ping timeout: 268 seconds]
<beach>
dirtcastle: I could explain to you why not every application is written in Lisp, but I have done that before, so I won't bore #commonlisp participants with it again.
<pve>
beach: is it written down somewhere? Like on the interwebs, because I would like to read it..
<beach>
I don't remember. Sorry. I'll let you know if I find something written down.
<pve>
ok, no worries
dider has quit [Quit: Client closed]
tibfulv has quit [Remote host closed the connection]
<dbotton>
that snippet causes an expected error on SBCL but not ECL
<dbotton>
My understanding is that is part of the standard
Oladon has joined #commonlisp
<dbotton>
Is ECL missing the functionality or is it just sbcl specific?
<jackdaniel>
declarations are convenient lies that the programmer tells the compiler; the latter may conformingly a) head the advice, b) ignore the advice, c) head the advice carefully, d) try to verify the advice
<jackdaniel>
s/head/heed/
<pjb>
dbotton: do you have a paste service that doesn't need javascript, such as http://termbin.com ?
<jackdaniel>
e) heed the advice and segfault (also conforming \o/ if the declaration is incorrect)
<Catie>
In my experience CCL likes to do E, it's very fun to play with
<pjb>
dbotton: your code is not conforming, since it likes to the compiler. Therefore anything happens. You're lucky if you get an error or any result ressembling 3.
gxt has joined #commonlisp
<aeth>
I wouldn't expect an ftype DECLARE for a global function to work (on the other hand, a global DECLAIM right above the relevant DEFUN probably should)
<pjb>
aeth: since the compiler can inline any file-local function call, declare will have an effect.
pranavats has joined #commonlisp
<Bike>
declaring an ftype locally is valid, aeth
<aeth>
valid, but it doesn't have to do anything
<aeth>
of course, none of it has to do anything, but DECLAIM FTYPE is common enough to come up
<dbotton>
aeth that is my question it seems according to ctlt that it should and is valid
<Bike>
have you observed ftype declarations not doing anything?
Fare has quit [Ping timeout: 260 seconds]
<Bike>
dbotton: your particular code is invalid, as pjb said.
<Bike>
"invalid" means it has undefined behavior, not that an error is necessarily signaled
<Bike>
"The consequences are undefined if any result is not of the declared type."
<kakuhen>
^ I was about to state its UB to violate the types in THE
<Bike>
of course, it's nice for an error to be signaled, but implementations don't have to do so
<kakuhen>
i.e. (the fixnum 1.0d0) and the likes are UB. You cant rely on your compiler signalling an error
<dbotton>
doesn't make the type system too useful if doesn't
<kakuhen>
SBCL signals a type error but CCL silently fails for instance
<pjb>
dbotton: it doesn't make declarations too useful, indeed.
<dbotton>
I guess outside of sbcl
<pjb>
dbotton: don't declare anything, let the compiler infer things and optimize things.
<kakuhen>
that's why you should always prefer check-type over a declare if you really need strict type checking across impls
<dbotton>
How does LW handle it?
<kakuhen>
that or increase safety levels; I know CCL does type checks on (safety 3) but not (safety 2)
<pjb>
it doesn't matter, non-conforming code can do whatever.
<Bike>
some types are impossible or impractical to check. leaving the consequences undefined lets you declare those types anyway for optimization.
<kakuhen>
^
<kakuhen>
(satisfies haltp) is a tough one to check ;)
<Bike>
for example, if you declare an array's element type, that specifies the type of the elements - not just the upgraded element type, like usual. so to check it an implementation would need to iterate over the array, which would probably offset any efficiency gain from it knowing the array is full of whatever.
<pjb>
non-conforming code is like programming in C. (the fixnum 1.0d0) CAN be equivalent to *(int*)(char*)(double x=1.0d0,&x) (note, not (int)1.0d0 !).
<pjb>
All kinds of silly stuff can occur is you write a wrong declaration. It's really very dangerous.
<Josh_2>
Bike: the combination is ideal though, high safety for testing, higher speed less safety in your live version :thinking:
<Nilby>
Type decls are useful, just not in the "programmer: you can't do this" way, but rather in the "compiler: maybe you can do this?" way. For the former we have things check-type and assert.
ec has quit [Ping timeout: 255 seconds]
<pjb>
Josh_2: not really. In production code, you want to ensure that no error pass thru. So you definitely want to keep the highest safety, and highest error detection for production.
<Josh_2>
I only declare types in classes and structures. Been a long while otherwise.
<pjb>
Josh_2: otherwise, it would be like using seat belt when testing your prototype cars, and removing them in production, because you've tested your car doesn't crash when driven correctly during the tests.
<Josh_2>
I disagree, on of the purposes of your testing version is to make sure that your typed code only receives the types expected
ec has joined #commonlisp
<pjb>
Any type declaration must be validated by a global analysis of the program to prove that you will never assign other than the specified type!
<_death>
dbotton: when you encounter "is an error" it means you shouldn't do it.. it's different from "signals an error", which means the implementation should do that
<pjb>
It's really costly to do.
<pjb>
I prefer to let the compiler insert good old type infered code, or run-time type checking as needed.
<Josh_2>
That is what I prefer as well
<Josh_2>
but if I knew I had a core part that was performance critical I would certainly make use of type declarations
<Josh_2>
<pjb>
Yes, but with extra care. Not writing non-conforming code like dbotton did.
<Josh_2>
Once I did a code test a friend of mine was given for a job interview using CL. Without the proper types the time taken to perform the data analysis was stupid.
<Josh_2>
pjb: agreed
<Josh_2>
The difference was hundreds of seconds down to seconds :sunglasses:
<dbotton>
pjb the non conformance was to see if it produced an error
<dbotton>
thank you all
Fare has joined #commonlisp
cage has quit [Quit: rcirc on GNU Emacs 27.1]
simendsjo has joined #commonlisp
Alfr is now known as Guest2096
Guest2096 has quit [Killed (calcium.libera.chat (Nickname regained by services))]
Alfr has joined #commonlisp
waleee has joined #commonlisp
Bung has quit [Remote host closed the connection]
Bung has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
_cymew_ has quit [Ping timeout: 264 seconds]
Brucio-61 has quit [Ping timeout: 260 seconds]
pdietz has joined #commonlisp
Brucio-61 has joined #commonlisp
Fare has quit [Ping timeout: 260 seconds]
Bung has quit [Ping timeout: 255 seconds]
Brucio-61 has quit [Client Quit]
scymtym has quit [Remote host closed the connection]
tyson2 has joined #commonlisp
lisp123 has joined #commonlisp
<Josh_2>
(list* :key1 key1 :key2 key2 keys) is much nicer than (append (list :key1 key :key2 key2) keys)
epony has quit [Quit: QUIT]
<Josh_2>
apply sure is cool
<Josh_2>
:sunglasses:
pranavats has left #commonlisp [Error from remote client]
dtman34_ has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
dtman34 has joined #commonlisp
<Josh_2>
One of the biggest projects I have made has been in constant use for almost 2 years now
<Josh_2>
pretty swell. Its FOSS as well
Fare has joined #commonlisp
<Josh_2>
But I have written 0 docs so its totally innaccessible for anyone but me :joy:
<Josh_2>
Most of the functionality was hacked into the program while it was running :sunglasses: so i've never taken the time to start from completely fresh so I could document how to get it running
simendsjo has quit [Remote host closed the connection]
<Josh_2>
Its a shame really, I've hacked so much functionality into this bot that I dont use at all anymore :shrug:
pdietz has quit [Quit: Client closed]
tetsuo9 has joined #commonlisp
random-nick has quit [Ping timeout: 264 seconds]
Krystof has joined #commonlisp
scymtym has joined #commonlisp
morganw has joined #commonlisp
<dbotton>
I always use doc strings, write when I can, notes etc. even if I can't understand myself sometimes most of the time I and others can :)
Brucio-61 has joined #commonlisp
tetsuo9 has quit [Quit: leaving]
tetsuo9_ has joined #commonlisp
random-nick has joined #commonlisp
lisp123 has quit [Read error: Connection reset by peer]
nij- has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
<dbotton>
_death helpful rule of thumb reading ctlt thanks
Fare has quit [Ping timeout: 260 seconds]
jeffrey has joined #commonlisp
pranavats has joined #commonlisp
Fare has joined #commonlisp
varjag has quit [Quit: ERC 5.4.1 (IRC client for GNU Emacs 29.0.50)]