Package rant

[nha...@gmail.com]

The package system is the only part of Shen I consider to be really unpleasant. I realize that it is supposed to be simple by design but in some situations it can really be a major time waster. Nested packages are particularly annoying to deal with. Every neutral symbol needs to be added to multiple exclusion lists and sometimes there are a lot of them.

I think part of the problem is how it just renames all symbols regardless of context. It may function better if it only renames symbols used in operator position and 'define'. That still leaves some problems with 'datatype' and 'synonyms' though.

Also ,Shen doesn't really support having two incompatible versions of the same package loaded at the same time very easily. You have to include a version number in the package name.

[Bruno Deferrari]

I was working last year on extending the library system I have here[1]
to support namespaces and a different way to handle symbols.

The idea was that the namespacing was controlled at the library
declaration level (and code was loaded using a special loader, not
Shen's default file load mechanism). Every library could define new
names only inside their namespace, then through import lists you could
remove prefixes if you wanted.

Also self-quoted symbols would not get any auto-prefixing, unless
prefixed by a single quote:

'sym => current-namespace.sym
sym => sym

But maybe the opposite is better, not sure.

Anyway, I never got to finish that, but I may have the code laying somewhere.

Note that this was not a standalone thing, it was an extension to the
library system that also handles other things (like enabling/disabling
macros and type rules), but it could be implemented without that.

[1] https://github.com/tizoc/shen-batteries/blob/master/library.shen

> --
> You received this message because you are subscribed to the Google Groups "Shen" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to qilang+un...@googlegroups.com.
> To view this discussion on the web, visit https://groups.google.com/d/msgid/qilang/622fb7c8-7889-4038-a6f9-c13d6a97d09fn%40googlegroups.com.



--
BD

[Mark Tarver]

Shen doesn't really support having two incompatible versions of the same package loaded at the same time very easily. 

Not certain that you could reasonably expect to have two incompatible versions loaded at the same time.

I think part of the problem is how it just renames all symbols regardless of context. It may function better if it only renames symbols used in operator position and 'define'. That still leaves some problems with 'datatype' and 'synonyms' though.

I don't think you can legislate apriori on this.  I mean I actually like the fact that when I place everything in a package all the symbols are renamed and

I choose which are not renamed.  If some are never renamed that just means I have less choice as to how things work.   I quite often hide datatypes

inside packages because I use them for type checking but don't want the user to have to bother with them.

Every neutral symbol needs to be added to multiple exclusion lists and sometimes there are a lot of them.

If you have a whole stack of symbols which are keywords in your packages and you are using them everywhere then the best thing is to 

define them once in a function.

(0-) (define keywords
   -> [foo bar])
(fn keywords)

(1-) (package mypackage (keywords)  [foo bar hello])
[foo bar mypackage.hello]

    

Mark 

--

[nha...@gmail.com]

Defining them as a function helps a fair amount.

Shouldn't a nested package automatically include the exclusion list of its parent package though?

[Mark Tarver]

Packages follow the default applicative order evaluation so the innermost package is unpackaged first

and then to the outermost.  (package foo [] (package bar [] a)) gives you foo.bar.a.  So the inner does not 

know about the outer and there's no transmission of keywords between packages.  It again gives you latitude 

of choice as to what renaming conventions are used in the inner packages.  But if you want the same renaming 

conventions throughout all subpackages then the functional approach in defining your keywords will abstract what 

you want in a small space.

Mark

To view this discussion on the web, visit https://groups.google.com/d/msgid/qilang/6b0c19b7-7601-4423-b3d0-5a183d6dce3dn%40googlegroups.com.