From: cbcurl on
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
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
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

"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...