<ixelp>
GitHub - byulparan/common-cv: The OpenCV binding library for CommonLisp
<Pixel_Outlaw>
I got it installed and OpenCV running but it seems to just kick off processes and not attach to any webcam.
tyson2 has quit [Remote host closed the connection]
lucerne has quit [Quit: Ping timeout (120 seconds)]
lucerne has joined #commonlisp
habamax has quit [Ping timeout: 240 seconds]
Pixel_Outlaw has quit [Remote host closed the connection]
donleo has quit [Ping timeout: 258 seconds]
habamax has joined #commonlisp
Pixel_Outlaw has joined #commonlisp
bilegeek_ has joined #commonlisp
bilegeek has quit [Ping timeout: 258 seconds]
habamax has quit [Ping timeout: 252 seconds]
dcb has quit [Quit: MSN Messenger 4.0.5]
habamax has joined #commonlisp
msavoritias has joined #commonlisp
pve has joined #commonlisp
habamax has quit [Remote host closed the connection]
habamax has joined #commonlisp
wonko-the-sane has joined #commonlisp
amb007 has quit [Ping timeout: 258 seconds]
amb007 has joined #commonlisp
Gleefre has quit [Remote host closed the connection]
Gleefre has joined #commonlisp
pranavats has left #commonlisp [Error from remote client]
rgherdt has joined #commonlisp
simendsjo has joined #commonlisp
Pixel_Outlaw has quit [Remote host closed the connection]
_cymew_ has joined #commonlisp
igemnace has joined #commonlisp
azimut has quit [Ping timeout: 252 seconds]
Cymew has joined #commonlisp
Cymew has quit [Remote host closed the connection]
Cymew has joined #commonlisp
shka has joined #commonlisp
zaymington has joined #commonlisp
mgl has joined #commonlisp
zaymington has quit [Remote host closed the connection]
zaymington has joined #commonlisp
Pirx has joined #commonlisp
kstuart has joined #commonlisp
<Pirx>
good morning
wonko-the-sane has quit [Ping timeout: 252 seconds]
Cymew has quit [Quit: Konversation terminated!]
Cymew has joined #commonlisp
dinomug has quit [Remote host closed the connection]
bendersteed has joined #commonlisp
attila_lendvai has joined #commonlisp
wonko-the-sane has joined #commonlisp
zaymington has quit [Ping timeout: 245 seconds]
pve has quit [Ping timeout: 260 seconds]
pve has joined #commonlisp
notzmv has joined #commonlisp
donleo has joined #commonlisp
bilegeek__ has joined #commonlisp
bilegeek_ has quit [Ping timeout: 260 seconds]
liminality has joined #commonlisp
wonko-the-sane has quit [Quit: leaving]
LW has joined #commonlisp
LW has quit [Client Quit]
shka has quit [Read error: Connection reset by peer]
pve has quit [Ping timeout: 252 seconds]
shka has joined #commonlisp
pve has joined #commonlisp
dino_tutter has joined #commonlisp
morganw has joined #commonlisp
danse-nr3 has joined #commonlisp
Lord_of_Life has quit [Ping timeout: 264 seconds]
morganw` has joined #commonlisp
morganw has quit [Read error: Connection reset by peer]
bilegeek__ has quit [Quit: Leaving]
anticrisis has quit [Read error: Connection reset by peer]
Lord_of_Life has joined #commonlisp
zaymington has joined #commonlisp
limiduality has joined #commonlisp
liminality has quit [Ping timeout: 255 seconds]
rgherdt_ has joined #commonlisp
rgherdt has quit [Ping timeout: 258 seconds]
alphacentauri has joined #commonlisp
notzmv has quit [Ping timeout: 240 seconds]
attila_lendvai has quit [Ping timeout: 245 seconds]
notzmv has joined #commonlisp
yitzi has joined #commonlisp
<Gleefre>
*symbols* are a namespace with strings as names; *packages* are a namespace of environments of the *symbol* namespace.
<Gleefre>
*readtable* is a namespace with characters as names mapping into the reader functions. *named-readtables* are a namespace of environments in *readtable* namespace :o
<Gleefre>
[talking about mit loop implementation] LOOP could be seen as a very special read function, where *loop-universe* is a "readtable"
<Gleefre>
That could make for a nice :named-readtables like expansion mechanism for the loop
thollief has joined #commonlisp
<bike>
readtables have more than reader macros. and i don't think loop being a reader makes much sense.
danse-nr3 has quit [Ping timeout: 272 seconds]
alphacentauri has quit [Ping timeout: 255 seconds]
<Gleefre>
Well...
<Gleefre>
Loop is implemented by incrementaly parsing the body as a symbol stream
<Gleefre>
Or rather stream of forms, not symbols
<Gleefre>
[ again - talking about implementations base on MIT loop ]
<Gleefre>
When it "reads" next keyword it calls a corresponding loop expander function
<Gleefre>
(Or rather when it "peeks" next keyword)
<Gleefre>
Which is very similar to READ - when it "peeks" a character, it then calls the corresponding reader-macros when one is available
alphacentauri has joined #commonlisp
<bike>
a lookahead parser does not a reader make
<Gleefre>
The difference between "loop expanders" and reader macros is that reader macro doesn't have access to the form being read, and it just returns the value it read; but loop expanders modify the resulting form currently being constructed
<Gleefre>
Ok, sure, LOOP is not implemented like READ, but rather like a more general thing
<Gleefre>
"lookahead parser"
<bike>
i mean the broader thing that you could have a namespace of loop keywords is true.
<Gleefre>
I'm not very experienced, especially in the field of parsers - so a lot I don't know
random-nick has joined #commonlisp
zaymington has quit [Remote host closed the connection]
zaymington has joined #commonlisp
<Gleefre>
I don't understand one thing about namespaces yet though
<Gleefre>
And that is functional namespace
<doulos05>
Does anybody here use the cl-cairo2 bindings?
waleee has joined #commonlisp
<Gleefre>
For some reason functional namespace in CL is very different from others. Probably in part due to the specific evaluation rules.
<Gleefre>
And it seems to allow something more profound than simple namespace can do
<bike>
i don't think it's that complicated?
<bike>
cl:function lets you either look up a name or have a lambda expression.
<Gleefre>
I mean, in itself it probably is not, but I can seem to fit it into my view of the world
<Gleefre>
MACROLET's analogue for symbols would be SYMBOL-MACROLET, yet it is very different
<Gleefre>
Hm, I think it is also different also because of the very different way to interact with objects in functional namespace - calling them. And when you "call" macros unusual stuff happens instead.
<Gleefre>
Now that I think about it... variables are a secondary namespace, functions are much more important
<bike>
i don't know what that means. also if you're just talking about them as namespaces, how the values are used is sort of unrelated
<Gleefre>
Ok, I was wrong too, variables are super important as well.
<Gleefre>
And I think the way you use values in the namespace is important
<Gleefre>
There is something strange going on between macros & functions
<Gleefre>
You can't bind them in the same manner (FLET vs MACROLET), you can't get the "local definition" in the same manner (FUNCTION vs MACRO-FUNCTION + &env), but then you can get global definition with `fdefinition`
<Gleefre>
And then the usage - calling - is really an unusual concept, so to say
<Gleefre>
And special operators make things even more complicated
alphacentauri has quit [Quit: WeeChat 4.0.5]
habamax has quit [Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.1.50)]
<bike>
that kind of comes down to how compilation works. during compilation you have a compiler environment that has macro functions, and notes the _existence_ of local functions without actually including their functions. at runtime there is implicitly an environment but unlike the compilation environment it doesn't have to actually exist as an accessible object. and it doesn't contain local macro functions at
<bike>
all
<bike>
macros get the first kind of environment as a parameter
<bike>
so the treatment of the environment is more complicated than being an association list.
<bike>
and the semantics also have to accomodate and interpreter type implementation where both environments exist as the same object.
<bike>
an interpreter
liminality has joined #commonlisp
limiduality has quit [Ping timeout: 240 seconds]
<Gleefre>
I
semarie has quit [Quit: WeeChat 4.0.4]
semarie has joined #commonlisp
<Gleefre>
*I'd say that MACROLET and SYMBOL-MACROLET are almost entirely different, which confuses me
<bike>
they do pretty different things, of course
<Gleefre>
MACROLET allows to manipulate code at compile time... And SYMBOL-MACROLET is more of a... binding with semantics of substitution - aka variables without an underlying place
<bike>
well, you can think of symbol-macrolet as binding a very simple macro function that takes no arguments and always returns the same expansion.
rgherdt__ has joined #commonlisp
<bike>
...in the variable namespace.
<Gleefre>
I can, but it is not truly what it is
<Gleefre>
Because no real function is included in fact
<Gleefre>
It's... just substitution
<Gleefre>
But local macro is a *function* that *exists* and can be *called* at compile-time, and then disappears
<bike>
there actually does have to be a function at some point because the expansion goes through *macroexpand-hook*.
<Gleefre>
Wait, really?
<bike>
yep. i have implemented symbol-macrolet several times
<bike>
you can't get at the expander function directly, but you can use it through macroexpand(-1)
<bike>
ooh, lookin nice shinmera
<Shinmera>
thanks :)
tyson2 has joined #commonlisp
<Gleefre>
I can't seem to find anything about *macroexpand-hook* at the symbol-macrolet clhs page :/
<bike>
check the page for macroexpand
<bike>
"Macro expansion is carried out as follows. Once macroexpand-1 has determined that the form is a macro form, it obtains an appropriate expansion function for the macro or symbol macro. The value of *macroexpand-hook* is coerced to a function and then called as a function of three arguments: the expansion function, the form, and the env."
<Gleefre>
Shinmera: Wow, so cool!
rgherdt_ has quit [Ping timeout: 240 seconds]
<bike>
the symbol macro expansion/der also "disappears" after compilation
<Gleefre>
I see... Ok, that's becoming a bit more complicated :/
<Gleefre>
I suppose that a ns-macrolet for user-defined namespace should call *macroexpand-hook* as well then. What do you think?
alphacentauri has joined #commonlisp
<Gleefre>
Although it is not really clear what should I call it on in this case... Hm
<bike>
i think that depends on the nature of the namespace. for example, types are a namespace, and deftype essentially defines a macro, but the expansion does not go through macroexpand hook.
rtypo has quit [Ping timeout: 255 seconds]
<bike>
symbol macros and functional macros both go through macroexpand-hook because they work on forms, not because they are both macros.
<Gleefre>
I must say I don't really understand the purpose of *macroexpand-hook* now
<Shinmera>
Obviously it's so that quicklisp can add its dots progress bar :)
varjag has joined #commonlisp
<bike>
could there be a nobler purpose? i doubt it
<Gleefre>
Well, then I suppose there is no need to call it from user-defined namespace's-macrolet
<bike>
macroexpand-hook is the only surviving member of a family of earlier hook functions like applyhook and evalhook, which were removed from the standard for making optimization impossible. macroexpand-hook only runs at compile time so it doesn't have that disadvantage
karlosz has joined #commonlisp
<Gleefre>
I still want to add something like macrolet to the user-defined namespaces, but don't understand how would that work
waleee has quit [Quit: WeeChat 4.0.2]
<Gleefre>
Analogue for symbol-macrolet is easy - it needs to substiture (<accessor> <unevaluated-name>) with the expansion form, and is not hard to do (because of macrolet existing). let is similar - it needs to generate underlying variables and to ns-macrolet them. But I can't seem to understand how macrolet would work :/ Is it even possible?
<Shinmera>
applyhook, oof
<bike>
you can use the symbol-macrolet trick i showed you to establish queryable "bindings" of names to expansion functions.
danse-nr3 has joined #commonlisp
<Gleefre>
Yeah, although I'm using my TMLET trick instead
waleee has joined #commonlisp
<Gleefre>
Hm, one "extension" to ns-symbol-macrolet would be to define a macro to be "called" on possible arguments to the <accessor>, so that (get X) and (get x :errorp nil) would result in different expansions.
karlosz has quit [Quit: karlosz]
<Gleefre>
But now that I think of it, MACROLET in fact [mainly] modifies the behaviour not of the accessor - FUNCTION - but of the "operator" - "CALL"
alphacentauri has quit [Ping timeout: 255 seconds]
<bike>
i think you may be adrift in a sea of invented abstractions
<Gleefre>
Kind of am
<Gleefre>
But I want to understand why functional namespace is so different from user-defined ones
<bike>
there is no call operator. macros are part of the basic evaluation semantics. and i see no reason that, for example, you couldn't define your own eval-like function, that operates in some user namespaces rather than the standard function and variable namespaces. in that case the user defined namespace wouldn't be particularly different.
igemnace has quit [Read error: Connection reset by peer]
<Gleefre>
Sure, there is no call operator in CL standard
<Gleefre>
What I want to be able to do is to unify special operators, functions and macros
<bike>
i mean. they're different things.
<Gleefre>
And not with EVAL, which has its own meaning - turns data into the code to be executed at runtime
<Gleefre>
bike: but they all are stored in the same namespace!
<Gleefre>
I think you can say that CALL is a generalisation of APPLY
<bike>
so what? their different natures only mean anything in the context of evaluation semantics.
<bike>
the namespace itself is just a mapping of names to things. the things may be interpreted differently by a function like eval but that's not the namespace's problem.
liminality has quit [Ping timeout: 240 seconds]
<Gleefre>
Yes, but if they are stored in the same namespace, that must mean something. I think my "CALL model" kind of explains it
waleee has quit [Ping timeout: 258 seconds]
<Gleefre>
Or does it?.. Ok, I'm lost again
<bike>
it doesn't. macros certainly don't "modify the behavior of the operator". they are part of the behavior of the operator. the evaluation semantics clearly define what is done with a cons and what to do when the car names a macro is laid out right there.
<Gleefre>
But there are a lot of rules there, which I don't like so to say
<bike>
from the perspective of your namespacing library, what you can maybe do is define namespaces to be accessible one way in the compilation environment (like macro-function) and another way in the runtime environment (like function) and what is done with that is not your problem.
<Gleefre>
Ok, that sounds interesting
<Gleefre>
I don't quite understand it though
<Gleefre>
The macro-function's problem is the environment argument...
<bike>
how is that a problem?
<bike>
here's a name, here's a table to look it up in. bam
<Gleefre>
Where that table would come from?
<Gleefre>
So another operator to "fetch" it
<yitzi>
Sounds like an implementation detail. :)
<bike>
the table is part of the environment. in your case you'd smuggle it in with tmlet or symbol-macrolet or something.
<Gleefre>
No, thats more of an API question
<bike>
macro-function is the api.
<bike>
anything below that is an implementation detail
<Gleefre>
As well as its ENV argument
<Gleefre>
And macro-function is only to be executed at compile time if you think about it
<Gleefre>
+ toplevel
<bike>
you can definitely use macro-function on non toplevel environments.
alphacentauri has joined #commonlisp
<bike>
it's perfectly well defined and occasionally useful.
<Gleefre>
Yes, but then you use it at compile time
<bike>
sure.
<Gleefre>
Now how do I get into the compile time the question is
<Gleefre>
MACROLET seems to be the only way
<bike>
tmlet or symbol-macrolet.
<Gleefre>
symbol-macrolet doesn't provide "hook" into the compile time
<Gleefre>
It is more of a substitution "engine"
liminality has joined #commonlisp
<bike>
sure it does. you can stick whatever information into your symbol, and then macroexpand it wherever. presto, you have your own namespace smuggled into the environment.
<bike>
you're literally already doing this for your existing code (with tmlet, but the principle is identical), so i don't understand what problem you're having
<Gleefre>
Ok, but that involves macroexpand which is kind of scary :/
<Gleefre>
I'm having a problem with understanding what should the API be and what should it do
<bike>
look. you wrote that tmlet monstrosity. being scared of macroexpand is frankly kind of silly after that.
<Gleefre>
Yeah, it is. But macroexpand does too much I'd say..
<Gleefre>
Ok, macroexpand works on NS-MACROLET too :o
<bike>
(defmacro xmacrolet (bindings &body body &environment env) ... `(symbol-macrolet ((%xmacros (list (cons ,name1 ,macro-value-1) ... (macroexpand-1 %xmacros env)))) ,@body)) and then (defun xmacro-function (name &optional env) (cdr (assoc name (macroexpand-1 '%xmacros env))))
<bike>
with some more complications if you want to include runtime "functions" in addition to the compile time "macros"
igemnace has joined #commonlisp
<Gleefre>
I think I'm starting to understand it...
<Gleefre>
Now need to do a bit more thinking and experimenting
<Gleefre>
Thanks :)
yitzi has quit [Remote host closed the connection]
alphacentauri has quit [Quit: WeeChat 4.0.5]
karlosz has joined #commonlisp
karlosz has quit [Quit: karlosz]
mgl has quit [Ping timeout: 245 seconds]
karlosz has joined #commonlisp
<phantomics>
When you have a file open to overwrite, is it possible to truncate the file, cutting it down to a particular byte length? In my application I want to keep the first part of a file, overwrite part in the middle and then remove the rest
waleee has joined #commonlisp
alphacentauri has joined #commonlisp
amb007 has quit [Ping timeout: 255 seconds]
karlosz has quit [Quit: karlosz]
karlosz has joined #commonlisp
karlosz has quit [Client Quit]
<jdz>
phantomics: You sure can use FILE-POSITION to set the position in the file, but for removing the rest you'll have to use unix/posix/implementation internal things to call ftruncate on the file descriptor associated with the stream.
<jdz>
At least I don't see anything in the spec which would allow to do this portably.
<phantomics>
Thanks, that's the impression I got
<phantomics>
Where it gets a bit complicated is writing unicode where character counts and file posiitons don't align
<jdz>
At which point you might consider writing a new file altogether.
amb007 has joined #commonlisp
<phantomics>
Yeah. that's how I'll approach it, read parts of the file into (unsigned-byte 8) arrays and then write a new file
<edgar-rft>
I'd write the parts you want to keep into a new file, then delete the old file and rename the new file to the name of the old file. That's what most file system operations would do under the hood anyway.
<phantomics>
Yeah, I'm overwriting the original with :supersede
varjag has quit [Quit: ERC (IRC client for Emacs 27.1)]
<phantomics>
Here's another annoyance: I can't read and write both text and bytes to and from the file
<phantomics>
I want to write a Lisp form into the output stream, but to know the location I have to go by file-position
<phantomics>
But file-position is counted in bytes so many Unicode characters cause it to not align
<phantomics>
So I know the file positions that start and end the place I want to overwrite with a Lisp form, but I can't read/write to a string by file position
notzmv has quit [Ping timeout: 240 seconds]
tibfulv_ has joined #commonlisp
tibfulv has quit [Ping timeout: 255 seconds]
<edgar-rft>
The variable byte number of UTF-8 characters is a known problem. Edi Weitz had written lots of stuff for it. I remember CL-UNICODE and FLEXI-STREAMS that can switch from character to byte encoding back and forth in the middle of the stream and other things.
<edgar-rft>
I know that SBCL also has implementation-specific stuff for Unicode characters and probably other CL implementations, too. Stupidly the last time that I had Unicode problems is long ago and I've forgotten lots of details.
<ixelp>
Common Lisp Libraries by Edi Weitz | A community project to maintain and improve libraries developed originally by Edi W [...]
<phantomics>
Thanks, I'll look into that
bjorkintosh has quit [Quit: Leaving]
bjorkintosh has joined #commonlisp
bjorkintosh has quit [Changing host]
bjorkintosh has joined #commonlisp
jrm has quit [Ping timeout: 258 seconds]
easye has quit [Ping timeout: 240 seconds]
<Gleefre>
Is there some way to define a local macro that is also a closure?
seok has joined #commonlisp
<beach>
Well, macros don't have access to the run-time environment since they are expanded at compile time.
alphacentauri has quit [Ping timeout: 255 seconds]
<Gleefre>
Yes, but can such compile-time function be a closure?
<Gleefre>
Seems like I want to get compile-time execution outside of macroexpansion
<Gleefre>
Maybe load-time-value will help me? Dunno
<bike>
a closure over what?
<Gleefre>
A variable created at compile-time...
easye has joined #commonlisp
<bike>
like how? what does that mean? not symbol-macrolet. what is the context? what is this for?
<Gleefre>
I want to get compile-time bindings
<Gleefre>
For that I figured I want to have a macro-accessor [ maybe only getter ] like (compile-time-var x)
<Gleefre>
And that macro is made by a macrolet (well, tmlet), that uses case to check if it is one of binded variables
<Gleefre>
And if yes, it should return compile time binding. But that binding also should be evaluated
<Gleefre>
So far it gets evaluated each time the getter/accessor is called :/
<Gleefre>
So more like symbol-macrolet
rgherdt__ has quit [Ping timeout: 240 seconds]
alphacentauri has joined #commonlisp
<Gleefre>
On sbcl I'm pretty sure that instead of value form inserting (sb-ext::eval-in-lexenv value-form env) will do the job, but I'm interested if it is possible to do so portably...
rgherdt has joined #commonlisp
yitzi has joined #commonlisp
bike_ has joined #commonlisp
<bike>
what does "compile-time bindings" mean. practically speaking.
<bike>
like what does it mean that the binding "also should be evaluated". at runtime?
bike has quit [Quit: Reconnecting]
<bike>
if you want to put your own information in compilation environments i've described how to do that with symbol-macrolet like three times now.
<bike_>
what does "compile-time bindings" mean. practically speaking. like what does it mean that the binding "also should be evaluated". at runtime?
<bike_>
if you want to put your own information in compilation environments i've described how to do that with symbol-macrolet like three times now.
<bike_>
stupid lag
bike_ is now known as bike
morganw` has quit [Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.1)]
<bike>
a macro that expands into nested backquotes in a macrolet is not a very comprehensible explanation
<bike>
i meant like, say what you are doing, in natural language
<Gleefre>
Sorry for that :/ I don't really have a usage example.
waleee has quit [Ping timeout: 255 seconds]
<bike>
that's a big problem, as far as i'm concerned
<Gleefre>
I mean, I want to use it in another macro
<bike>
okay, that would be a usage example, then.
<Gleefre>
I'll try to make a smaller one, one second
<bike>
it will really probably be easier if you can just explain what you want it to do.
<Gleefre>
I mean, I'm still trying to make analogue of macrolet in user-defined namespaces
<Gleefre>
*an analogue
<Gleefre>
So I'm writing a macro that will create a compile-time binding. The problem is that I don't see a way to "force" the value to be evaluated during macroexpansion
<bike>
i don't know what you mean by evaluated during macroexpansion. macrolet does not really "evaluate anything during macroexpansion", does it? it makes a macro function and a binding for it.
<Gleefre>
Yes, but the macro function is a function object
<Gleefre>
It is not a "lambda to be evaluated each time"
<bike>
sure. the function is produced at compile time. not during macroexpansion. and making a function at compile time is more specific than evaluating an arbitrary form at compile time.
<bike>
in CLTL2 there was a function called "enclose" for implementing macrolet. you'd give it a lambda expression and a compilation environment, and it would return an actual function. there was nothing for evaluating an arbitrary form in a compilation environment.
<Gleefre>
That's kind of sad :/
<bike>
it would get confusing. if you have (flet ((foo ...)) (compile-time-let ((x (foo))) ...)) what happens? it's already kind of confusing with macrolet.
<Gleefre>
Well, that would be an error
<bike>
right, but i mean it entails an entirely new evaluation mechanism where that kind of thing is an error
Gleefre has quit [Remote host closed the connection]
Gleefre has joined #commonlisp
<Gleefre>
Ok, I'm confused. Mine "ctlet" actually evauluates it :/
<Gleefre>
I should not use eval-in-lexenv I guess, as it is an internal function, so it doesn't necesseraly check some things (probably)
<Gleefre>
[ and it evaluated it because I defined a constant function (foo () 10) which it probably "forced" as a constant one ]
<Gleefre>
But the fact that it should error is not a new evaluation mechanism
<Gleefre>
#'foo errors when foo is defined as a local macro
<Gleefre>
[ well, maybe it is new.. But not too new I think. ]
<bike>
it's not part of standard semantics. macrolet makes it undefined.
<Gleefre>
Does it? Sbcl says "Compile-time error: found macro name FOO as the argument to FUNCTION"
<bike>
sbcl defines it as an error, yes
<bike>
well, no, that's actually different
<bike>
it says FOO was a macro name? even though it was defined by flet?
<Gleefre>
Yes
<Gleefre>
Also... ECL doesn't error there :o
<bike>
okay, so sbcl signals an error with a slightly dumb message, ecl does whatever. both in the remit of "undefined"
<Gleefre>
Ok, is that valid? (macrolet ((foo ())))
<Gleefre>
CMUCL says "Local macro FOO is too short to be a legal definition." :/
<bike>
that's valid
jrm has joined #commonlisp
Cymew has quit [Ping timeout: 252 seconds]
<phantomics>
I got the file write working, it takes multiple stages of reading/writing as text and binary, didn't need any libraries
<Gleefre>
Seems like almost all of them report the same error as sbcl, ECL/ABCL just return the function, CLISP says its undefined
<Gleefre>
Weirdly, hyperspec says: "The value of function is the functional value of name in the current lexical environment." "If name is a function name, the functional definition of that name is that established by the innermost lexically enclosing flet, labels, or macrolet form, if there is one." [ note the macrolet ]
<Gleefre>
And then it goes "Specifically, it is an error to use function on a symbol that denotes a macro"
<Gleefre>
And finally it says "Exceptional Situations: None. "
<Gleefre>
Ah, here it goes: "An implementation may choose not to signal this error for performance reasons, but implementations are forbidden from defining the failure to signal an error as a useful behavior. "
<Gleefre>
One thing I'm thinking about right now is if it is possible to disallow usage of compile-time bindings at run-time
alphacentauri has joined #commonlisp
yitzi has quit [Remote host closed the connection]
<bike>
good lord.
<bike>
i was going to say letting the bindings be accessible at runtime seems harmless, but not if they're setfable. i don't even understand what that would mean.
<Gleefre>
That would result in various weirdness
mgl has quit [Ping timeout: 255 seconds]
<Gleefre>
I already made it a bit less weird by using embedded function
<Gleefre>
*functions
<Gleefre>
That make it impossible to compile [usage of compile-time variables at run-time] using compile-file
<Gleefre>
*that makes...
<bike>
if it's a constant (or at least computed at compile time), it makes enough sense semantically at both runtime and compile time, i think. it's just a LET that you're allowed to access within macrolet bodies
<bike>
but that stops making any sense if you can mutate it, since macros are expanded basically whenever
seok has quit [Quit: Client closed]
seok has joined #commonlisp
<bike>
really, the fact macros can be expanded ever makes use of it as a place seem pretty fraught
<bike>
like in your example at the end, bar can legally return any nonnegative integer
<bike>
i guess it can't return 0, but other than that
<bike>
can be expanded whenever*
<Gleefre>
Yeah
<Gleefre>
But - it will return exact amount of times it was expanded :o
<bike>
that number is immediately invalid, but yes
<bike>
(as in, the macro could be expanded again after your call)
<Gleefre>
Well, next time it will be expanded it will be technically another macro
<bike>
what is this for?
<White_Flame>
if you reload from a fasl, often the compile-time bindings won't be available anymore
morganw has quit [Remote host closed the connection]
<White_Flame>
I don't think that's guaranteed, though
<Gleefre>
bike: I don't know, just for fun
<Gleefre>
This exact case, that is
tibfulv has quit [Remote host closed the connection]
<Gleefre>
White_Flame: what do you mean by compile-time bindings?..
<White_Flame>
toplevel ones, looking at your code i guess you're dealing with lexical?
<bike>
well if you ever do find a use, let me know so i can find a bunker
<Gleefre>
Yes, I wrote compile-time-let, and it works only for lexical compile-time bindings
tibfulv has joined #commonlisp
<Gleefre>
bike: you mean setfable compile-time bindings or just compile-time bindings?
<bike>
more the first one
<bike>
though the fact that it works just like lexical variables makes it seem less practically useful to me
<White_Flame>
I had an issue where I was building up a hashtable at compile-time, where all the macroexpansion sites write into a hashtable, then that table was accessed at runtime. It only worked when you both compiled & loaded in the same image :-P
<Gleefre>
In any case I feel like that might happen soon or never
<bike>
compared to something that accepts an environment like macro-function
<Gleefre>
bike: It allows you to write all kind of stuff, where you expand a macro into a compile-time-let
<bike>
because with that you can do something like toplevel (defmacro whatever ... (if (compile-time-variable 'whatever-behavior) do-something do-something-else)) and then you can control the behavior of WHATEVER in a given scope with (compile-time-let ((whatever-behavior t)) ...)
<Gleefre>
And it removes complexity of the &environemnt object you need to call macro-function
<bike>
(compile-time-variable 'whatever-behavior env) i mean
<bike>
the complexity is there for a reason
<jcowan>
Gleefre: Based on your stated interests, you might want to look into the Kernel language, a Lisp dialect in which the unifications you are describing are already part of it.
<bike>
yeah, kernel's neat
<bike>
simpler semantics in this case since there's no compiler or macros
<bike>
i've thought a bit about macrolet or compile-time-let in it but didn't do anything with it
LispTyro has joined #commonlisp
<Gleefre>
jcowan: Um... I mean, maybe? But I put myself a goal to grok CL, so don't really want to get distracted.
<Gleefre>
That being said, I rather mean that I almost surely won't write programs in it, but just looking at the language seems interesting
<jcowan>
In that case you should work directly on learning CL as it is and not get distracted by "How could it maybe do this or that?"
<jcowan>
The right place for that is #clschool.
<Gleefre>
I mean, I *think* I known enough CL to say I know it.
<Gleefre>
But I want to *grok* it
<jcowan>
You seem to have a lot of fairly elementary confusios.
<Gleefre>
Do I?
thollief has quit [Quit: Leaving]
<Gleefre>
[ I'm learning CL for 3+ years already, and am doing quite well I think ]
<Gleefre>
I mean, if you can tell me where I'm confusing stuff, I'd love to hear that - and to learn what's wrong and what's true in reality
<jcowan>
I'm learning it for 30 years now, and I know how much I don't know.
<Gleefre>
I know that I don't know a lot of stuff yet, but I also know that I know a lot of it already. :I
<Gleefre>
That being said, I also don't know a lot of stuff about programming in general, I guess :/
alphacentauri has quit [Quit: WeeChat 4.0.5]
alphacentauri has joined #commonlisp
pve has quit [Quit: leaving]
Pirx has quit [Ping timeout: 252 seconds]
mgl has joined #commonlisp
<bike>
Gleefre: i mean if you can write all this arcana you certainly know something about the language, but also said arcana isn't really necessary for any practical program i'm aware of
<LispTyro>
what is arcana?
<jcowan>
LispTyro: Stuff that is arcane (obscure)
<LispTyro>
I see
<LispTyro>
Gleefre: did you systematically work through any Common Lisp books?
<Gleefre>
LispTyro: yes, including PCL, On lisp, LoL [ both land of lisp and let over lambda ], successful lisper ( or smth like this? a bit older book )
<Gleefre>
I also read some chapters from ANSI Common Lisp (the book), and read quite a lot of hyperspec