Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Common Lisp running natively over WebAssembly for the first time

soi-disant.srht.site

Post reply on HN
Print view View original

41–50 of 72 posts

Re: Show HN: Common Lisp running natively over WebAssembly for the first time

#41

Post by aidenn0 »

coryrc wrote: post #25
catchclose8919 wrote: post #7

...god, my eyes ...why is everything CL plagued by such horrible design choices (hyperspec, Lisp-IDEs... all!) - why such ugly colors, ugly typography, bad contrasts, ugly logos, ugly diagrams, ugly supporting graphics?! I know that even the language itself is kind of the opposite of "beautiful", but the way all docs, blogs, websites etc. look ...seriously, is this intended to scare away any aesthetically sensitive p…

The hyperspec is copyrighted and licensed in a way where we can't change it at all. It's like the primary source to learn so impossible for anyone knowledgeable to clean-room reverse engineer a new one.

The final draft of the ANSI specification is freely available to use. There's at least one transcription of it available in the public domain[1]

1: https://github.com/phoe/clus-data/tree/master/live/cl

Re: Show HN: Common Lisp running natively over WebAssembly for the first time

#42

Post by aidenn0 »

This probably doesn't count as "natively" but I've run ABCL[1] under Doppio[2]. Startup times are under a minute in Chromium based browsers and under an hour in Firefox. I've run into zero stability issues, but its no speed demon.

[edit]

Just tried again today and Firefox gets to a REPL in about 3.5 minutes, while chromium is still right about 1 minute.

1: https://abcl.org/

2: https://plasma-umass.org/doppio-demo/

Re: Show HN: Common Lisp running natively over WebAssembly for the first time

#43

Post by miloignis »

gumby wrote: post #38
miloignis wrote: post #37

Earlier quoted context omitted.

Not OP, but as a fellow Lisp-on-wasm developer one problem is that the current release doesn't support tail call elimination. There's a proposal for it (a tail_call instruction), and Chrome has implemented it, but the Firefox/Spidermonkey team hasn't prioritized it, so it's sat for a couple years. At least two implementations (maybe two browser implementations? I don't recall) are needed for standardization, so thing…

There is no branch instruction at all?

There is, but all control flow is structured and the argument/return address stack is out of your control. You have blocks, loops, and if/else statements. The behavior of a branch instruction differs based on context - in a block, it jumps out of the block, in a loop it jumps to the beginning of the loop.

If you really wanted full tail-call behavior, you would either have to compile every function into the same mega-function in a loop and have some sort of if/else tree, or use trampolines (which would additionally require either storing parameters in memory somewhere or using the same type signature for all functions, since function calls are typed).

Overall, it's not a super great situation for true tail-call elimination. For now, I've implemented limited tail-call elimination for single-function recursive calls (transforming them into an in-function loop), and that's patched things up enough for me to continue working for now until I either need to come up with an optimized trampoline or the tail_call instruction finally gets standardized.

Re: Show HN: Common Lisp running natively over WebAssembly for the first time

#44

Post by stareatgoats »

jedimastert wrote: post #16
stareatgoats wrote: post #13

Earlier quoted context omitted.

I think aesthetics is sometimes equated to "superficiality", "commerciality" even "girlishness" and the surface impression tends to be the polar opposite for niches that really want to distance themselves from anything such. Which is not commendable but there you go.

Which is really interesting given how male-dominated the web design field is

I assume that was a convoluted way of disagreeing with the attribution of (some) "girlishness" to aesthetics? Suffice to say, the male domination doesn't by itself exclude all (pleasing) aesthetics, except in those niche corners of the internet with the "no girls allowed" sign on. At least maybe, it's really just a theory ;-)

Re: Show HN: Common Lisp running natively over WebAssembly for the first time

#45

Post by gumby »

miloignis wrote: post #43
gumby wrote: post #38

Earlier quoted context omitted.

There is no branch instruction at all?

There is, but all control flow is structured and the argument/return address stack is out of your control. You have blocks, loops, and if/else statements. The behavior of a branch instruction differs based on context - in a block, it jumps out of the block, in a loop it jumps to the beginning of the loop. If you really wanted full tail-call behavior, you would either have to compile every function into the same mega-…

Thanks, that is pretty dreadful.

Re: Show HN: Common Lisp running natively over WebAssembly for the first time

#46

Post by fami-com »

catchclose8919 wrote: post #35
coryrc wrote: post #25

Earlier quoted context omitted.

The hyperspec is copyrighted and licensed in a way where we can't change it at all. It's like the primary source to learn so impossible for anyone knowledgeable to clean-room reverse engineer a new one.

...you're not joking, right? jeeezus

