eddof13 has joined #commonlisp
random-nick has quit [Ping timeout: 265 seconds]
lucerne has quit [Remote host closed the connection]
wilfred has quit [Quit: Connection closed for inactivity]
silasfox has quit [Ping timeout: 265 seconds]
tyson2 has joined #commonlisp
eddof13 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
unyu has joined #commonlisp
lucerne has joined #commonlisp
eddof13 has joined #commonlisp
taiju has quit [Remote host closed the connection]
taiju has joined #commonlisp
ilshad has quit [Ping timeout: 265 seconds]
igemnace has joined #commonlisp
igemnace has quit [Client Quit]
waleee has quit [Ping timeout: 265 seconds]
igemnace has joined #commonlisp
eddof13 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
sabra has quit [Remote host closed the connection]
IAmRasputin has joined #commonlisp
Bike has joined #commonlisp
IAmRasputin has quit [Ping timeout: 265 seconds]
ilshad has joined #commonlisp
Bike has quit [Quit: Client closed]
tyson2 has quit [Remote host closed the connection]
akoana has quit [Quit: leaving]
shka has joined #commonlisp
srhm has quit [Quit: Konversation terminated!]
taiju has quit [Ping timeout: 264 seconds]
ilshad has quit [Ping timeout: 265 seconds]
taiju has joined #commonlisp
Alfr has quit [Quit: Leaving]
dsk has joined #commonlisp
<beach> Good morning everyone! And happy solstice!
<beach> jcowan: Thanks!
<phantomics> Happy solstice beach
<phantomics> Here's a question that's kind of the opposite of yesterday's: when I have a dynamic variable with a definition assigned to it that's effective within a scope, is it possible to set the variable's top-level value from inside the scope? Here's an example:
<phantomics> (defvar ab 10) (funcall (lambda (a) (let ((ab ab)) (set-toplevel ab 20) (+ a ab))) 15) ab
<phantomics> The (set-toplevel) is a theoretical macro that sets the value of ab at its top level so the end result of this will be 20. If setf or (set (symbol-value ...)) is used in place of set-toplevel, the result is always 10
<beach> There is no standard way. But the implementation may have something. Most implementations would assign to the top-level binding if you create a new thread and do it in that thread.
<phantomics> Right, I ran into that problem with threads before
<beach> Problem?
<phantomics> I had a variable scoping issue when using threads
wanagnuj has joined #commonlisp
wanagnuj has quit [Client Quit]
<phantomics> Was confusing because the nesting looked right, realized I couldn't get the variable value I wanted because threads were being spawned inside one of the functions
<beach> I see.
wanagnuj has joined #commonlisp
<phantomics> That's a pain if the implementation can't be counted on though, I may have to find another way
wanagnuj has quit [Client Quit]
wanagnuj has joined #commonlisp
wanagnuj has quit [Client Quit]
<beach> I know of no implementation that does it differently.
<phantomics> In APL it's possible to assign both values that are scoped inside a function and the top-level dynamic variable outside a function using different syntax
<phantomics> Outside-scope assignment is a fairly obscure thing to do anyway, I can just implement it with a thread and see if there's ever a problem
<jcowan> beach: What I expected to find in the inlining paper was a discussion of inlining functional arguments, as when you want to inline a call (mapcar car list-of-pairs), where you could not just inline mapcar but also inline car within it.
<mfiano> Writing a macro that expands to two defvars?
<mfiano> I mean you are basically accessing for a dynamic variable to not be dynamic, so you'll have to use additional storage
<beach> Oh, right, DEFVAR or DEFPARAMETER may work.
<mfiano> s/accessing/asking/
<beach> jcowan: Sorry to have disappointed you. That's not the focus at all of that paper.
* beach goes to look at the definition of DEFVAR and DEFPARAMETER.
<phantomics> mfiano: yeah, I'd need two defvars, and I'd have to remember to reference the top-level variable in the (let) block of any function definition done at the top level
Lord_of_Life_ has joined #commonlisp
<beach> It is not clear to me whether those two affect the innermost binding or the top-level binding.
<jcowan> phantomics: If your macro expands to two defvars, it should instead map to (progn (defvar ...) (defvar ...))
<mfiano> beach: defparameter as a non toplevel form does not have to recognize that the variable should be special
<beach> What does that mean?
<beach> Where do you see that?
<jcowan> beach: Sure. I just thought it would be mentioned, that's all
Lord_of_Life has quit [Ping timeout: 258 seconds]
Lord_of_Life_ is now known as Lord_of_Life
<beach> jcowan: Right, thanks.
<jcowan> I don't know if any Lisps actually implement it: Kottlin does
<beach> I see.
<mfiano> beach: "However, the compile-time side effects described below only take place when they appear as top level forms"
<mfiano> where the side-effects are that they be recognized to establish a special variable
<beach> mfiano: Right, but that's different from what binding is affected at run time.
x88x88x has joined #commonlisp
<beach> Just for kicks, let's see what SBCL does.
<beach> SBCL DEFPARAMETER affects the innermost binding.
<mfiano> Yes, it would be up to the impl I believe.
<beach> It looks that way, yes.
<beach> Note to self: In WSCL, specify which binding is affected by non-top-level DEFPARAMETER and DEFVAR.
<mfiano> That case is probably extremely rare, at least in the non-code-smell sense.
<beach> Indeed. But I see no reason not to specify it.
<mfiano> Yes
<beach> I mean, at least specify that the implementation has a choice.
<mfiano> Agreed
<moon-child> phantomics: you might consider not relying on cl's dynamic scoping, and instead using your own binding stack
<mfiano> ^
<mfiano> I second this. Then you can maintain pointers to the top and bottom
<moon-child> alternately, use some standard prefix for local variables (use a separator, like +; even if you allow rebinding +, you will never allow rebinding ++, so it avoids collisions)
<phantomics> moon-child: perhaps an ideal solution... but a lot of work
<beach> phantomics: Maybe. But it is often a bad idea to rely on the semantics of the implementation language matching the language being implemented.
<moon-child> I do not agree
<moon-child> first: there are certain things that it makes sense to rely on. Integer arithmetic, for instance
<moon-child> second: if you are designing a language that integrates closely with its target (as april seems to with cl), then it makes sense to try to express things idiomatically in terms of the target, where possible
<beach> Oh, I didn't mean the way certain functions work. I was referring to the overall semantics.
<moon-child> right. Second argument is more relevant, in that case
<beach> Right. If you want integration, that's a different story.
<phantomics> APL is orthogonal to CL in many ways, there are just a few hangups
<beach> "orthogonal"?
<moon-child> phantomics: here's an option: discard dynamic scoping in april entirely :)
<beach> That sounds bad.
<phantomics> Orthogonal in that many of the concepts are 1-1 mappings. a+⎕←b×c is the same as (+ a (print (* b c))) for example
<beach> That's not how I think about "orthogonal", but hey.
<phantomics> What does it mean to you? Going against the grain of CL?
<beach> "being totally unrelated"
<mfiano> phantomics: I think you mean the opposite
<beach> mfiano: No, the opposite to opposite.
<phantomics> April produces CL arrays you can easily interact with in CL, its workspace are CL packages. APLs implemented in other languages make special data structures that you can't process using the host language, especially since most are written in languages that don't support multidimensional arrays
ad_absurdum has joined #commonlisp
kakuhen_ has joined #commonlisp
<moon-child> well, depends on what you mean by 'process using the host language'. Dyalog apl (for instance) is written in c++; its arrays are implemented in terms of c++ structures and are surely manipulable from the (c++) implementation
<mfiano> Right. When I see "orthogonal" I think geometrically, as in, on an orthogonal axis, not even comparable.
<moon-child> you can even write plugins in c that manipulate those arrays
fiddlerwoaroof_ has joined #commonlisp
<beach> mfiano: Exactly. And I don't think that is what phantomics meant.
<phantomics> I remember hearing it used differently. I would say instead that APL parallels Lisp in many respects
ggoes_ has joined #commonlisp
derelict_ has joined #commonlisp
<moon-child> now I am thoroughly confused. I would say that apl parallels lisp in one respect (power derived through manipulation of a homogenous data structure) and almost no others
<moon-child> :)
<phantomics> Their history is kind of similar too: both are mainframe languages, both were used essentially as operating systems and frontend user interfaces on their host machines. Both fell out of favor when the microcomputer revolution happened due to needing a powerful computer to be useful
<moon-child> yes
<moon-child> (though lisp did a better job of surviving, I think because it was academic so there were free implementations)
<phantomics> Vector languages have traditionally been more proprietary than other language families, see k
dsk has quit [*.net *.split]
ad-absurdum has quit [*.net *.split]
kakuhen has quit [*.net *.split]
ggoes has quit [*.net *.split]
derelict has quit [*.net *.split]
eta has quit [*.net *.split]
fiddlerwoaroof has quit [*.net *.split]
<phantomics> Also, APL has historically mostly been an interpreted language, deploying it means you have to deploy interpreters. It also means there are a few APL features you can't implement with a compiler
<moon-child> yes. But I mean originally, lisp was used for ai at universities, and apl was used for finance at businesses, and this was in the era before commercial languages were generally opensource
<moon-child> there were a few historical apl compilers. One I was even able to dig up source for (though I couldn't get it running)
ggoes_ is now known as ggoes
CrashTestDummy2 has joined #commonlisp
lucerne has quit [Read error: Connection reset by peer]
<phantomics> The main APL compiler is called Apex: http://www.snakeisland.com/apexup.htm
<phantomics> It's been around since the 80s
<moon-child> ooh, that's a new one I didn't know about
CrashTestDummy3 has quit [Ping timeout: 265 seconds]
<phantomics> To me the main similiarities between the languages are their simple syntax and how they model arrays and functions. Working on them "feels" similar, even if the appearance of the code is very different. Especially because both are designed around a REPL.
ilshad has joined #commonlisp
x88x88x has quit [Ping timeout: 265 seconds]
jeosol has joined #commonlisp
lucerne has joined #commonlisp
ChanServ has quit [shutting down]
bilegeek has quit [Quit: Leaving]
x88x88x has joined #commonlisp
ilshad has quit [Ping timeout: 268 seconds]
taiju has quit [Remote host closed the connection]
ChanServ has joined #commonlisp
kakuhen_ has quit [Quit: Leaving...]
Lycurgus has joined #commonlisp
kakuhen has joined #commonlisp
kakuhen has quit [Changing host]
kakuhen has joined #commonlisp
ad_absurdum has quit [Quit: Leaving]
Oladon has quit [Quit: Leaving.]
cjb has quit []
dsk has joined #commonlisp
rgherdt has joined #commonlisp
x88x88x has quit [Ping timeout: 258 seconds]
IAmRasputin has joined #commonlisp
IAmRasputin has quit [Ping timeout: 265 seconds]
derwolf has joined #commonlisp
Cymew has joined #commonlisp
unyu has quit [Quit: WeeChat 3.2]