From: cbcurl on 14 Dec 2009 09:57 On Dec 8, 3:28 pm, "Bill Cunningham" <nos...(a)nspam.invalid> wrote: > "cbcurl" <cbc...(a)gmail.com> wrote in message > > news:679a89c3-8396-4672-95ce-58b37558b8f2(a)g7g2000yqa.googlegroups.com... > On Dec 7, 8:16 pm, p...(a)informatimago.com (Pascal J. Bourguignon) > wrote: > >>> Don't be silly, markup languages are not programming languages. > >> They can be. Curl is a programming language that can also be used as a >> markup language. > > What is Curl? Now I've never heard of that. I thought TCL/TK might be > mentioned in writing OSs but maybe not. I have never used tcl/tk so I can't > comment on it. It's interpreter driven anyway so neither it nor perl could > be used for writing OSs. Curl is a language specifically designed for web-deployed applications. It has an extensible prefix syntax that allows you to freely mix marked up text with code. It is statically typed and object oriented but also provides dynamic typing ability as well. The syntax is somewhat like lisp but uses curly braces instead of parens (thus the name 'curl') and uses "noisewords" to delimit syntax, with the result that the code ends up looking more like a C-style language. The fact that you can write markup in Curl allows developers to write their API documentation in Curl as well. Curl is primarily used in Japan, but you can get a copy of the RTE and development environment from www.curl.com if you are interested. - Christopher
From: cbcurl on 14 Dec 2009 10:11 On Dec 8, 4:15 pm, p...(a)informatimago.com (Pascal J. Bourguignon) wrote: > "Bill Cunningham" <nos...(a)nspam.invalid> writes: > > "cbcurl" <cbc...(a)gmail.com> wrote in message > >news:679a89c3-8396-4672-95ce-58b37558b8f2(a)g7g2000yqa.googlegroups.com... > > On Dec 7, 8:16 pm, p...(a)informatimago.com (Pascal J. Bourguignon) > > wrote: > > >> Don't be silly, markup languages are not programming languages. > > > They can be. Curl is a programming language that can also be used as a > > markup language. > > You have a problem with the notion of subset. Don't be stupid. You know perfectly well that I have no such confusion. You said "markup languages are not programming languages": i.e. the set of markup languages does not intersect the set of programming languages. I provided a counterexample. Really all you meant to say is that the markup features that are the defining characteristic of markup languages are not sufficient for programming tasks, so a pure markup language such SGML, HTML, or XML couldn't be used for this purpose. - C
From: Pascal J. Bourguignon on 14 Dec 2009 10:41 cbcurl <cbcurl(a)gmail.com> writes: > On Dec 8, 4:15Â pm, p...(a)informatimago.com (Pascal J. Bourguignon) > wrote: >> "Bill Cunningham" <nos...(a)nspam.invalid> writes: >> > "cbcurl" <cbc...(a)gmail.com> wrote in message >> >news:679a89c3-8396-4672-95ce-58b37558b8f2(a)g7g2000yqa.googlegroups.com... >> > On Dec 7, 8:16 pm, p...(a)informatimago.com (Pascal J. Bourguignon) >> > wrote: >> >> >> Don't be silly, markup languages are not programming languages. >> >> > They can be. Curl is a programming language that can also be used as a >> > markup language. >> >> You have a problem with the notion of subset. > > Don't be stupid. You know perfectly well that I have no such > confusion. You said "markup languages are not programming languages": > i.e. the set of markup languages does not intersect the set of > programming languages. I provided a counterexample. So we can see you also have a problem with the intersection. Perhaps you should go back to primary school and study these basic concepts again? A â B and A â© B = â are quite different propositions. "markup languages are not programming languages" means that the set of markup language is not a subset of programming language. This is what I said. From that you can infer that there exist at least one markup programming language that is not a programming language, but you cannot infer that there is no programming language that can be used as markup language, or that there is no language that is both a markup language or a programming language, the negation of both things being therefore what I meant implicitely. > Really all you meant to say is that the markup features that are the > defining characteristic of markup languages are not sufficient for > programming tasks, so a pure markup language such SGML, HTML, or XML > couldn't be used for this purpose. Yes. -- __Pascal Bourguignon__
From: BGB / cr88192 on 14 Dec 2009 14:06
"cbcurl" <cbcurl(a)gmail.com> wrote in message news:6ab12032-0333-42cd-8b54-4037b7973dd5(a)t19g2000vbc.googlegroups.com... On Dec 8, 3:28 pm, "Bill Cunningham" <nos...(a)nspam.invalid> wrote: > "cbcurl" <cbc...(a)gmail.com> wrote in message > > news:679a89c3-8396-4672-95ce-58b37558b8f2(a)g7g2000yqa.googlegroups.com... > On Dec 7, 8:16 pm, p...(a)informatimago.com (Pascal J. Bourguignon) > wrote: > >>> Don't be silly, markup languages are not programming languages. > >> They can be. Curl is a programming language that can also be used as a >> markup language. > > What is Curl? Now I've never heard of that. I thought TCL/TK might be > mentioned in writing OSs but maybe not. I have never used tcl/tk so I > can't > comment on it. It's interpreter driven anyway so neither it nor perl could > be used for writing OSs. <-- Curl is a language specifically designed for web-deployed applications. It has an extensible prefix syntax that allows you to freely mix marked up text with code. It is statically typed and object oriented but also provides dynamic typing ability as well. The syntax is somewhat like lisp but uses curly braces instead of parens (thus the name 'curl') and uses "noisewords" to delimit syntax, with the result that the code ends up looking more like a C-style language. The fact that you can write markup in Curl allows developers to write their API documentation in Curl as well. Curl is primarily used in Japan, but you can get a copy of the RTE and development environment from www.curl.com if you are interested. --> odd... I had also made a language which was lisp-like, but using curly braces. my reason for doing so was mostly because I had added infix expressions, and had wanted to use parens for such things as forcing evaluation order, ... {foo (2+3)*5} it does not use commas, but instead is whitespace sensitive in many cases: "2-3" vs "2 -3", where the space essentially makes it mean "2, -3" rather than "2-3". its design was mostly to be easier to type interactively, as I ended up using it primarily as an interactive non-trivial calculator (replacing my use of guile for this task...). I think I remember I had also used a haskell-derived notation for lambdas: "\{x} (x*x)" functions were declared like "{foo: x}=(x*x)". it also had complex numbers, vectors, (if I remember correctly) basic quaternions, ... it could also graph stuff (and save the results as image files). (I think I also did a lot of this, as, I had a class which used the TI-83, but didn't so much like the UI of the TI-83...). it was intended also for paramatic geometry construction, but didn't end up used quite so much for this task. I had called it "BGGL3" (for BGB Geometry Generation Language), where there was: BGGL, which was loosely derived from Scheme but which had keywords, and primarily used named parameters (loosely derived from SmallTalk and CL), and was dynamically scoped. I later came to the opinion that naming the parameters and using dynamic scope was not worthwhile... BGGL2 was derived from PostScript, and found to be largely unusable... BGGL3 was basically much closer to Scheme, but used lexical scoping and a modified syntax. more recently, for my uses I may have reason to revive the language (BGGL4?), although I will likely make a few alterations: adding more comprehensive vector and quaternion facilities, and probably matrix math, ... switching primarily to CSG operations (and more abstract "geometry objects") rather than direct geometry construction. possibly, it may be fused into, or absorb parts of, the Valve220 variant of the map format (such as adding "entities" and "brushes"), or made available for use from within map files (implied stuffing the interpreter into the BSP tool), ... granted, to do all this well would require a mapper which can deal with all this, so I may have reason to write something like this. support for all this would probably be pulled of by adding a variant of a prototype-based object system (although, objects will have named "types" to indicate their intended functioning). so, it may make more sense to implement a sort of "loose class-instance", rather than pure prototype OO (it would look and behave more like C/I-OO, but likely be implemented more like P-OO). it would also be loose in that it would be dynamically typed, and objects could add arbitrary custom slots to objects (absent explicit subclassing). {class: <classname> <super> (<declaration*>)} ;declare class {<classname> <param*>} ;new class instance 'new' could likely be a constructor method, which will be what is given the arguments, ... {csgbrush {csgface [1 0 0 16] "foo/bar" [0 1 0] [0 0 1]} {csgface [-1 0 0 16] "foo/bar" [0 -1 0] [0 0 1]} {csgface [0 1 0 16] "foo/bar" [1 0 0] [0 0 1]} {csgface [0 -1 0 16] "foo/bar" [-1 0 0] [0 0 1]} {csgface [0 0 1 16] "foo/bar" [1 0 0] [0 1 0]} {csgface [0 0 -1 16] "foo/bar" [-1 0 0] [0 -1 0]} } or such... |