freenode/#lisp - IRC Chatlog
Search
9:22:43
Shinmera
schweers: What do you mean? The reader is just an algorithm. You can implement it in any language.
9:23:35
schweers
Shinmera: I don’t know a lot about bootstrapping, but then I remembered that one needs a working CL environment to build sbcl, so it doesn’t seem that unusual anymore.
9:25:12
dmiles
i i was suprised at sbcl is that impls end up doing a minimalistic reader in their lnaugage (say C) then if they start to writ e alisp reader in Lisp.. their C code gets jealous and starts to take over until the lisp becomes busywork
9:27:33
dmiles
so they weight the cost benefits of having two codebases.. one lame one in C they cant delete (and they forever have to improve) .. vs a *overly* fantastic one im Lisp
10:24:21
dmiles
well my current reader is doing pretty well... it will probly be a week to two months before i really need to borrow a reader in lisp
11:05:57
beach
scymtym_: It looks like it is close to being usable. I certainly intend to start using it for reading SICL code.
11:29:30
scymtym_
beach: it should definitely be fine (strictly speaking "no worse than") for that particular case since it still mostly identical to the code it is replacing. i was referring to FIXMEs for not-yet-defined condition types, recently discovered (small) bugs and the like with that statement
11:56:55
beach
scymtym__: Sure, I understand that it is not completely finished, but it is definitely getting there.
12:43:50
pfdietz
dmiles: SBCL doesn't have to have a reader written in C, any more than a C compiler needs to have a lexer/parser written in assembler.
13:11:46
dmiles
pfdietz: to read SBCL's lisp reader into SBCL i was assuming there was a less functioning primordial reader
13:45:44
pfdietz
And gcc is written in C and compiled with a C compiler. The first C compiler written by Dennis Ritchie was in PDP-11 assembler though.
13:51:36
beach
It is very strange to me that so many people assume that a Common Lisp system must be (at least partially) written in some other language.
13:58:37
beach
makomo: So you are saying that, if asked, these people don't think that C compilers are written in C?
13:59:34
makomo
i always like to think about what would happen if you had the ability to destroy all compilers for high-level languages in an instant
14:00:02
makomo
the same would happen if you destroyed all of the robots in factories or something like that
14:00:51
makomo
it's a very interesting concept, because if you go deep enough, *someone* had to make the first version from something that was more primitive
14:09:26
JuanDaugherty
maybe with a core bootstrap in something else, e.g. the vm in smalltalk being in machine lang
14:17:58
dmiles
do others think that makomo is correct.. we'd have to start from scratch with lisp if there was not already a lisp impl?
14:18:47
makomo
dmiles: well how else would you do it? the initial lisp compiler was surely written in something that was not lisp, because lisp didn't exist until that moment :-)
14:19:08
beach
What do you mean by "start from scratch"? You would obviously have to write the first Lisp system in some other language.
14:19:45
jackdaniel
"starting from scratch" is a bold statement - you have all ideas around (even the standard)
14:20:26
makomo
when you get to the bottom of that thought, someone somewhere implemented the first program with a few electrodes :D
14:20:26
jackdaniel
while starting of scratch would be also thinking on how this should be specified
14:20:27
dmiles
well i just mean we have everything of all the lisp code and spec yet we didnt have lisp impl in any language other than lisp
14:21:37
makomo
so if you destroyed everything we had now, we would have to redo that whole process again
14:22:17
jackdaniel
makomo: that's not as terrifying, since you have all the design all over the place, you may implement from scratch only n-1 step to bootstrap step n
14:22:58
lieven
let me give you an even better one. If the electricity grid over a big enough area goes down, getting it up again would be a major problem.
14:23:45
dmiles
or like when the computer chip factory burned down in singapore iot took us 5 years before we could buy ram again
14:24:27
schweers
chris wellons wrote about part of this problem: http://nullprogram.com/blog/2016/11/17/
14:25:23
wingodboleash
actually, maybe in the process of reinventing the wheel somebody will find out that we've been doing it all wrong since the very beginning and so maybe it'll be for the better if everything gets destroyed...
14:25:28
JuanDaugherty
i.e. the first electronic ones were, the jackard looms were punched hole programs but not computers
14:30:41
wingodboleash
on a sidenote, why does it seem to me that i'm gonna have to write my own custom implementation of lisp to be truly satisfied with the language ? Seems to me that there's a sort of a law for lisp where everyone feels this at some point, and those who actually come up with a new implementation just increase the entropy of the scheme universe ! And then it becomes harder for a beginner to choose which dialect to choose and the beginner gets the same
14:31:53
lieven
schweers: http://yarchive.net/comp/linux/extreme_system_recovery.html Al Viro once did that for real without docs
14:32:37
dmiles
i am making my impl because i dont think anyone has ever built common lisp on prolog before
14:32:41
beach
wingodboleash: I take it you mean a new language as opposed to a new implementation of an existing language? That is not a problem, because new languages usually don't become widely used.
14:33:38
wingodboleash
yeah... like theres a feeling that i want to create a dialect of lisp that is taylored to my use... probably what lisp is most useful for ?
14:34:52
Shinmera
I'm a practical person, so I really don't see the use in creating yet another language for which you'll have to waste decades upon decades until you're at a point where you have enough libraries to be actually productive.
14:36:23
dmiles
JuanDaugherty: what Shinmera saiid is the reason I have to build my impl.. Imagine how many ytears it would take get all the lisp libraries for prolog?
14:36:38
Shinmera
wingodboleash: Well fortunately for you this channel is only about Common Lisp, and that world is just one language.
14:37:34
JuanDaugherty
dmiles, to me function is function, i'd rather think about ways to leave function as is and work on a means to leverage in a common system
14:37:48
dmiles
jackdaniel: the problem is there are 7 refernce impl of Prolog.. immagine me having to write all teh lisp libraries for all 7 ?
14:39:37
JuanDaugherty
everything pretty much boils down to the same ol jacked up 8080 instruction set anywho these days
14:39:46
dmiles
but then the whoile prolog world would need to abandon their 7 impls and jsut use proplog.. the path i have now all 7 can run all the lisp libraries
14:41:06
jackdaniel
dmiles: you coming up with your own incompatible implementation is like in this xkcd joke: we have 6 standard, that's unacceptable (and they make 7th standard)
14:43:32
dmiles
jackdaniel: though luckily i am *only* implemeting one standard that i did not create (common lisp). and having to write 3-5 shims to cover the differnces in the 7 impls of prolog
14:46:05
dmiles
the 3-5 shims (prolog-to-prolog compatibility libaries) already mostly exist . why i probly only have ot create 3-5
14:46:45
dmiles
JuanDaugherty: i find hta tis the only hard part about the impl.. Do i act like SBCL or do i cat like Clisp or like ECL?
14:48:07
dmiles
meaning i picking one #+<SBCL/ECL/CLISP> and making sure i conform to being really hte same
14:52:24
dmiles
Also though I figure most users with be user of Sicstus and SWI.. using things like CLEWS
14:56:56
dmiles
*nod* though since SWI is the slowest, it hard not having some of its libs on sicstus.. which the common-lisp libs will more than make up for
15:02:22
dmiles
to contrast speed differnces though i wrote a HPSG parser on SWI, and Goolseby ported a HPSG to ACL.. What took 2 seconds to run on SWI took 30secs on ACL
15:07:33
dmiles
https://github.com/SWI-Prolog/bench/blob/master/chat_parser.pl <- in fact, its a daily benchmark for SWI
15:10:27
dmiles
here is the output of the english2logic system: https://docs.google.com/document/d/1rdI_f-2YnX0e2RD6rGAY57YAqzLj2xHsk36m5HT6SoM/edit
15:43:20
beach
I think I pretty much finished my ELS submissions. There is enough time to write another paper. Or I could go back to design and coding.
16:12:00
Xach
I don't know why clisp is doing that, sorry. I don't use clisp a lot, but when I do, I haven't gotten signal 6 quits.
16:15:17
paule32
REINITIALIZE-SOURCE-REGISTRY-AND-RETRY :R1 Retry finding system cl-ppcre after reinitializing the source-registry.
16:49:08
pjb
dmiles: each implementation has a lisp reader of course. I don't know if sicl already has one implemented. You may have a look at: com.informatimago.common-lisp.lisp-reader.reader
17:19:44
mfiano
Xach: Ok, please let me know if you get build failures for gamebox-math from this morning's pull.
18:26:54
paule32
pjb: so, i don't know, if it a homework to get the right values/content on the output, you marked with !!! expected 1
18:36:41
rumbler31
paule32: Vielleicht sollen Sie etwas aenders als clisp benuetzen. Z.B ccl or sbcl
18:38:48
rumbler31
one good reason, is that clisp is old (2010-07-07), and trying with ccl or sbcl is easy, and you can get more help with those
18:40:41
rumbler31
well, right now, new versions are released frequently. Also, do you still use windows xp? or have you upgraded to windows 10, or 7?
18:42:18
rumbler31
so you like using a new version of linux, but you won't try a new version of lisp? :-)
18:42:30
pjb
paule32: type (apropos "TOPOLOGICAL-SORT") this should show you what package it comes from.
18:43:24
pjb
paule32: obviously you cannot remove it, it's an important part of the algorithm. Instead, you can try to design a different algorithm to evaluate a circuit.
18:47:41
pjb
This imports all the usual packages from the com.informatimago, so my functions are available.
18:48:21
pjb
(actually, I do that in a com.informatimago.pjb package, and I just use it in cl-user and others.
19:06:47
pjb
paule32: in the mean time you can just remove com.informatimago.tools.manifest from the systems to load.
19:26:04
pjb
paule32: why would you expect output from loading a lisp source file, and then QUITTING!?
19:30:05
mgsk
Is it possible to do something like (defun something (&key a b &rest c) ...) where in (something :a 1 :b 2 :c 1 2 3) they keyword :c "collects" all remaining forms, i.e. C = (1 2 3)?
19:31:50
Xach
What actually happens is that the &rest var collects subsequent keyword/value pairs. but they have to be matched.
19:32:57
Xach
(defun make-a-thing (class-name &rest args &key &allow-other-keys) (apply 'make-instance class-name args)) for a dumb example
19:35:27
mgsk
I was just thinking about how use-package (in emacs) allows for arbitrarily many forms to be given to a keyword (until the next keyword). But rather than complicate things, I'll re-think my design
19:47:28
pjb
paule32: why does it quit in the end? You're doing it wrong! Never quit from a lisp image!
19:52:36
pjb
mgsk: for example, something like (let ((arguments '(:a 1 :b 2 3 4 5 6))) (destructuring-bind (&key a b c) (loop with expected = '(:a :b) while (and arguments (cdr arguments) (member (first arguments) expected)) collect (pop arguments) into keys collect (pop arguments) into keys finally (return (list* :c arguments keys))) (list :a a :b b :c c))) #| --> (:a 1 :b 2 :c (3 4 5 6)) |#
19:55:46
pjb
mgsk: so (defun foo (&rest arguments) (destructuring-bind (&key a b c) (loop with expected = '(:a :b) while (and arguments (cdr arguments) (member (first arguments) expected)) collect (pop arguments) into keys collect (pop arguments) into keys finally (return (list* :c arguments keys))) (list :a a :b b :c c)))
20:44:31
phoe
paule32: using Lisp without slime is a terrible experience. you might as well be using a non-interactive language like C or Java.
20:46:02
phoe
doesn't matter what Java is. coding in Lisp without any kind of interactivity layer for it prevents you from taking advantage of one of its most important features.
20:51:34
paule32
pjb: $ clisp elo.lisp # in elo.lisp: (load "./init.lisp") ; where your code from paste
20:57:55
pjb
paule32: well, perhaps you don't have a clean cl-user package. Of course, I've already explained years ago, that one should clean his cl-user package in the rc files…
21:00:22
pjb
paule32: then add (load (merge-pathnames (make-pathname :directory '(:relative "RC") :name "COMMON" :type "LISP" :case :common) (user-homedir-pathname) nil)) in your ~/.clisprc.lisp file.
21:00:34
aeth
Would it be possible to write something that automatically recompiles all users of a macro, struct, inline function, etc., when it is recompiled? Basically, all of the stuff that can go stale.
21:01:03
aeth
(structs doing this, of course, is implementation-specific, but it would have to be done to be portable, and to support SBCL)
21:01:21
phoe
Write a custom DEFUN/DEFMETHOD/DEFeverything that codewalks the forms and finds all uses for the macro in question.
21:01:44
pjb
aeth: have a lookt at: Image Based Development http://www.informatimago.com/develop/lisp/com/informatimago/small-cl-pgms/ibcl/index.html
21:01:57
phoe
Then write a custom DEFMACRO that, whenever a macro is recompiled, finds all users of that macro stored via the above forms, and recompiles them.
21:02:15
aeth
phoe: I was hoping that there was an easier way. SLIME and/or ASDF probably already know certain things.
21:02:33
pjb
aeth: this way you can save the source of each form; you may add a plist to macros, structures, inline functions, etc, to list all the things that need to be recompiled.
21:02:53
Bike
i don't think they implementations actually usually track macro usage, just function usage, which they need to know for linking purposes
21:06:19
aeth
What has issues with recompiling, btw? I'm aware of inline functions, macros, and sometimes (afaik it's implementation-specific) structs.
21:07:53
aeth
I think package definitions also have issues, but only if you remove things (rather than add things)
21:08:07
aeth
But you can remove those manually by going into the package and uninterning manually iirc
21:09:05
Bike
depending on how you construe the workings of load-time-value in relation to compilation, maybe you'd need to recompile for lots of random reasons
21:09:33
Bike
strictly speaking, some properties of classes, though i don't know if any implementation actually takes advantage
21:09:37
aeth
Oh, actually, I never have to do the whole in-package thing for uninterning ever again, in implementations that support foo::(unintern 'whatever)
21:13:31
aeth
the syntax is: (unintern 'foo::some-symbol-to-remove :foo) because I need to tell it to remove the 'some-symbol-to-remove that's in foo
21:16:19
aeth
Anyway, my actual point was: if I recompile a function without recompiling the defpackage that imports the new symbol (oops), I now need to unintern that symbol before recompiling the defpackage or else there's a conflict that the debugger wants me to resolve.
21:18:12
Xach
You get "undefined function frob" and you change defpackage to :use the package that provides frob and you get a conflict?
21:18:25
Xach
That happens to me - when it does, I use shadowing-import-from to clobber the existing one.