freenode/#sicl - IRC Chatlog
Search
6:37:55
beach
Yesterday, I got rid of the function-cell-finder function and I store function cells in the static environment of the top-level function instead. The idea is to define the code object so that it contains not only a top-level function to execute in order to "tie" the code to some first-class global environment, but also a list of constants and a list of function names used by the code. Before the top-level function is called, the
6:37:55
beach
function names are converted to function cells, and the constants and the function cells become part of the static environment of that top-level function.
6:38:58
beach
Once that is done, I need to start looking at the referee reports for my papers and incorporate the remarks.
8:53:32
heisig
In case anyone is missing social interaction during the curfew, I set up a Jitsi server at chat.heisig.xyz
11:01:49
beach
heisig: I think I'll pass. I don't even have a webcam or a microphone connected to my desktop, and I taped over the camera on my laptop, just to annoy anyone trying to turn it on from outside.
11:26:51
heisig
beach: Sure, it was just an offer. I hope you succeeded in your main mission for today.
12:35:09
Bike
i have a local setup where cleavir saves function names, docstrings, and lambda-lists for functions (names only for flet and labels)
12:35:25
Bike
they're just carried forward unexamined to HIR, where the translator can use them if it wants to. does that sound reasonable?
13:09:50
Bike
guess i could add a little client-specializable generic function to determine what exactly the names should be
13:29:30
beach
Bike: I don't know what needs SICL is going to have in that respect. My (untested) plan is to use source-tracking information in the backtrace, so that keeping names around is not going to be needed. But I may regret that tentative plan depending on how it works out in practice.
13:30:36
beach
Bike: On the other hand, it can't hurt to have that information. As you pointed out, client code can do what it wants with it.
13:30:50
Bike
for the docstring and lambda list too? i guess it's not much parsing to do or anything
13:32:03
beach
I'm not sure what I will need or use at this point. The idea of using source tracking was that it would then be independent of various transformations.
13:33:23
beach
Like, instead of showing function names in the backtrace, it would probably show the calling form instead, as a string in source code.
13:34:54
Bike
well, in clasp at least, it's not just backtraces, it lets functions print as #<FUNCTION FOO> or whatever. and lambda lists are for the slime minibuffer, and i assume you'll have something like t hat in your editor. of course you can do both of those with the source tracking still.
13:36:30
beach
The lambda list would probably have to be kept in some parsed form so that completion and such would work.
13:37:53
Bike
You could just use the parsed object CST gives you, no? But what completion do you mean?
13:37:56
beach
I am not sure about the printed form of functions. I would have to think about the situations where the user would look at such objects.
13:38:44
beach
Yes, the CST would work. I guess I just meant something that shows where in the lambda list the user is about to supply an argument.
13:41:20
Bike
for printed form... mostly just the repl i would think. functions aren't externalizable so it's pretty much only for human consumption
13:43:47
beach
Right. And I am not yet sure about the way I would want to work in the REPL. I am convinced it will be inside the debugger most of the time and I need to start working like that to see what I need.
13:47:25
Bike
well, i can tell you from experience that if nothing else, having something meaningless like #<FUNCTION LAMBDA> gets frustrating quickly
13:48:18
beach
But say you can put the mouse over it, and have the entire source code displayed in the source window.
13:49:47
Bike
well, i'm doing this in cleavir/ anyway, i'll just make the information available and we'll see where things go
13:54:01
beach
I think that working with our current tools is extremely frustrating when the slightest thing goes wrong. I also think that what I am good at is to refuse to accept this state of things. But right now, I don't see how to improve the current tools because they depend on technology that I can't see myself working on, like communication between Emacs and the Common Lisp implementation.
13:54:39
beach
So what I need is a set of pure Common Lisp tools for which I can dream up new ways of interaction.
13:54:46
Bike
it's true, stuff like having to be able to send objects over the wire rather than just working with them directly seems inhibiting
16:06:19
alandipert
heisig just tried jitsi, looks great, looking forward to participating in future meetings
16:12:30
alandipert
well, the technology looked great, through my webcam i looked especially unkempt and not great :-)
16:15:38
heisig
I think the meetings will happen more or less at random, whenever someone calls for it.
16:20:09
Bike
ok, next is part two: gonna have enter instructions store some kind of information about declarations for variables in the lambda list