I think the Markdown creator’s way of seeing it is that the success of Markdown is specifically due to the fact it has no spec.
Once the creator of CommonMark realized there was such a difference of ideology there, I think he asked the Markdown creator if calling the Markdown spec “Common Markdown” would be better, since that made it a specific dialect of its own. The Markdown creator said something like, any specification that looked like it specified the term “markdown” would give people the wrong idea. So the spec creator went with “CommonMark” instead.
When I feel like agreeing with the specless point of view, I’d say Markdown is a natural language that revolves around what looks good in a plain text file. Standardizing Markdown would keep it from advancing together with advancements to the natural language around it.
However, I almost always prefer having a spec. I think implementations of a language ossify it already, and specs ameliorate the ossification by helping users understand which behaviors are likely to change and how to avoid relying on them. Meanwhile, another more abstract source of ossification takes the form of developers’ ignorance that certain features are even needed (e.g. because all the people who need them are marginalized or across a language barrier); a spec can provide developers with information on why those features are needed and how they need to work.
The update is in progress, but it takes a while because it’s a build of all packages form scratch on an old machine.
@jaklingonzal has joined the channel
@magnus.an has joined the channel
@carl.morris.world it seems that eval would be appropriate for you, if you could post your minimal example, it would be helpful for us to see more closely what you want to do
I just setup an example on GitHub: https://github.com/venuur/minimal-eval-example
I wanted it to be smaller, but I haven’t figured out everything I can trim yet.
It’s a language implemented using #lang br following the tutorials on Beautiful Racket: https://beautifulracket.com/appendix/master-recipe.html
The crux of it is from test-eval.rkt: https://github.com/venuur/minimal-eval-example/blob/master/test-eval.rkt #lang racket
(require rackunit)
; What works but requires a file per small test.
(check-equal?
((dynamic-require "test-script.rkt" 'gs-program-result))
"123")
; What I would like to work
;(check-equal?
; (with-output-to-string (eval "lang minimal-eval-example" "1 2 3"))
; "123")
And to give credit where it’s due, I’m just implementing Golfscript as an exercise in learning to use Racket: http://golfscript.com/golfscript/
@carl.morris.world Let’s forget eval for a moment. What would the ideal test expression look like?
Ideally something like (check-equal? (run-with-my-lang "1 2 3") "123")
Then instead of having a separate file test-script.rkt for each snippet I want to eval, I could include it inline in the test module.
Using eval is definitely one route.
Another idea: Write a temporary file “test.rkt” with the context of "#:lang golfscript 1 2 3". Then use dynamic-require to run the contents of the file.
Ahh, so write the scripts to temp files as the tests are running
Maybe eval is better fit here after all.
Wouldn’t make-module-evaluator fit the same style as the temporary file?
looks up make-module-evaluator
I think so - but if eval is used (either directly or with make-module-evaluator) I think, the custom golfscript reader needs to be invoked manually.
With make-module-evaluator you can pass it a string that has the #lang line at the top, and it will use that lang for the reader
Fits perfectly then!
that’s so cool! I didn’t know you could pass the lang line in directly.
I just tried it, and it seemed to work.
False alarm, I got an error
```
dynamic-require: name is protected
name: 'read-syntax
module: #<resolved-module-path:(submod "C:\Users\carlm\workspace\golfscript\minimal-eval-example\minimal-eval-example\main.rkt" re...(make-module-evaluator "#lang minimal-eval-example\n1 2 3")
(make-module-evaluator module-decl
[ #:language lang
#:allow-for-require allow-for-require
#:allow-for-load allow-for-load
#:allow-read allow-read])Does putting a (call-with-trusted-sandbox-configuration (lambda () ...stuff...)) around it help?
It got rid of the error
It worked. (define x (call-with-trusted-sandbox-configuration
(λ () (make-module-evaluator "#lang minimal-eval-example\n1 2 3"))))
(display (x '(gs-program-result)))
Prints 123 as hoped
Now I can wrap that up in a function to make my test scripts inline.
On Reddit bjoli has an interesting question on using Chez from Racket. It is possible, but is there already an chez-ffi (similar to the current C ffi), or is that something to look forward to?
Thanks @alexknauth, @soegaard2!
That seems sensible
Answered there.
Just put up a blog post on modeling WebAssembly in Redex: https://www.asumu.xyz/blog/2019/04/29/webassembly-in-redex/
^ @asumu post
aha, it was the instance argument I was missing when I wrote that code