It's been getting popular for at least 2 years lol
I tried it but really just didn't like it. Too underpowered for desktop, too complicated for phone
(I won't spend too much time on it, to avoid duplicate work)
as token of gratitude :)
does someone know what scheme is used in try.scheme.org ?
it seems like gambit but...
anybody is welcome to add to the discussion at: schemeorg/try.scheme.org#1
we’re currently discussing security issues with running untrusted code in the REPL
the try.scheme.org REPL allows things like
(load “http://…”) which is neat but dangerous… I added a whitelist to guard loading untrusted code
try
,help...
what remains to be done: 1) an online code editor to modify the local filesystem, 2) TAB completion of symbols/variables, 3) support utf8 in files, 4) fix small things that are broken/missing
If anyone would like to help out, you are welcome to join the project… things are advancing quickly (most of the new work was done this past week)
(and if so, how do I trigger that option?)
(or check for it)
I think “print-evaluably” would be a better term for what you want… this feature is a huge can of worms… (what is doing the evaluation? in which scope? etc) In any case this shouldn’t be implemented in the pretty printer but rather in a preprocessing of the datum before it is passed to the pretty-printer. The procedures
##inverse-eval and ##inverse-eval-in-env are used by the REPL for that purpose, but they are rather basic:> (##inverse-eval 123)
123
> (##inverse-eval (list 1 2 3))
'(1 2 3)
Also this in another file:
(##set-debug-settings! 15 3)
Looks like I have output that goes to
/dev/null and/or is overwritten in buffers?
Here is a stripped down example of behavior that really tripped me:
":" ; ( echo -e 'INTERPRETED' ; gsi letrec-star-reordered.scm; echo -e '\nCOMPILED' ; gsc letrec-star-reordered.scm && gsi -e '(load "letrec-star-reordered")' ) 2>&1 | less
(define (displayln . a) (for-each display a) (newline))
(define (reordered)
(letrec* ((x (begin (displayln 100) 42))
(_200 (displayln 200))
(_300 (displayln 300 (list x)))
(_400 (displayln 400))
(y (begin (displayln 500) 23)))
(displayln 600 (list y))))
(reordered)Note how, when compiling, line 300 is moved below line 500.
Is that a bug in
letrec* or in my understanding of its spec as "evaluate left to right" ?
IIUC, the code is compiled by
lib/_eval.scm function ##comp-let-like-form but the code is lacking in comments, so it is hard to understand both what is going on and what should be going on.
drewc @drewc is just thinking off what Gambit may be based on
I'm fairly certain he's not actually using
letrec* but forms that expand to it, so perhaps, yes, yes I am :)
In the meantime, I'm nesting
let and begin statements (with the nest macro) until this matter is resolved. I wasted too many hours on this. I'd like to fix Gambit, but understanding that code would require serious archaeology to unearth the intent of the code, so I can fix it.
drewc @drewc just realised he's run into that a few times but thought it was thinking CL like, not scheme like, and used
let and friends to get over that. (define (ordered)
(letrec* ((displayln (lambda a (for-each display a) (newline)))
(x (begin (displayln 100) 42))
(_200 (displayln 200))
(_300 (displayln 300 (list x)))
(_400 (displayln 400))
(y (begin (displayln 500) 23)))
(displayln 600 (list y))))
(ordered)
I was trying to figure out why I thought it was scheme and the lack of order. Took me about 3/4 of an hour and a half cup of coffee, and came up with that.
Which is how
letrec works, but not how letrec* should work.
gambiteer on master
Speed up implementation of SRFI… (compare)
feeley on master
Universal backend: add URL whit… (compare)