http://clhs.lisp.se/Front/Help.htm#Legal >Permission to copy, distribute, display, and transmit the Common Lisp HyperSpec is granted provided that copies are not made or distributed or displayed or transmitted for direct commercial advantage, that notice is given that copying, distribution, display, and/or transmission is by permission of LispWorks Ltd., and that any copy made is COMPLETE and UNMODIFIED. IN PARTICULAR, the material that MUST appear in the copy includes:

>...

>Permissions related to performance and to creation of derivative works are expressly NOT granted.

>Permission to make modified copies is expressly NOT granted.

>Permission to add or replace any links or any graphical images to any of these pages is expressly NOT granted.

It's one of the most restrictive licences.

Re: Show HN: Common Lisp running natively over WebAssembly for the first time

#47

Post by metagame »

christophilus wrote: post #10
catchclose8919 wrote: post #7

...god, my eyes ...why is everything CL plagued by such horrible design choices (hyperspec, Lisp-IDEs... all!) - why such ugly colors, ugly typography, bad contrasts, ugly logos, ugly diagrams, ugly supporting graphics?! I know that even the language itself is kind of the opposite of "beautiful", but the way all docs, blogs, websites etc. look ...seriously, is this intended to scare away any aesthetically sensitive p…

Oh, wow. I thought you were just another HN hater, but nope. I think my eyes are bleeding.

I took a picture of a box of pens, snatched the hex values from it, and then threw them directly onto the page. I'm glad you like it!

Re: Show HN: Common Lisp running natively over WebAssembly for the first time

#48

Post by metagame »

jhgb wrote: post #28
catchclose8919 wrote: post #7

...god, my eyes ...why is everything CL plagued by such horrible design choices (hyperspec, Lisp-IDEs... all!) - why such ugly colors, ugly typography, bad contrasts, ugly logos, ugly diagrams, ugly supporting graphics?! I know that even the language itself is kind of the opposite of "beautiful", but the way all docs, blogs, websites etc. look ...seriously, is this intended to scare away any aesthetically sensitive p…

> why such ugly colors, ugly typography, bad contrasts, ugly logos, ugly diagrams, ugly supporting graphics What? It looks perfectly fine on my monochromatic Genera monitor! Jokes aside, Firefox's reader view makes it only marginally more readable. I wonder if it took the author extra effort to make it look like that, and whether there's a better page sanifier than the reader view.

All of the CSS is handwritten for exactly the intended effect that it gave.

Re: Show HN: Common Lisp running natively over WebAssembly for the first time

#49

Post by metagame »

stareatgoats wrote: post #13
catchclose8919 wrote: post #7

...god, my eyes ...why is everything CL plagued by such horrible design choices (hyperspec, Lisp-IDEs... all!) - why such ugly colors, ugly typography, bad contrasts, ugly logos, ugly diagrams, ugly supporting graphics?! I know that even the language itself is kind of the opposite of "beautiful", but the way all docs, blogs, websites etc. look ...seriously, is this intended to scare away any aesthetically sensitive p…

I think aesthetics is sometimes equated to "superficiality", "commerciality" even "girlishness" and the surface impression tends to be the polar opposite for niches that really want to distance themselves from anything such. Which is not commendable but there you go.

I don't think you hit the mark at all, as the person who wrote the page. Nothing you note is a bad thing; they're all positives. Superficiality is my specialty.

Your comment kind of shows some biases you might want to work on.

Re: Show HN: Common Lisp running natively over WebAssembly for the first time

#50

Post by metagame »

jedimastert wrote: post #17
brokenkebab2 wrote: post #12

Earlier quoted context omitted.

Talking about the page behind the link - it's not like Sistine chapel, of course, but it's completely ok. In digital realm your perception is very strongly affected by medium/device/environment. Maybe that's the case. Not commenting about hyperspec though

As someone that has (admittedly minor) struggles with reading and visual processing, I would call the accessibility at least absolutely atrocious. I don't know if I feel more or less betrayed by the fact that the HTML seems to be more or less bespoke and a screen reader would have no problem with the page, but all of these choices feel all the more intentional.

The page was written to render well if you turn reader view on, and the color schemes are all in one line and easy enough to change. The only thing missing from the reader view is the aside, which is silly and in proper contrast on the original page.

However, the contrast is WCAG AA-conformant (except for the links that aren't in a black box, which aren't important links, as I went out of my way to confirm as I wrote the post). The page is actually pretty accessible.

Accessibility is important to me, as many people I've known in my life have been disabled, but so are silly aesthetic choices.

It was intentional, but it also was well-intentioned. That's why it's readable in more or less every web browser, regardless of whether it supports the one line of CSS I'm using, and accessible to screen readers (although I didn't throw in any elements specifically for them, the page is written simply enough that it should work, intentionally).

Post reply on HN