Arc Forumnew | comments | leaders | submitlogin
3 points by fallintothis 5018 days ago | link | parent

Paraphrasing: if you don't have chocolate, you'll be more careful to keep cakes not-chocolatey.

Having one namespace isn't about concision any more than large == bloated (largeness is necessary but insufficient for bloat). Some code (short or long) lends itself to one namespace, some doesn't. And bashing the latter into one namespace doesn't make it concise.

Take arc.arc. It has a lot of code, but fits in one namespace because it rarely defines a function for another's sake. Functions/macros are usually either mutually exclusive library utilities, or were supposed to be exposed anyways (e.g., loop is used to define for, but it's okay, because we wanted loop anyways). Even so, there are cases like =, whose logic is spread across expand=, expand=list, setforms, metafn, and expand-metafn-call.

This versus http://arclanguage.org/item?id=11179, which provides (essentially) just sscontract, but is still large enough to naturally spread across functions that shouldn't be exposed (much like =). What would a "concise" sscontract be? One giant if statement with copy/pasted afns? At least with that method, all of the "bloat" like

  (def priority (c)
    (or (pos [find c _] '("&" ".!" ":~"))
        0))
wouldn't leak and (very possibly, considering the general name) clobber someone else's priority.


1 point by projectileboy 5014 days ago | link

Hmm... I'm with you. But wouldn't it best to let people define their own namespace facilities based on what they need?

-----

1 point by fallintothis 5012 days ago | link

I'm not sure what you mean. Are you suggesting that people write a namespace system each time they need one? Or that there should be some composable facilities that let people pick & choose the features they need? The latter kind of sounds like "y'know, namespaces, but done right", so I can hardly disagree with it. :P

-----

3 points by shader 5012 days ago | link

Yeah, I frequently see people hacking together their own namespace systems, and either trying to go for the most complete and cumbersome system possible (handling dependencies, versions, etc.) or something that isn't general enough to be used more than once.

Maybe we should try and design a set of very basic namespace handling tools, and then allow users to extend off of them. Basic as in "See namespace. See namespace hold names. See namespace export names for use" If we make them simple enough, and generic enough, it should be possible to add whatever other features are necessary later.

Right now the only hard part about implementing namespaces seems to me to be support for macros. Anyone have any ideas on how to allow macro indirection via namespaces without having first class macros? Or maybe just a good way to handle first class macros themselves?

-----

1 point by rocketnia 5007 days ago | link

Anyone have any ideas on how to allow macro indirection via namespaces without having first class macros?

Lathe's approach (where namespaces are friendly-name-to-unfriendly-global-name tables encapsulated by macros):

  arc> (use-rels-as ut (+ lathe-dir* "utils.arc"))
  #(tagged mac #<procedure: nspace-indirect>)
  arc> (macex1 '(ut (xloop a list.7 b 0 a.b)))
  (gs2012-xloop a list.7 b 0 a.b)
  arc> (macex '(ut (xloop a list.7 b 0 a.b)))
  ((rfn next (a b) a.b) list.7 0)
  arc> (ut:xloop a list.7 b 0 a.b)
  7
Maybe we should try and design a set of very basic namespace handling tools, and then allow users to extend off of them.

Funny, that's part of what I had in mind as I made Lathe's module system. :-p Is there some aspect of Lathe's namespace handling that's inconsistent with what you have in mind? The point of the Lathe module system is mainly to keep the rest of the Lathe utilities safe from name conflicts, so I'll gladly swap it out if we can come up with a better approach.

(In case you haven't heard me rant about Lathe before, you can get to my original blog post about the module system via http://arclanguage.org/item?id=11610 and see all the current Lathe code at http://github.com/rocketnia/lathe. )

-----

1 point by ylando 5006 days ago | link

Anyone have any ideas on how to allow macro indirection via namespaces without having first class macros?

You can do something similar to my class macros, see:

  http://arclanguage.org/item?id=12003
You only need to declare namespace instead of class and it will work.

-----

1 point by projectileboy 5007 days ago | link

Well, I think people could write their own to suit their tastes. It seems to me you'd only really do this once. The exception would be a big fat project which wanted to use its own namespace mechanism; if you wanted to do something within such a project you'd probably bend to the will of how that project does things.

-----

1 point by akkartik 5018 days ago | link

I don't (and didn't) disagree with any of that.

-----