ng0 has quit [Quit: Alexa, when is the end of world?]
ZombieChicken has quit [Ping timeout: 256 seconds]
ZombieChicken has joined #racket
jao has joined #racket
FreeFull has quit []
dddddd has quit [Remote host closed the connection]
moldybits has quit [Quit: WeeChat 2.4]
Guest23267 has joined #racket
Guest23267 is now known as nozmv
nozmv is now known as zmv
zmv is now known as notzmv
aeth_ has joined #racket
jao has quit [Ping timeout: 250 seconds]
aeth has quit [Ping timeout: 255 seconds]
aeth has joined #racket
aeth_ has quit [Ping timeout: 246 seconds]
moldybits has joined #racket
aeth has quit [Ping timeout: 244 seconds]
aeth has joined #racket
GoldRin has joined #racket
q9929t has joined #racket
dmiles has quit [Ping timeout: 246 seconds]
q9929t has quit [Quit: q9929t]
lavaflow has quit [Read error: Connection reset by peer]
lavaflow has joined #racket
dmiles has joined #racket
meepdeew has quit [Remote host closed the connection]
_whitelogger has joined #racket
ZombieChicken has quit [Remote host closed the connection]
ZombieChicken has joined #racket
endformationage has quit [Ping timeout: 268 seconds]
<dzoe>
Is there a way to specify form result in scribble/srcdoc's form-doc? It seems to me that apart from describing it in the text there is no way to do it.
notzmv has quit [Remote host closed the connection]
Arcaelyx has quit [Ping timeout: 245 seconds]
selimcan has joined #racket
orivej has joined #racket
Arcaelyx has joined #racket
lavaflow has quit [Read error: No route to host]
lavaflow has joined #racket
selimcan has quit [Ping timeout: 245 seconds]
lavaflow_ has joined #racket
lavaflow has quit [Ping timeout: 250 seconds]
selimcan has joined #racket
selimcan has quit [Remote host closed the connection]
ng0 has joined #racket
ng0 has quit [Quit: Alexa, when is the end of world?]
ubLIX has joined #racket
vraid has quit [Ping timeout: 252 seconds]
ubLX has joined #racket
ubLIX has quit [Ping timeout: 255 seconds]
vraid has joined #racket
ZombieChicken has quit [Remote host closed the connection]
GoldRin has quit [Ping timeout: 268 seconds]
vraid has quit [Read error: Connection reset by peer]
_whitelogger has joined #racket
ricekrispie2 has joined #racket
ricekrispie has quit [Ping timeout: 250 seconds]
FreeFull has joined #racket
jao has joined #racket
dddddd has joined #racket
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
acarrico has joined #racket
endformationage has joined #racket
DGASAU has quit [Ping timeout: 255 seconds]
proksi has left #racket ["Be back later..."]
Arcaelyx has quit [Ping timeout: 250 seconds]
DGASAU has joined #racket
ubLIX has joined #racket
orivej has quit [Ping timeout: 268 seconds]
ubLX has quit [Ping timeout: 268 seconds]
cky has quit [Ping timeout: 258 seconds]
SenasOzys has joined #racket
cky has joined #racket
selimcan has joined #racket
selimcan has quit [Remote host closed the connection]
ubLX has joined #racket
ubLIX has quit [Ping timeout: 246 seconds]
amz3 has joined #racket
<amz3>
hello, I am trying to setup a repository to do tests portably across scheme implementations
<amz3>
I can import (tests helpers) but I can not import (nstore) which is in src/
<amz3>
what I am doing wrong
<bremner>
dunno much about r7rs; how does it know to look in src? in "#lang racket" I would (require "src/nstore.rkt")
brendyyn has quit [Ping timeout: 246 seconds]
jao has quit [Ping timeout: 246 seconds]
jao has joined #racket
<amz3>
tx, I asked the question as racket-r7rs github issue
badkins has quit [Remote host closed the connection]
SenasOzys has quit [Read error: Connection reset by peer]
selimcan has joined #racket
fanta1 has joined #racket
selimcan has quit [Remote host closed the connection]
acarrico has quit [Ping timeout: 255 seconds]
ubLX has quit [Quit: ubLX]
q9929t has joined #racket
<lexi-lambda>
amz3: I answered your question at length on GH, but the tl;dr is that R7RS does not specify where modules should be loaded from, so doing it portably is impossible. Go take it up with the standard authors if you think that’s an unhelpful design choice (I do).
<amz3>
lexi-lambda: tx a lot.
<rain1>
i agree that this is a problem
<rain1>
what would be a good solution for filesystem based implementations of r7rs that could become an ad-hoc standard?
q9929t has quit [Quit: q9929t]
<amz3>
the thing is that most scheme have an existing module system, and making a new standard is difficult, i guess.
<rain1>
(my understanding is that this was left unspecified to support non-filesystem based implementations... like putting code in a SQL database for example, but i don't think any actually exist?)
<lexi-lambda>
I think such a justification is tenuous at best, since a module system without a specification of how modules are loaded means the module system is not portable. So even with access to an R7RS-compliant Scheme, you can’t use the module system without relying on implementation-specified behavior. At which point one has to wonder: why is it in the standard?
fanta1 has quit [Quit: fanta1]
<lexi-lambda>
My takeaway is that RnRS is not really about specifying a standard language for writing portable code, it’s about having a small language that’s easy to implement as an exercise in compiler implementation or as a common starting point for building new languages that don’t want to have to go through the effort of designing everything from scratch.
<rain1>
>such a justification is tenuous at best
<rain1>
this is what the author of the spec told me
<lexi-lambda>
And there is some value in that, I think. But then it’s not really a “standard” so much as it is a “design document”.
<rain1>
I totally disagree with this choice and think filesystem search path stuff should be specified in the standard
<lexi-lambda>
And yes, I’m not saying it’s your justification, I’m just saying it’s not a justification I accept. :)
<rain1>
yeah
<lexi-lambda>
I have heard that justification before.
<rain1>
IMO this point, and also the way the library syntax forces your entire module to be wrapped in a bracket are 2 reasons why R7RS is not catching on well
<rain1>
some people are ok with it but i feel like im writing my whole program in LETREC rather than using DEFINE's
<lexi-lambda>
I really think R7RS makes much more sense if you accept that it is not about standardizing things enough so that people can write portable Scheme programs but is simply a set of guidelines for someone who wants to implement their own little language that behaves in a familiar, if not entirely predictable, way.
<rain1>
(and how there's no HTML version of the spec, like we have for R5RS)
<rain1>
that's good point but what i really wanted from the spec is the ability to write portable code, and this isn't a goal that should be difficult at all
<lexi-lambda>
Why do you want to write portable Scheme?
<rain1>
waste of time redoing everything to run it on another scheme
<lexi-lambda>
Why do you want to run your code on more than one Scheme?
<bremner>
maybe racket isn't available somewhere i need to run my code?
<bremner>
for example.
<rain1>
why you ask this
<amz3>
maybe not run the same thing in another scheme, but at least having the possibility to change scheme depending on the domain..
<amz3>
and having standard saying those are the basics stuff a scheme should have, helps moving from one implementation to the other
<lexi-lambda>
bremner: What you’re asking for in that case is a portable language that’s higher level than, say, C, but doesn’t actually support very much in the way of actual portable features. I don’t understand why that would help you.
<lexi-lambda>
It sounds like what you’re saying is “I want to have a high-level language that does all the things I want but runs everywhere I want without having to modify it”, and that doesn’t seem like a problem specifying a small functional language is going to solve.
<lexi-lambda>
rain1: I ask because I do not understand why people bother with writing portable Scheme instead of just picking an implementation and sticking with it. How often are you really going to be able to run any non-trivial Scheme program on multiple implementations without changing parts of the program? Scheme doesn’t specify enough to write anything real.
<amz3>
r7rs is not small if you take into account all the dockets
<amz3>
the thing that i miss from the standard is cffi
<lexi-lambda>
How many Schemes actually implement all the dockets, anyway?
<bremner>
lexi-lambda: I know nothing about r7rs. or scheme really. I just have the practical problem of racket code that doesn't run everywhere I want it to.
<rain1>
I agree with you that scheme doesn't specify enough to do this
<rain1>
what i want is that it should take zero effort to write scheme code that runs unchanged in all the implementations that have the set of libraries you depend on
<lexi-lambda>
bremner: Sure, it’d be great to have code that runs in more places. I’m just saying I don’t see how having a language standard really makes that any easier than just porting your implementation of choice to a new platform. Fundamentally you have to do the same work.
<rain1>
it's understandable that portable C programming is difficult and requires ./configure stuff and hacks and #ifdefs
<lexi-lambda>
rain1: Right, but I’m asking *why*. Why would you rather be able to do that in a language called “Scheme” instead of in a language called “Racket” or “Guile”?
<rain1>
it makes no sense that if i implement a unification algorithm in one i can't run it in another without doing a bunch of work
<lexi-lambda>
I do not understand why. To me, that’s like saying it makes no sense to implement a unification algorithm in Haskell if I can’t run it in OCaml without doing a bunch of work.
<rain1>
it's accurate to compare racket and guile to haskell vs ocaml
<rain1>
racket sabotaged portability by getting rid of mutable pairs
<lexi-lambda>
Either you have a big, consistent language with few implementations (including possibly just one) that supports real, portable programs, or you have a small language with many implementations. You wouldn’t have a billion Schemes if the language actually specified enough to do anything useful.
<rain1>
but the code should run on all schemes
<lexi-lambda>
I think you’re getting hung up on this idea of minor impediments to portability like differences in module loading and mutable vs immutable pairs, but even if you didn’t have those differences, my points is that you’re still writing Scheme, which doesn’t let you do anything.
<lexi-lambda>
And if it did let you do all the things you wanted, there wouldn’t be so many different Scheme implementations.
<amz3>
I disagree r7rs allows to build quite interesting stuff on its own
<amz3>
for instance, the nstore srfi is based on r7rs
<amz3>
disclaimer I am the one who submitted that srfi
<rain1>
scheme is an extensible language so each scheme should be an extension of core scheme just by adding new libraries
<amz3>
nstore = srfi 168
chickendan has joined #racket
<rain1>
it should be simple to program in an intersection of the capabilities of a few schemes, just by importing only the modules that that few schemes provide
<lexi-lambda>
amz3: There is a pretty big difference between R7RS small (which is the only standardized version of R7RS to date) and the “R7RS plus a bunch of SRFIs” that is the unreleased R7RS large. And there isn’t much evidence that those SRFIs are consistently implemented by various implementations, anyway.
<rain1>
it's totally OK if some SRFIs are missing, what's important is a common standardized core
<lexi-lambda>
rain1: An “extensible language” cannot magically acquire the ability to spawn subprocesses if it does not expose that capability to the programmer.
<lexi-lambda>
And the “standardized core” of Scheme doesn’t let you do anything useful.
<rain1>
couldn't you just have a library that supports spawning subprocesses?
<lexi-lambda>
No, you can’t implement that library in terms of the core primitives in Scheme.
<rain1>
nobody requires that the library be implemented in core scheme
johnjay has quit [Ping timeout: 246 seconds]
<amz3>
well that's true, that doesn't make scheme standard useless
<rain1>
a library can be implemented in a implementation specific way
<lexi-lambda>
rain1: Yes you do, if it’s going to be portable.
<lexi-lambda>
If it’s implementation-specific, then you gain nothing from your so-called “portability”.
<amz3>
maybe rnrs is not about portability but a core set of powerful and common primitives upon which one can solve bigger problems
<rain1>
you're getting mixed up about what has to be portable and what doesn't
<rain1>
two different schemes could implement a library or SRFI that supports spawning processes, one could be done in C and the other in go - and then my scheme code can run in both
<lexi-lambda>
Perhaps our source of conflict is that I’m talking about a program while you’er talking about libraries.
johnjay has joined #racket
<lexi-lambda>
From my POV, a program is either portable or it isn’t. And a program is only portable if all of its dependencies are portable.
<lexi-lambda>
But a program can be assembled from a mixture of portable and non-portable libraries, and you can still re-use portable libraries on multiple Scheme implementations, even if the program is tethered to a particular implementation. Is that the idea you’re getting at?
<amz3>
yes
<amz3>
at least me, I agree with lexi-lambda
<amz3>
stmt
<amz3>
statement
<rain1>
I see what you mean. What I had in mind was that a given program could be expected to run on scheme implementations that implement all the libraries/modules it requires. But its not important if those libraries/modules are implemented using compiler specific stuff, assembly code, or in portable scheme (like how SRFI-1 has a reference implementation in portable scheme)
<rain1>
I would like to be able to say: ok, guile, chicken and chibi all implement r7rs + spawn-process so if I only import those modules and use them my code will likely run on all 3 of those
<lexi-lambda>
amz3: Okay, I can sort of buy that, though I think Scheme has clearly failed at getting any value out of that goal, and the culture is such that it isn’t going to change. But I’d be happy to be proven wrong. Until then, though, I’m happy writing Racket (or Guile, or any other decent language derived from Scheme).
<amz3>
(I think nowdays, code accompagnying srfi are called "smaple implementation")
<rain1>
i totally agree that scheme standardization has failed at this
<lexi-lambda>
rain1: Right, you want the idea of a sort of modular language so that a Scheme implementation can implement a subset of the known modules, and you can run a program on any implementation that implements the full subset that your program (and all its transitive dependencies) happens to use.
<rain1>
yeah! because of the high level nature of scheme and the extreme flexibility of scheme (due to macros) this isn't actually a lot to ask for. it's not like C
<rain1>
and i agree about the culture, a lot of the people making implementations are totally ok with the lack of portability and don't see it as a benefit - and i don't hold that against them
<lexi-lambda>
Sure. It’s a nice idea. I just think it’s not likely to happen because of the enormous amount of investment from several different parties necessary to make it happen.
<rain1>
it wont happen but I still think we can step towards it by e.g. properly specifying how module resolution should work. and how a srfi should be imported
<lexi-lambda>
Implementing a language that does useful things once is hard enough. Doing it a dozen times while coordinating between all the implementations requires people dedicated enough to make the one language and then some.
<rain1>
i don't think the fact there is a different way it can be done on every single scheme is a benefit or helping anybody
<rain1>
i feel like if there was just a single way to do it on all platforms that would be better
<lexi-lambda>
Implementing SRFI 1 is significantly less meaningful than implementing things like subprocesses, threads, a C FFI, etc. Things that can actually expand the scope of what the language can do.
<lexi-lambda>
And implementing those things is much harder. People who implement a Scheme often don’t want to implement those things.
<lexi-lambda>
We have a few implementations that do… Racket, Chez, Guile, Chicken. But even those languages have pretty different goals.
<lexi-lambda>
Getting them to all agree on one way of doing things isn’t just a technical problem, it’s a social problem of agreeing what the right thing is.
<lexi-lambda>
I think R6RS tried to do this, to a point, and the response from the Scheme community at large was clear: they didn’t like it.
<rain1>
thanks for being available to bounce these ideas back and forth. I feel like I clarified my own thinking as well as learned some other viewpoints
<amz3>
+1
orivej has joined #racket
Arcaelyx has joined #racket
acarrico has joined #racket
vraid has joined #racket
ZombieChicken has joined #racket
ubLIX has joined #racket
moldybits has quit [Quit: WeeChat 2.4]
moldybits has joined #racket
badkins has joined #racket
dddddd has quit [Ping timeout: 255 seconds]
dddddd has joined #racket
<jcowan>
I do think that R7RS is about standardizing things, but it's not about standardizing *everything*.
<jcowan>
For example, nobody says that C is not a standardized language, but nevertheless the exact directory from which foo.h is loaded when you say #include <foo.h> is not standardized. Neither is the character set in which C code is written.
<jcowan>
If you want to run C code on IBM mainframes, you have to convert it to EBCDIC (unless the mainframe is running Linux, of course)
<jcowan>
There's a Unixoid convention that include files go in /usr/include, but not all of them do (there's typically an include path, something about which the C standards are silent), and it definitely doesn't apply to Windows, much less anything else.
<jcowan>
lexi-lambda: R7RS-large is not unreleased, it's just incomplete.
<jcowan>
I will say though that I too don't care about making programs portable between implementations, because (almost) all implementations are already portable enough for the highly restricted set of targets nowadays. But I do care about portable libraries very much, and that was (in my mind, I'm not the Scheme BDFL) the main justification for R7RS.
<jcowan>
amz3, rain1: ^^
s455wang has quit [Quit: WeeChat 1.6]
badkins has quit [Remote host closed the connection]