Re: [fonc] Flat text and 1D syntax considered harmful
On Sun, Jul 21, 2013 at 2:43 PM, Gath-Gealaich gath.na.geala...@gmail.comwrote: On Sat, 20 Jul 2013 14:28:59 +0200 Pavel Bažant pbaz...@gmail.com wrote: On the other hand, imagine math notated the same way programming languages are. That would be awful! IMHO, it is awful for PL, too, but everyone got used to it. Actually, that would be anything but awful - it would be positively splendid! Mathematical notation is fuzzy and ambiguous in places, a luxury it can afford because it's ultimately processed by the human brains of mathematicians - beings that, despite specializing in a field renowned for exactitude in reasoning and results, are ultimately still only human beings. Computers can't afford ambiguous notation, which is why Sussman in his book on computational approach to classical mechanics (Structure and Interpretation of Classical Mechanics) threw mathematical notation out of the window and went with a functional, machine-readable one. Mathematical notation is intended to be compact and easily readable by humans. It serves this purpose well. Some computer algebra systems use it, so it definitely can be made non-ambiguous. If manipulating richly notated expressions is perfectly possible in computer algebra systems, what's wrong with having a rich syntax for say Standard ML and manipulating it the same way? Even the good old DOS version of Derive edited formulas at the structure level! Like 20 years ago. The point is, everyone else already treats structured data as structured data, only the software development community treats structured data as the corresponding unstructured stream of bytes which happens to represent the data on the disk. It's almost like editing SVG files in a text editor instead of using a drawing software. It's almost as if the programmers subconsciously wanted source code to be really a code in the sense of something secret, incomprehensible. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Flat text and 1D syntax considered harmful
There are various ways to present the same structure. Trees, for example, can be represented top-down, bottom-up, left-to-right, dynamically (front to bottom), graphically, textually, etc. Each representation can also lead to different ways of editing them. So each application wants to represent them in a certain way. So you can have a toolbox of tree representations and editing modes, but don't count on having a single one to serve all the applications. Yes, I agree. But that's just what I had in mind with the pixmap editor example -- the editor provides a specialized pixamap drawing interface, but the idea was the general array editing capability provided by the OS shell to be applicable *uniformly* to any array-like structure in any application, i.e. to the pixmap, too. This way any generic array manipulation tools I may have created for myself have much broader usability. The whole environment (OS + applications) would be structure centric, not bytestream centric. And this problem is compounded by the number of different data structures. A nD array and a tree cover 80 % of structures the user conceptually works with. Add DAGs and a few other types of graphs and you are at 90 %. Moreover, specialized views can often be ambiguous, whereas the generic ones wouldn't be ambiguous. 3) Get rid of established but unnatural ways of manipulating data. Most importantly, get rid of flat text and find neat graphical representations for the most common structures. Bouhahaha! I mean, graphical representations are nice. To read them. But when it comes to editing, ie. to transfering information from the human brain to the computer, nothing beats in bandwidth the ten fingers and the ~100-key keyboard. I am sorry, my wording was not exact. I meant to say find neat generic graphical *presentations* of structures and edit the structures directly, not their on-disk linear representations. I didn't say anything about input methods. There is no reason why one couldn't directly and very efficiently edit structures using a keyboard. Such systems actually exist, but I think they are underused in the programming community. Unless you want to develop high resolution brain waves reading systems. This would be nice, I could then prepare my answers in advance. The point is that you can't think like that, in such general terms, for all applications and for everybody. Yes, I use very general arguments, so there is greater risk of missing important details. At the same time, there is higher chance of finding new ways to simplify all this stuff. Software development is a disaster today and the various tools constantly emerging are actually just masking the real problems, making really effective solutions even less likely. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Flat text and 1D syntax considered harmful
Well, I'm not a mathematician, but when I have to do equations, the problem I have in doing math on a screen doesn't come from the text matrix, but rather from the lack of automatic tools to manipulate the equations. On the paper, hand written math notation is optimized enough so you can just rewrite and rewrite transformed equations. (But for big ones it can still become boring fast, and it's always very error prone). What you'd want on a computer, is not to reproduce the paper/hand notation, but to add algebraic tools to manipulate the equations at a higher level. Now this is about what is done in semi-automatic theorem proving systems, where the user gives hints, and the program performs the equation rewritting itself until it reaches the final proof. It's not done in a graphical and animated way, but is it necessary? ax+b=cx+d click and drag cx on the other side and get an animation that ends into: ⇔ (a-c)x+b=d click and drag b on the other side and get an animation that ends into: ⇔ (a-c)x=(d-b) click and drag (a-c) on the other side and get an animation that ends into: ⇔ ⦚ a≠c ∧ x=(d-b)/(a-c) ⦚ a=c ∧ b=d It works as well in text than in graphics. Now instead of slow and painful click-and-drag, you could just type editing commands like C-s cx RET I am not against keyboard input. What you suggest is not text editing -- this is structure editing and this is exactly my point. The fact that the structure is presented as flat test is irrelevant. The editing works on a representation that is not flat but structured. Moreover, I find it intuitive that the same approach (structured editing) would be useful in programming, too. Unfortunately, even advanced IDEs are based on text editing instead of structured editing. IDEs support *some* structured manipulations, but in a totally ad-hoc way, bolted-on what is basically a typewriter. The DOS version of Derive was much better in this respect 20 years ago. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Flat text and 1D syntax considered harmful
This! There have been so many attempts - by people who were by no means stupid - to replace text as the primary representation of code! And ALL of them have failed, miserably! The best anyone has ever achieved was to enthuse a few managers, much to the detriment of the engineers who eventually had to use the shit on a daily basis! Nope, there are some that succeeded. Latex documents are a kind of a source code. Lyx (lyx.org) very successfully replaces Latex source editing with structured document editing. It still has a Latex fallback (snippets of Latex embedded in the Lyx document), but 95-100 % of the document is pure Lyx. I see no principal reason why the same thing could not be done with a say C++ source or Javascript source. It would be actually pretty straightforward. Maybe many past projects tried to invent a new language together with the graphical (re)presentation. But one can just keep the semantics of the language. A source code represents a tree. When you lay out the tree left to right, top to bottom, you get something pretty similar to what a tediously formatted source code looks like, just nicer and more regular. Parentheses are replaced by indentation and frames or something like that. It looks almost the same except, as a bonus, you can embed pixmaps or tensor formulas in Penrose notation into the code. Selection does not operate on pieces of text, but on subtrees, so the editing operations are a little bit different. For example, you cannot produce unbalanced parentheses, because there are either no parentheses, or they are just part of the presentation, but not of the representation. Also: 1D representations are established exactly BECAUSE they are NATURAL! The logical part of your mind (the neocortex, some people used to call it the left half of the brain, but this has firmly been established to be a somewhat shitty simplification) works serially in time: state(t+1) = f( state(t) , input(t) ) It works in 1D! An it likes representations in... 1D! Cheers, Frank I do not think this is a valid argument. A programmer's attention may very well jump all over the code in a nonlinear fashion, even though his thinking may be a sequential process. The brain does not work with the source code character by character. It uses the highly parallel visual cortex to identify the structure. That's why formatting the source is so important -- you are basically creating a 2D syntax in an ad-hoc way, so you can leverage the capabilities of the visual cortex. The editor attempts to make this process easier in an ad-hoc way through functionality like format paragraph etc. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Flat text and 1D syntax considered harmful
Thank you for the pointers to potentially relevant work. PB On Sun, Jul 21, 2013 at 12:43 AM, John Carlson yottz...@gmail.com wrote: I believe that X3D-Edit provides dual views. On Jul 20, 2013 5:26 PM, John Carlson yottz...@gmail.com wrote: Sorry if I mixed 2D and 3D ideas here. On Jul 20, 2013 5:12 PM, John Carlson yottz...@gmail.com wrote: Now that I think of it, this is the old argument of immediate mode versus retained mode graphics. A hybrid system I believe is best. Postscript/pdf has 3 types of graphics. Images, text, and curves. Many systems these days only deal with images and text. I'd like to remind people that curves are important too. I realize that curves are decomposed into triangles and later textures, but if we manage them as curves, there's a chance for a better user experience. However some like bumpy user experiences and some like smooth user experiences. That's why we provide dual/hybrid modes. On Jul 20, 2013 4:20 PM, John Carlson yottz...@gmail.com wrote: Another program which has worked well in dual text/graphic mode has been dreamweaver. Yes I understand it may not do all the behavior you want. However it doesn't stop you from adding that behavior. On Jul 20, 2013 4:13 PM, John Carlson yottz...@gmail.com wrote: One such test automation system is Sikuli, which uses images and image recognition as key components. To implement the image as 1D text seems rather foolhardy. On Jul 20, 2013 4:09 PM, John Carlson yottz...@gmail.com wrote: I think one thing that has succeeded is macro editors. You can make macro languages which work on selectors or add conditionals/recursion to such a macro editor to achieve a fairly complete programming language. You could also treat exceptions similar to conditionals. I believe the area this works best for is test automation. On Jul 20, 2013 11:22 AM, frank fr...@frankhirsch.net wrote: On 07/20/2013 04:21 PM, Pascal J. Bourguignon wrote: 3) Get rid of established but unnatural ways of manipulating data. Most importantly, get rid of flat text and find neat graphical representations for the most common structures. Bouhahaha! This! There have been so many attempts - by people who were by no means stupid - to replace text as the primary representation of code! And ALL of them have failed, miserably! The best anyone has ever achieved was to enthuse a few managers, much to the detriment of the engineers who eventually had to use the shit on a daily basis! Also: 1D representations are established exactly BECAUSE they are NATURAL! The logical part of your mind (the neocortex, some people used to call it the left half of the brain, but this has firmly been established to be a somewhat shitty simplification) works serially in time: state(t+1) = f( state(t) , input(t) ) It works in 1D! An it likes representations in... 1D! Cheers, Frank ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Flat text and 1D syntax considered harmful
Yes, what you write is what I had in mind. But this would really be abandoning 1d representation. I consider this to be a very important conceptual shift, not a mere moderate change! The presentation would be still 1d-like, but this is not important -- you may very well switch among several presentations. Applying this universally in the whole system allows one to use generic editing tools, without the impedance mismatch and continuous parsing of flat text in gazillion of different formats. It is then natural to apply this approach to the whole OS shell, not just the IDE. I had the source control for free idea, too, and it is nice to hear it from someone else, too. On Sun, Jul 21, 2013 at 2:04 PM, Gath-Gealaich gath.na.geala...@gmail.comwrote: On Sat, 20 Jul 2013 17:54:54 +0200 frank fr...@frankhirsch.net wrote: This! There have been so many attempts - by people who were by no means stupid - to replace text as the primary representation of code! And ALL of them have failed, miserably! The best anyone has ever achieved was to enthuse a few managers, much to the detriment of the engineers who eventually had to use the shit on a daily basis! Hmm, perhaps extremes are a bad thing, but some moderate changes could yield improvements? I've recently thought of a programming system that would dispense with source files, but not in order to replace them with some sort of visual programming system or anything of the kind - simply to impose some potentially useful constraints onto the editing process, Paredit-style. For example, keeping the source in form of a data structure would obviate the parsing process - you'd eliminate syntactic errors. That's not to say that this would make the editing process visual, as in playing with pictures - you'd simply be unable to make edits that violate the code structure (say bye to unbalanced parentheses - yes, I'd like the system to be an enhanced derivative of Scheme, coincidentally). When I started thinking about the editing process this way, some interesting ideas clicked into place - for example the notion that if I made the program data structure (every module being a grove of trees) a persistent one, many useful and desirable features of a programming environment get simplified: for example, the notion of Git-like versioning on disk and undo-redo in memory simply become the same thing. The different versions of the code would share most of the structure, dispensing with most of the need for compression (which Git needs in order not to blow up your disk with redundant data) and simplifying code comparison and diffing (once you find that two (sub)trees of code you're comparing have an identical root node, you don't need to go any deeper; you already know that they're identical). Gath ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Flat text and 1D syntax considered harmful
The structures you need when programming behavior are lists of operations, something like lisp's cond with parameters, and the ability to refer to a cond from anywhere in the program (recursion, procedure call). Everything else is icing on the cake. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Flat text and 1D syntax considered harmful
On Sun, Jul 21, 2013 at 5:04 AM, Gath-Gealaich gath.na.geala...@gmail.comwrote: On Sat, 20 Jul 2013 17:54:54 +0200 frank fr...@frankhirsch.net wrote: Hmm, perhaps extremes are a bad thing, but some moderate changes could yield improvements? I've recently thought of a programming system that would dispense with source files, but not in order to replace them with some sort of visual programming system or anything of the kind - simply to impose some potentially useful constraints onto the editing process, Paredit-style. For example, keeping the source in form of a data structure would obviate the parsing process - you'd eliminate syntactic errors. That's not to say that this would make the editing process visual, as in playing with pictures - you'd simply be unable to make edits that violate the code structure (say bye to unbalanced parentheses - yes, I'd like the system to be an enhanced derivative of Scheme, coincidentally). I have been thinking along parallel dimensions; no implementation yet, but this is a sketch of a minimal system: http://mnemnion.github.io/blog/2013/06/17/an-introduction-to-ent/ ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Macros, JSON
I thought about this briefly. One issue is how to distinguish literal strings from identifiers. On Sun, Jul 21, 2013 at 10:28 AM, John Carlson yottz...@gmail.com wrote: Hmm. I've been thinking about creating a macro language written in JSON that operates on JSON structures. Has someone done similar work? Should I just create a JavaScript AST in JSON? Or should I create an AST specifically for JSON manipulation? Thanks, John ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc -- --- james mccartney ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Macros, JSON
As an alternative to JSON you might consider EDN: https://github.com/edn-format/edn Alan On Jul 21, 2013, at 11:46 AM, John Carlson yottz...@gmail.com wrote: Hmm. I've been thinking about creating a macro language written in JSON that operates on JSON structures. Has someone done similar work? Should I just create a JavaScript AST in JSON? Or should I create an AST specifically for JSON manipulation? Thanks, John ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Macros, JSON
JSON is all well and good as far as lowest common denominators go. However, you might want to consider EDN: https://github.com/edn-format/edn On the other hand, if you are doing that then you might as well go *all* the way and re-invent half of Common Lisp :-) http://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule Alan Moore On Sun, Jul 21, 2013 at 10:28 AM, John Carlson yottz...@gmail.com wrote: Hmm. I've been thinking about creating a macro language written in JSON that operates on JSON structures. Has someone done similar work? Should I just create a JavaScript AST in JSON? Or should I create an AST specifically for JSON manipulation? Thanks, John ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Flat text and 1D syntax considered harmful
Looks interesting. Have you seen LightTable? If not, see: http://www.lighttable.com/ Alan Moore On Sun, Jul 21, 2013 at 12:03 PM, Sam Putman atmanis...@gmail.com wrote: On Sun, Jul 21, 2013 at 5:04 AM, Gath-Gealaich gath.na.geala...@gmail.com wrote: On Sat, 20 Jul 2013 17:54:54 +0200 frank fr...@frankhirsch.net wrote: Hmm, perhaps extremes are a bad thing, but some moderate changes could yield improvements? I've recently thought of a programming system that would dispense with source files, but not in order to replace them with some sort of visual programming system or anything of the kind - simply to impose some potentially useful constraints onto the editing process, Paredit-style. For example, keeping the source in form of a data structure would obviate the parsing process - you'd eliminate syntactic errors. That's not to say that this would make the editing process visual, as in playing with pictures - you'd simply be unable to make edits that violate the code structure (say bye to unbalanced parentheses - yes, I'd like the system to be an enhanced derivative of Scheme, coincidentally). I have been thinking along parallel dimensions; no implementation yet, but this is a sketch of a minimal system: http://mnemnion.github.io/blog/2013/06/17/an-introduction-to-ent/ ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Macros, JSON
You would have to create a JSON object which would have key (identifier), value pairs. On Jul 21, 2013 3:22 PM, James McCartney asy...@gmail.com wrote: I thought about this briefly. One issue is how to distinguish literal strings from identifiers. On Sun, Jul 21, 2013 at 10:28 AM, John Carlson yottz...@gmail.com wrote: Hmm. I've been thinking about creating a macro language written in JSON that operates on JSON structures. Has someone done similar work? Should I just create a JavaScript AST in JSON? Or should I create an AST specifically for JSON manipulation? Thanks, John ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc -- --- james mccartney ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Macros, JSON
I think what would be more difficult would be identifying what is persistent and what is runtime values. Also, JSON doesn't contain pointers, so one would have to use strings for pointers. On Jul 21, 2013 3:22 PM, James McCartney asy...@gmail.com wrote: I thought about this briefly. One issue is how to distinguish literal strings from identifiers. On Sun, Jul 21, 2013 at 10:28 AM, John Carlson yottz...@gmail.com wrote: Hmm. I've been thinking about creating a macro language written in JSON that operates on JSON structures. Has someone done similar work? Should I just create a JavaScript AST in JSON? Or should I create an AST specifically for JSON manipulation? Thanks, John ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc -- --- james mccartney ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Macros, JSON
Or numbers for pointers... On Jul 21, 2013 3:43 PM, John Carlson yottz...@gmail.com wrote: I think what would be more difficult would be identifying what is persistent and what is runtime values. Also, JSON doesn't contain pointers, so one would have to use strings for pointers. On Jul 21, 2013 3:22 PM, James McCartney asy...@gmail.com wrote: I thought about this briefly. One issue is how to distinguish literal strings from identifiers. On Sun, Jul 21, 2013 at 10:28 AM, John Carlson yottz...@gmail.comwrote: Hmm. I've been thinking about creating a macro language written in JSON that operates on JSON structures. Has someone done similar work? Should I just create a JavaScript AST in JSON? Or should I create an AST specifically for JSON manipulation? Thanks, John ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc -- --- james mccartney ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Macros, JSON
What makes this important is whether your running in stateless or stateful mode. If you only run the macro once no big deal. If you try to run on a server, you may find that you need to reset items like cursors to their original values. On Jul 21, 2013 3:43 PM, John Carlson yottz...@gmail.com wrote: I think what would be more difficult would be identifying what is persistent and what is runtime values. Also, JSON doesn't contain pointers, so one would have to use strings for pointers. On Jul 21, 2013 3:22 PM, James McCartney asy...@gmail.com wrote: I thought about this briefly. One issue is how to distinguish literal strings from identifiers. On Sun, Jul 21, 2013 at 10:28 AM, John Carlson yottz...@gmail.comwrote: Hmm. I've been thinking about creating a macro language written in JSON that operates on JSON structures. Has someone done similar work? Should I just create a JavaScript AST in JSON? Or should I create an AST specifically for JSON manipulation? Thanks, John ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc -- --- james mccartney ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Macros, JSON
Hmm. Seems like someone has already done XMLisp. I thought s-expressions were the lowest common denominator. JSON is all well and good as far as lowest common denominators go. However, you might want to consider EDN: https://github.com/edn-format/edn On the other hand, if you are doing that then you might as well go *all* the way and re-invent half of Common Lisp :-) http://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule Alan Moore On Sun, Jul 21, 2013 at 10:28 AM, John Carlson yottz...@gmail.com wrote: Hmm. I've been thinking about creating a macro language written in JSON that operates on JSON structures. Has someone done similar work? Should I just create a JavaScript AST in JSON? Or should I create an AST specifically for JSON manipulation? Thanks, John ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Macros, JSON
Lisp is such a joy to implement. FORTH is fun too.
I'm working on a scheme-alike on and off. The idea is to take the message
passing and delegation from Self, expose it in Lisp, and then map all of that
to JavaScript.
One idea I had when I was messing around with OMetaJS was that it might have
some kind of escape syntax like
(let ((x 1))
#{x++; }#
)
Would basically mean
(let ((x 1))
(+ x 1))
...which would make doing primitives feel pretty smooth, and also give you
the nice JSON syntax.
The rule is simple too, '#{' followed by anything:a up until '}#' - eval(a)
Only problem is relating environment context between the two languages, which I
haven't bothered to figure out yet. The JS eval() in this case is insufficient.
(Sorry about the pseudocode, on a phone and don't keep OMeta syntax in my
head...)
On Jul 21, 2013, at 1:15 PM, Alan Moore kahunamo...@closedsource.com wrote:
JSON is all well and good as far as lowest common denominators go. However,
you might want to consider EDN:
https://github.com/edn-format/edn
On the other hand, if you are doing that then you might as well go *all* the
way and re-invent half of Common Lisp :-)
http://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule
Alan Moore
On Sun, Jul 21, 2013 at 10:28 AM, John Carlson yottz...@gmail.com wrote:
Hmm. I've been thinking about creating a macro language written in JSON that
operates on JSON structures. Has someone done similar work? Should I just
create a JavaScript AST in JSON? Or should I create an AST specifically for
JSON manipulation?
Thanks,
John
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Macros, JSON
Probably a more usable language would be arrived upon via some extensions to JSON. May I recommend OMetaJS? :) The lack of a unique atomic symbolic literal as distinct from a string is one of the things I'm grappling with right now. To get that I'd need to intern the atoms. Jury's out whether it's a good idea to try to used JS typed arrays to implement the symbol interning or to use an under the hood tag on the string at the intermediate level to distinguish them (hidden from the programmer who just sees a Lisp alike.) On Jul 21, 2013, at 1:45 PM, John Carlson yottz...@gmail.com wrote: Or numbers for pointers... On Jul 21, 2013 3:43 PM, John Carlson yottz...@gmail.com wrote: I think what would be more difficult would be identifying what is persistent and what is runtime values. Also, JSON doesn't contain pointers, so one would have to use strings for pointers. On Jul 21, 2013 3:22 PM, James McCartney asy...@gmail.com wrote: I thought about this briefly. One issue is how to distinguish literal strings from identifiers. On Sun, Jul 21, 2013 at 10:28 AM, John Carlson yottz...@gmail.com wrote: Hmm. I've been thinking about creating a macro language written in JSON that operates on JSON structures. Has someone done similar work? Should I just create a JavaScript AST in JSON? Or should I create an AST specifically for JSON manipulation? Thanks, John ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc -- --- james mccartney ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Macros, JSON
All this talk of macros and quotes reminds me that there is Kernel language
where they are extraneous (if I understand it correctly). Operative and
applicative combiners are used explicitly:
http://www.wpi.edu/Pubs/ETD/Available/etd-090110-124904/unrestricted/jshutt.pdf
On Sun, Jul 21, 2013 at 5:06 PM, Casey Ransberger
casey.obrie...@gmail.comwrote:
Lisp is such a joy to implement. FORTH is fun too.
I'm working on a scheme-alike on and off. The idea is to take the message
passing and delegation from Self, expose it in Lisp, and then map all of
that to JavaScript.
One idea I had when I was messing around with OMetaJS was that it might
have some kind of escape syntax like
(let ((x 1))
#{x++; }#
)
Would basically mean
(let ((x 1))
(+ x 1))
...which would make doing primitives feel pretty smooth, and also give
you the nice JSON syntax.
The rule is simple too, '#{' followed by anything:a up until '}#' -
eval(a)
Only problem is relating environment context between the two languages,
which I haven't bothered to figure out yet. The JS eval() in this case is
insufficient.
(Sorry about the pseudocode, on a phone and don't keep OMeta syntax in my
head...)
On Jul 21, 2013, at 1:15 PM, Alan Moore kahunamo...@closedsource.com
wrote:
JSON is all well and good as far as lowest common denominators go.
However, you might want to consider EDN:
https://github.com/edn-format/edn
On the other hand, if you are doing that then you might as well go *all*
the way and re-invent half of Common Lisp :-)
http://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule
Alan Moore
On Sun, Jul 21, 2013 at 10:28 AM, John Carlson yottz...@gmail.com wrote:
Hmm. I've been thinking about creating a macro language written in JSON
that operates on JSON structures. Has someone done similar work? Should I
just create a JavaScript AST in JSON? Or should I create an AST
specifically for JSON manipulation?
Thanks,
John
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Flat text and 1D syntax considered harmful
On Sun, Jul 21, 2013 at 1:32 PM, Alan Moore kahunamo...@closedsource.comwrote: Looks interesting. Have you seen LightTable? If not, see: http://www.lighttable.com/ Alan Moore Indeed! Although I currently use Catnip: https://github.com/bodil/catnip Because the source is available now and the workflow is great. The main reason there's not even a toy ent is because LightTable will be open sourced 'one of these days'. cheers, -Sam. On Sun, Jul 21, 2013 at 12:03 PM, Sam Putman atmanis...@gmail.com wrote: On Sun, Jul 21, 2013 at 5:04 AM, Gath-Gealaich gath.na.geala...@gmail.com wrote: On Sat, 20 Jul 2013 17:54:54 +0200 frank fr...@frankhirsch.net wrote: Hmm, perhaps extremes are a bad thing, but some moderate changes could yield improvements? I've recently thought of a programming system that would dispense with source files, but not in order to replace them with some sort of visual programming system or anything of the kind - simply to impose some potentially useful constraints onto the editing process, Paredit-style. For example, keeping the source in form of a data structure would obviate the parsing process - you'd eliminate syntactic errors. That's not to say that this would make the editing process visual, as in playing with pictures - you'd simply be unable to make edits that violate the code structure (say bye to unbalanced parentheses - yes, I'd like the system to be an enhanced derivative of Scheme, coincidentally). I have been thinking along parallel dimensions; no implementation yet, but this is a sketch of a minimal system: http://mnemnion.github.io/blog/2013/06/17/an-introduction-to-ent/ ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Macros, JSON
On 7/21/2013 12:28 PM, John Carlson wrote: Hmm. I've been thinking about creating a macro language written in JSON that operates on JSON structures. Has someone done similar work? Should I just create a JavaScript AST in JSON? Or should I create an AST specifically for JSON manipulation? my scripting language mostly uses S-Expressions for its AST format. my C frontend mostly used an XML variant. I had a few times considered a hybrid, essentially like XML with a more compact syntax (*1). in the future, most likely I would just use S-Expressions. while S-Exps are slightly more effort in some cases to extend, they are generally faster than manipulating XML, and are easier to work with. JSON could work, but its syntax is slightly more than what is needed for something like this, and its data representation isn't necessarily ideal. EDN looks ok. *1: node := '' tag (key'='value)* node* '' tag key=value tag2 key2=val2 tag3 where value was a literal value with one of several types, IIRC: integer type; floating-point type; string. note that there were no free-floating raw values. a free-floating value would instead be wrapped in a node. had also considered using square braces: [array [int val=1234] [real val=3.14] [string val=string] [symbol val=symbol]] the allowed forms would otherwise have been fairly constrained. the constrained structure would be mostly for sake of performance and similar. note: the XML variant used by my C frontend also ended up (quietly) adding support for raw numeric values, mostly because of the added overhead of converting between strings and numbers. Thanks, John ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
