defstructs and packages

Why CL includes two non-orthogonal concepts for code organization? Why to define an IMAGE package I have to separately declare (defstruct image-state ...)?

Can we replace defstructs with packages in future Lisps?

We should replace packages instead.

>>2
"package" is a nice name for a self-sufficient unit of code.

Also, packages/defstructs should be more first-class, by including interface choke-points, which would allow changing package internals without whole program recompilation.

defstruct is pretty old and you should use CLOS instead of it, unless you need performance(or just have no need for CLOS' full power), in which case you can either use structures or classes stored as structures (different metaclass, slightly unportable, but I haven't encountered an implementation where it doesn't work).

Packages are just slightly enhanced collections of symbols, and I don't see why would you think structures and packages are related except in the ways symbols are related with the rest of the language.

Why to define an IMAGE package I have to separately declare (defstruct image-state ...)?
I don't understand this part of your statement at all. To define an image package you use (defpackage image ...). If you want to make your structures/classes visible in another package, you can always import the symbols.

>>1,4
Are we both talking about the same concept, because I don't think we are. Modifying a structure at runtime may require recompiling certain portions of your program, but I don't ``bounce'' (half-restart) my lisp that often, you can change packages or even structures at runtime, but some details regarding structures are not as portable across implementation (hence why CLOS should be used if you want such gurantees).

>>5
You don't understand CLOS. It's purpose is OOP-modelling, not code managing. Packages, on the other hand, is a way to break big project into orthogonal pieces or combine orthogonal pieces into a big project.

>>5
Modifying a structure at runtime may require recompiling certain portions of your program
Java world uses so called "interfaces", which allow on-fly package replacement.

>>6
I don't use structures to ``code manage'', I use them as a cheap alternative for OO when I don't need the full power of CLOS.

>>8
This is why you have a mess, which requires reloading whole project, when structure changes. Welcome to C++!

Also, CL has no privilege management. You can't have sandbox package with restricted rights for unsafe code. Neither you can use packages as EXE files. So you cant use CL as a base for operating system.

>>9
I never said I use structures often either. I tend to use CLOS for larger/mid-sized projects and structures for small ones.

>>10
Use C# then if that's what you need. Nobody prevents you from making a "safe-CL", actually I think AllegroCL or one of those commercial lisps attempted something of that sort.

>>12
C# can't do this either. Implementing an OS would require something like Unix privileges, where package-system acts as a filesystem on top of garbage collector.

>>13
filesystem on top of garbage collector.
Modern Unixes have it as /dev and /proc

>>10
If packages were a collection of bindings instead of symbols, then you could.

>>16
Why do we still differentiate between symbols and strings?

We can attach reader package-info as metainfo on top of strings, which macros would then use to resolve stuff.

For example, following simple functions could be used to transparently attach info (like package or source file) to any heap-object

(defparameter *meta-db* (make-hash-table :test 'eq))

(defun meta-set (info object)
  (setf (gethash object *meta-db*) info))

(defun meta-get (object)
  (gethash object *meta-db*))

>>17
Why do we still differentiate between symbols and strings?
Because symbols are not strings. And symbols are not identifiers either.

>>19
Idiot.

>>19
Symbols' name is a string, but symbols themselves tend to be structures which have a name (string), a home package (nil if uninterned), a plist, value, functional value, and may belong to many other standard namespaces (classes, structures, etc) or user-defined namespaces (wether the namespaces to which it belongs (or aditional properties) is stored in the symbol structure or not is irrelevant as long as a proper accessor interface is provided).

if you want true privates in CLOS, just use closed-over variables from a lambda.

>>22
Of course you can inspect bindings in a closure in a good-enough implementation, just like your can do the same with privates and a good enough debugger in other languages. Not that I see much point in ``privates'' (despite it not being that hard to implement with CLOS, however c.l.l already had a huge debate on this and it proves mostly useless).

>>21
a plist, value, functional value
see >>18

>>22>>23
It's not about "privates", it's about access control. I want a sandbox package, where I can place malware virus code and safely run it.

SBCL has package locks, but they're just not the right thing. Unix maybe ugly and inconsistent, but it does it's file system thing right.

>>26
I'm sure you can do better.

>>27
Of course, that's why I use Scheme instead.

>>28
Scheme can't even do real macros, because of its broken package system.

>>18
That is, instead of simple metainfo, like >>18, Scheme uses these syntax-objects making macro-processing a nightmare.


begin-for-syntax syntax-e syntax->datum syntax->list syntax-property #' (void) quote-syntax datum->syntax syntax-parameter-value syntax-rule raise-syntax-error internal-definition-context? syntax-parameterize make-set!-transformer prop:set!-transformer free-identifier=? syntax-local-value/immediate syntax-local-transforming-module-provides? syntax-local-module-defined-identifiers syntax-local-module-required-identifiers make-require-transformer (require (lib "stxparam.ss" "mzlib")) syntax? (require mzlib/defmacro) define-macro syntax-local-lift-expression (require racket/stxparam-exptime) make-rename-transformer syntax-local-require-certifier make-parameter-rename-transformer syntax-local-value define-syntax-parameter make-provide-transformer syntax-local-provide-certifier syntax-source local-expand/capture-lifts local-transformer-expand/capture-lifts syntax-local-lift-values-expression syntax-local-lift-module-end-declaration syntax-local-lift-require syntax-local-lift-provide syntax-local-name syntax-local-context syntax-local-phase-level syntax-local-module-exports syntax-local-get-shadower syntax-local-certifier syntax-transforming? syntax-local-introduce make-syntax-introducer exn:fail:syntax make-syntax-delta-introducer syntax-local-make-delta-introducer syntax-case define-syntax syntax-rules with-syntax syntax-position syntax-line syntax-column ...

>>30
I just wrote my own defmacro/gensym.

>>31
http://docs.racket-lang.org/mzlib/mzlib_defmacro.html

Important: Although define-macro is non-hygienic, it is still restricted by Racket’s phase separation rules. This means that a macro cannot access run-time bindings, because it is executed in the syntax-expansion phase. Translating code that involves define-macro or defmacro from an implementation without this restriction usually implies separating macro related functionality into a begin-for-syntax or a module (that will be imported with require-for-syntax) and properly distinguishing syntactic information from run-time information.

The main problem with Racket's macro system (and with other syntax-case systems) is that instead of raw s-expressions you're dealing with syntax objects. This becomes very ugly when identifiers are handled: instead of dealing with plain symbols, you're dealing with these syntax values (called “identifiers” in this case) that are essentially a symbol and some opaque information that represents the lexical scope for its source. In several syntax-case systems this is the only difference from defmacro macros, but in the Racket case this applies to everything — identifiers, numbers, other immediate constants, and even function applications, etc — they are all wrapped.

>>32
Important: Although define-macro is non-hygienic, it is still restricted by Racket’s phase separation rules. This means that a macro cannot access run-time bindings, because it is executed in the syntax-expansion phase. Translating code that involves define-macro or defmacro from an implementation without this restriction usually implies separating macro related functionality into a begin-for-syntax or a module (that will be imported with require-for-syntax) and properly distinguishing syntactic information from run-time information.
Uh, where exactly did I mention using Racket?

>>34
Isnt Racket "The Next Big Lisp", every fag uses?

>>35
Racket is broken as fuck.  Hell, starting from such a great idea, I can't imagine how they could have fucked it up worse than that.

>>35
I think that's Clojure.

>>-
Ignore the ``in Lisp'' guy, please, and his defmacro vs syntax-case trolls.

>>38
You can't ignore the truth.

What is a plist?