Arc Forumnew | comments | leaders | submit | krapp's commentslogin

Whatever they are, they aren't exactly tables. We can't use Racket's JSON parser on forum data because of that.

I think they are supposed to be tables, though.

reply

3 points by zck 18 days ago | link

Interesting. At least for `len`, it can be fixed with a `defextend`, I believe. (https://github.com/arclanguage/anarki/blob/master/arc.arc#L2...)

To Chesterton's Fence it, though, I am not sure if templates are intended to work differently.

reply

3 points by zck 18 days ago | link

`len` will work with templates after this PR: https://github.com/arclanguage/anarki/pull/182

I'm leaving it unmerged for now until we can see if we can make templates work like tables for all things, except the changes we _want_.

reply

3 points by akkartik 18 days ago | link

I've always implicitly assumed that tables were just an implementation detail for templates, and assumed they were like objects. I think that might be why it never occurred to me to apply `len` on a template, and why a large program like news.arc never ran into this gap.

I have no objection to your approach of making them more like tables. I also have no objection to updating the documentation to stop referring to them as tables. One of those options might be less work than the other :)

reply

3 points by zck 17 days ago | link

> I've always implicitly assumed that tables were just an implementation detail for templates, and assumed they were like objects. I think that might be why it never occurred to me to apply `len` on a template, and why a large program like news.arc never ran into this gap.

Ah, interesting! Here's some background that might help understand why having them act like tables might help. `len` wasn't the first function that I found didn't work with templates; it was just the simplest. I was working on adding teardown functionality to unit-test.arc, and I wanted to look at some of the suites that were created, to see if I was adding tests properly. As the templates end up pretty big (one suite with two tests is about 25 lines), and it was late at night, I figured I'd make it simple on myself, and just look at the keys of the template.

This had nothing to do with the desired "production" code, but only with REPL-hacking introspection.

I want to make them reasonably easy to REPL-hack with; whether they're actually tables or not I don't particularly care right now. The most important table functions are probably len, keys, vals, and maybe maptable/each.

reply

2 points by akkartik 17 days ago | link

How about some rep-hacking rather than REPL-hacking? :D

   (keys rep.tem)

reply

3 points by zck 16 days ago | link

Haha, that certainly works. It brings up the question of "what Arc internals should people need to know about?". I've never looked into Arc's tagged types until this issue.

reply

2 points by akkartik 16 days ago | link

My answer to that question has always been, "it depends." The anti-encapsulation ethos (homoiconicity, using lists where other languages may use objects, the entire compiler fitting in one file and being accessible front-and-center, etc.) means that there's always the ability to peel back another layer of the onion when it becomes relevant.

reply

2 points by krapp 16 days ago | link

I think it's a documentation issue. I think I had to search the forums to find out about it when I was playing with JSON interop. Nowhere on the actual template page in the Arc documentation does it tell you this is a thing.

Some things I've only been able to figure out by studying the compiler or arc source code itself. Granted, that's illuminating, but it's also sometimes really annoying.

reply

2 points by rocketnia 15 days ago | link

"to find out about it"

Sorry, to find out about which part?

reply

2 points by rocketnia 15 days ago | link

Ah, I think I understand: The fact that you can call `rep` on a template instance.

reply

1 point by akkartik 15 days ago | link

Indeed. It never occurred to me to write about this. Would you be interested in writing something up? I can help you wrestle with the documentation system if you like.

reply

3 points by krapp 18 days ago | link

Templates should just enforce a signature for table fields, but otherwise decompose to tables. I think the issue is that the tables generated by (inst) from a template are annotated as type 'tem when that should (could?) be done with a tag that doesn't actually change the type. Since the template name is passed to the function, you could just build the table with default values without annotating it. You could also delete most of the template functions that just serve as template versions of table functions.

edit: I was also assuming templates type-hinted field values but I don't think they do. Maybe they should?

Also, does anyone else find it a bit odd that a language feature like this is in a lib file rather than being part of the core language?

reply

3 points by akkartik 17 days ago | link

Small languages take it as a mark of pride to move as much as possible into libraries :) The pitch is that the language is powerful, and nothing shows that like language features as libraries.

