freenode/lisp - IRC Chatlog
Search
4:26:53
drmeister
Is it fair to return something like "#.(FOO x y)" from print-object if *print-readably* is T?
4:27:11
drmeister
Not x and y of course - arguments that can be evaluated in the top level environment.
4:45:34
drmeister
That's what I'm using it for - internal objects that need to be literals within fasl files.
4:51:10
fiddlerwoaroof
Especially when it doesn't matter whether the object is created at read time or not
4:52:56
elderK
fiddlerwoaroof: That raises a good question. When should you provide specializations for make-load-form and suchlike?
5:14:35
fiddlerwoaroof
I like specializing print-object, because it makes values of a particular easier to understand
5:15:21
fiddlerwoaroof
I've never used make-load-form because I've never run into a situation where adding a new loadable object was the right solution
5:16:28
fiddlerwoaroof
I use #. occasionally in print-object, when the object being printed is not supposed to be mutable
5:16:58
fiddlerwoaroof
e.g. here: https://github.com/tarballs-are-good/coalton/pull/1/commits/034df50ae3380086e5d0901402ceef5371c6ab2f
5:18:41
beach
During SICL bootstrapping, customizing print-object is a must. Otherwise, in phases 3 and 4 all objects (generic functions, classes, slot objects, methods, method combinations) print as <HEADER>. :)
5:20:15
fiddlerwoaroof
even if you use PRINT-UNREADABLE-OBJECT, it makes your classes a lot nicer to use in the repl
5:22:46
beach
SaganMan: No, but making fantastic progress. I finished phase 4, and now I am working on the necessary conditions for being able to "tie the knot", i.e. converting my acyclic graph of objects to a normal-looking cyclic graph as Common Lisp expects.
5:24:00
SaganMan
beach: woah, hasn't it been more than 4weeks since you started working on it? I don't know what kind of difficulties are, I bet it's tough
5:24:49
beach
Yes, I think it is one of the hardest things I have ever attempted. And I am quit serious about that.
5:25:26
beach
The main reason is that it has not been done before, and that involves 4 different versions of every MOP metaobject.
5:26:48
SaganMan
beach: woah so no one has done this before you? that's awesome man, you're breaking the boundaries
5:27:30
beach
Yes, I am totally convinced that nobody has tried to build a Common Lisp system this way. Not even the AMOP suggests such a possibility.
5:27:57
SaganMan
beach: it might be difficult and confusing but after all the ordeal, you'll be master of the domain.
5:28:09
beach
And the paper we are working on that describes this bootstrapping procedure shows that all the examples in the "Living with Circularity" appendix in the AMOP just disappear.
5:29:08
beach
SaganMan: Sure, but the main purpose is that one should be able to modify the source code of even the most basic MOP features, like adding a slot to a metaclass, and then just re-run the bootstrapping procedure.
5:29:51
beach
Plus, by doing it this way, I can skimp on A LOT OF maintenance problems that other systems require.
5:30:39
SaganMan
beach: I don't understand the technical stuff but from what I've worked on programming in past, it's okay if the model/system is crude or ineficient, you will make things better later
5:32:21
beach
SaganMan: Sure. Once I fully understand what I did AND once I am able to describe it fully in written form, I think it will be quite beautiful.
5:34:35
beach
SaganMan: I hope so. We are working on the paper. http://metamodular.com/bootstrapping.pdf
5:34:36
fiddlerwoaroof
I suppose you're also implementing your gf dispatch algorithm as part of this?
5:36:24
beach
We are not yet taking feedback on the paper. The description of the technique is still incomplete.
5:40:36
beach
Also, ELS is not that prestigious a conference. But I am in the luxury position that I don't need a promotion, so I can publish what I think is important and where I want to publish it, as opposed to what others think is important.
5:48:41
beach
SaganMan: Come on! Lisp is not on the radar of any research lab in the world, except possibly EPITA where Didier Verna works.
5:51:09
SaganMan
beach: I believe the research is going in new languages by taking concepts from lisp..
5:52:51
beach
Yes, that's part of the problem. Novelty is funded, even when it is not that novel. But when Lisp is mentioned, no matter how novel some technique is, it is not funded, because Lisp is considered dead.
5:53:07
shka_
i don't think that there is much of language specific research going on in the first place
5:53:15
beach
I guess drmeister has been able to revive it a bit by attaching Lisp to things that do get funded, like building molecules.
5:53:55
shka_
since 90s teached everybody that innovation in languages are mostly ignored by the industry
5:55:42
beach
Anyway, time to go find my (admittedly small) family to have breakfast. And then off to the defense. I'll be back later.
5:56:59
SaganMan
shka_: the problem is that many companies or even programmers just see programming languages as tools for their task. They hardly care about any language in particular.
6:52:44
jackdaniel
pjb: these are two different "operators", lumping them together is bad, because 1) ",X" always produces a form eventually while ",@X doesn't"; 2) it is like assuming the hypothesis you try to prove, my point is that they can't be treated the same
8:57:39
aeth
It's imo good if you want to create something constant and immutable (obviously just by convention) in a macro. I also wrap that object in a defun so you have to call a function to get it.
11:12:12
elderK
Hey guys, another day studying macros and reading papers. Reread Bawden's paper. Studied CLtL2 and CLHS more. Was able to write my own version of the "quasiquote expander" in Appendix C.
11:12:36
elderK
Still, while I can "expand" a nested bunch of quasiquotes, I still can't really look at something like once-only and understand what the heck it's doing.
11:13:29
elderK
I am now reading through parts of On Lisp and ANSI Common Lisp, with hopes of help. Are there any other sources of information that helped any of you learn to like, understand what something like PCL's once-only expands to?
11:15:25
elderK
It's mostly seeing things like ``(,,g ,,n)) that gets me. I've manually expanded that and wind up with (g n), which is... I guess, what you'd expect. Trying things out in the REPL is only so useful, as it results in things I can't really explain :( Like, extra commas appear in the output that I would not have expected.
11:15:29
makomo
elderK: just keep at it is my answer :-). ONCE-ONLY is not an invention of PCL btw. it dates back to at least Norvig's PAIP (but i don't know who the original author of the macro is)
11:16:23
elderK
makomo: :( I don't know what else to do. When I saw collect ``((,,g ,,n)) in the PCL once-only, I was like... whaaaa? So, I went through the process documented in the CLHS - the one you sent linked me to with examples.
11:16:53
elderK
I wound up with a surprisingly huge bunch of appends, lists, etc. Condensing it down, I wound up with (list g n)
11:17:04
makomo
elderK: the double backquotes and commas in ``(,,g ,,n) are there to "force" double evaluation
11:17:46
makomo
(they're not really forcing anything, it's just how the template (and the macro itself) is supposed to work)
11:18:47
makomo
elderK: it'll be hard to see through the logic of ONCE-ONLY once you fully expand the backquotes
11:19:17
makomo
yes, you will end up with something like (list g n), but that doesn't really tell you much
11:19:36
makomo
after the 1st evaluation, somewhere within the output there'll be something like (list <result-of-g> <result-of-n>) most likely
11:20:27
makomo
but still, it isn't really helpful to look at the backquote-expanded version of ONCE-ONLY
11:21:38
makomo
elderK: once you grasp the formal rules, you should use them to derive the evaluation semantics for various "backquote idioms"
11:21:44
elderK
See, even that confuses me. We're doing the expansion of one `, and then what, evaluating?
11:21:57
makomo
or at least to clarify the rules to yourself and iron out any exceptions which you might be unsure about
11:22:33
makomo
elderK: perhaps the pretty printing is confusing you. SBCL's backquote longform is pretty printed by SBCL back into the "backquote syntax"
11:22:56
makomo
their longform consists of the SB-INT:BACKQUOTE macro and a literal structure as an argument
11:23:28
makomo
``(,,a ,,b) gets read by SBCL into some longform and then evaluated (as you typed it at the REPL)
11:23:53
makomo
the evaluation of that returns code which is the longform of the inner backquote template
11:24:39
elderK
Even the long-form has SB:COMMA and stuff. Where as in my manual expansion, I didn't have any commas.
11:25:16
elderK
But what I don't get, is why the values of a and b are being substitued in - but still have commas.
11:25:43
elderK
Probably because I did a full expansion I guess. I'll do some more expansions tomorrow.
11:25:57
makomo
elderK: the longform is implementation-defined. the rules listed in CLHS produce just one out of infinitely many possible longforms
11:26:17
makomo
you should not rely on the expansions being the same as those you get when following the CLHS' rules by hand
11:26:31
makomo
what you should expect though is that the result of k nested backquotes is the same after k evaluations
11:27:01
elderK
Right, so if I evaluate the result of what SBCL gives me for ``(,,a ,,b), it should wind up eqvuialent to whatever my final result is, right?
11:28:29
elderK
So for instance, to get a hold on what PCL's once-only is doing, I would effectively need to expand it fully, by hand.
11:28:57
makomo
SBCL expands into that tricky longform with a literal structure in order to facilitate pretty printing (the other implementations can't really pretty print it once they've fully expanded it)
11:29:27
makomo
(because they emostly expand to a form that's a variation of the one given by CLHS' rules)
11:30:13
makomo
you should definitely take a look at the macroexpansion of ONCE-ONLY, that *will* be helpful
11:31:58
makomo
once you grasp the little pieces, compose them to grasp the bigger thing (without fully bq expanding it)
11:32:11
makomo
but to understand the little pieces, you might have to bq expand them (which is the point of (2))
11:32:40
elderK
Right. So, constructing some "simplified examples" of say, ,, and ,', and ,,@ and such, and BQ expanding them, to get a feel
11:33:24
elderK
Due to implementation like, differences and all, I'll probably wind up doing this either by hand, or by writing another little BQ expander.
11:34:10
makomo
elderK: note that, if you're using SBCL, the pretty-printing behavior of backquote is actually very helpful when reading macroexpansions
11:35:36
elderK
I still don't get exactly what it is doing. To me, it's collecting a bunch of (x y) lists, where x and y are respectively the value-of-the-value of g and n.
11:37:09
elderK
The Bawden paper was unfortunately, not that useful to me. I guess it /has/ however given me a nice list of standard cliches to manually BQ expand and explore.
11:37:54
jackdaniel
shka__: you may scroll the backlog for insight into that. it is not valid common lisp form sadly
11:45:32
elderK
Gotta say, I am thankful that both CLHS and CLtL2 are available online, free to all.
12:36:34
ogamita
jackdaniel: What do we mean by "form"? ` produces a sexp, not necessarily a form in the sense of eval (code). if eg. X is not bound, then ,x will signal an error. Just like if X isbound to a non-list, ,@X can signal an error. This is irrelevant to the rules and their application, that is purely formal (hence the use of the term "form" to designate things that are not necessarily sexps). This is classic in formal systems and rewriting
12:38:10
jackdaniel
form is described in a glossary, I've copied this definition to the org file I've linked yesterday
12:41:05
ogamita
jackdaniel: clearly, ` is unrelated to code. It's a mechanism to build sexps from a template. Therefore any use of the term "form" in that page is unrelated to the glossary definition.
12:42:41
jackdaniel
your "clearly" doesn't make sense to me (and isn't very compelling argument if we talk about specification, I'm not denying it appeals to your intuition though). ,@ works on a form, not on multiple forms (produces multiple forms for splicing informally speaking)
12:43:42
another-user
hi, is there some documentation/guides/blog posts on MOP outside of AMOP, i can't get my hands on the book any time soon, i tried to read MOP section in SBCL manual but it's rather unhelpful
12:45:06
jackdaniel
another-user: metamodular has the gist of it http://metamodular.com/CLOS-MOP/ (two chapters)
12:57:52
ogamita
jackdaniel: ` is unrelated to code. It's a mechanism to build sexps from a template. Therefore any use of the term "form" in that page is unrelated to the glossary definition.
12:58:23
ogamita
(when a demonstration is a simple implication, to me it's a clear demonstration ;-))
13:02:52
ogamita
jackdaniel: that said, I would agree that 1- clhs in general is not formal enough. 2- the rules in 2.4.6 Backquote are not formal rules, despite the formality of the English language used in that section.
13:04:19
ogamita
jackdaniel: and I could agree that either as the rules are stated, or there's an ambiguity in the rules that 3- make ,@,@form invalid.
13:04:59
ogamita
jackdaniel: the question is what do you think, should ,@,@form do what it does in most implementation and what we thing it should be, or should it be invalid?
13:05:24
ogamita
ie. the question is whether we should formalize 2.4.6 to ensure that ,@,@form works, or to ensure that it doesn't?
13:06:50
ogamita
jackdaniel: again about "form", notice that when 2.4.6 speaks of ,form this would prevent form to be eg. (a b ,x c) because as such, this is not a valid form as per the glossary (because of the comma without a backquote!
13:07:27
ogamita
jackdaniel: so if we accepted your argument using the glossary definition of form, this while restrict greatly the possible backquote templates!
13:13:10
jackdaniel
ogamita: I find your assertions unfounded in the specification. I've led my arguments in the org file. Implications you talk about are based on your intuition not on CL standard. My whole point is that conforming program can't depend on ,@,@foo doing recursive splicing.
13:20:16
Xach
Hmm, I find it a little odd to see (error 'some-condition-type-that-is-not-a-subtype-of-error)
13:21:01
Xach
i'm looking at something using error for control flow. but i think it should probably use throw instead. SIGNAL isn't appropriate because control should certainly not continue.
13:22:31
jackdaniel
it is indeed unsettling a little, but function error (specification-wise) has nothing to do with condition error (except that it defaults to simple-error)
13:23:08
Colleen
Bike: drmeister said 7 hours, 37 minutes ago: In aclasp the FORMAT function is implemented in C++ and it doesn't use the printer - so it prints differently from bclasp once FORMAT is installed. different results from bclasp - that's bad for serialization in fasls.
13:26:27
jackdaniel
if you have guarantee that it is handled above, then you may safely use signal, no?
13:27:06
Xach
right. that's my concern. signal could silently continue if there is a mistake in up-stack handling. throw would enter the debugger.
13:27:27
Xach
it really boils down to the friction of seeing ERROR used in that type of control flow
13:27:47
Bike
if the "throw" and the "catch" are in different functions i think i'd use ERROR anyway, and make the condition an error subclass, just so that if i accidentally called the throwing function by itself i'd get a coherent debugger entry
13:28:09
jackdaniel
I'd vote for error, because it does everything you expect from it, but throw should be fine too
13:29:59
Xach
(defun decline-to-handle () (signal 'declined) (error "Hey, you didn't handle the signal, dummy!"))))
13:44:25
ogamita
I would have said signal, but if it must not continue (and signal can not return anyways), perhaps defining a specific function for this kind of flow control would be indicated.
13:44:47
jackdaniel
when I do (error (make-condition 'warning)) debugger doesn't say anything about error, it is simply invoked, so from the user perspective it isn't a big deal to see this
13:51:42
_death
the error (assuming it's not a string) gives another hook, but indeed you can use BREAK (like ERROR) if you don't want that hook
14:48:22
pfdietz
SBCL changed that at one point and broke a lot of code that was making that assumption.
14:56:48
jackdaniel
I think you may log in with other oath providers as well, but to make sure you need to ask on #common-lisp.net
14:57:41
dlowe
totp is a standard 2fa method - there's other apps/devices than google auth that support it
15:20:02
jcowan
makomo: ONCE-ONLY is not in the Maclisp manual, but it is in the Chine Nual and in Genera, so it was introduce some time in the history of Lisp Machine Lisp.
15:52:19
dim
hi guys! Xach if you're around, I think https://pastebin.com/TjdsKfJh falls in your area, thanks to being buildapp related
16:21:04
makomo
jcowan: wow, amazing!, thanks for the info. (at first i thought Chine Nual was a typo btw, first time i heard of it :-))