freenode/#lisp - IRC Chatlog
Search
10:53:06
dmiles
i eliminate them with 4 lines of code: https://github.com/TeamSPoon/wam_common_lisp/blob/master/prolog/wam_cl/funcall.pl#L140-L143
10:54:34
phoe
to sum things up really fast and messy, you need to have the compiler at your disposal to properly implement EVAL.
10:54:57
Shinmera
What was the reason that eval is different from (compile NIL `(lambda () () ,expr))?
10:57:08
dmiles
the orignal question was "outside of the case of EVAL and some whereness of trying to eval at runtime" .. x y z
10:57:09
beach
dmiles: Because the arguments can contain arbitrary expressions that need to be evaluated before the function can be applied. This is elementary in implementing Common Lisp. You really should have a look at Lisp in Small Pieces.
10:57:47
dmiles
i was trying to avoid discussing eval :P but i accidently brought it upo in the question
10:58:53
dmiles
the question was "outside the case of EVAL, is there a reason one might have to macroexpand at runtime"
11:04:11
dmiles
phoe: yeah, though mostly i make a little lambda that returns that experession with load-time-value for things liek that if they dont seem constant
11:16:07
beach
So #.(random 666) is first an example of something that is NOT constant at compile time, and then you agree that it IS?
11:16:18
dmiles
ok so i think the answer to my question is: "except in the cases that the programmer is forcing the need for eval, (yet they can still use apply/funcall), except the case the programmer is using macroexpand (or evaluating the macroexpransion with hopes of evaluating it next), you should be able able to complle programs well enough that you will not need to relly on preserving your enviroment
11:16:55
random-nick
shouldn't everything evaluated with #. be constant at compile-time since it is evaluated at read-time?
11:17:45
dmiles
beach: really i assumed the lisp reader gave me a random number and i compile things never knowing the number ws random
11:18:36
beach
It gives you one number. So it is constant. But you gave this as an example of something that is NOT constant. And then you changed your mind.
11:19:57
dmiles
i was under the assumption it related to load-time-value (but i think that assumption was wrong)
11:21:38
dmiles
if the users code contained (read-from-string ".(random 666) ") that might be differnt
11:21:44
beach
Maybe you don't care whether your implementation is conforming or not, but if you do, I think you are in for A LOT of work.
11:24:22
dmiles
well i been working for 3 months it.. i have one month left in budget to be able to run 2 differnt applications.. then if i can get that done i get 2 more months to run/compile 2 more applications.. then after that i get to worry about conformance and passing the ansi-tests
11:30:32
dmiles
so my intial goal is compile and run "DAYDREAMER" and (PTTP or "Knowledge Machine") by end of January
11:39:18
flip214
Xach's report of ASDF 3.3.1 breakage in newer SBCL includes a few non-ASDF related things, AFAICT.
11:39:23
flip214
for example, http://report.quicklisp.org/2017-12-25/failure-report/cl-sendmail.html#cl-sendmail says
11:39:44
flip214
; Derived type of CHILD is (VALUES LIST &OPTIONAL), conflicting with its asserted type XMLS:NODE.
11:51:39
flip214
Xach: yeah. so QL tries to build systems even if any of the dependencies are known broken?
11:52:36
flip214
and re http://lispblog.xach.com/post/169109562413/fasl-package-pitfall: is the right solution a (:depends-on #+project-b :project-b) in the ASDF?
11:57:44
dmiles
but i am doing it backwards in hopes of being able to get paid durring the time of "A LOT of work"
12:58:55
flip214
well, the idea is that if it existed during compilation, it'll do so after reloading the FASLs too
13:16:35
Shinmera
So if you load b, load a, restart, load a, then a contains fasls with b in it, but the asd won't load b.
13:19:14
Shinmera
A "solution" would be to put #+b (ql:quickload :b) into the source files, except that'll give you nasal demons because recursive loading in ASDF is bad juju.
13:23:58
Shinmera
More than weakly-depends-on, you'd need to be able to say that a component only gets loaded/compiled in the presence of a certain system.
13:26:57
jackdaniel
well, I agree there is no good solution for that. If anything, before first use of b putting #+project-b (eval-when (…) (asdf:load-system :project-b))
13:27:43
Xach
jackdaniel: that seems like it would only load project-b when project-b is already loaded?
13:28:17
Shinmera
Xach: The idea of the snippet is to encode the fact that it was compiled with b in the fasl.
13:29:10
Xach
jackdaniel: How does project-b get added to *features*? In my example, it is added by loading project-b.
13:30:39
jackdaniel
Shinmera: if you grok asdf enough you start to understand, that it's nasal deamons even without recursive load (as in – it does what it does)
13:32:08
jackdaniel
actually undefined consequences are always undefined, that was at least claim in the original article
13:42:44
jackdaniel
Xach: fwiw, if you consider loading fasls that way, you may want to put (require 'asdf) before asdf:load-system in this chunk
13:46:12
Shinmera
Xach: Do you have info on which systems conflict with each other? As in, they can't both be loaded in the same instance
14:39:27
scymtym
Xach: are you aware of any progress regarding cxml? i didn't hear back from dlichteblau yet (sent mail mid November, CCed you)
14:50:48
beach
So export takes a designator for a list of symbols. According to the glossary, that excludes a string or a list of strings if I read it correctly. Am I right?
14:57:46
scymtym
beach: assuming you mean the "designator" glossary entry, which part of the entry lets you conclude that?
15:01:57
beach
So if I substitute SYMBOL for OBJECT, I get "a non-nil symbol (denoting a singleton list whose element is that non-nil symbol) or a proper list (denoting itself)".
15:04:55
beach
I guess I am on the right track, because SBCL rejects a string (which would be a symbol DESIGNATOR, but not a symbol, of course).
15:06:25
scymtym
the EXPORT example. i thought it used a string which would become a singleton list containing a string. thus the question
15:08:34
beach
By the way, I found a cute way of checking if something is a proper list. No doubt I am not the first one to do that, but it's simple: (integerp (ignore-error (list-length list)))
15:59:25
beach
KZiemian: I don't know if you have thought about this issue yet: There is a general explanation in the Common Lisp HyperSpec that if a dictionary page mentions an object type, and nothing explicit is said on that page about what happens if the type is violated, then the consequences are undefined (or perhaps unspecified, I don't remember) if it is.
15:59:26
beach
I think many people incorrectly assume that en error will be signaled. It would be worthwhile to remind the reader of such dictionary pages of these consequences. It could be in the form of a link to the general page (with an appropriate text), or a direct statement of what happens if the type is violated.
16:04:34
specbot
The ``Arguments and Values'' Section of a Dictionary Entry: http://www.lispworks.com/reference/HyperSpec/Body/01_ddc.htm
16:04:55
beach
Notice: "Except as explicitly specified otherwise, the consequences are undefined if these type restrictions are violated."
16:06:32
KZiemian
beach: If I had time, I put today some explenation about CLUS current aims and problem
16:11:26
beach
KZiemian: If you want to make a specific note on each entry concerned, I can help you with the text for that. Like, for this one, I would say something like:
16:11:35
beach
Note from the CLUS maintainer: While this page explicitly says that there are no exceptional situations, notice that section 1.4.4.3 implies that, if the lists (all arguments except the last) are not proper lists, the consequences are undefined.
16:13:28
beach
... and if you compile a list of dictionary entries that need to be amended, I can work on such a list, and create specific notes.
16:15:21
KZiemian
beach: When I start to understand direction in which CLUS is going now enough to make this come true I will contact you
16:15:48
KZiemian
beach: now CLUS is for me like a maze, which have one path that I more or less understand
16:27:23
beach
KZiemian: Before you put any of your own notes into the CLUS, you should have them reviewed by some native speakers of English, or possibly by me.
16:31:19
KZiemian
beach: I don't care too much about it too. Yes CLUS is serious matter, I don't dare put notes in it without chacking
16:33:38
beach
I can't be a regular contributor, but certainly if you ask for specific help, I'll help out.
20:38:55
shka
ebrasca: it seems that it is job that single person can handle, but i am no expert whatsoever
21:15:50
pjb
Write documentation like programs. Write down specifications for the documentation, make an analysis, and write the implementation. Test it on real programmers.
21:22:10
pjb
You have a programmer process that needs to take specifications and module documentations as input, and produce code as output. You need to write the documentations. The specification of the documentation is that it provides good data to the programmer process so he's able to produce good code from the specifications.
21:24:44
pjb
it is even possible to write code that will produce correct results when run on buggy and failing processors.
21:27:39
pjb
The lesson here is that programming doesn't involve computers at all. The job of programmers can be applied on any kind of systems, everywhere.
21:31:24
pjb
Of course, there's a tendency to move processes to hardware computers, and the more so when AI increases. But you can do your job with people when you don't have hardware, or when you need more human intelligence (cf. eg. the Mechanical Turk).
22:44:25
pierpa
(NREVERSE (LIST 'YEAR 'NEW (IF (OR (EVENP (NTH-VALUE 5 (GET-DECODED-TIME))) T) 'HAPPY 'SO-SO) 'A 'HAVE))