freenode/#lisp - IRC Chatlog
Search
9:38:47
adlai
e.g., if you're reading a code which is mostly multibytes, and occasionally a single byte.
14:13:28
sjl_
no one had ops in #clnoobs to combat the spam a while back, so folks moved to a new channel
17:15:33
flip214
sjl_: that problem got solved in the new channel? or should we start keeping a note somewhere?
20:08:11
Godel[m]
Hi, in https://fare.livejournal.com/188429.html, the author claims that `… Racket keeps evolving, and not just "above" the base language, but importantly below. This alone makes it vastly superior to CL …`. What could it mean to evolve below the language? Is he referring to the subsets of racket that exist (functional, lazy)? (I haven't programmed in racket.)
20:14:38
mfiano
Also, he eventually moved to Gerbil Scheme, though I believe he is doing mostly ML these days.
20:15:16
oni-on-ion
Godel[m], perhaps something about racket swapping their guts to chez scheme recently
20:15:43
Godel[m]
Sorry, I don't understand what is runtime type stuff. I haven't dealt with racket at all.
20:22:11
Bike
if you're that concerned you should just ask fare. there's probably an email address on there somewhere.
20:23:46
oni-on-ion
why i say branding is because most/all the other schemes can do the racket things
20:25:46
oni-on-ion
well. parenscript is CL that produces JS. do you want CL to *consume* JS , or something else ?
20:26:45
jmercouris
you can't just translate javascript to CL, there are many semantics to the way javascript does addition, for example
20:27:15
sjl_
https://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf is 800+ pages. probably nontrivial.
20:27:21
oni-on-ion
hehe well i wouldnt want to <insert source code> everytime i want to describe it.
20:27:32
fortitude
jmercouris: it's not really an interpreter, but there is http://marijnhaverbeke.nl/cl-javascript/ which might be a starting point
20:28:32
oni-on-ion
well, guile did it. https://www.gnu.org/software/guile/manual/html_node/ECMAScript.html
20:30:55
fortitude
I'd think that trying to preserve all the strange type-conversion stuff would be quite the trick (c.f. all the "what the heck javascript" talks)
20:31:21
jmercouris
I have been thinking a lot about web engines, and I have concluded that the web standard has increased so massively and javascript become so large partly as a way to increase the barrier to entry for new engines
20:32:38
jmercouris
I'm just thinking about all of the components, and what it would take to reasonably fund such a task
20:35:01
Bike
the good thing about it being a virtual machine is that, in theory, you don't need to think like a person to implement it, just follow all the steps stupidly
20:35:23
fortitude
if you're doing a greenfield project, it might be easier to implement webassembly support and take somebody else's javascript-on-WA, assuming that exists
20:35:38
oni-on-ion
if parenscript was written in prolog, one could just swap the args, and get the inverse.
20:41:21
jmercouris
considering; "Embeddable, portable, compact: can run on platforms with 160kB flash and 64kB system RAM"
20:43:27
Bike
it's not how they develop it. if you look at the repo they use separate source files like regular human beings.
20:44:16
Bike
and microsoft's "chakra core" and v8 are both open source, i just don't thinkt hey have ffiable apis
20:45:10
jmercouris
so I guess the minimum budget to develop a new web rendering engine must be at least 500,00.00 USD
20:46:13
Bike
also, that's one designed for low memory usage rather than speed. it probably doesn't jit and stuff.
20:48:25
jmercouris
or rather as an open question, can anyone in the channel explain to me JIT? I don't know much about compilers
20:48:31
White_Flame
of course, that example is in C, and thus has to implement their own GC, while in Lisp you can simply use the native one
20:48:50
White_Flame
I don't think javascript is all _that_ difficult to implement in a naive approach
20:49:09
White_Flame
parsing the source text is probably going to be one of the more finnicky things to do
20:49:50
fortitude
jmercouris: at a very high level, JITing is essentially using an interpreted chunk of code until you've collected som stats about how it is actually being used, then replace it with a compiled version that takes advantage of those stats
20:50:59
White_Flame
you can do things like inline virtual functions, if you can at runtime resolve & assume its type will be consistent
20:51:48
White_Flame
they tradeoff quick-to-start execution in more naive bytecode environments, with slow-to-start optimized machine language outputs
20:51:51
fortitude
jmercouris: the stats you collect allow you to optimize the compiled code for how it's actually being used, instead of how you assume it might be used in some hypothetical future
20:52:16
fortitude
the tradeoff is having to wait a bit before you can actually do that (warmup times turn out to be pretty variable in some systems)
20:52:48
White_Flame
in fact, the entire raison d'état for webasm was to decrease the startup latency of loading & parsing
20:53:10
jmercouris
as the VM runs it makes better and more informed decisions about how to compile snippets?
20:53:39
White_Flame
although it doesn't make its own new auto-classifications; it simply routes the optimization paths the authors have provided
20:53:53
fortitude
thing is the optimizations are local and ephemeral (you don't save them in a "smarter" vm that you use the next time you start your browser up)
20:54:40
White_Flame
and many of the JIT heuristics are incredibly simple, merely figuring out what the actual concrete type of a variable usually is
21:00:35
White_Flame
a histogram is a count of occurrences. X axis is which type a variable happened to be during a pass, Y axis is the count
21:02:28
White_Flame
there's usually a count of times a section of code has been run, and when that hits a threshold, it attempts to optimize it further (and coined the name "hotspot")
21:06:54
White_Flame
the JVM and various JS engines are really fascinating to look into. There's a ton of money & talent thrown at making those faster (regardless of the language quality that runs on them)
21:08:53
jmercouris
what a shame, that money could be spent to heat dumpsters in the NY winters and it would be put to better use
21:34:55
aeth
jmercouris: The real issue is why are those programmers being paid to work on JS engines and not CL.