I was very proud in Wart that multi-branch ifs were a library feature. And check out this quote in a blog post about Forth:

    : (   41 word drop ; immediate
    ( That was the definition for the comment word. )
    ( Now we can add comments to what we are doing! )
(https://yosefk.com/blog/my-history-with-forth-stack-machines...)

---

I disagree with your vision for templates. If you just want something that behaves like tables, why not just use tables? A helper that fills in default values would be pretty easy to write.

Think about the use case of news.arc. There's a list of 'objects' that need to be serialized to disk and unserialized from disk. What should happen if you change the default for a template in code? Should the default update transparently for existing objects? If so, you need some way to distinguish tables that were generated by templates. Which implies something that manages them throughout their life cycle.

reply

2 points by krapp 16 days ago | link

>Small languages take it as a mark of pride to move as much as possible into libraries :)

Yeah, I've seen projects that show off the power of a language by doing "x in < 100 lines" that just don't count a remote API call with half a million LOC running on a server or something ;) But with language features like macros and templates that have become ubiquitous, I feel like it's kind of cheating not to just fold them into arc proper.

But that's just me... one thing I've learned being here is that I seem to flow against the culture more than with it, so I can just agree to disagree.

> If you just want something that behaves like tables, why not just use tables?

They are tables, that's what's frustrating. They're tables with metadata. From what I can tell reading earler posts about templates, they used to be something that behaves like tables. Interop between forum data and Racket (and any code where tables are expected) is awkward because that incompatibility has to be worked around, resulting in extra code and extra complexity. Templates need a separate API despite having the same behavior as tables.

>If so, you need some way to distinguish tables that were generated by templates. Which implies something that manages them throughout their life cycle.

Fair enough. But why is it necessary to change their type to do so? Why not make this a feature of tables as a whole, if it's useful? Or tag tables in a way that doesn't change their type, if that's possible?

I understand that tradeoffs have to be made and I'm not trying to be cantankerous or dismiss the value of anyone's work, and no, I couldn't do better myself (yet), which is why I'm commenting on it it rather than making a PR. I'm just wondering if this is the best possible implementation of the concept, given how often I and other people seem to run into issues with it.

reply

2 points by akkartik 15 days ago | link

Don't worry about sounding dismissive, I totally understand where the questions are coming from.

Tables and objects feel like separate concepts, and they have complementary strengths and weaknesses, and one doesn't subsume the other. To me it seems obvious that if we want to have both, we need them to have different types.

For example, sometimes you want the 'dynamic' ability to set arbitrary keys of metadata on a thing. Sometimes you want the same operation to be an error, by providing a schema. How would a single type do both? No language does so, to my knowledge.

Things should have the same type when they have compatible behavior. When they are incompatible, they shouldn't.

Supporting helpers like len and keys may well still make sense. And as the original story did, this is easy to do.

But in general, having incompatible types easily share functions without sharing too much is an open problem: https://en.wikipedia.org/wiki/Expression_problem A language can easily add a method to many types, or add a new type to many methods. But we don't yet know how to achieve both sides.

And honestly, I think the expression problem isn't important. It doesn't take too much code per method/type. And making it easier just encourages large, bloated codebases.

> ...given how often I and other people seem to run into issues with it.

One thing that might be useful here is a list of issues people have encountered with templates. Maybe we should create a wiki page on GitHub and add to it every time an issue comes up. Then we can have a big-picture view of them and a sense of how many are things people need to learn about Arc, and how many are bugs to be fixed.

I believe Anarki behaves exactly the same as Arc's intent when it comes to templates. The changes that I made here seemed strictly superior to the buggy implementation upstream. But if you disagree you should absolutely feel free to just revert the commits and go back to Arc behavior. I don't use Arc anymore, so my opinions are extremely weakly held, you don't have to bother persuading me. Or, if you have some other specific issue in mind, I'd be happy to be persuaded that I'm wrong.

reply

2 points by rocketnia 15 days ago | link

"But in general, having incompatible types easily share functions without sharing too much is an open problem: https://en.wikipedia.org/wiki/Expression_problem A language can easily add a method to many types, or add a new type to many methods. But we don't yet know how to achieve both sides."

I'm trying to follow, but I think you and I must have different understandings of the expression problem. That article lists several known solutions to the expression problem. The solution Anarki uses is `defextend`.

What do you mean by "sharing too much"?

Is Anarki's `defextend` technique already encouraging a bloated codebase, or is there some other technique you're thinking of that would do that?

reply

2 points by akkartik 14 days ago | link

Yeah, I suppose you could say the problem is 'solved'. I think of it as a trade-off with costs. We don't know how to achieve zero cost.

For example, I absolutely agree with you that 2 lines per method to extend every table method to some new type constitutes a solution for us. But if we had a thousand such types and a thousand such methods, it may seem like less of a solution. But then `defextend` would be the victim rather than cause of bloat.

