Re: In core structure editor, anyone?
On Dec 10, 2:59 pm, falcon <[EMAIL PROTECTED]> wrote:
> Could you describe in-core editing a bit more? Sounds interesting.
The canonical structure editor (not "structured editor") is probably
Interlisp-D's SEDIT, or its predecessor DEDIT. (See
http://bitsavers.org/pdf/xerox/interlisp/3102300_interlDprimer_Nov86.pdf
for an archive of Interlisp docs, including docs on SEDIT.) Interlisp
was for a while one of a couple major dialects of Lisp, along with
MACLISP, that were perhaps the most widely used dialects. There were
lots of dialects of lisp in fairly wide use; Common Lisp was intended
to merge the most common idioms in use across a lot of dialects
without losing *too* much of the facilities of any one popular
dialect, but Common Lisp might perhaps resemble MACLISP a little more
than it resembles Interlisp.
Interlisp was the system programming language for the Xerox D-machine
series.
A structure editor, as exemplified by SEDIT, does not operate on text
in a file buffer; instead, it operates on the lisp data structures
represented by the text. When you edit lisp code in emacs, even with a
utility like Paredit, which helps you with the syntactic structure,
you are operating on text characters stored in some sort of array.
There is a connection between the text and what the lisp reader
produces in memory, but you operate on the text, not on the in-memory
lisp objects that are represented by the text.
Structure editors are different: they operate on the in-memory data
structures.
Consider a lisp (or Clojure) list, (a b). This list is a chain of cons
cells, where a cons cell is a pair of pointers. The left pointer
points to the symbol 'a'; the right one points to a second cons cell.
In the second cons cell, the left pointer points to the symbol 'b' and
the right one points to nil.
Now consider the text "(a b)", as seen by some editor. It's a row of
character values: '(', 'a', ' ', 'b', ')'.
The lisp (or Clojure) reader converts that row of characters into the
chain of cons cells described above; the printer converts the chain of
cons cells into the row of characters. There is necessarily a close
correspondence between the text and the in-memory objects, but they
are not the same thing.
Text editors edit text. Structure editors edit the in-memory data
structures.
This might be a good place to repeat that in lisp, and perhaps in
Clojure, I'm not sure, the code is not the text; it's the in-memory
objects. This differs from most programming languages. In most
languages, when you say "source code," you mean text. Strictly
speaking, the text in a ".lisp" text file is not the source code for a
lisp program; it is a text description of lisp source code; the actual
source code is constructed by the lisp reader when it reads the file.
Indeed, given the syntactic rules of Common Lisp, it's possible to
have two very different text files that contain (text specifications
for) exactly the same source code.
Most of the time, this distinction is pretty much academic, because of
the close and necessary correspondence between lisp source code and
its textual representation. There are a few places where the
difference is noticeable, though, and some of them illustrate how a
structure editor differs from a text editor.
For example, consider a circular list: suppose we used RPLACD to make
the nil at the end of (a b) point at the first cons cell, the one
whose left side points to the symbol 'a'. If that value is returned at
the repl (and *print-circle* is not configured to inhibit it) then the
printer will be stuck in an infinite loop printing (a b a b a b a
b
Now, of course, the circular data structure is not infinite, it's just
circular; it points to itself. But the textual representation is a
little inconvenient for printing such a structure, and indeed, it's
inconvenient for constructing it in the first place (the Common Lisp
reader and printer have a sort of a hack specified in them for these
purposes).
It's quite a bit more convenient to work with such a data structure in
a structure editor, which makes it clear that there isn't really
anything weird or magical about the circular list. It just has an
arrow in the rightmost box of the chain that points to the leftmost
box. No big deal.
Structure editors are not in common use, maybe because, while they're
a valid and maybe cool alternative to text editors for lisp code, it's
not clear how useful they are for other kinds of code. In most
programming languages a lexer and parser construct an abstract syntax
tree from the source code. In lisp, the abstract syntax tree *is* the
source code. That being the case, it makes a lot of sense with lisp to
operate directly on the parse tree. In other languages, not so much.
Some folks love structure editors. I never really used one, but my old
friend and longtime lisp hacker Philip McBride really likes them. I'd
be very glad to see one for Clojure just because it would be fun to
have the option to play around with the
Re: Lisp/Clojure doesn't have syntax?
On Dec 11, 3:58 pm, Randall R Schulz wrote:
> On Thursday 11 December 2008 13:47, Sean Spencer wrote:
>
> > That was one of the best explanations of code as data I've ever read.
> > Kudos!
>
> Thanks. You forced me to look up the reference to which I alluded:
>
> On Thursday 11 December 2008 06:32, evins.mi...@gmail.com wrote:
>
> > Subject: Re: In core structure editor, anyone?
>
> > Structure editors are not in common use, maybe because, while they're
> > a valid and maybe cool alternative to text editors for lisp code,
> > it's not clear how useful they are for other kinds of code. In most
> > programming languages a lexer and parser construct an abstract syntax
> > tree from the source code. In lisp, the abstract syntax tree *is* the
> > source code. That being the case, it makes a lot of sense with lisp
> > to operate directly on the parse tree. In other languages, not so
> > much.
>
> So the kudos go to Mikel Evins (or is it Evins Mikel?).
Thanks.
It's mikel evins. GMail somehow arranged a few years ago to make my
preferred account name ("mikel") and my second choice ("mikelevins")
and my third choice ("mikel.evins") inaccessible to me. I haven't
bothered to understand what the problem is.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
Re: In core structure editor, anyone?
On Dec 11, 12:39 pm, TNeste wrote: > On Dec 10, 2:15 pm, Simon Brooke wrote: > > > I note people seem mainly to be using Emacs as an editing/development > > environment for Clojure. But as people keep pointing out, Clojure is > > homoiconic; the canonical source of a function is not a stream of > > bytes read from a file, but is a structure in core. > > > Now, in-core editing does raise some issues - there needs to be some > > means of associating the structure which is the canonical source of a > > function with the function itself, so that when the user invokes (edit > > froboz) (or (edit 'froboz), or whatever), the source structure for > > froboz is displayed in the editor. But in-core structure editors are > > extremely powerful and useful when editing homoiconic languages, so... > > is anyone working on an in-core editor for Clojure? > > Do you mean structured editing combined with image based development? > I haven't really looked that closely at the old Interlisp documents > but I suppose the source code is managed the same way it is in most > Smalltalk systems but I have always been a bit puzzled about how that > works with Lisp. > > In Smalltalk it is fairly straightforward since there is an obvious > mapping from classes and methods to source code. With lisp it is not > that simple as there is no limit to the syntactic forms that the user > might want to query and edit in different forms. For example, if I > have (define-foo my-foo ...) macro that is used to define some complex > function named my-foo what happens when I do (edit 'my-foo)? Do I get > the original define-foo form or the macroexpansion? What about when > define-foo does something more complex like defines a bunch of methods > and datastructures or binds my-foo to a closure? There needs to be > mechanism that associates evaluated forms with the name(s) of the > resulting object(s) and it probably couldn't, in general, be done > automatically. Depends. Using a decent lisp environment nowadays, the lisp will remember the files and line numbers for all the forms it has read, so you can get those back pretty easily, as long as you don't turn that feature off, and as long as you have those text files. If you don't have the original text, but only the data produced from it by the reader and compiler, then the best you can usually do is some plausible lisp forms that correspond to what's in memory--generally a bunch of fully-expanded s-expressions that don't look all that much like code a human would write. It'll be accurate, but not necessarily congenial. In older Lisp systems, like Interlisp and Genera, the systems remembered absolutely everything about how a given hunk of data was created, including versions of everything, including mouse-and-window direct-manipulation operations, so you could view the contents of a structure editor in any form you found convenient. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: defining keywords ?
On Dec 11, 9:08 pm, Chouser wrote: > On Thu, Dec 11, 2008 at 7:49 PM, Robert Koberg wrote: > > > Hi, > > > Would it be desirable to further define keywords such that it allows a > > special kind of namespacing. > > > * This could allow for more efficient (for the user) and targeted > > navigation over large, nested collections. > > * It would allow for mixing related data that might need to be treated > > in different ways. > > * It could provide the building blocks for a collection transformation > > language > > > For example: > > > :keyword or :nil:keyword - defines a keyword in a null namespace > > -- keeps backward compatibility > > -- equivalent to the XML element (no namepsace defined) > > > ::keyword - defines a namespaced keyword in a default namespace > > -- equivalent to the XML element http://some/namespace"/> > > > :myns:keyword - defines a namespaced keyword in a named namespace > > -- equivalent to the XML element http://some/namespace > > "/> > > > Perhaps a requirement for this type of thing would be that the > > namespaces need to be declared on the root element of the (nested) > > collection. > > Keywords can already be namespace-qualified: > > user=> (namespace :foo) > nil > user=> (namespace :my-ns/foo) > "my-ns" > user=> (namespace ::foo) > "user" > > The idea of using this feature to specify XML namespaces has been > discussed. Rich even adjusted the reader rules to allow fully-qualified > URLs as namespaces: > > user=> (namespace :http://n01se.net/chouser/tag) > "http://n01se.net/chouser"; > > This should allow something to parse XML and produce a tree of Clojure > collections representing it with full namespace qualifications, though to my > knowledge this hasn't been done yet. It would be a convenience for some of my work if it were legal to do (derive :foo :bar) using unqualified keywords. I don't know enough yet about Clojure to know what that might break. In Common Lisp, the text ":FOO" is guaranteed always to be turned into a reference to the exact same keyword object, a symbol in the KEYWORD package whose name is "FOO"; I don't know what the rules are in Clojure about keywords without namespaces. Perhaps they're like uninterned symbols; I don't know. I'm building a type system for classifying lots of hunks of data and selecting appropriate operations for them, and derive is nice for that, but it's a minor inconvenience to have to namespace-qualify all those typenames. It's nice that I *can* qualify them by namespace; it isn't always nice that I *have* to. That said, it doesn't prevent me from getting anything done, it's just a sort of pebble in my shoe sometimes. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Persistent storage
On Dec 18, 7:18 pm, "Mark McGranaghan" wrote: > I've likewise though a fair bit about this, but haven't been able to > come up with a particularly satisfying solution. > > One approach I've considered is a watcher-type system where > persistence is defined in terms of immutable snapshots and append-only > journals: you snapshot the data to disk occasionally and otherwise > maintain persistence by appending changes to a journal before > committing; these changes can be replayed in the case of failure. This > will probably require additional hooks into Clojure's MVCC > implementation. This might actually be workable for smallish data > sets, where it is reasonable to hold everything in memory. > > Anyone interested in the topic of "persistent data structures on disk" > might want to look into the implementation of CouchDB. They currently > use (IIUC) a persistent B tree on disk that uses crash-safe > append-only modifications and is "garbage collected" by occasionally > copying over all reachable portions of the tree into a new file. This > may be interesting in and of itself, but I also expect that we'll see > more interesting things in this space from the CouchDB project. > > - Mark > > On Thu, Dec 18, 2008 at 7:53 PM, Kyle Schaffrick wrote: > > > On Thu, 18 Dec 2008 18:06:40 -0500 > > Chouser wrote: > > >> On Thu, Dec 18, 2008 at 4:47 PM, r wrote: > > >> > Is is possible to use some kind of backend storage for Clojure's > >> > data structures? I mean something like Perl's "tie" function that > >> > makes data structures persistent (in sense of storage, not > >> > immutability). > > >> > Such storage should be inherently immutable the way Clojure's data > >> > are (so a simple wrapper on sql is probably not good enough) and > >> > provide means of querying database and indexing (ideally > >> > multidimensional). > > >> I would looove this. > > > This occurred to me the other day as well; the name "Mnejia" which > > popped into my head says a lot about the sort of thing I had in mind :) > > >> > I wonder if this could be at library level or would rather have to > >> > be hard-coded into Clojure itself. Did anyone try to do it? > > >> I've pondered a couple approaches, though only enough to find > >> problems. > > >> One approach would work act like a Clojure collection, with structural > >> sharing on-disk. This would be great because it would have > >> multi-versioning and transaction features built right in. It would > >> also have the potential to cache some data in memory while managing > >> reads and writes to disk. > > > This is an interesting observation. > > > Something in the vein of OTP's Mnesia for Clojure would be *very* cool > > indeed, and I have been thinking a lot about ways to implement > > distribution mechanisms for Clojure on top of which such a thing could > > be built. I imagine however that even sans distribution it would be > > quite powerful and useful, and a fun project. > > > [ Mostly off-topic musings follow :) ] > > > The big problem with mimicking Mnesia for distribution is that a lot of > > Erlang distribution idioms (used heavily in Mnesia AFAIK) rely on BEAM's > > ability to marshall funs across the network (and indeed I think Mnesia > > can even use that to serialize them on disk tables). If serialization of > > a fun is possible in Clojure, doing it is way over my head :) Obviously > > if you can serialize the sexp before the compiler gets ahold of it, this > > is easy, but usually you don't get that lucky. > > > If one were able to marshall a Clojure fun, I had envisioned > > constructing a sort of "distributed send", probably built atop one of > > the many good message-queueing protocols already extant, that can be > > used to cause that fun to be run on a remote Agent, giving you a more > > Clojure-flavored distribution mechanism. Not RPC, but not exactly Actor > > model either. > > > H... :) > > > -Kyle The largest project for which I'm using Clojure currently uses a CouchDB instance for server storage and uses neo4j for single-user persistent storage. Both are working well for me so far. They aren't transparent, but, then again, I'm not sure that any persistent storage mechanism is. Based on past experience, I prefer to have all operations that alter persistent storage go through a fairly small number of API calls, so that the search space is small when it's time to fix bugs. Writing that API, and then ensuring that everything in the system uses it, is about as much work as writing the data- marshaling subsystem that you need for storage that requires marshaling, so in that sense it's no loss. There may even be a disadvantage to a storage subsystem that purports to be "transparent": if the only way to get objects into and out of the store is by marshaling them through your API, then there won't be rogue code somewhere using some other API to scribble something wrong in your database. If you use a "transparent" storage layer, then there are ways other
Re: Streams work
On Jan 21, 1:33 pm, Rich Hickey wrote: > I've started documenting the streams work I have been doing, for those > interested: > > http://clojure.org/streams > > Feedback welcome, > > Rich This work reminds me in a general way of the old Dylan iteration protocol. They're not the same, and the Dylan iteration protocol does not provide the safety for concurrency that you're working on. Still, just in case any of the old ideas happen to be useful, I thought I'd provide a link: http://amigos.rdsathene.org/other/prefix-dylan/book.annotated/ch12.html#iteration%20protocol0 (this link is to a webbed version of the 1992 lisp-syntax version of Dylan. the manual is getting increasingly hard to find online.) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Inheritance & multiple inheritance using structs
On Jan 19, 12:38 am, David Nolen wrote: > Of course it might be the case that not many people are interested in the > implementing ideas from CLOS for Clojure It's definitely interesting. I'd like to have eql specializers and the ability to build hierarchies of arbitrary types (e.g. a hierarchy of strings for one particular application I'm working on), so any hacking around with CLOS-like dispatching and specializers is interesting to me. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Convincing others about Clojure
On Jun 25, 12:59 am, Baishampayan Ghose wrote: > Their concerns are thus: > > 1. How do you get Clojure programmers? Lisp is not for the faint hearted. You advertise for programmers and include Clojure, Lisp, Java, and functional programming on the roster of desirable skills. Lisp hackers want to hack Lisp. Over the past twenty years I;ve been on four teams that wrote the bulk of their code in Lisp, and finding people to do it has never been an issue. On the largest project we had somewhere in the neighborhood of 60 people; the non-Lispers that were hired had no trouble taking instruction from the Lispers. > 2. What about the performance of Clojure? Is it fast? It's usually about as fast as plain Java. Occasionally someone will write something that is slower. If it's slow enough to notice, it's generally easy to recode it to recover the speed. > 3. People who want to use this are more academically inclined and are > not practical. This will make the whole project fail. That one is just a prejudice.No one has that kind of knowledge, so whoever said it is just making it up, or revealing a personal bias. You'll have to figure out the best way to deal with it based on knowledge of the individual's personality. If it's a question of talking to investors, it's been my experience that, barring the quirks of particular individuals with prejudices, investors ask about platforms and technologies to (1) disqualify people who clearly have no clue and (2) find out how nimble you are about responding to inconvenient questions (because you're going to have to talk to a lot of people who will ask a lot of inconvenient questions, and the investors want to make sure before they give you money that you can talk confidently and convincingly under those circumstances). So in talking to investors about your platform I'd suggest focusing on advantages rather than trying too hard to defend against perceived disadvantages, and don't give out details that the questioners don't need to know. For example, why would they need to know what the source language is? The proposed product runs on the JVM, a proven platform. That should be enough, unless you want to build a sales pitch around specific competitive advantages Clojure gives you. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Creating an object given a class object
On Jan 12, 1:50 am, Konrad Hinsen wrote: > On 11 Jan 2010, at 23:09, .Bill Smith wrote: > > > Every class object has a newInstance method: > > > user=> (Class/forName "java.util.HashMap") > > java.util.HashMap > > user=> (.newInstance (Class/forName "java.util.HashMap")) > > # > > user=> > > > Is that what you are looking for? > > It seems close, but it doesn't work for me. From experimenting I have > the impression that this works only for constructors with no arguments. > > I found some stuff in the Java docs on reflection that could work, but > this is getting very complicated... I'll first see if I can do without. > > Thanks, > Konrad. I have this lying around for situations where I need to call an arbitrary constructor: (defn construct [desc] (let [dclass (:class desc) initargs (to-array (:initargs desc)) initclasses (make-array Class (count initargs))] (doseq [i (range 0 (count initclasses))] (aset initclasses i (class (aget initargs i (let [constructor (. dclass (getConstructor initclasses))] (if constructor (. constructor (newInstance initargs)) (throw (Exception. (format "no %s constructor for args: %s" (str dclass) (map str initclasses Why the rigamarole with make-array and aset, rather than to-array or into-array? To ensure that I *always* get a Class[], even when the input list is empty (the reflection calls are finicky about that). -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Leiningen, Clojure and libraries: what am I missing?
On Mar 4, 7:33 am, Jan Rychter wrote: > I haven't hacked on new Clojure stuff for the past two months or > so. Now, having updated my repositories, I find that everybody just > dropped ant and moved to leiningen. > > I tried to make sense of things, but can't. I must be missing something > big here. [...] > How do people deal with this? Here's how I do it. We've got five people in different places with different systems writing code for a dozen projects, of which five are Clojure projects. We use a common git server for coordination. Our standard project layout places all five Clojure projects as siblings in a common directory, along with a directory called "xglib" that contains common libraries. We tried leiningen, and it's appealing in some ways, but it makes too many assumptions about the way projects are organized, and its habit of downloading scads of jars quickly became annoying. We have five projects with partially-overlapping dependencies, some of which have others as dependencies. It was tiresome always to have multiple redundant copies of the same jars all over the place, so instead we created the common xglib directory, which is a sibling of the projects, and which contains all the libraries used by them. We use NetBeans as our standard IDE, not because I like it (I don't like any current-generation IDE) but because it works, and telling new contributors how to set it up to work with our projects is easy. So each project is, in fact, a NetBeans project. We also use Emacs, because a couple of use hate it slightly less than we hate NetBeans. We have a custom variant of swank-clojure-project (just a couple of function definitions, really) that knows how to find our common libraries directory and add all the jars in it to the CLASSPATH before running the Clojure REPL. It's also possible to use other editors (TextMate, for example) with this setup. The standard way we do builds is with NetBeans, but we can also do them with ant. It's not great, but it works, and it stays out of our way better than anything else we've tried so far. A couple of us are old Lisp hackers with memories of things like SK8 and Leibniz and MCL and SPE and Genera, so grumbling is ongoing, but we must adapt to the times we live in. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Implementing Clojure
Hey, guys. Suppose I wanted to tinker around with a compiler for Clojure on a new back-end. What would you guess is the best starting point (perhaps ClojureScript?), and what's the best spec to use to ensure compliance with the language? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Implementing Clojure
On Saturday, February 27, 2016 at 7:09:39 PM UTC-6, Alan Moore wrote: > > It kind of depends on the backend you are targeting. If it looks and > smells like the JVM you might look at ClojureCLR. > > If it looks like Python see Clojure-metal by Timothy B. > > The ClojureScript compiler was optimized for speed (as recently pointed > out) so it may not be as straight forward to use as a reference. Although, > as it is/can be self hosting this may be an advantage if your goals include > self-hosting on the target. > > What are your target/goals? > > Alan > I thought I might fool around with a Clojure on Common Lisp because I want some things that Common Lisp runtimes do and existing Clojure runtimes don't. I know how to write Lisp compilers and interpreters and how to implement Clojure's data structures, so what I mainly want is a handy reference to the definition o the language so that I'm not just bumbling around in in random documentation. But I wouldn't mind swiping from existing compilers wherever it makes sense. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Implementing Clojure
On Saturday, February 27, 2016 at 9:11:38 PM UTC-6, Andy Fingerhut wrote: > > The reference documentation is available here, starting with the Reader at > this link, but continuing on with all of the other topics you see on the > left hand side of this page, such as Evaluation, Special Forms, Macros, etc. > > http://clojure.org/reference/reader > > Any questions not answered there are probably best answered by the > implementation itself. > > That's what I was afraid of. Thanks. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Implementing Clojure
On Sunday, February 28, 2016 at 4:13:23 AM UTC-6, puzzler wrote: > > Yes, unfortunately, Clojure doesn't have an actual spec. The lack of a > spec probably helps keep the language more "agile", but I know several > people who automatically discount the language because of that. > I don't discount it; it's a good language with a good ecosystem. A spec would be nice when writing an implementation, though. Even more convenient would be a suite of compliance tests. I can use the linked reference docs, of course, but it's more work to slog through them, and is exactly what I was hoping to avoid. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Implementing Clojure
On Sunday, February 28, 2016 at 1:31:40 PM UTC-6, puzzler wrote: > > Look here for some compliance tests: > https://github.com/clojure/clojure/tree/master/test/clojure/test_clojure > > Excellent; thank you. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Implementing Clojure
On Sunday, February 28, 2016 at 2:17:19 PM UTC-6, Stephen Nelson wrote: > > You could also consider implementing an interpreter > That's precisely what I am considering--an interpreter or compiler--and exactly why I'm asking these questions. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: STM style disk persistance
On Jun 22, 12:57 pm, Timothy Baldridge wrote: > Greetings, > > I've recently started learning Clojure. For the past year or so I've > been using CouchDB, and am very happy with the MVCC disk storage > system it uses. Has anyone tried marrying the two system systems to > create a truly persistent data primitive where any "updates" to a map > is written to the disk? > > To me this seams like a awesome opportunity for Clojure. If we could > create maps/vectors/whatever and read/"write" to them and have their > contents somehow stored in on disk, complete with transactional style > support, clojure could basically have a built-in database system that > could be used in countless situations. > > So has anyone tried this? If not, I may just give it a whirl, and > others would be welcome to help. Yep, I've tried it. It can be done, but it's not simple. What you seem to want is orthogonal persistence, which remains an active area of research. You can do much more limited forms of persistence, but there are always a bunch of knotty problems you have to solve. The on-disk representation of the values is never the same as the in-memory representation, so you have to decide on a marshaling scheme; that's a whole design project in itself. Efficiency considerations for persistent storage are never the same as for in-RAM storage, so you have to make a bunch of decisions and tradeoffs about how to keep RAM and disk synchronized without throwing efficiency out the window. There are a zillion considerations about how you intend to use the store that influence the tradeoffs you make about how to store and marshal things--do you want to suport concurrent access to stores? How much and what kind of concurrency? Do you want ACID guarantees? How big do you want the stores to get? Do you want replication? Sharding? What kind? Do you want to optimize for availability? Consistency? Fast reads? Fast writes? Embedded use? Client/server applications? Big flat stores of data that are not much interconnected? Highly-structured, graphlike data? And on and on. There are a ton of variables, each of which involves a bunch of tradeoffs, and they can be combined a zillion different ways to yield different and more complicated tradeoffs. That's why there are a zillion persistence solutions around, and none of them is particularly simple. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure / Common Lisp Question
On Jun 18, 9:52 am, rob levy wrote: > As an informal survey of people who use both Clojure and Common Lisp for > different projects, what do you see as the main determining factors behind > your choice to use either Clojure or Common Lisp for a project, given the > present state of Clojure. Let's only assume we are talking about projects > you completely own and have complete freedom to do what you want with. At this point, Clojure is my default choice for new projects. If there isn't a compelling reason to do a project in a another language, I use Clojure. It doesn't take very much practical pressure to get me to use Common Lisp instead; I still like it nearly as much as Clojure, and there are still things I like better about it. It takes much more practical pressure to get me to use something other than Clojure or Common Lisp. I do like Haskell very much, and wouldn't squawk if some reason to use it for a project cropped up. I even have a personal project I'm doing in Haskell for reasons that aren't relevant to this topic. So how do I make the choice between Clojure and Common Lisp? It's a little hard to answer clearly. As I say, Clojure is my default choice. Basically, if there is some reason I'd prefer not to rely on the JVM, or if there's something about the particular project that makes me want features that a favorite Common Lisp implementation has and Clojure or the JVM doesn't, then I use Common Lisp. Both Clojure and Common Lisp are decent approximations to an imaginary Lisp that is my favorite programming language. They're closer to that imaginary language than anything except a long-extinct version of Dylan. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: More urgency for CinC & CLR given Oracle's lawsuit against Google?
On Aug 13, 11:32 am, Quzanti wrote: > > The only two implications I can think o > (1) Hardly helpful for people's confidence in the Java Platform, if > Oracle embarks on these kind of surprise antics. May push people > towards CLR. If Oracle start getting aggressive, then everyone will > start worrying who they will attack next. That's the issue. Gosling has mentioned that during management meetings in the wake of the Oracle acquisition of Sun, the Oracle attorneys were salivating over JVM licensing; the issue is Oracle seeing such lawsuits as an attractive revenue stream, and what effect that will have on the Java market for the long term. In the short term, the java market is huge in the server space, and it looks promising in the mobile space. In the desktop client space it's essentially dead because Sun killed it by suing Microsoft over a noncompliant implementation. What Sun got out of that suit was a nice short-term benefit (a lot of cash from the settlement), and a major long-term loss, as Microsoft replaced their nonconformant JVM with a new VM and source language that were just different enough to be invulnerable to additional suits. Oh, and a thriving desktop client market in which Java participates not at all. The concern is that, if Oracle sees lawsuits over technical noncompliance as an attractive revenue stream, then they'll go about suing everyone with deep pockets who has any involvement with Java, with more or less the same effect that the Sun suit against Microsoft had--or at least sowing enough anxiety and confusion to have a chilling effect on the Java market, and making the JVM look less attractive as a platform. Again, in the short term it's unlikely to have much effect, because the existing Java ecology is so large and rich. The long term is more of a crapshoot, though, and the uncertainty there certainly makes it a good idea to make Clojure as able as possible to survive independent of any particular VM. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Leiningen 1.2.0 released
On Aug 19, 10:39 pm, Phil Hagelberg wrote: > I just pushed out a new release of Leiningen, a Clojure build tool, > with lots of help from many contributors. > > This adds a couple new tasks (test! and interactive) and the ability to chain > tasks. It also allows for user-level init scripts and user-level plugins, so > you > don't have to declare things like swank as a dependency for every project you > use; just install it once and be done with it. > > The repl task now acts as a socket server, so multiple concurrent connections > may be used. > > Another neat feature is the ability to bundle shell script launchers > with your jar > files. Leiningen will place these in the ~/.lein/bin directory so you can have > an easy way to launch projects from the command-line. > > One last "new feature" is the Leiningen stickers:http://twitpic.com/2e33r1 > If you've contributed to Leiningen, you can send for one yourself; details > at:http://groups.google.com/group/leiningen/browse_thread/thread/fb4db02... > > Users of 1.1.0 and 1.2.0 can upgrade with "lein upgrade". Otherwise download > the script fromhttp://github.com/technomancy/leiningen/raw/stable/bin/lein, > place it on your $PATH and make it executable, and then run "lein > self-install" to get going. New users should check out the > Tutorial:http://github.com/technomancy/leiningen/blob/master/TUTORIAL.md > > A complete list of the new features and bug fixes can be found > athttp://bit.ly/lein-news > > Enjoy! Thanks very much for the continued work on lein; I usually do enjoy it. Up til now, I've avoided using ELPA (it doesn't play nicely with my 25 years' worth of Lisp-oriented emacs customizations). It may be helpful for other hoary old lisp hackers to know that you really want to use ELPA with lein, no matter how fervently you may believe that you don't. I managed to evade ELPA up until this lein release, but it seems the free ride is over. ELPA still hamstrings and lobotomizes my Common Lisp environment, so, instead of loading either it or my usual environment at Emacs startup, I now load a pair of M-x commands, one for loading the familiar and comfortable Common Lisp environment, and one for loading that other thing, about which the less said, the better. I'm mildly nauseated, but both Common Lisp and clojure+lein appear to be working again. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
where did I read that?
I'm working on a project in which it would be very useful to be able to easily determine how many characters were consumed in the course of a read operation, in a similar fashion to the way that Common Lisp's read-from-string returns as a second value the index of the next character of the input past the end of the object that was read. I want to, for example, read Clojure values from a buffer and keep track of where in the buffer they were read from. Anyone have any good ideas of how to accomplish this without some level of reimplementation of read? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: where did I read that?
On Aug 28, 1:41 am, Robert McIntyre wrote: > I took a stab at it and came up with this: > is that what you're going for? I was actually asking how to avoid doing what you did :-). If it's necessary to do it, that's fine, but I thought I'd ask first, in case there was a way around it that I hadn't noticed. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
