IRC channel logs
2015-09-21.log
back to list of logs
<ahmedtd>If I have created an environment using (null-environment) <ahmedtd>What is the easiest way to load some code from a file and evaluate it in the null-environment <ahmedtd>(eval) takes an environment argument, but (load) doesn't <ahmedtd>Is the best way just to read the whole file into a string and then do (eval string-containing-code) ? <mark_weaver>ahmedtd: can you give me a higher-level description of what you're trying to accomplish? <ahmedtd>I am writing a small "make" utility in guile <ahmedtd>I would like the user to be able to put some s-expressions that describe the dependency graph between files in a file (like make's "Makefile") <ahmedtd>Right now, I just do (load user-file) <mark_weaver>I think the result of (null-environment) is not supposed to be mutable, so you're not allowed to add more bindings to it. <mark_weaver>so it doesn't really make sense to load a file into that environment. <ahmedtd>Then, is there a way to get a "clean" environment? <mark_weaver>however, guile can almost certainly do what you need, if I can understand what that is. <ahmedtd>Basically, I want there to be as few abilities as possible in the user-code environment <ahmedtd>For example, a makefile should not be opening network sockets <ahmedtd>I suppose I'm looking for some sort of sandboxing capability <mark_weaver>well, I'm afraid we can't do secure sandboxing in guile presently. <mark_weaver>it turns out that there are ways of accessing arbitrary modules in guile from even a clean environment. <ahmedtd>It doesn't need to be secure, in the traditional sense <ahmedtd>I'm not trying to guard against someone writing a malicious makefile <mark_weaver>well, okay. if you don't need security, then look at the #:pure specifier when defining a module. <mark_weaver>see section 6.19.8 (Module System Reflection) of the guile manual <mark_weaver>hmm, trying to find a documented procedure to creating a fresh empty module. <ahmedtd>(resolve-module my-new-empty-module #:ensure) <ahmedtd>But I can't figure out what my-new-empty-module should be <mark_weaver>you'll need to create a module name, a list of symbols, that is unique. <mark_weaver>and by the way, at present, modules can never be freed. <ahmedtd>So, that module will have *nothing* in it? <ahmedtd>Well, I guess I can find that out easily enough <mark_weaver>so, you won't be able to successfully do much in it until you import some things into it. <ahmedtd>Oh, and my question had another part -- what do you think is the best way to read code from a file and shove it into that module? <mark_weaver>which you can do with 'module-use!', 'module-add!', 'module-define!', etc. <ahmedtd>Hmmm, I guess I don't mean "shove in" but "execute in the context of" <mark_weaver>well, one way is to use 'read' to read one top-level s-expression at a time from the file, and call 'eval' on each one. <mark_weaver>until 'read' returns an object x such that (eof-object? x) returns true. <mark_weaver>however, if the procedure 'load' is bound in the module (under some name, maybe not 'load'), then it becomes easier. <mark_weaver>then you can just eval `(load ,filename) in that module <mark_weaver>ahmedtd: I would suggest defining one or more modules in your code that exports the precise bindings that you wish to be available from your makefiles, and then use 'module-use!' to import those modules into the fresh module. <mark_weaver>you can use #:re-export (<bindings> ...) to export things that you imported from existing guile modules. <ahmedtd>#:re-export is an option of module-use? <mark_weaver>the result of (null-environment 5) is also something that can be passed as the second argument to 'module-use!' <mark_weaver>ahmedtd: no, it's an option of 'define-module', which is the preferred way to define modules in guile. see section 6.19.3 of the guile manual, and look in the guile source code for many examples. <mark_weaver>e.g. look at ice-9/safe-r5rs.scm, which incidentally contains the definition of 'null-environment' although you shouldn't copy that because it makes use of undocumented interfaces that might go away in the future. but it has 'define-module' at the top with #:re-export <ahmedtd>Is it only possible to define one module per file in guile? <ahmedtd>Or does it just stay in effect until the next (define-module) ? <mark_weaver>I would have to investigate the possibility of defining more than one per file, but I don't know how it would interact with things like our handling of *.go files, etc. <ahmedtd>Well, then I'll just stick to one per file <taylanub>compiling a 250-line file of mine that uses some heavy macros takes 20 seconds on 2.0.11, tested with ',time (compile-file "foo")'. macro expansion seems to take 2 seconds, tested with ',time (begin (macroexpand '(include-from-path "...")) #f)'. when I output the tree-il object returned by macroexpand into a file, it's 2.5MB. how can I best take on optimizing this? <amz3>taylanub: what does the macro? <amz3>obviously I can't help with the optimization <amz3>still it's interesting to read someone else code :) <amz3>I have question: why are you doing `let` inside the `define-syntax` for instance in `bytestructure-ref-helper*` <amz3>it seems to me that you are just renaming the variables <taylanub>amz3: syntax-rules pattern variables don't behave like normal lexical variables. if the <bytevector> input to the macro is an expression, like '(some-heavy-function-call-returning-a-bytevector)' then it will be inserted in every place in the code where I put <bytevector> in the syntax template <amz3>`let` will force evaluation of the matched pattern <taylanub>yeah, it will evaluate it once and bind it to a variable. and if it was already a variable then that's no problem because our compiler isn't that dumb :) (it would be a very tiny overhead at most anyway) <amz3>thx. I don't well enough marcro. I though that macro passed "matched values" as syntax objects or proper values <amz3>but here it's seems to matched object is something else <amz3>btw I like the syntax you propose. I did not fully understand the reason until now. <taylanub>it does pass them as syntax objects. for example a syntax object wrapping a function call expression. then when that syntax object is inserted multiple times in the output, it means the expression is evaluated in each such place. <amz3>so syntax objects can be "manipulated" and "evaled" <taylanub>yeah, they can be manipulated and inserted into code, and will be evaluated/executed when the code is run. (they generally can't be evaluated explicitly.) <sneek>davexunit, you have 2 messages. <davexunit>paroneayea: saw this last night via your pump.io account. very cool stuff. <davexunit>similar to what I had in mind: a struct per SQL construct rather than quoted lists <ArneBab_>taylanub: Do I spot it correctly that for each of the ~30 numeric descriptors you generate 50 lines of code? <taylanub>ArneBab_: hah, commenting out the use of test-numeric-descriptors reduced the time to 2.7 seconds! thanks :-) <__uu__>hi, is there any recommended guile toy project? <amz3>I just merge develop into master <amz3>__uu__: there is three high level projects I know: sly the game engine written by davexunit <amz3>there is #guix that is the gnu package manager and os <amz3>there is artanis the web framework <amz3>there is also "haunt" static blog engine <amz3>I read, i interting toy TODO item in skribillo which involves rendering some skribe text into pdf <amz3>there is cairo binding, so you can use that <amz3>__uu__: I think I did not understand your question <amz3>__uu__: what do you mean ? <__uu__>sorry for a late reply. I want to find some toy projects written in guile to practice. <__uu__>so I can play with it with my limited guile knowlege.. <amz3>I think haunt is a good candidate <amz3>but __uu__ what are you interested in? <mark_weaver>__uu__: I'm still a bit unsure what you are looking for. you're looking for an existing project to contribute to? or some example code to study? <mark_weaver>there's such a wide variety of code, it's hard to know what to recommend. <__uu__>amz3: I dont know what I like in fact.. <__uu__>maybe I am asking a stupid question <mark_weaver>__uu__: I don't think it's a stupid question, I'm just trying to understand clearly. <__uu__>mark_weaver: currently I am like a boy in total dark <mark_weaver>somewhere, I have a bunch of solutions to "project euler" problems written in guile <__uu__>I have been working on computer vision, but guiles does not seem to support that well <amz3>(an advice that I find good is "take a problem/subject you are interested in and study it, hack on it" it can be difficult at times because you stumble upon much more difficult code that you are looking for) <amz3>(eventually you climb the ladder) <amz3>I use to find euler problem kind of dull, but actually it's interesting <__uu__>amz3: what is the most interesting project have you done? <mark_weaver>__uu__: at present, guile is not fast enough to do heavy image processing in pure scheme, but one of the design ideas of guile is to allow easy mixing with C, so the higher-level logic can be in scheme and the hot code can be in C. <amz3>it's not scheme, it's a python to javascript translator. But stopped because it was just interested in knowing if I could do it :D <__uu__>mark_weaver: yeah, mixing with C is super easy. But the problem is that most of my code is written in C++ <__uu__>take opencv for example, I have to convert all my functions to its c interface to work with guile <amz3>there this pypy project always talk about, I will just port it to scheme if so much people look for c++ bindings <mark_weaver>and I would expect that the power of scheme could be very valuable for implementing the higher-level aspects of computer vision in an elegant way, although I confess to being mostly ignorant of that subject so maybe I'm wrong. <amz3>it's called cppyy it allows to bind c++ code <__uu__>amz3: yeah, cppyy seems a big project <amz3>__uu__: that said my current project is more exciting, it's opencog, an advanced IA, it could make good use of opencv <mark_weaver>hmm, yes, we don't have good integration with C++. it would be good to improve that, although I'd like to keep C++ out of core guile itself. <mark_weaver>but we should probably have an additional (optional) library written in C++ to help with C++ integration <__uu__>amz3: oh! you are the author of opencog!! <amz3>__uu__: no!! I'm just fiddling around opencog, linas is. <amz3>to be precise, I build a backing storage in scheme to prototype <amz3>the backing store is central in opencog, that where everystarts and end <amz3>it's a programmable database (or wanna be) <amz3>but really it's crazy project, I'm not sure anything useful we come out of it, except that will know better scheme and opencog <amz3>(basically I take note using code) <amz3>I read nothing about opencv integration in opencog <amz3>if you are into machine learning there room for contribution <__uu__>mark_weaver: amz3: when you say improving c++ integration, what do you mean? It sounds easy, but I don't think so <mark_weaver>well, one thing that has recently been brought up is to allow guile exceptions to integrate with C++ exception handling <__uu__>but exception does not seem like the most essential part <mark_weaver>obviously it would be great to extend our dynamic FFI to call into C++ libraries, but that seems like a very big job <__uu__>I only wish the maybe c++ integration did not become another SWIG <amz3>what is the problem with SWIG? <paroneayea>page-break-lines makes reading guile source so much nicer <paroneayea>(setq page-break-lines-char (string-to-char "┄")) <__uu__>amz3: I prefer to the way of c integration in guile <davexunit>paroneayea: the guix source includes many page breaks <civodul>paroneayea: don't miss C-x ], C-x n p, and the likes <davexunit>always something new and amazing to learn in Emacs <paroneayea>"C-x n s" is one of my favorite narrowing commands, narrowing subtrees in emacs <amz3>civodul: how do you type C-x ] on an azerty keyboard? <civodul>Emacs gives a strong incentive to do that ;-) <ArneBab_>amz3: I use either neo-layout.org or my own layout. Emacs actually gets better to use with an optimized layout. <ArneBab_>who needs hjkl if n and p are on the baseline? <amz3>I will consider this once I buy an ergodox <amz3>I'm super proud of the name of my new project: culturia <amz3>it's competly a reference to cultureandempire.com the book by peter hinjens <amz3>and the SF book of Ian Banks <amz3>in Culture & Empire, Peter Hinjens argue that "in a few decades spyig will be so cheap in terms of speed that everybody will be doing it" <amz3>he is kind of blind, because I think the problem is not really processing speed but software <amz3>how come that there is not software to create summary of texts in libreoffice or evince? <davexunit>so guilers, I often find myself wanting a record type macro that defines a constructor that uses keyword arguments and allows inheriting from other records of the same type and changing only specific fields. <davexunit>turns out this was easy to implement as a syntax-rules macro: mutating <davexunit>inspired by guix's define-record-type*, but *much* simpler. <davexunit>I should ask guile-user, too, but does anyone else want stuff like this? <serhart>davexunit, almost every time I define a record I end up writing something like this <paroneayea>yes, would be useful to have a formalized version <paroneayea>davexunit: there are some ways in which maybe it could be enhanced too, maybe having defaults for the keywords, but that would admittedly be much more complex than the minimalist version you pasted <davexunit>the above macro is for immutable records only, but immutable records are the ones that benefit from this the most. <davexunit>paroneayea: there's syntax for default field values <davexunit>in the example code, (make-foo) and (make-foo #:bar "bar" #:baz "baz") are equivalent <paroneayea>I was looking at the (field getter)... and forgetting how magical match could be <davexunit>I write macros on intuition and it usually just works <amz3>it's some kind of prototypal inheritance <amz3>yes, it's useful in the context persistent record <davexunit>except there's no subtyping involved. it's to reduce tons of typing when you want to change one or two fields of a big immutable record. <davexunit>I'd also like to take this time to say that define* is incredible. <davexunit>allowing default argument expressions to refer to previously defined arguments is brilliant. <amz3>inherit is not the best word <amz3>since it's a partial clone <davexunit>I borrowed the Guix terminology. I would use a better name if there is one. <davexunit>(make-foo #:inherit thing #:baz "hi amz3") reads pretty well, I think. <amz3>honestly I would prefer something like (inherit-foo thing "hi amz3") <amz3>but maybe it doesn't cover all the required surface <daviid>for me it looks terrible :) folks, use goops instead <daviid>this goops fear is just 'bizare', try it first <davexunit>this has nothing to do with OOP. I've used GOOPS. I write in an OOP style for money. <davexunit>this is for providing syntax that makes it easy to alter immutable records. <davexunit>you can definitely think the syntax is terrible, though. that would be fair. :) <amz3>I use a lot of keyword arguments in python, but did not have the occasion to use them much in guile. don't know why. <daviid>calling something 'inherit' or 'inherit-from', then saying it is to easy alter an immutable record is, well, suspect :) i won't discuss this further though, i'm too busy [should have even written the first comment :)] <amz3>daviid: in javascript the equivalent of inherit does that <daviid>amz3: i really don't care what a brain damaged language did for its design :) <amz3>even if the it brain damaged prototypal inheritance is interesting <davexunit>perhaps 'inherit' is the wrong word to be using here. seems to be causing too much confusion with what we know as inheritance in OOP. <davexunit>maybe (make-foo #:copy thing #:bar "less confusing?") <amz3>but OOP should not be thinking master <amz3>I think given prototypal paradigm, "inherit" makes sens <davexunit>I don't think this qualifies for prototypal inheritance a la Self <civodul>i think it's fine to use 'inherit' and dismiss its OOP meaning <civodul>we want to live in a future where minds aren't polluted by the Gang of Four <davexunit>what do you think of the macro? of course Guix's define-record-type* is more robust, but I was aiming for something that is less of a DSL. <davexunit>and didn't need thunked fields and all that. <davexunit>I'm going to use it in Sly. I've wanted this in lots of places, but didn't want to snarf 'define-record-type*' from Guix. <civodul>it won't make it an error when trying to specify a non-existent field <civodul>but you'll get a compile-time warning <civodul>BTW did you look at 'set-field' in (srfi srfi-9 gnu) <civodul>not sure if that's as convenient/appropriate <davexunit>maybe it's more efficient than what my macro does, but leveraging the features of define* greatly simplified things. <civodul>set-field is optimized for the complex case ;-) <davexunit>I've tried to use it along with define-immutable-record-type but unfortunately found it lacking. <paroneayea>it's really nice when you want record instances that are derivative of others <amz3>I use guix's define-record-type* all-the-time <davexunit>my issue with define-immutable-record type is that, setting aside the 'set-field' syntax for a moment, changing N fields of a record requires constructing N new records. <davexunit>and the 'set-field' syntax is just too awkward for my tastes. <davexunit>being able to change nested fields is a cool feature, though. <civodul>set-fields (plural) creates just one record <civodul>the thinking was that we needed a super-duper functional construct if we were to displace imperative programming <davexunit>I might update my macro to use define-immutable-record-type, though, and use the functional setters. <davexunit>provided that doesn't add some overhead I'm not aware of. <davexunit>hmm keyword quoting a syntactic variable doesn't work as expected <davexunit>have to use (symbol->keyword 'syntax-variable) <davexunit>civodul: if you would like to humor me, what do you feel is wrong with the gang of four? (I'm not a fan either) <cmhobbs>davexunit, just came from loadaverage to ask the same :D <davexunit>I find myself pretty consistently wrestling against Ruby to do things that are easy in Scheme. <cmhobbs>davexunit, i think the converse is true to some degree as well <cmhobbs>anyway, not starting a holywar... programming is hard <cmhobbs>and i generally dislike ruby, though it pays my bills <cmhobbs>perhaps it has to do with how much of scheme i have at the forefront of my brain <davexunit>Ruby lacking lexical scope is enough to damn it in my mind. <cmhobbs>i'm not really steeped in scheme so i stumble a lot <cmhobbs>it's easier than some languages, though <cmhobbs>as i used common lisp for quite a while <cmhobbs>anyway, i sound like i'm arguing for ruby here <davexunit>I was thinking about implementing a memoization macro in Ruby and the amount of problems I have to consider that are non-issues in Scheme is astounding <cmhobbs>ruby comes naturally to me because i use it for 8 hours a day <davexunit>mostly owning to the fact that there's no lexical scope. <taylanub>today I learned bytevector-u16-native-ref may error on non-aligned access, i.e. the given index must be a multiple of 2. 4 for u32, 8 for u64. <taylanub>it works in Guile, but something to keep in mind for portable code... <civodul>ACTION discovers huuuuuge backlog in guile-devel <paroneayea>civodul: there's a nice (ice-9 json) in there too! :) <mark_weaver>civodul: the SRFI-25 implementation from andreas has problems, e.g. he seems to not know that all vectors are arrays. <mark_weaver>(there are several 'cond's that first test to see if something is an array, and then a later case checks to see if it's a vector) <davexunit>civodul: mark_weaver asked me to look at the sxml patch from rekado, but I haven't gotten around to it yet. :/ <davexunit>civodul: I think it's pretty good. I don't love it, but I don't disapprove. <paroneayea>civodul: I really like it, and I like the compact version <mark_weaver>civodul: I mean that at first I wasn't sure if I liked it, but over time I've grown to like it more. <paroneayea>I feel like maybe the way the G intersects with the next paren could be better, but that's a nit. <paroneayea>also the "omg too google" responses don't make sense since this precedes that <davexunit>of all the color options, I like the light blue. <paroneayea>I suggest we swap out the color on each page reload ;) <davexunit>paroneayea: yes we need to over-engineer this somehow. <davexunit>paroneayea: that feature will require adding dynamic server-side scripts to GNU's web server. perfect for wasting time! ;) <mark_weaver>taylanub: I think that something needs to be done to make the SRFI-123 implementation more efficient. I'm afraid that people are going to use it, because so many people like things like that, and then they'll yell from the rooftops "guile is 10 times slower than python" because of it. <rotty>mark_weaver: thanks for the feedback; i guess a ML post is forthcoming? <mark_weaver>rotty: I apologize, I've been overloaded (mostly with child care duty I'm afraid) <mark_weaver>rotty: also, I wonder if you couldn't make good use of (ice-9 match) to reduce the number of calls to 'car', 'cdr', 'cadr', etc. <paroneayea>davexunit: well, we need to land ijp's guile->js stuff <davexunit>rekado: I've been hesitant about your SXML patch partly because SXML just plain doesn't understand namespaces, and a proper fix might entail more work. <rotty>Nothing to apologize for - the patch is not high prio, otherwise i'd have re-posted <davexunit>civodul: re: guile-json: that is also pure Scheme, but has implementation issues. <davexunit>using macros, hash tables instead of a persistent structure, etc. <rotty>mark_weaver: iirc, i just minimally adapted the reference implementation <mark_weaver>rotty: okay. well, in guile, (array? <vector>) => #t and the array operations work on vectors as if they were arrays of rank 1. <paroneayea>sxml + namespaces is something I'd really like to see in the future <mark_weaver>so the code needs to be aware of that. right now, in the cond statements that first check for an array and later a vector, the vector case is dead code. <mark_weaver>rotty: also, the module should contain a call to (cond-expand-provide (current-module) '(srfi-25)) <mark_weaver>davexunit, paroneayea: I'm not sure I'd go so far as to say that SXML doesn't understand namespaces. most of the code is written to take into account namespaces, but I think the idea is that code that manipulates SXML shouldn't need to think about namespaces at all. the namespaces should be taken into account during the sxml->xml and xml->sxml conversions. <mark_weaver>if you look in module/sxml/upstream/SSAX.scm, clearly it was designed to support namespaces. <davexunit>mark_weaver: then perhaps rekado's solution is just fine, then. <davexunit>I need to take a more thorough look over it all. <mark_weaver>davexunit: one important property is this: we need to be able to convert xml->sxml and then back again without changing the meaning of the document. <taylanub>mark_weaver: ugh, I didn't think about that :\\ I haven't done any profiling but an efficient 'type-of' might help. anyway, for the time being I'll leave it be; other things have higher priority. <mark_weaver>and also, the symbols used in the SXML need to be such that the application won't be confused by namespaces <mark_weaver>taylanub: the whole thing with checking one type at a time is really bad <mark_weaver>taylanub: probably you should use GOOPS, because that's where we have optimized type dispatch, and likely to get faster in the future. <davexunit>mark_weaver: one of the questions I had was: should this information be encoded in the SXML? but after reading your thoughts, it seems that the answer is "no" <taylanub>ok, I'll look into GOOPS on my next iteration of a Guile-specific SRFI-123. <mark_weaver>davexunit: well, the application needs to be able to tell 'xml->sxml' how the namespaces should be mapped to symbol prefixes, so that e.g. if an application is expecting to work with SVG, it can ask that SVG elements have no prefix, and other namespaces that it doesn't know about will be mapped in a different way. <mark_weaver>so that if the application sees a 'g' node in the SXML, it knows that's really the SVG 'g' and not 'g' from some other namespace. <taylanub>I was also not sure about the 'register-blah!'. I figure one might define record types concurrently, and it could screw up there. using GOOPS would solve that too I guess. <davexunit>I suppose that makes the case for a namespace alist to exist outside of the sxml objects <davexunit>I believe that's what rekado's patch adds, iirc. <civodul>davexunit: ooh i thought guile-json was bindings to json-c <mark_weaver>davexunit: but one question is: what happens if a namespace is encountered in the document that wasn't in the alist. <paroneayea>civodul: btw I am already using davexunit's ice-9 json pretty extensively in my activitystuff repo <mark_weaver>davexunit: regarding your JSON module, one thing I'm not sure about is the use of #nil. I would prefer to avoid the use of #nil whenever possible. <davexunit>civodul: I'll reply properly in the ML, but I took a look at (language ecmascript parse) and I don't think it's fit for (ice-9 json). JSON isn't *really* javascript, after all. <davexunit>I used that *before* I knew of #nil's origin and intended use-case <davexunit>mark_weaver: guile-json used #nil, and I should've known better than to copy from it. ;) <paroneayea>I thought it was a pretty natural mapping, though... I did have to replace a whole bunch of my code from being null? to (eq? x #nil) <mark_weaver>paroneayea: I'll leave that to you and davexunit to figure out :) <mark_weaver>the problem with #nil is that it has muddy semantics. we don't know whether it's a boolean or an empty list, and we can never really get that right. it's a hack to cope with the fact that those two very different concepts are conflated in lisp. <mark_weaver>if it were up to me, I would try to find a way to transition away from the use of #nil and toward distinct #f and () <paroneayea>so, are my suspicions confirmed that #nil is kind of the intermediate "it's kind of both" representation of '() and end-of-list test as null? <mark_weaver>but there's no way to get it right. all we can hope for is to get something that works most of the time. <paroneayea>I didn't realize it until I became more of a schemer but <davexunit>paroneayea: there's some issues with using literal symbols like that, because they may be used as object keys as well. <paroneayea>I do agree that nil being the "only falsey" *and* being an empty list <davexunit>and the notion that functions are different from other objects ;) <paroneayea>I didn't get why it bothered me until I ended up doing so many tests for '() vs #nil vs #f in json-ld transformations <paroneayea>where the algorithms do VERY different thinggs in all cases <paroneayea>davexunit: if you're fine with 'null anyway, I am too <davexunit>paroneayea: we could use something like (define null (cons 'json 'null)), but then users have to unquote that in their json expressions <paroneayea>davexunit: that would namespace it a bit but I think 'null is fine and here's why: <paroneayea>'@ and 'null will be the *only* symbols in sjson <davexunit>and we'd have to eq? check for that. srfi-41 does this. <paroneayea>and so '@ and 'null being the only symbols simplifies a lot of code <davexunit>paroneayea: but '@ is perfectly usable as an object key <paroneayea>if we were permitting arbitrary symbols as strings then <paroneayea>davexunit: it isn't in sjson->json string is it? <paroneayea>I think it's valuable that sjson does not permit symbols as keys <paroneayea>oh, well I understood wrong then. I think having '@ and 'null be the only acceptable symbols is a huge win <paroneayea>and '(@ ("foo" . 1) ("bar" . 2)) still looks pretty nice <mark_weaver>davexunit: yeah, I'm also a bit unsure about accepting symbols <davexunit>I think sjson loses some elegance when you *have* to use string keys. <paroneayea>davexunit: is '(@ ("foo" 1) ("bar" 2)) permitted also? hm <davexunit>mark_weaver: the set of valid JSON object keys is not equal to the set of valid Scheme symbols <paroneayea>plus having to coerce strings to scheme symbols would really be a pain in my butt. <davexunit>so I think enforcing strings and not optionally allowing symbols is the way to go. <mark_weaver>davexunit: oh, well, any string can be a symbol, although some need to be quoted. <mark_weaver>davexunit: enforcing strings is probably best, I suppose. <davexunit>paroneayea: I don't understand the "coerce" part <davexunit>paroneayea: actually, using 'null shouldn't cause any issues <davexunit>but picking either strings or symbols always would be good, but either choice shouldn't cause any issues <paroneayea>now that you mention it, parsing the parts with keys <paroneayea>okay, so I'm fine with that potential feature, though I will def stick to strings myself for keys :) <davexunit>well, we should pick one to ensure that (equal? stuff (json->sjson (sjson->json stuff))) => #t <davexunit>I lean towards symbols, but curious to hear why strings <paroneayea>sneek: later tell davexunit: Well, here's two compelling reasons: the json-ld algorithms require sorting strings alphanumerically, so I'd have to coerce to strings then back anyway, and another reason is that strings with all kinds of symbols that are not "basic symbol friendly" is more than common, including whitspace and who knows what, and that just won't *look* nice in code to print out the way that quoted symbols look <taylanub>for those interested, Bytestructures's bit-field layouting behavior is now verified to match that of GCC, via a piece of code that auto-generates tons of C code and the corresponding Bytestructures code and compares their output ^_^ 
