I think css-syntax would make more sense than css-syntax3, personally
Believe me, I understand. I never liked numbers in collection names. I only entertain it since packages conflict on collection names easily. I figure if the package tracks W3C specs, the collection names can follow their levels (read: editions).
I guess it wouldn’t be bad if css-syntax tracked cross-level changes. They would have to share code somewhere anyway.
“They” being the modules inside the collection.
Do you have any interest in writing a #lang css?
Yes, and I did recently write a pidgin lang that used css-expr. It sectioned off racket/base and css-expr rulesets with a #:begin-css-expr keyword.
#lang css-pidgin
(define some-color '\|#888\|)
#:begin-css-expr
[* #:color ,some-color]
I didn’t release it because it seemed too opinionated.
When the parser is fleshed out, it will be possible to write a CSS superset that targets css-expr. Then you’d have a pure-Racket CSS preprocessor lang. :slightly_smiling_face:
(To be fair css-expr already has preprocessor features. It’s just a pain to type in it)
A lexer and syntax colorer also means we can get syntax highlighting in example code used in #lang slideshow presentations, which would be neat
On that note, do you know where I can find a simple color:text<%> implementation example?
I’m assuming what you’re suggesting entails defining one.
for a lexer, you just need something like https://github.com/racket/syntax-color/blob/master/syntax-color-lib/syntax-color/racket-lexer.rkt
Not a clue. I’ve never made one myself. Does Beautiful Racket talk about how to implement syntax highlighting?
Lookee there :eyes:
I had forgotten all about it! There were at least one nice feature:
Wow, you went all the way down to some CSS component value grammars.
There’s some CSS-SYNTAX–2.1 specifics that I’d probably leave out, but would you mind if I adapted some of that with credit to you in the project?
Use whatever you can.
Thanks so much!
I’ll note that that code actually runs today
(I swapped the planet require for just using racket/base for with-output-to-string)
Looking at the code: I have a feeling that the grammar follows some specification. Otherwise there are a few odd rules (like the one for the letter A).
Eyeballing it, it looks like it follows https://www.w3.org/TR/CSS2
Note that the syntax-colorer is separate: http://planet.racket-lang.org/package-source/soegaard/stylesheet.plt/1/0/syntax-coloring.scm
I am not sure why.
The W3C’s specs only speak of a tokenizer and parser. Does Racket’s idea of a lexer conflict in some way?
A “lexer” and a “tokenizer” is the same.
Yes, but I wasn’t sure if the spec forced a semantic difference. (EDIT: clarity)
For example, a “parse error” in the spec is not a reason to throw an exception.
But a parse error can occur in the lexer OR parser.
Since weird details like that crept up, I figured one of them justified a different module.
Could be. The syntax-colorer can’t throw errors halfway through, say, as string: "foo
How many different CSS packages (on both the catalog and PLaneT) are there? If some of them are deprecated / unmaintained / outdated maybe we could update them to point to the others.
That’s what I’m doing now. I came across https://pkgd.racket-lang.org/pkgn/package/w3s, which has the same mission as my own package. It’s undocumented and biased towards a desktop app though. For that reason I edited my own package README to include this blurb:
If prudent, I may also include dependencies from other projects and reprovide their bindings in the right collections. That would depend on if the license of the outside code is compatible with the license of this repository, and written consent of the author(s). Those authors will also appear in the credits.
To do this, since the w3c package already uses a css collection, this means that css-* collections would depend on css/* modules. :worried:
I recommend either reaching out to the authors of other CSS packages and asking if they’d be willing to move their code around or update their docs, especially if they’re not maintaining or using the project anymore.
for instance, it would be much nicer if the w3c package put its css collection inside an outer w3c collection (so you’d import it with (require w3c/css))
that would be much better for all involved
It always feels like a language with a module system shouldn’t have these kinds of name collision issues.
Yeah, would be nice to have something similar to rename-in but for collections.
Does the collection system give us anything meaningfully useful? JS doesn’t have this concept and it seems to do OK
It gives you (or really @lexi.lambda) the ability to define typed/2htdp/universe in a separate package