reply

3 points by rocketnia 14 days ago | link

Ah, you're imagining us having to write and maintain 1000×1000 individual `defextend` forms someday? Yeah, that does seem like a problem that would not feel solved once we got to it. :-p

I don't think that aspect of the expression problem is solvable in a language design. Instead, it's an ongoing conversation in the community. Sometimes the intent of one feature and the intent of another feature interact, leading people to do a nonzero amount of work to figure out the intent of the two features put together. That work is an essential part of what the community is trying to accomplish together, so it's a cost that can't be eliminated. The intent has to be reflected in the code somewhere, so there will be a nonzero amount of code that serves feature-coordinating purposes.

Regardless, I'm optimistic that although the amount of code will be nonzero, it'll still have a manageable size. To the extent we have any kind of consistency around these feature interaction decisions, those consistent principles can develop into abstractions. The only way we'll have 1000×1000 individual intersections to maintain is if we as a community culture are already maintaining 1,000,000 compelling and distinct justifications for them. :)

reply

1 point by akkartik 14 days ago | link

Indeed. I'm curious: does my interpretation of the expression problem miss what the papers tend to focus on?

reply

2 points by rocketnia 13 days ago | link

Well... That's a good question.

I haven't read any more than a few papers on it, and maybe only one of those in depth (which I'll mention below). Mostly I'm going by forum threads, wiki articles, and the design choices certain languages make (like Inform's multimethods and Haskell's type classes).

As far as I understand the history, Philip Wadler's work basically defined the strict parameters of the expression problem and explored solutions for it. Separate compilation and the avoidance of dynamic casts were big deals for Wadler for some reason.

That work was focused on Java, where it's easy to define new classes that implement existing interfaces but impossible to implement new interfaces on existing classes.

The solution I'm most familiar with for Java-style languages is the use of object algebras, as described in Oliveira and Cook's "Extensibility for the Masses: Practical Extensibility with Object Algebras" (https://www.cs.utexas.edu/~wcook/Drafts/2012/ecoop2012.pdf). In this approach, when you extend the system with a new type, you define a new interface with a generic type parameter and a factory method for building that type, and you have that interface inherit all the existing factory methods. So you don't have to solve the unsolvable task of implementing a new interface for an existing class, because you're representing your types as type parameters and methods, not simply as classes.

So I think the main subject of research was how best to represent an extensible program's types and functions in a language like Java where the most obvious choices weren't expressive enough. I think it's more of a "how do we allow extensions to be made at all" problem than a "how do we make all the extensions maintainable" problem.

But then, I've really barely scratched the surface of the research, so I could easily be missing stuff like that.

reply

2 points by akkartik 15 days ago | link

> ... with language features like macros and templates that have become ubiquitous, I feel like it's kind of cheating not to just fold them into arc proper.

Cheating how?

It's totally fine to move something into arc.arc if you want to do that. It's always felt like a non-existent distinction in my mind whether something is under arc.arc or libs/. Is Anarki all language or all standard library? Depends on how you look at it. Why does it matter?

> But that's just me... one thing I've learned being here is that I seem to flow against the culture more than with it, so I can just agree to disagree.

This doesn't feel like a disagreement, more like a language barrier. If I understood better I might know whether I agree or not.

reply

2 points by akkartik 15 days ago | link

I just remembered that I don't understand this comment. Arc stores forum data in s-expressions, not JSON. How would we expect a JSON parser to work?

Is making it work just a matter of calling the Racket primitive on `rep.template` instead of `template`?

reply

2 points by krapp 15 days ago | link

I spend all my time with Arc working on the forum, so JSON is more important to me than it might be to someone else who primarily focuses on the language.

I was working on the data export feature, which before just dumped a user's posts and comments as a printed statement, but I wanted it to export JSON because that's more portable. Racket has a really nice JSON parser, unfortunately all the forum data is templated, so I can't just pass it to Racket because it doesn't understand the type. There may be a way to get it to work at that level but I don't know what it is.

So I had to get an old JSON parser for Arc and rewrite a bit of it to be able to generate JSON from forum data. I think it was zck's parser but I'm not entirely sure ATM. It works, but it's an awkward workaround. Any data coming from the forum has to go through one parser, and any other data, such as from a remote API would be going through another (Racket's.)

>Is making it work just a matter of calling the Racket primitive on `rep.template` instead of `template`?

Yes, I had to hunt around to even know that existed, because it's not in the docs.

reply

