freenode/#lisp - IRC Chatlog
Search
9:52:11
ogamita
fiddlerwoaroof: let and declare will have effect at run-time. When the file is compiled, nothing says that *arg* is a special variable.
9:52:53
ogamita
fiddlerwoaroof: the problem is that you put everything in a single toplevel form. This single form needs to be compiled before it's executed. But it provides itself information that is needed to compile itself. It's not possible.
9:53:25
ogamita
fiddlerwoaroof: you can add a toplevel form: (eval-when (:compile-toplevel) (declaim (special *arg*))) or just (defvar *arg*).
11:27:34
tfb
shka__: what can't? That the thing currently called 'AI' will make us all rich or that this is just another AI hype cycle close to its peak?
11:29:51
tfb
Yes, that's obviously absurd, but it's in the nature of hype cycles that people do a lot of hyping: that's how they get funding
12:15:49
vms14
atm I just see one of the lisp methods to make programs is to make functions which call another functions which also call another functions
12:17:52
vms14
I guess this method to calling routines which in turn call another routines and every one is like a little step is what is called bottom up design, but maybe I'm wrong
12:19:43
heisig
vms14: Lisp also allows you to write functions that write or manipulate programs. That is the the crucial difference.
12:20:36
margaritamike
heisig: Functions that write or manipulate other programming languages, as well?
12:21:19
heisig
vms14: Often you are fine with just using functions all the way. But sometimes, the right macro or code generator can shorten and improve your code by orders of magnitude.
12:21:48
vms14
it means reflective is the ability of a language to "check" itself and it's a nice thing for metaprogramming
12:22:09
White_Flame
well, there's usually not much introspection that fundamentally needsto happen for metaprogramming
12:22:23
White_Flame
it can usually be a one-way thing, taking spec data as input and generating code as output
12:22:42
margaritamike
I guess I was asking a question. Can lisp be used as a high level manager program that manipulates slave programs written in other languages? If so, can it still have its late binding debugging appeal with that scenario in manipulated a broken slave program written in another language without recompiling?
12:22:43
heisig
margaritamike: Why would anyone want that :) (Joke aside, there are such projects, e.g., https://github.com/kiselgra/c-mera )
12:23:13
White_Flame
margaritamike: any language can do that, as you're genreally going to be working with external processes and sockets
12:24:12
White_Flame
but you really hae to define what "broken"and "fixing" mean. The erlang approach of letting things die, reporting errors, and relaunching stuff covers a lot of situations
12:24:26
margaritamike
Ohh I thought it could force other programs to be manipulated via late binding with its magical debug powers as well. :(
12:25:04
White_Flame
but are you seriously going to code ability for software to be able to autonomously analyze, debug, and fix general purpose code?
12:25:31
vms14
also I know just a bit of yacc, but I guess with Lisp there is no need to use yacc anymore
12:28:01
White_Flame
but again, it's a heavy AI dream to have the machine find out that the current code doesn't match human intent (ie is buggy) and automatically discover how to fix it so it does match that human intent
12:30:03
larryba
while we are on the topic of parsers, what parser libraries are recommended these days?
12:34:23
ogamita
vms14: compare https://github.com/informatimago/scquery/tree/master/sources-cl with https://github.com/informatimago/scquery/tree/master/sources for example.
12:34:51
vms14
In C most of the work you do is in bigger functions, In Lisp the functions are little functions calling other functions and modifying the output of those called functions
12:35:00
ogamita
vms14: I admit that C is slightly more verbose than lisp (you have to declare the types of variables), but a lisper would write the same code in lisp and in C.
12:35:24
ogamita
vms14: you're confusing bad programmers (most C programmers) with good programmers (most lisp programmers), with languages.
12:36:42
vms14
most of programmers think that modularity is just to separate things in different files
12:36:43
ogamita
vms14: have a look at the intepreter pattern. Consider implementing it in a C program. Then consider using llvm.
12:37:30
ogamita
vms14: 1- half of the programmers are newbies with less than 5 years of experience, given that the programmer population doubles every 5 years.
12:37:53
White_Flame
vms14: many C programmers are micro-performance oriented, and consider function calls to be expensive
12:38:20
White_Flame
it's very likely not true anymore with the internal parallelism fo CPUs, but whatever
12:38:27
ogamita
vms14: 2- more than half the new programmers are very bad programmers: they have no education or diploma, and if they have an education and diploma, realize that most of them get it with 10/20 grades, meaning they fail half the time.
12:38:58
White_Flame
vms14: function calls in Lisp have like 1 or 2 little instructions for clearing a carry flag or setting a register to the number of parameters
12:39:15
White_Flame
of course, parsing keyword parameter on the callee side is more work than plain positional args
12:40:01
ogamita
vms14: therefore you can count coarsely that only 1/4 of the newbies are any good. And being optimistic, assuming that 1/2 of the oldies are any good (let's hope they've learned something), that gives at most 1/4+1/8 = 3/8 passable programmers.
12:41:11
ogamita
function call cost is completely overflown in C with memory management LOC and processor cycle.
12:41:24
vms14
you start making a little function which does one thing, then the other function works with this output and so on
12:42:04
ogamita
Happily, you can recover some of this cost by linking with libgc, and forgetting free, but not entirely given the way C is compiled, libgc has to be conservative.
12:43:15
White_Flame
why not? prompt-read in that example is used 3 times. That's certainly worth breaking out
12:43:22
ogamita
void prompt_for_cd(){ add_record(make_cd(prompt_read("Title"),prompt_read("Artist")),parse_integer(prompt_read("Rating"))); }
12:43:38
aeth
ogamita: Lisp works with expressions so you wind up writing fairly different code from C even if you know both languages. e.g. in most languages you'd have to write something like "foo; if (x > 1) foo = 42; else if (x < 1) foo = -42; else foo = 0;" but in CL it's (cond ((> x 1) 42) ((< x 1) -42) (t 0))) and you don't even need the intermediate variable, you can just use the cond directly.
12:43:43
White_Flame
of course, newbies tend not to use any abstraction at all and just straight-line all code to figure out what it does, before learning the benefits of function organization
12:43:47
ogamita
The only problem here, is memory: prompt_read returning a string, it should be freed.
12:43:58
aeth
ogamita: And expressions like the cond version really do encourage splitting something off into a function at a smaller size than the point where you'd break something up in a language like C or even python
12:44:21
ogamita
You can deal only with expressions, using only one return statement in each function ,and using ?: a lot.
12:45:04
ogamita
You can do something like: void prompt_for_cd(){ void* t,*a,*r; add_record(make_cd(t=prompt_read("Title"),a=prompt_read("Artist")),parse_integer(r=prompt_read("Rating"))); free(t);free(a);free(r); }
12:45:32
aeth
ogamita: The difference is that ternary and even some lambdas (like Python's lambdas) exist to obfuscate code and make things hard and are basically unusable past trivial one liners, but in CL your "one liner" forms can go on for dozens of lines.
12:46:29
aeth
ogamita: Even if my example was just an if/else there's a good chance I'd translate a COND into if/else instead of ternary, especially if it was more advanced than just setting a foo to a number
12:47:18
ogamita
aeth: if you add the parentheses,emacs will ident it readbaly, evenwith multiple embedded ?: return ((test) \n ? (then) \n : (else)) ;
12:48:08
ogamita
vms14: now, you have a very big interpreter pattern implementation called libecl ;-)
12:48:58
vms14
libecl is a package for reading and writing the result files from the Eclipse reservoir simulator
12:49:58
jackdaniel
libecl is a shared object library which implements common lisp (Embeddable Common Lisp implementation)
12:54:30
vms14
also lex and yacc because I like metaprogramming, and I wanted to make a shit toy language
12:54:56
vms14
this fact is a part of why I want to learn lisp, not for metaprogramming, but to steal concepts
12:55:30
ogamita
margaritamike: of course, you can use CL to fork out external programs and manage them. You benefit from the superior error handling compared to bash. You just have to be careful to collect and transfer the status of the child processes correctly. Now of course, you won't be able to debug the child processes using CL (unless you actually run the foreign program inside lisp, (there is a paper showing how they loaded a linux driver IIRC
12:55:30
ogamita
inside a sbcl lisp image to debug it)), but you will be able to "debug" and recover from failure more easily with CL than with bash.
12:55:49
vms14
But I see Lisp is different than other languages I have tried and I really like it more
12:57:02
vms14
I have some things in mind, like the when statement (not like the when of lisp), a concurrent one
12:58:31
vms14
with lisp is so easy to do that since you can just make repl and check the when struct when a variable inside this struct is changing it's value
12:59:34
larryba
vms14 if building programs by composing small, reusable functions appeals to you, there are languages that encourage that style of programming even more than CL
13:01:06
vms14
And I see it better even if I'm just a noob and I'm not able to really appreciate lisp
13:01:20
margaritamike
To have a safe place to write shitty Lisp code, that tells you whether your code is right or not, in some environment
13:02:57
vms14
I'd like to start with the onlisp and then the letoverlambda, but I should walk before run
13:08:55
robdog
one thing that bugged me about the intro chapters of lisp books, is that they dive deep into (car and (cdr .. which in my opinion for a newbie, you DONT need.. at that moment
13:09:53
ogamita
jprajzne: you could use pseudo-scheme to do the little schemer exercises directly in scheme in a CL implementation.
13:10:32
ogamita
jprajzne: or you could translate it; basically define -> defvar or defun, and the only big difference is that for high order functions, you may have to use function and funcall.
13:11:28
ogamita
jprajzne: people have been studing sicp and doing all the exercises in CL instead of scheme (or even, in C++ or other languages).
13:12:15
robdog
Clojure is another lisp, which is "modern" and there seems to be a bunch of new tutorials and books..the concepts are the same
13:12:33
ogamita
robdog: it depends what for. If you're processing lists, use first/rest/endp/list*/list; If you're processing conses, use car/cdr/null/cons.
13:13:00
vms14
robdog: yes, if you "must" use java for some reason, clojure can make your life better
13:13:36
jackdaniel
robdog: "the concepts are the same" is a false claim. Clojure devotes itself to a data-driven functional paradigm (for better or worse), while CL doesn't (it is open for paradigm which programmer wants to use)
13:13:43
ogamita
anyways, as al lisper, you need to know a little of common lisp, of scheme and of emacs lisp. Then you may choose to know a lot of CL or scheme or emacs lisp, depending on what language you want to use to write your applications.
13:13:58
jprajzne
i don't even know what and where i would and could use lisp :) am just trying to exercise my brain with different kind of thinking
13:14:56
ogamita
Or, when I have to write C or C++ code, to write and debug prototypes, that I then translate to C or C++.
13:15:38
robdog
then you discover how awesome emacs is ..(and the key bindings suck) but how its organized and customizable in lisp is awesome
13:15:47
vms14
I saw a post where says if you want to be a good C programmer you need one interpreted language to make your prototypes
13:16:19
jprajzne
ogamita: reading about all the places where one can find lisp, am wondering why it's not topping the list of most used prog. langs. :)
13:16:53
beach
vms14: Interpretation and compilation are both implementation techniques. No language specifies that one or the other has to be used for its implementation.
13:17:25
ogamita
jprajzne: as explained above, half of the programmers are newbies with less than 5 years experience, and half of all the programmers are uneducated or have a diploma with 10/20 grades, which mean they fail half the time. Ie. most of them are dumb.
13:17:36
robdog
Perl was my prototype language.. prototype for me : you have one night to code up the idea..get it done
13:18:15
jackdaniel
[note: please move this discussion to #lispcafe, it is hardly related to CL anymore]
13:19:02
vms14
An interpreted language is a type of programming language for which most of its implementations execute instructions directly and freely, without previously compiling a program into machine-language instructions.
13:20:45
vms14
since a compiler should translate to asm, and whatever it translates to a "higher" language is a transpiler
13:24:33
beach
Interesting definition. So if a bunch of people go ahead and write Python compilers, suddenly the LANGUAGE becomes compiled, even though its definition has not changed. Such a definition is not valid in my book.
13:25:13
aeth
A naive interpreter isn't very good, so I can understand why you would want bytecode. For instance, you wouldn't be able to rewrite things to simplify them if you're just executing the source code line by line. So the instructions an interpreter interprets aren't going to be the lines of source code.
13:26:14
aeth
beach: On the one hand, languages aren't faster than other languages: implementations are. On the other hand, some languages make efficient implementations very hard to write (which doesn't mean it's impossible: e.g. LuaJIT or JavaScript)
13:27:23
vms14
https://stackoverflow.com/questions/2657268/whats-the-difference-between-compiled-and-interpreted-language
13:29:48
p_l
beach: I'd say that Python can't be called compiled language so long as it doesn't have proper compilation semantics :P
13:30:01
aeth
Certain languages are definitely designed with interpreters in mind, like certain Lisp dialects that rely on fexprs like (iirc) PicoLisp. On the other hand, Common Lisp definitely isn't so this is definitely #lispcafe or at least ##lisp material
13:33:44
aeth
(And if the question gets linked to elsewhere it's normally too interesting to keep open)
13:35:53
aeth
As far as compiled vs. interpreted goes, what I find interesting about Common Lisp is that it has some very mature compiled implementations, but even those implementations behave with most of the advantages you would expect from an interpreted language.
13:39:48
vms14
I see elephant https://www.common-lisp.net/project/elephant/doc/elephant.html#Overview
13:40:11
jdz
My benchmark of adding a web-server to my running application does not even work in C nor golang.
13:46:39
Xach
stack overflow is a pretty good place to ask lisp questions. there are a lot of active people who answer things in a helpful way.
13:46:40
aeth
vms14: they'll correctly point out that most of the heavy lifting is probably done by the C library
13:47:04
vms14
also I tell them that it's not slow, but it's easy to make slow programs, specially if you use lists like they were vectors
13:47:16
aeth
vms14: This is probably better, but SBCL has ben slipping probably 5-6 ranks already on that chart. https://benchmarksgame-team.pages.debian.net/benchmarksgame/which-programs-are-fast.html
13:49:26
aeth
Ruby's another example of a language that has semantics that makes an efficient implementation hard, apparently.
13:50:15
beach
p_l: I say Python is not a language, because it doesn't have an independent specification.
13:52:17
vms14
I guess it's an error to use ruby on rails for a server, having all the alternatives we have
13:52:23
Xach
If you'd like to use Common Lisp, use it - it is fun and people will help if they can.
13:52:40
aeth
Iirc, Ruby's used for Github, Gitlab, and a bunch of other websites. If it's dead, many of us would like Common Lisp to be that dead.
13:54:12
p_l
vms14: I actually recently went with RoR for new application. It really makes a ton of things easy, for the common path
13:54:41
vms14
and It's not due to language fault, it just scares people and they don't want to see it's power
13:55:10
p_l
best chances to use Lisp involve clients who don't ask about what language the application is written in
13:56:15
phoe
way too many people talk about how Lisp is magical and wonderful and silver bullet and holy and superpowerful and what not
13:57:23
phoe
vms14: yes, there's no point writing Lisp without an editor that is smart enough to support you writing Lisp.
13:58:04
beach
vms14: Yes, the world is full of ignorant and stupid people. Nothing new here. Now drop it.
13:59:55
aeth
vms14: Could Lisp formatting be made very slightly more readable when experience with the existing style is not taken into account? Perhaps. But then we would use the uniformity of style which is one of the largest advantages of Common Lisp, and even Lisps in general (which usually have very similar styles to each other). Compare this with the 10 different ways to write C.
14:00:17
jprajzne
it doesn't help much if you say 'hey stupid, don't care about x, y, z but still learn the damn thing'
14:00:27
aeth
Uniformity of style makes a language readable, so we go with what already exists instead of bikeshedding.
14:01:34
aeth
But because we all use exactly the same indentation we have code that's readable to anyone with experience in the language, instead of having 10 different indentation styles, several of which are major, like with C.
14:02:36
aeth
And we don't need some kind of solution like Go has where (afaik) you write how we want and then a tool converts it into a common style. Because we have the common indentation style already.
14:03:04
phoe
Lisp is already clear and readable enough if you are willing to learn to read it, spend some time reading it and have an editor that handles the mechanical work for you in case of any edits. Not many people have a combination of the first two, so not many people read Lisp; and even fewer have a combination of all three.
14:03:12
Xach
one nice thing about common lisp is that if you feel strongly about how something should be done you can simply do it that way and ignore anyone who says you should do it differently (this is also an option in any other area of life)
14:05:37
aeth
People use a language when a platform or ecosystem they want access to uses that language. That makes them willing to learn a language and get through all the barriers and ignore the disadvantages. That is, people use a programming language to do things, and they use it if it enables them to do things with libraries/frameworks/etc. or if it is the language of a platform (either something big like the Web or small like the language you mod a
14:07:31
aeth
Can Common Lisp be fast? Yes. Can Common Lisp be beautiful and elegant? Yes. Can Common Lisp do fancy things that are hard in most other languages? Yes. But does Common Lisp enable people to write something that they want to write?
14:08:37
vms14
My intention is to make lisp more attractive to people in order to help it make more mainstream which is a benefit for all
14:08:50
aeth
People have used languages with imo major issues like FORTRAN (especially very early versions), C, COBOL, BASIC, JavaScript, Lua, etc. They use(d) them because of the platform and/or ecosystem.
14:09:21
vms14
So the first thing is try to make parenthesis less scaring, because it's the main reason one runs when sees lisp code
14:10:47
jdz
I use parens to make sure code is indented properly so that I know the code is what I intend it to be.
14:11:09
aeth
You can create the most perfect language in the world, but if no one uses it, no one will, unless you're a $1,000,000,000,000 corporation and can have a massive marketing push. D has some good ideas but no one is pushing it. Common Lisp isn't even the best possible Lisp, it's just the common one. The best thing you can do for Common Lisp is to create a library, framework, or platform that people want to use.
14:14:24
beach
vms14: What is your point? We went through all this several times in #clschool. Are you trying to convince all these smart, knowledgeable, and experiences lispers who hang out here to change their style so that we can attract all those stupid, ignorant, newbie programmers out there?
14:14:28
aeth
People aren't avoiding Common Lisp because of its style. They're avoiding Common Lisp because while it's a very fast language to write things from scratch in, no one writes things from scratch these days and the library selection is small and largely undocumented. (And if you think CL has it bad, look at pretty much every other Lisp, with the exceptions of Clojure and Emacs Lisp.)
14:15:04
aeth
The solution to that problem is to either write more libraries or document existing libraries.
14:15:17
beach
vms14: Furthermore, you told me in a PM that you would be a "nice boy" or something to that effect. Apparently, you changed your mind?
14:16:02
vms14
every language has it's own conventions, and if you want to contribute to this community you need to follow their rules.
14:16:10
aeth
marvin2: I'm just talking about a hypothetical. For instance, something exactly like Common Lisp but without rplaca and rplacd would be a cleaner language.
14:16:54
jackdaniel
but how lack rplaca / rplacd make a language cleaner? you may ignore them if they had never existed
14:17:52
beach
vms14: The only reason I can see is that you somehow try to convince people here that your opinions are worth more than generations of smart, knowledgeable, and experienced Lisp programmers. That just isn't going to happen.
14:18:11
ogamita
Actually, a lisp pure interpreter (ie. eval) is not that bad, compared to other languages, since it works on the sexps, which gives direct access to the expression structure needed to interpret in most cases, while other languages need to be parsed first, and often have disparate syntactic elements to be gathered to be interpreted.
14:18:49
aeth
jackdaniel: You can ignore something if you're writing code, but not if you're reading it.
14:19:00
jackdaniel
rolling out a new-better-common-lispâ„¢ is as simple as creating "nbcl"/"nbcl-user" packages and importing only symbols you consider clean
14:19:28
jackdaniel
well, you may still see rplaca/ rplacd if someone makes a convenience functions for themself
14:19:32
beach
vms14: I am calling people stupid, ignorant, and inexperienced if they judge some technology based on incorrect assumptions and superficial impressions, without finding out the facts, and without attempting to train themselves in the essentials of programming language design.
14:19:38
aeth
Because stuff like rplaca or &aux exist, people who have been writing CL for years still have to look things up from time to time
14:20:01
jackdaniel
&aux is actually a very useful idiom for not wrapping whole body in one single LET
14:20:46
beach
vms14: Yes, I have been called "arrogant" and even "elitist" for daring to suggest that people have some training in the profession that they exercise.
14:21:18
ogamita
And yes, some sexps could be excuted directly by some hardware, so you wouldn't even need a interpreter or a compiler (just a macro-expander = minimal-compiler).
14:21:30
jackdaniel
I think that not many people here are interested in this "discussion", common approach would be type /ignore <nick> and get over it. either way please end it
14:23:12
aeth
ogamita: That is an old debate and optimizing compilers targeting simple instruction sets won, mainly because software updates faster than hardware.
14:24:17
aeth
ogamita: And also the economics of scale on general purpose CPUs is not something you can ignore. SBCL on x86-64 will probably beat any CL hardware made, even with the slowing down of the performance improvements.
14:25:45
ogamita
aeth: this is not the question. Nowadays, with all those computers and processors connected to the wild internet, running in controlled environment is more important than running fast. Therefore having a hardware lisp machine could become commercially interesting again.
14:27:01
aeth
ogamita: I'm not sure, though. Even there, it's probably better to have a very simple, well-auited machine. Hardware Lisp would be pretty complicated, and it would be hard to patch if there was a security flaw.
14:27:03
ogamita
Also, a lot of user programs run in the browser, if you can send sexps instead of javascript, and have them run native-fast and secure without compilation, this should make the whole system faster.
14:28:09
ogamita
(not all of them would be needed in the hardware actually, but we'd have to add a few primitive functions, so that's about the count).
14:29:56
aeth
ogamita: I think you'd have more success with specialized Lisp hardware if you extended RISC V than if you made an architecture based on Lisp primative forms.
14:31:00
jackdaniel
using stock open hardware sounds like a plan (creating new lisp machine does not)
14:31:49
ogamita
First, only tagged memory. Even on storage. The only raw bytes would come from the network.
14:31:58
larryba
shka__, personal experience, changing return type from "a" to "Maybe a" in one function in a several thousand lines code base, and then have the compiler guide you to correct every single application of that function (and functions that call the functions that call it, etc) and then have the program just work as soon as it compiled, was pretty awesome
14:31:59
aeth
Extensions to help Common Lisp, such as tagging and GC support at a hardware level, are probably things similar languages are also interested in, so the effort could be shared.
14:34:26
jackdaniel
creating a new lisp machine as a community project is unlikely, extending stock hardware seems as an idea which would capture more mindshare, so my bets are on what aeth says
14:36:49
larryba
shka__, I don't understand how he imagines that existing callers (that did not expect null, but are now getting it), won't break. it will either break at compile time, or at runtime
14:40:07
ggole
larryba: it works if you partition values into sets and the Nothing value is disjoint from the rest
14:41:23
aeth
Extending RISC V also means you can run C, Linux, etc. Then you're just porting SBCL or CCL or another implementation and not implementing an entire OS and CL implementation from scratch.
14:41:28
larryba
ggole, it is only guaranteed to work if you check every single reference for null, but nobody does that (or would want to do it)
14:42:20
jackdaniel
aeth: to play devil advocate (I like your idea), this won't be a Lisp operating system, so it will inherit security and performance flaws from current hardware
14:42:25
larryba
ggole, it *may* work if you used the reference in a way that it doesn't matter whether it is null or not. but that is just pure luck, and you're relying on it
14:43:58
jackdaniel
and to support the idea: if risk v is extended to support Lisp better nothing prevents a developer to write Lisp operating system on that (so these flaws won't be inherited)
14:47:12
larryba
ggole, add1 does, because it called a function that started returning nil, but before, it didn't
14:48:12
ggole
A change to returning nil is not backwards compatible under the suggested system, though?
14:49:00
ggole
The suggestion is pretty much subtyping, with the usual variance for arguments and return values.
14:52:22
ggole
Or at least, it's a breaking change, in the sense that some existing code would no longer type check.
14:52:44
larryba
are you talking about ML style Option type, or what you would do in a language without it?
14:53:45
ggole
The type variable in the ML option ranges over all ML values, including all values of type option. This is exactly what distinguishes one approach from the other.
14:54:24
larryba
Option is a type in ML. that is the only way to have nil equivalent. without option, you are guaranteed not to have nil
14:55:44
larryba
here's an example. (defun fetch-in () ...) returns just an int, everything is fine. nobody checks if it returns an int, because it always does. but then one day your coworker starts returning nil, for whatever reason. how does that subtyping help you? (and why is it OT? it only applies to clojure?)
14:58:34
ggole
However, if you previously returned int + nil, and changed things to always return int, it would still type check, because int is a subtype of int + nil.
14:59:18
larryba
that is not what I took out of that video, though, admittedly, I did just fast forward through first 40 minutes. but in those 40 minutes, he criticized languages where this fails to type check, specifically because your code no longer compiles
15:01:44
Selwyn
is PAIP relevant today regarding Common Lisp coding style? I am enjoying the book, but I am reading it mostly to get better at Common Lisp and would not like to pick up dated habits
15:02:18
Xach
I don't remember the exceptions - I need to revisit. But I would not worry about it in general.
15:05:42
aeth
That's one thing I could think of that older Lisp books might use that is increasingly uncommon in contemporary Lisp (most people just use SETF for everything)
15:08:03
Selwyn
it mentions that some people prefer(red) both, and that a programmer should be consistent in their choice
15:08:07
_death
I use both SETQ/GET, see nothing wrong with them.. in my opinion there are two good styles in modern CL.. one of them is taught in PAIP
15:09:41
_death
the other I would call CLOS style... and for that you can read AMOP or CLIM spec, for example
15:10:04
larryba
ggole, I don't know Kotlin, I can't see how both things he is suggesting can be true. that assigning nil to String fails to compile (you have to use String?, instead), and yet passing String? to a function accepting String still works
15:12:58
aeth
Two styles? There are three solutions for any(*) problem: higher order function, macro, or CLOS.
15:18:09
ggole
They do quite different things, I don't think one is an obvious improvement over the other
15:18:13
larryba
but, his first example, that did the opposite, (changed String to String?), would still break
15:19:16
larryba
(and that is the whole point, because, again, either it breaks at compile time, or you have to manually visit all the call sites to make sure it doesn't break at runtime)
15:20:44
larryba
I would say this is better, I don't see any disadvantages, but there are obvious advantages. of course, this just works for Option/Maybe type, but not for Either
15:22:14
larryba
unless Kotlin allows you to create custom types like that. but, going by the video, it doesn't, nullability is hardcoded into the language
15:22:54
ggole
The disadvantage is that you can't use Maybe to indicate presence/absence of a value without mishandling the nil case (eg, see the multiple return values for gethash)
15:23:22
ggole
However, it is fairly clear that it matches the way that values work in dynamically typed languages quite well.
15:24:08
ggole
Because you can't tell the difference between finding/returning nothing, and finding an valid entry which has the value nil
15:26:26
larryba
hmm, yes. there's already nil, so even if it was syntactically valid, it would still just be nil.
15:36:17
marvin2
you could expand this to lists too. should a single element and lists form a union? Option type is basically a list with zero or one elements
16:06:18
namra
i'm kinda new to common lisp and encountered an issue with sbcl 1.4.13 while trying to install clack. the issue is actually with one of the indirect dependencies namely nibbles.
16:07:16
namra
from the backtrace: 0: (SB-X86-64-ASM::MOVZX (#<SB-C:TN t1[RDX] :NORMAL> #<SB-X86-64-ASM::EA base=#<SB-C:TN t2[R8] :NORMAL> disp=1>) #<SB-ASSEM:SEGMENT {100265AE63}> RDX #<SB-X86-64-ASM::EA base=#<SB-C:TN t2[R8] :NORMAL>
16:07:24
Xach
namra: nibbles has been recently updated - have you updated your quicklisp install too?
16:10:43
namra
though this is because wanted to checkout the following changes https://github.com/glv2/nibbles/commit/f18c323b7af3c3b555743f03ecdc84fdf963a2e0
16:14:18
namra
looks like even after i did the (ql:update-dist "quicklisp") it still tried to load an older version of nibbles
18:42:02
fiddlerwoaroof
hmm, where does the standard say that "let and declare will have effect at runtime". This isn't generally true for declarations with DECLARE
18:42:55
verisimilitude
If I recall correctly, a type declaration is equivalent to wrapping THE around the relevant variables.
18:45:22
fiddlerwoaroof
e.g.: A type declaration of a symbol defined by symbol-macrolet is equivalent to wrapping a the expression around the expansion of that symbol, although the symbol's macro expansion is not actually affected.
18:45:24
fiddlerwoaroof
A type declaration of a symbol defined by symbol-macrolet is equivalent to wrapping a the expression around the expansion of that symbol, although the symbol's macro expansion is not actually affected.
18:46:54
fiddlerwoaroof
(tangentially, htmlize.el + a cloudflare-wrapped webserver makes a great pastebin.)
18:48:39
Bike
"Declarations at the head of the method body that apply to the method's lambda variables are treated as bound declarations whose scope is the same as the corresponding bindings." in clhs defmethod
18:53:25
Bike
oh, i see. it's not the "actual" binding, just some internal thing in the body of call-next-method that i can't really make sense of
18:57:01
Bike
since it's so limited it probably won't have any noticeable effect, though i'm not totally sure.
18:58:10
fiddlerwoaroof
It's kinda like why I hate using (OPTIMIZE (SPEED 3)) because it forces a bunch of compile-time noise on you
18:58:40
fiddlerwoaroof
I wish there were some kind of granular mechanism to opt-into various style-warnings
19:00:51
Bike
well, that's because if you're using speed 3 it's expected that you'll want to go ever faster
19:04:41
fiddlerwoaroof
Bike: yeah, but once I've thought about one of the warnings it generates, I should be able to mark that one as "done"