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?
>>2
"package" is a nice name for a self-sufficient unit of code.
Name:
Anonymous2011-07-27 16:52
Also, packages/defstructs should be more first-class, by including interface choke-points, which would allow changing package internals without whole program recompilation.
Name:
Anonymous2011-07-27 18:03
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).
Name:
Anonymous2011-07-27 19:01
>>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.
Name:
Anonymous2011-07-27 19:08
>>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.
Name:
Anonymous2011-07-27 19:19
>>8
This is why you have a mess, which requires reloading whole project, when structure changes. Welcome to C++!
Name:
Anonymous2011-07-27 19:22
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.
>>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.
Name:
Anonymous2011-07-27 19:44
>>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.
Name:
Anonymous2011-07-27 19:48
>>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.
Name:
Anonymous2011-07-28 6:50
>>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.
Name:
Anonymous2011-07-28 6:52
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))
>>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).
Name:
Anonymous2011-07-28 10:56
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).
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.
Name:
Anonymous2011-07-28 21:21
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?
Name:
Anonymous2011-07-28 21:57
>>34
Isnt Racket "The Next Big Lisp", every fag uses?