3 points by rocketnia 15 days ago | link

Not that it helps you much now, but the best documentation for tagged types (including the `rep` operation) is probably this: http://arclanguage.github.io/ref/type.html

You can get to it from the "Type operations" link in the table of contents. Of course, you might've been drawn to the "Templates" page instead.

And unfortunately, that documentation describes Anarki's stable branch. Making documentation of similar quality for Anarki's master branch might be quite a bit more work. So even if you were familiar with tagged types already, the knowledge that template instances were a tagged type on Anarki master might be hard to discover.

I suppose a more ideal form of the documentation would describe on the "Templates" page that template instances were a tagged type with a certain representation. It could describe the direct implications of that, but it would also have a link to the "Type operations" page for more background.

reply

2 points by krapp 13 days ago | link

>I suppose a more ideal form of the documentation would describe on the "Templates" page that template instances were a tagged type with a certain representation. It could describe the direct implications of that, but it would also have a link to the "Type operations" page for more background.

That would have been tremendously helpful, can we do that? Who actually maintains the documentation, can it be updated?

reply

1 point by akkartik 14 days ago | link

Perhaps we should maintain the docs only in plain-text and only within the repo, just because of the operational overheads of managing multiple branches. At least that way they won't seem to lie to a newcomer. I'm curious to hear what others think.

reply

2 points by krapp 13 days ago | link

There is already a wiki that isn't getting much use[0].

[0]https://github.com/arclanguage/anarki/wiki

reply

1 point by akkartik 13 days ago | link

It sounds like you mean a JSON generator (emitting JSON) rather than parser (ingesting JSON). Is that right?

reply

2 points by krapp 13 days ago | link

Yes.

reply


Is the problem the equality between nil and the empty list, or did that just expose some unknown flaw with the way Arc deals with macros?

reply

3 points by zck 25 days ago | link

I _think_ it's some weirdness with the nil/empty list thing. I was getting a case where (str x) resulted in the string "nil", but whatever that object was was not treated as nil, for example in conditionals.

reply


I support updating html.arc in general, particularly to bring it more in line with HTML 5. I think I added support for data attributes at some point, but some things like an async attribute for script tags are still difficult, because it expects all attributes to have a value.

In a perfect world, though, it would use a structure like Racket's html parser[0], and could be used without namespace pollution.

In a more perfect world (to me), Arc would support XML natively. But I'm probably the only person here who would want to write HTML directly in an Arc script.

[0]https://docs.racket-lang.org/html-parsing/index.html

reply


I'm still working on it, but it's just in my spare time. Better API functionality is definitely on the todo list.

I added a project page to the github[0] to loosely collect and organize forum issues and development. Anyone is welcome to contribute.

[0]https://github.com/arclanguage/anarki/projects

-----

3 points by krapp 234 days ago | link | parent | on: Pg just released a new Lisp: Bel

I assume someone is already working on a Racket implementation.... wish I knew how, it looks like it would be fun.

Might I suggest calling it "Babel?"

-----

4 points by rocketnia 231 days ago | link

There's at least one implementation attempt starting up here: https://github.com/luksamuk/believe

Other name ideas:

- (isa bel)

- Rebel -- similar in theme to "Anarki," although there's already an unrelated Racket library called "Rebellion"

- Bombelli -- analogous to the spelling of "Anarki," and it can refer to a mathematician credited for putting complex numbers on solid ground

- Pachelbel -- would be a good name for an implementation written in D :-p

-----

2 points by rocketnia 210 days ago | link

That one was Believe, written in C11. Here's the link again: https://github.com/luksamuk/believe

Looks like there's another project now, BelJS, written in JavaScript: https://github.com/ajlopez/beljs

-----


We already have syntax in the form of bracketed functions (or whatever they're supposed to be called) and {} for tables.

I'm speaking out of my depth here, but I think it would be nice if scoped syntax extension were a "first class" feature of Arc. It would be nice to be able to load, say, native support for XML syntax as a library or something, or to easily extend the language through grammar definitions.

Also, infix notation in a Lisp? If I had a monocle I would drop it into my coffee with shock forthwith!

-----

3 points by akkartik 318 days ago | link

Have you seen my proposal for infix syntax for Arc? I think it's pretty nice: http://arclanguage.org/item?id=16775. The big drawback: you have to give up '-' in symbol names.

-----

3 points by krapp 316 days ago | link

>The big drawback: you have to give up '-' in symbol names.

I wouldn't have a problem with that, but I'm probably of a minority opinion, since that seems to be a Lisp thing. When I started with Arc it took me a while to realize that symbols with asterisks in the name weren't something special like pointers, and using angle brackets just seems wrong after years of writing HTML.

Although if it were possible to do something along these lines, one could have the best of both worlds:

    (defgrammar infix ...)
 
    (w/grammar 'infix (do


    ))

