Introduction
Introduction Statistics Contact Development Disclaimer Help
_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
Visit Hacker News on the Web
COMMENT PAGE FOR:
Liskell – Haskell Semantics with Lisp Syntax [pdf]
skywhopper wrote 9 hours 52 min ago:
I was told Lisp didn’t have syntax.
zephen wrote 5 hours 32 min ago:
It has minimal, very regular, syntax.
Which is a strength in some aspects, and, although many lispers will
never admit it, a weakness in others.
felipelalli wrote 10 hours 3 min ago:
Savior of the universe.
swatson741 wrote 10 hours 23 min ago:
Date of publication is from 2007.
srott wrote 11 hours 5 min ago:
How does it compare to Shen?
[1]: https://shenlanguage.org
adastra22 wrote 10 hours 41 min ago:
Kinda hard to tell when I can’t find a single example of the
language on its website.
vindarel wrote 11 hours 5 min ago:
The other way round, a Haskell on top of a Lisp, in production today:
[1] > Coalton is an efficient, statically typed functional programming
language that supercharges Common Lisp.
Presentation this year on the ELS:
[1]: https://github.com/coalton-lang/coalton/
[2]: https://www.youtube.com/watch?v=of92m4XNgrM
dieggsy wrote 10 hours 6 min ago:
I'm not sure I'd say this is "the other way around"; Coalton strives
to implement Haskell or ML-adjacent semantics (in the type system,
for example) with Lisp syntax. "With" here meaning that it is both
implemented in and written with Lisp syntax.
Edit: I think I see what you mean now. Lisp backend vs Haskell
backend.
Anyway, Coalton is a joy to use and IMO a breath of fresh air in CL.
It's quite easy start using as a library; go all-in or only use it in
specific parts of the code. It's great to be able to choose between
(or intermix)the flexibility of CL and the guarantees of a statically
typed language (as well as some nice performance boosts with arguably
less work). Some aspects are still young (some of the standard
library, ecosystem, editor support), but it's quite thoughtfully
crafted and I'm excited to see where it goes.
flavio81 wrote 7 hours 46 min ago:
>Coalton strives to implement Haskell or ML-adjacent semantics (in
the type system, for example) with Lisp syntax. "With" here meaning
that it is both implemented in and written with Lisp syntax.
Not exactly. Coalton brings ML-style strong typing to Common Lisp.
But Coalton code is also Lisp code.
The backend, thus, is Common Lisp, and it is available at all
times, thus leveraging all its power.
fithisux wrote 11 hours 19 min ago:
It is time for Rusted !!!
Rust semantics with D syntax (garbage collector is a bonus).
Xophmeister wrote 11 hours 9 min ago:
Didn’t D get an ownership model, a la Rust’s affine types,
relatively recently?
fithisux wrote 2 hours 36 min ago:
I don't think so, but they are working towards it.
The big news is that this will cover the GC cases too, not only the
manual memory management.
EricRiese wrote 11 hours 24 min ago:
There's also Hackett: Haskell with Racket's syntax and macro system, by
Alexis King
privong wrote 10 hours 16 min ago:
To save folks a search:
github repo: [1] Documentation:
[1]: https://github.com/lexi-lambda/hackett
[2]: https://lexi-lambda.github.io/hackett/
bjoli wrote 11 hours 27 min ago:
I will prempt the comment that always shows up in discussions of this
kind:
No. Typeclasses do not replace proper macros. Go home, you are drunk.
Y_Y wrote 10 hours 6 min ago:
I'll get in trouble if I show up this drunk at this hour, can't I
just bolt on a templating system?
BalinKing wrote 10 hours 53 min ago:
Another argument I've often heard is that laziness largely obviates
macros. Personally, I agree that this is often true—but not always,
and that last bit is where Lisp-style macros would be really nice.
(^^ edited based on one of the responses below.)
Symmetry wrote 10 hours 3 min ago:
The venerable master Qc Na was walking with his student, Anton.
Hoping to prompt the master into a discussion, Anton said "Master,
I have heard that objects are a very good thing - is this true?" Qc
Na looked pityingly at his student and replied, "Foolish pupil -
objects are merely a poor man's closures."
Chastised, Anton took his leave from his master and returned to his
cell, intent on studying closures. He carefully read the entire
"Lambda: The Ultimate..." series of papers and its cousins, and
implemented a small Scheme interpreter with a closure-based object
system. He learned much, and looked forward to informing his master
of his progress.
On his next walk with Qc Na, Anton attempted to impress his master
by saying Master, I have diligently studied the matter, and now
understand that objects are truly a poor man's closures." Qc Na
responded by hitting Anton with his stick, saying "When will you
learn? Closures are a poor man's object."
At that moment, Anton became enlightened.
merelysounds wrote 9 hours 51 min ago:
Some fun code examples in Ruby:
[1]: https://medium.com/@citizen428/of-closures-and-objects-e...
jasbrg wrote 10 hours 29 min ago:
do you know of a post or something you could point to that
elaborates that argument? interested because I'm having trouble
coming up with the line of reasoning on my own
BalinKing wrote 10 hours 20 min ago:
I'm having trouble finding anything concrete online (other than
people simply repeating the folk wisdom) other than control flow
operators, which are implemented as normal functions in Haskell
(i.e. including custom control flow operators).[0] Although, one
Reddit comment[1] did also mention typeclasses as obviating other
types of macros, so I've edited my earlier comment accordingly.
[0] [1]
[1]: https://www.reddit.com/r/haskell/comments/5xge0v/comment...
[2]: https://www.reddit.com/r/haskell/comments/1929xn/comment...
ddellacosta wrote 10 hours 22 min ago:
This is not a direct response to the question of how laziness
obviates the need for macros, but it mentions some specific
relevant cases:
[1]: https://augustss.blogspot.com/2011/05/more-points-for-la...
<- back to front page
You are viewing proxied material from codevoid.de. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.