When I saw your change, I liked it. I think it's pretty weird for news.arc to be part of lib/.
I get the impression lib/ was created in Anarki to declutter the root directory, and people weren't sure if news.arc objectively wasn't a library or if they just hadn't thought of how to use it as a library yet, so it went into lib/ and stayed in there like the rest of the less essential .arc files. :-p
I think a stable branch is a good idea. People can experiment elsewhere while not stepping on anyone's toes.
>Ideally we can get to a point where you can just repo your own app and marry it with a tagged release while collectively the app users can report any breaking changes.
Currently, it looks like "apps" are mapped to an admin namespace and will only work for that user, so that would need to be changed to make them portable.
Another option is to have stable branches/tagged releases.
As for "breaking things harder and more often". I don't think 'harder' has to happen 'often'. I'd be ok with 'harder' when need be with more 'often' being good.
This language has 3-6 people active users and maybe another 6-10 lurkers. More changes like the app/news change have potential to garner more users and more users means more changes which may lead to a fuller and richer language.
Having the news app so heavily integrated was a poor design choice to begin with. This is a language and the language development should not be constrained by a single application which is currently the case. That app needs to be a downstream consumer of the language.
Ideally we can get to a point where you can just repo your own app and marry it with a tagged release while collectively the app users can report any breaking changes.
If we don't do this the language is dead for all but a hand full of hardcore arc lovers + news appers.
> We should be breaking things harder and more often.
That line of thinking is completely incompatible with my requirements as I'm using News for my own web page that sort of needs to work. Fork time, I guess.
For what it's worth I agree with the app/news changes. So Good Job I say.
And with that said, after looking at the anarki directory it's apparently becoming a dumping ground for people to place files at the top level. I'm not sure why this is happening, but I hope others take a look at what you have done with app/news and continue the trend of organizing things better.
Ok. I will try to be more careful in the future. In fact, I won't even merge until someone looks at the commit, fair enough?
It isn't broken, though, at least not if "broken" implies an unusable state. I did test the forum before I pushed, I just didn't catch everything... I didn't even know prompt.arc existed, or what it was for, but apparently neither did you. ;)
But news does still work. It just doesn't work from the same location as previously, which I think is hardly setting fire to the store.
The risk here is that everytime a newcomer tries out our codebase and finds it broken, we lose a potential recruit. And we don't have so much incoming attention that we can afford to be lax with it. Our situation is akin to a store that is mostly empty: we can't afford to just shut down longer, because that way lies death. We have to stay open for business.
Not allowing in obvious breakage is also a way to show respect for your collaborators, other people programming on the same codebase. When you come to Arc you would be demotivated if the news app didn't work, if you had to first get it working, figure out who broke it and how. It's the same with others. When we find a few hours to hack on something fun, we all prefer that it start out in a non-broken state. And we try to leave it in a non-broken state.
So I have a suggestion for you: everytime you create a PR, first try to break it yourself. Ask yourself what changed, and what it may affect. Try to catch the really obvious stuff yourself, like "does news load, does it look the same, can I submit a post?" Run the unit tests. Report in the commit message or PR what all you did by way of testing. These exercises will make you a better programmer. Tell yourself that the goal is to make changes in an efficient manner, solve the problem in a single PR, rather than require more changes to fix breakage in one change, that cause their own breakage, and on and on.
None of this is particularly serious. It's not like any breakage here is a deal-breaker. As long as others see you making an effort to get better I think you'll get a lot of support.
>It breaks anything relying on `run-news`. For example if you have Anarki running as a systemd unit, you'll have to fix that.
Fair enough, although I would point out that, given that this is a language designed for experimentation with an open commit policy, breaking changes should be tolerated and expected if the end result improves the codebase, which in this case I believe it does.
Given that is not a mature language or a stable framework yet, I would disagree that breaking changes, per se, should be avoided as a matter of course. We should be breaking things harder and more often.
And... people just have to fix it once. No one is suggesting a new hierarchy every week. Literally, just that applications should live somewhere other than /lib.
> It creates an overcomplicated folder hierarchy for the Anarki package manager, e.g. if you add a custom app through prompt.arc, it will now be in `anarki/apps/news/www/apps/[user name]/[app name]` rather than `anarki/www/apps/[user name]/[app name]`. Is it really necessary to have another `apps` folder inside the `apps` folder? Why?
The package manager should be updated as well, mea culpa. But that demonstrates that the forum should have been moved to begin with, since it didn't conform to that convention. Also /anarki/www/apps/[user name]/[app name] is more complicated than the convention I want to use, which is /anarki/apps/[app name].
> Perhaps when new stuff is added, it is fine to break things, but what new features does this commit bring, or what problem does it solve?
It solves the problem of the forum being in the same path as the library. Every other language with a web framework separates one from the other.
>Again, sorry for being negative here. Am I being unreasonable?
For the criticism? No, I'm the newb, my last commit was kind of garbage, I can take it and I welcome it.
For wanting to give up and switch forks because I moved some code into a new folder? I think that is a bit unreasonable. Try to meet me halfway here, I'm not just breaking stuff for the lulz.
I hadn't tried running it yet. You also make some good points that I hadn't immediately considered just from scanning the change. I wasn't aware of prompt.arc, for example. Thanks.
I'll just quickly give my unrequested view about your commit[0] changing the directory structure, and again I am sorry if I come across very negative, but I'll try to be constructive in my criticism:
- It breaks anything relying on `run-news`. For example if you have Anarki running as a systemd unit, you'll have to fix that.
- It breaks existing News sites because it expects the `www` folder to be in a different location.
- It creates an overcomplicated folder hierarchy for the Anarki package manager, e.g. if you add a custom app through prompt.arc, it will now be in `anarki/apps/news/www/apps/[user name]/[app name]` rather than `anarki/www/apps/[user name]/[app name]`. Is it really necessary to have another `apps` folder inside the `apps` folder? Why?
- Perhaps when new stuff is added, it is fine to break things, but what new features does this commit bring, or what problem does it solve? I am not sure what this ongoing shuffling around paths and files really helps, but it sure does break stuff. Would it not be more interesting to work on new features for News or new programs in Arc than bike shedding existing code?
I think you should really just check out the existing Arc package manager, prompt.arc. It does have a way of separating user apps from the rest of the Anarki repo. It can be used from within News, but perhaps it needs to be documented more in the README and shown more prominently in the News interface?
I am not saying what commits should stay or go, as the idea with Anarki is that it's open for everyone's commits. However, I do find this folder shuffling somewhat disagreeable, so perhaps I should just keep my own Anarki fork?
Again, sorry for being negative here. Am I being unreasonable?
I was assuming it would work like PHP where dependencies are just cloned into into a local /vendor folder namespaced by owner/repo.
But that assumes there's a package manager, which assumes there's a consensus and standard around package management, and namespaces, and modules, and... we can just stick a pin in that for now.
Heh, I really hope there never comes a day when Arc has vendor code. I'd really like for it to continue encouraging people to hack on their dependencies. And that requires keeping the code nearby. So a separate directory for apps is fine, and you're right that it allows versions of the same app to coexist. But hopefully we never start shoving libraries into a system path..
>Currently you get in trouble when two libraries have a variable with the same name.
Ha. Yeah. (cough (body) cough).
>I'm not sure what you'd consider problematic about news.arc being in the lib folder
It's not news.arc per se, it's everything belonging to the forum (folders, static files, tests, etc) and the general practice of keeping applications in the same place as the standard library (for want of a better term.)
>(But also: why?)
As long as Arc only has a single application (ignoring the blog, which no one seems to care about) then it doesn't matter... but once people want alternate versions of the forum, or other applications, or once remote dependency inclusion becomes a thing, then separating the core from application and vendor code makes things far better organized than including everything into a single directory.
It is indeed a problem that Arc doesn't have private module scope. Currently you get in trouble when two libraries have a variable with the same name.
Rocketnia has done some work on namespaces in anarki/lib/ns.arc but I haven't had too much of a look at it yet. I would personally appreciate if there was a little bit added to the README about how those work.
I'm not sure what you'd consider problematic about news.arc being in the lib folder, but if you'd like to put it in another folder, then why not? (But also: why?)
T-expressions are my attempt at answering the question 'what's the minimal clean notation for expressing Prolog terms in S-expressions?'
PicoLisp's Pilog, for example just decides that 'a term is a list'. Which is very clean and simple - but unfortunately it means you can't distinguish between a term AND a list, and it's often very important to tell the two apart.
So the simplest solution is just to reserve one symbol (I use '/' because it's available and not special-syntax on most Lisps... though any symbol would do, and if I were writing from scratch, I might think about repurposing '.') to indicate 'the start of a Prolog-like term'.
The rest of that post series is really just about teasing out some of the implications of this, because I think it opens a lot of interesting possibilities for adding a very minimal notion of 'typed expression' to Lisp. Minimal in that there is no specification of what the meaning of a type is; just that a certain expression is more than just a raw list.
There's a number of applications of this: we can replace almost all special non-S-expression 'reader macro' syntax, for example.
Also having lists which are not Lisp functions/macros means we could implement 'implicit cons', which allows us to drop a lot of complexity in list-builder expressions. For example:
If x were (a b) and y were (c d e) then a standard Lisp expression might look like this:
(cons 1 (cons (car x) (cdr y)))
giving
(1 a d e)
But if we had a Lisp where function calls (or all forms) were term-expression terms, ie prefixed with '/', then we can write that expression as:
(1 (/ car x) / cdr y)
Suddenly we get a lot cleaner notation... fewer nested parens, less awkward syntax, and we can apply this technique to a lot of things.
For another example: say we had a list which was generated from a procedure (local or remote) and we wanted to show that it continues at a remote website:
where "more-at-URL" is either a function that evaluates to a list, or just a piece of syntax that's parsed by some higher level.
This is a basic "lazy list" technique, well known to Lisp people for decades.... but the fact that we don't need to hide it behind lambdas, we can do this inline and mark ANY list up with a CDR that is an arbitrary expression, I think is an important capability that is worth thinking about.
I also think that we can then take this syntax and extend it down to the level of formal logic, because what we are essentially doing is writing (slightly extended) First-Order Predicate Logic expressions... and so we might want to think about exact mappings between FOPL and our Lisp expressions. And vice versa: I think we need to look hard at what Lisp, especially the S-expression 'dotted pair' allows us to express that standard vanilla FOPL does not. And ask what that extra piece of information might imply for logic - in the vein of, eg, what the HiLog researchers found, since this is a very similar kind of syntactic extension to FOPL as HiLog is. See, for example, the 1980s Sinclair Spectrum MicroProlog, which uses S-expressions internally to store Prolog expressions, and which discovered the dotted-pair technique for FOPL expressions and called it 'meta-variables'.
Final note: My syntax in the blog posts assumes that I have a custom reader macro and so I don't put a space after the / wherever it appears, in order to make the expressions look a but cleaner... but if you were embedding T-expressions on top of S-expressions in an existing Lisp, you would put a space there. And also you'd need to sort out some way of disambiguating in all cases between /-as-symbol and /-as-syntax. This last bit might be a little tricky.
> Really, #t and #f are not proper Arc booleans[0], so it makes sense that Arc can't tell what type they are.
Really, #t and #f are not proper Arc anything, but the language apparently handles them so IMHO Arc should also be able to know what type they are. Otherwise, I fear, this will become a Hodge Podge language that will lose appeal.
Personally I don't care if Arc supports booleans. I only care that it can translate booleans (when need be) to a meaningful Arc semantic. That said, if we're going to support booleans then let's not create partial support.
That documentation may be wrong. On the other hand, it may be correct in the context of someone who is only using Arc, not Racket.
There are a lot of ways to conceive of what Arc "is" outside of the Racket implementations, but I think Arc implementations like Rainbow, Jarc, Arcueid, and so on tend to be inspired first by the rather small set of operations showcased in the tutorial and in arc.arc. (As the tutorial says, "The definitions in arc.arc are also an experiment in another way. They are the language spec.") Since #f isn't part of those, it's not something that an Arc implementation would necessarily focus on supporting, so there's a practical sense in which it's not a part of Arc our Arc code can rely on.
(Not that any other part of Arc is stable either.)
Having nil represent both false and the empty list is also what Common Lisp does.
Really, #t and #f are not proper Arc booleans[0], so it makes sense that Arc can't tell what type they are.
You can configure the value Arc chooses for a JSON null with the $.json-null function, which I think is fine as JSON APIs might have differing semantics.
But now that I look closer at the ac.scm history (now ac.rkt in Anarki), I realize I was mistaken to believe Arc treated #f as a different value than nil. Turns out Arc has always equated #f and 'nil with `is`, counted them both as falsy, etc. So this library was already returning nil, from Arc's perspective.
There are some things that slip through the cracks. It looks like (type #f) has always given an "unknown type" error, as opposed to returning 'sym as it does for 'nil and '().
So with that in mind, I think it's a bug if an Arc JSON library returns 'nil or #f for JSON false, unless it returns something other than '() for JSON []. To avoid collision, we could represent JSON arrays using `annotate` values rather than plain Arc lists, but I think representing JSON false and null using Arc symbols like 'false and 'null is easier.
For round-tripping between JSON and Arc, I would expect the JSON values {}, {"foo": null}, {"foo": false}, and {"foo": []} to parse as four distinct Arc values.
I recommend (obj), (obj foo (list 'null)), (obj foo (list 'false)), and (obj foo (list (list))). Arc is good at representing optional values as subsingleton lists:
; Access a key that's known to be there.
t!foo.0
; Access a key that isn't known to be there.
(iflet (x) t!foo
(do-something-then x)
(do-something-else))
Using my `sobj` utility, you can write (obj foo (list 'false)) as (sobj foo 'false).
Meanwhile, I don't think there's any big deal when we don't have Arc-style booleans....
; Branch on the symbols 'false and 'true.
(if (isnt 'false x)
(do-something-then)
(do-something-else))
; Alternative
(case x true
(do-something-then)
(do-something-else))
> This parameter determines the default Racket value that corresponds to a JSON “null”. By default, it is the 'null symbol. In some cases a different value may better fit your needs, therefore all functions in this library accept a #:null keyword argument for the value that is used to represent a JSON “null”, and this argument defaults to (json-null).
If you set the JSON null to nil before running your example, it works as you'd expect:
I think we should get rid of json.rkt and use the Racket built-in. It's way better documented, and we should use that one. (But I'm not going to delete json.rkt myself, particularly when I know someone is working with it.)