-----

2 points by krapp 405 days ago | link | parent | on: Ask Arc: Arc forum RSS

There does already appear to be an RSS feed in the footer, but it doesn't appear to be sending the correct MIME-type so Firefox at least thinks it's just a malformed HTML page.

If I remember, I'll try to get it working later tonight since I'm messing with the stylesheets and HTML anyway.

Does anyone think a subscribe link to each thread would be a good idea?

-----

3 points by shader 405 days ago | link

I think a subscribe link for each thread would probably be overkill. Most threads don't last very long, especially since there's a time-limit on responses.

What exactly is it you're working on?

-----

3 points by krapp 405 days ago | link

>What exactly is it you're working on?

ATM, simplifying the HTML and CSS, removing obsolete tags (like font) where possible. Also eventually themes and having the base font size be selectable, since not everyone is comfortable reading 10pt grey on grey text.

-----

4 points by shader 402 days ago | link

Sounds good.

I guess these improvements will only affect people using the Anarki implementation of the forum? It would be nice if we could get some upgrades to the original arclanguage.org instance.

Specifically turning off the feature that disables replies on old threads, and probably switching to a most-recently-updated ordering scheme.

-----

2 points by krapp 414 days ago | link | parent | on: Noob resources for Arc/Anarki?

>"Package manager" means wildly different things and has wildly different responsibilities in different contexts and languages and platforms

I disagree. Most package managers for most languages share the same core functions and responsibilities: import and export code (likely from or to a repo), organize code into "packages" or "applications" according to some hierarchy, describe dependencies for packages using metadata and manage those dependencies when importing or updating.

The "special sauce" between them is in the way packages are defined and the metadata, and the way dependencies are handled, and those are details the Arc community could argue about until the heat death of the universe. But ~90% of what new people will want from Arc is to import News as an application or import libraries into their own local version of News.

-----

2 points by akkartik 406 days ago | link

Hmm, we've had this conversation a few times, and I think I may be unfairly holding others back. To reiterate the obvious, you should absolutely feel free to create a package manager in Anarki. The way you put it suggests it may not even be that much work for a rudimentary tool. Why not try it? Let a thousand flowers bloom :)

-----

2 points by krapp 405 days ago | link

>The way you put it suggests it may not even be that much work for a rudimentary tool.

From what little I know, it would be an exercise in suffering [0,1] and that's not even getting into arguments over how versioning should work. But I still want to do it... eventually.

I kind of suspect it would be pointless without some changes to the language itself which I don't know how to implement myself yet, and I don't want to just wait for other people to do the work. Basically, I don't think we can have useful packages until we can do something about the possibility of packages being able to globally redefine things and create unintended havoc. Namespaces would be nice too.

I am hoping to get something like plugins working in the forum, though. I've already combined the repo and what was the plugin manager and I've been trying to get hooks to work through it so that it would be possible to 'plug' scripts in or out of those hooks during runtime. It might also be useful as a way to add updates by hotpatching the existing code (which is really the only valid use I can even think of for being able to redefine things in Arc.)

Maybe, if that ever gets anywhere, something like a package manager can emerge from it.

[0]https://medium.com/@sdboyer/so-you-want-to-write-a-package-m...

[1]https://news.ycombinator.com/item?id=11088125

-----

3 points by shader 405 days ago | link

I'm actually somewhat intrigued with the idea of using guix[0] as a language package manager. It has really nice facilities for setting up "environments" that contain a set of packages, so you can use it for bundling together all of the deps needed to build a particular application. As a bonus, it uses scheme as its configuration language :)

It wouldn't solve arc side of actually loading packages, which probably still needs work, but it should work pretty well at managing them.

____

[0] https://www.gnu.org/software/guix/

-----


relevant HN thread: https://news.ycombinator.com/item?id=19430840

-----

3 points by krapp 445 days ago | link | parent | on: Noob resources for Arc/Anarki?

>I install packages (although I think the only ones I use are ones I've created) by downloading the file, then calling `(load "/path/to/file")`.

To be fair, though... when most people say they want to "browse and install packages" for a language, they don't mean including local files through a REPL. Although that is the best we can do in Arc for now.

-----

More