Loading ...
Sorry, an error occurred while loading the content.
 

back online

Expand Messages
  • cr88192
    ok, I have returned from my month long experience with pretty much no computer or internet access... I continue on my current language effort. it still looks a
    Message 1 of 16 , May 3, 2004
      ok, I have returned from my month long experience with pretty much no
      computer or internet access...

      I continue on my current language effort. it still looks a lot like
      javascript...

      the math parser is left-associative. this may sound weird, but there
      are reasons (mostly related to me being unsure how to approach order
      of operations in math-parsing...).

      fragment (in case anyone forgot and actually cares):
      var i;

      for(i=0; i<16; i++)
      {
      if(i<5)continue;
      if(i>12)break;
      println(i);
      }

      function foo(a1, a2)
      {
      println("foo", a1, a2);
      }

      foo(2, 3);

      var foo_obj=Object.clone();
      println(foo_obj);

      foo_obj.x=3;
      foo_obj.y=4;
      foo_obj.pr=fun()
      {
      local z;
      z=x+y;
      println("obj", x, y, z);
      };

      println(foo_obj.x, foo_obj.y);
      foo_obj.pr();

      println(("foo"+"bar")+3);
      println({1, 2, 3});
      println(xml {<?xml version="1.0"?><xmltest><aTag/>some
      text</xmltest><another/>});

      I have inline if's: (a>b)?a:b;
      I also have switch (pretty much the same syntax as c, though it
      doesn't quite behave the same as of yet).

      adding strings will concatenate them, adding numbers to strings will
      skip forwards over the characters.
      similar will likely go for arrays (still considering the array+array
      case).


      for a gui this time I am taking the approach of keeping the ui itself
      seperate from the code that uses it.
      the ui has a syntax similar to web-forms:
      <form>
      <vbox>
      <input type="button" label="Button0"/>
      <input type="checkbox" label="Button1"/>
      <input type="text" value="textbox"/>

      <input type="radio" name="rad0" label="Radio1"/>
      <input type="radio" name="rad0" label="Radio2"/>
      <input type="radio" name="rad0" label="Radio3"/>
      </vbox>
      </form>

      important differences exist though:
      it is not html, and thus html fragments wont work as expected;
      vbox, hbox, and table are currently used as the only real means to
      organize widgets (things like <br/> would make formatting more
      complex);
      there is a "text" widget <text>a glob of text...</text> if text is
      needed;
      labels have been for the most part merged into widgets;
      ...

      as a minor bit of coolness, I actually made the widgets (sort of)
      look like their windows counterparts, as opposed to multicolored
      squares (as I had typically used in the past...).

      all for now.
    • Marcin 'Qrczak' Kowalczyk
      ... And I just made a binding between Kogut and Python (incomplete yet), with appropriate automatic translation of objects: simple types are converted by
      Message 2 of 16 , May 3, 2004
        W liście z pon, 03-05-2004, godz. 08:51 +0000, cr88192 napisał:

        > for a gui this time I am taking the approach of keeping the ui itself
        > seperate from the code that uses it.

        And I just made a binding between Kogut and Python (incomplete yet),
        with appropriate automatic translation of objects: simple types are
        converted by value, other are appropriately wrapped and unwrapped.
        Exceptions are propagated, various protocols (e.g. those concerning
        collections) are translated. Unicode strings and long integers work.

        This gave me instant access to many libraries with zero additional
        effort per library. For example Gtk+. Here is a transliterated example
        from pygtk:

        use Foreign.Python;
        let gobject = PyImport "gobject";
        let gtk = PyImport "gtk";
        let window = gobject.new gtk.Window
        type:gtk.WINDOW_TOPLEVEL
        title:"Hello World"
        allow_grow:gtk.FALSE
        allow_shrink:gtk.FALSE
        border_width:10;
        window.connect "destroy" ?_... {
        window.hide();
        gtk.main_quit()
        };
        let button = gobject.new gtk.Button
        label:"Hello world"
        parent:window;
        button.connect "clicked" ?_... {
        WriteLine "Hello World";
        window.destroy()
        };
        window.show_all();
        gtk.main();

        --
        __("< Marcin Kowalczyk
        \__/ qrczak@...
        ^^ http://qrnik.knm.org.pl/~qrczak/
      • cr88192
        ... itself ... yes, I had commented on this as many of my previous gui s were basically tied to the object system (eg: 3 such guis were tied to different forms
        Message 3 of 16 , May 3, 2004
          --- In langsmiths@yahoogroups.com, Marcin 'Qrczak' Kowalczyk
          <qrczak@k...> wrote:
          > W li¶cie z pon, 03-05-2004, godz. 08:51 +0000, cr88192 napisa³:
          >
          > > for a gui this time I am taking the approach of keeping the ui
          itself
          > > seperate from the code that uses it.
          >
          yes, I had commented on this as many of my previous gui's were
          basically tied to the object system (eg: 3 such guis were tied to
          different forms of the lang/bgb object system).
          I figured: crap, why don't I just do the gui in pure c, and seperate
          it into multiple layers:
          the widget layer (does drawing and manages forms/widgets, doesn't
          care where the interaction is comming from);
          an interface layer (may involve a network);
          the language interface (objects, methods, ... for interacting with
          the interface layer).

          eg: I am considering spec'ing something for doing a gui over xmpp (or
          maybe allowing sharing of the ui). mirroring a ui like this would
          likely be more effective than my previous attempts (usually working
          by mirroring objects), mostly as one could get by with copying the
          forms (which are luckily not very stateful), info about the widget
          states, and by propagating messages pertaining to state changes.

          of course, this may well still be pointless.

          > And I just made a binding between Kogut and Python (incomplete yet),
          > with appropriate automatic translation of objects: simple types are
          > converted by value, other are appropriately wrapped and unwrapped.
          > Exceptions are propagated, various protocols (e.g. those concerning
          > collections) are translated. Unicode strings and long integers work.
          >
          oh yes, I remember this kind of experience...
          lang/bgb and my xml-rpc code had used different typesystems, even
          though I had created both they had no where near similar workings.

          it was a sufficient pita that effectively I started considering
          designing a new lang to escape it (that and I was also beginning to
          see the limits of a scheme core, and of my previous typesystem...)

          > This gave me instant access to many libraries with zero additional
          > effort per library. For example Gtk+. Here is a transliterated
          example
          > from pygtk:
          >
          > use Foreign.Python;
          > let gobject = PyImport "gobject";
          > let gtk = PyImport "gtk";
          > let window = gobject.new gtk.Window
          > type:gtk.WINDOW_TOPLEVEL
          > title:"Hello World"
          > allow_grow:gtk.FALSE
          > allow_shrink:gtk.FALSE
          > border_width:10;
          > window.connect "destroy" ?_... {
          > window.hide();
          > gtk.main_quit()
          > };
          > let button = gobject.new gtk.Button
          > label:"Hello world"
          > parent:window;
          > button.connect "clicked" ?_... {
          > WriteLine "Hello World";
          > window.destroy()
          > };
          > window.show_all();
          > gtk.main();
          >
          of course, in this case the pita may well be worth it...

          all for now.
        • Daniel Ehrenberg
          Aside from the dubious benefit of XML being builtin to the syntax, I don t understand what the advantage of your language is over Io; it seems to be more
          Message 4 of 16 , May 3, 2004
            Aside from the dubious benefit of XML being builtin to
            the syntax, I don't understand what the advantage of
            your language is over Io; it seems to be more flexible
            and expressive while having a syntax less cluttered
            with punctuation. Although your idea of a declaritive
            GUI with XML is interesting, I still prefer the way
            Groovy or CLIM do it, with making nested syntaxtic
            structures within the language (which is still
            declaritive).

            Daniel Ehrenberg


            --- cr88192 wrote:
            > ok, I have returned from my month long experience
            > with pretty much no
            > computer or internet access...
            >
            > I continue on my current language effort. it still
            > looks a lot like
            > javascript...
            >
            > the math parser is left-associative. this may sound
            > weird, but there
            > are reasons (mostly related to me being unsure how
            > to approach order
            > of operations in math-parsing...).
            >
            > fragment (in case anyone forgot and actually cares):
            > var i;
            >
            > for(i=0; i<16; i++)
            > {
            > if(i<5)continue;
            > if(i>12)break;
            > println(i);
            > }
            >
            > function foo(a1, a2)
            > {
            > println("foo", a1, a2);
            > }
            >
            > foo(2, 3);
            >
            > var foo_obj=Object.clone();
            > println(foo_obj);
            >
            > foo_obj.x=3;
            > foo_obj.y=4;
            > foo_obj.pr=fun()
            > {
            > local z;
            > z=x+y;
            > println("obj", x, y, z);
            > };
            >
            > println(foo_obj.x, foo_obj.y);
            > foo_obj.pr();
            >
            > println(("foo"+"bar")+3);
            > println({1, 2, 3});
            > println(xml {<?xml
            > version="1.0"?><xmltest><aTag/>some
            > text</xmltest><another/>});
            >
            > I have inline if's: (a>b)?a:b;
            > I also have switch (pretty much the same syntax as
            > c, though it
            > doesn't quite behave the same as of yet).
            >
            > adding strings will concatenate them, adding numbers
            > to strings will
            > skip forwards over the characters.
            > similar will likely go for arrays (still considering
            > the array+array
            > case).
            >
            >
            > for a gui this time I am taking the approach of
            > keeping the ui itself
            > seperate from the code that uses it.
            > the ui has a syntax similar to web-forms:
            > <form>
            > <vbox>
            > <input type="button" label="Button0"/>
            > <input type="checkbox" label="Button1"/>
            > <input type="text" value="textbox"/>
            >
            > <input type="radio" name="rad0" label="Radio1"/>
            > <input type="radio" name="rad0" label="Radio2"/>
            > <input type="radio" name="rad0" label="Radio3"/>
            > </vbox>
            > </form>
            >
            > important differences exist though:
            > it is not html, and thus html fragments wont work as
            > expected;
            > vbox, hbox, and table are currently used as the only
            > real means to
            > organize widgets (things like <br/> would make
            > formatting more
            > complex);
            > there is a "text" widget <text>a glob of
            > text...</text> if text is
            > needed;
            > labels have been for the most part merged into
            > widgets;
            > ...
            >
            > as a minor bit of coolness, I actually made the
            > widgets (sort of)
            > look like their windows counterparts, as opposed to
            > multicolored
            > squares (as I had typically used in the past...).
            >
            > all for now.
            >
            >
            >





            __________________________________
            Do you Yahoo!?
            Win a $20,000 Career Makeover at Yahoo! HotJobs
            http://hotjobs.sweepstakes.yahoo.com/careermakeover
          • Steve Dekorte
            Hey Folks, I think the goal for most of our projects is primarily just to have fun and explore ideas and hopefully learn some things in the process. With this
            Message 5 of 16 , May 3, 2004
              Hey Folks,

              I think the goal for most of our projects is primarily just to have fun
              and explore ideas and hopefully learn some things in the process. With
              this in mind, let's try to keep feedback and comments constructive and
              positive. However, if you want to attack popular languages written by
              folks not on the list (like Java), then have at it. :-)

              Cheers,
              -- Steve
            • cr88192
              ... I am not directly competing with io... the idea of the xml is to hopefully make it easy to work with, as xml does seem to be getting pretty popular. part
              Message 6 of 16 , May 3, 2004
                --- In langsmiths@yahoogroups.com, Daniel Ehrenberg
                <littledanehren@y...> wrote:
                > Aside from the dubious benefit of XML being builtin to
                > the syntax, I don't understand what the advantage of
                > your language is over Io; it seems to be more flexible
                > and expressive while having a syntax less cluttered
                > with punctuation. Although your idea of a declaritive
                > GUI with XML is interesting, I still prefer the way
                > Groovy or CLIM do it, with making nested syntaxtic
                > structures within the language (which is still
                > declaritive).
                >
                I am not directly competing with io...

                the idea of the xml is to hopefully make it easy to work with, as xml
                does seem to be getting pretty popular.

                part of the external ui idea is possibly to make it easier for users
                to customize/skin the ui.

                of course, quite likely there will be no users...

                the gui is being kept seperate from the language, it should hopefully
                be usable standalone if needed.

                inline syntax for the gui's is another possible approach, but one not
                used by me.
                I had before considered one based on function calls:
                vbox(button("button0", "Button0"), checkbox("check0", "Button1"), ...)
                however, with my current design this would be reduced largely to
                constructing chunks of xml anyways...

                or something...
              • Sébastien Pierre
                Hi! ... I like the idea of being able to embed a language into another. For instance, this is exactly what we do in Python, Perl or Java when writing
                Message 7 of 16 , May 3, 2004
                  Hi!

                  cr88192 wrote:

                  > --- In langsmiths@yahoogroups.com, Daniel Ehrenberg
                  >
                  > the idea of the xml is to hopefully make it easy to work with, as xml
                  > does seem to be getting pretty popular.

                  I like the idea of being able to "embed" a language into another. For
                  instance, this is exactly what we do in Python, Perl or Java when
                  writing docstrings, pod or javadoc. However, this poses the problem of
                  validating the embedded language: is your language able to tell if the
                  xml is well-formed, correct ?

                  Languages like xduce or cduce (<http://www.cduce.org/>) manage to embed
                  XML into their syntax without keeping the XML syntax, but rather
                  adapting it to the host language.

                  > part of the external ui idea is possibly to make it easier for users
                  > to customize/skin the ui.
                  >
                  > of course, quite likely there will be no users...
                  >
                  > the gui is being kept seperate from the language, it should hopefully
                  > be usable standalone if needed.

                  It seems like many efforts now gear toward UIs described in XML (HTML to
                  some extent, Glade, XUL and now XAML). I also think that UI layout is
                  better suited to a specific domain language, such as thoses provided by
                  XML. Apple's Cocoa seems to follow the same approach: the interface is
                  build graphically with Interface Builder, which saves the interface data
                  in ".nib" file. Then one can simply "connect" an object to the hooks
                  defined by the components in the ".nib" files -- which is pretty much
                  the same as using XUL+JavaScript.

                  -- Sébastien
                • cr88192
                  ... xml ... For ... of ... the ... well, if not the parser screws up... ok, for my other stuff I had an xml parser written allready. when xml is seen, it
                  Message 8 of 16 , May 4, 2004
                    --- In langsmiths@yahoogroups.com, Sébastien Pierre <sebastien-
                    lists@t...> wrote:
                    > Hi!
                    >
                    > cr88192 wrote:
                    >
                    > > --- In langsmiths@yahoogroups.com, Daniel Ehrenberg
                    > >
                    > > the idea of the xml is to hopefully make it easy to work with, as
                    xml
                    > > does seem to be getting pretty popular.
                    >
                    > I like the idea of being able to "embed" a language into another.
                    For
                    > instance, this is exactly what we do in Python, Perl or Java when
                    > writing docstrings, pod or javadoc. However, this poses the problem
                    of
                    > validating the embedded language: is your language able to tell if
                    the
                    > xml is well-formed, correct ?
                    >
                    well, if not the parser screws up...

                    ok, for my other stuff I had an xml parser written allready.
                    when 'xml' is seen, it will eat the brace, invoke the xml parser so
                    long as there is not a closing brace, then will eat the closing brace
                    and graft the xml onto the parse tree (no big deal, since I had just
                    ended up using xml for the parse trees anyways...).

                    some things are missed by the parser (eg: tags can mismatch in some
                    cases and not be noticed, but this is an issue with the xml parser
                    and is not related to the graft).

                    > Languages like xduce or cduce (<http://www.cduce.org/>) manage to
                    embed
                    > XML into their syntax without keeping the XML syntax, but rather
                    > adapting it to the host language.
                    >
                    this is possible, but in my case it was trivial enough to just use
                    the normal xml parser...

                    however, for other things it would be necessary write a new parser
                    (eg: if I want to add pattern decomposition, or the ability to
                    evaluate expressions).
                    I had considered mod'ing the syntax:
                    foo=xml {<bar>baz</bar>};
                    bar=xml {<foo><{foo}></foo>};

                    print(bar); => <foo><bar>baz</bar></foo>

                    the pattern syntax would be different.

                    another approach could be to just use functions/methods to
                    construct/deconstruct xml.

                    xmltag("foo", xmltag("bar", "baz"));

                    of course, a new syntax/parser may make more sense...

                    > > part of the external ui idea is possibly to make it easier for
                    users
                    > > to customize/skin the ui.
                    > >
                    > > of course, quite likely there will be no users...
                    > >
                    > > the gui is being kept seperate from the language, it should
                    hopefully
                    > > be usable standalone if needed.
                    >
                    > It seems like many efforts now gear toward UIs described in XML
                    (HTML to
                    > some extent, Glade, XUL and now XAML). I also think that UI layout
                    is
                    > better suited to a specific domain language, such as thoses
                    provided by
                    > XML. Apple's Cocoa seems to follow the same approach: the interface
                    is
                    > build graphically with Interface Builder, which saves the interface
                    data
                    > in ".nib" file. Then one can simply "connect" an object to the
                    hooks
                    > defined by the components in the ".nib" files -- which is pretty
                    much
                    > the same as using XUL+JavaScript.
                    >
                    hmm... once again I am somewhat unoriginal, oh well, this is
                    something I would have expected hoards of people to have been doing
                    anyways.

                    I am largely ripping off and altering html, this seems to be an ok
                    approach.
                  • Daniel Ehrenberg
                    The following is intended to be constructive criticism, unlike my previous extremely rude comment. Note how I don t mention Io. I understand the benefits of
                    Message 9 of 16 , May 4, 2004
                      The following is intended to be constructive
                      criticism, unlike my previous extremely rude comment.
                      Note how I don't mention Io.

                      I understand the benefits of having XML easy to use
                      within the language, but does it really require making
                      it part of the syntax? The DrScheme IDE, for example,
                      lets you embed "XML boxes" where you type in XML, but
                      it saves the XML as a series of function calls instead
                      (and preserves information about what should and
                      shouldn't be displayed as XML). For example
                      <html><body/></html> would be parsed into (html ()
                      (body ())) (in languages with function calls like
                      function(arg1, arg2), this looks extremely ugly,
                      though). Although this might be somewhat specific to
                      Scheme, you might want to consider if it might be
                      useful for your language to do something like that
                      using ordinary syntactic featues. I think you
                      mentioned something like this, and you said it would
                      be constructed into chunks of XML with your current
                      design. Do you mean that XML is inextricably attached
                      to your GUI and you are forced to use XML as an
                      internal datastructure? Although declaritive GUIs are
                      convienent, this sort of design would seem to make it
                      hard to upgrade when a sucessor to XML is invented
                      (and not everyone will love XML forever).

                      Daniel Ehrenberg

                      > I am not directly competing with io...
                      >
                      > the idea of the xml is to hopefully make it easy to
                      > work with, as xml
                      > does seem to be getting pretty popular.
                      >
                      > part of the external ui idea is possibly to make it
                      > easier for users
                      > to customize/skin the ui.
                      >
                      > of course, quite likely there will be no users...
                      >
                      > the gui is being kept seperate from the language, it
                      > should hopefully
                      > be usable standalone if needed.
                      >
                      > inline syntax for the gui's is another possible
                      > approach, but one not
                      > used by me.
                      > I had before considered one based on function calls:
                      > vbox(button("button0", "Button0"),
                      > checkbox("check0", "Button1"), ...)
                      > however, with my current design this would be
                      > reduced largely to
                      > constructing chunks of xml anyways...
                      >
                      > or something...




                      __________________________________
                      Do you Yahoo!?
                      Win a $20,000 Career Makeover at Yahoo! HotJobs
                      http://hotjobs.sweepstakes.yahoo.com/careermakeover
                    • cr88192
                      ... I could use a different syntax, but it my case it was quite convinient to use as it saved me having to write code to parse something else... of course
                      Message 10 of 16 , May 4, 2004
                        --- In langsmiths@yahoogroups.com, Daniel Ehrenberg
                        <littledanehren@y...> wrote:
                        > The following is intended to be constructive
                        > criticism, unlike my previous extremely rude comment.
                        > Note how I don't mention Io.
                        >
                        > I understand the benefits of having XML easy to use
                        > within the language, but does it really require making
                        > it part of the syntax? The DrScheme IDE, for example,
                        > lets you embed "XML boxes" where you type in XML, but
                        > it saves the XML as a series of function calls instead
                        > (and preserves information about what should and
                        > shouldn't be displayed as XML). For example
                        > <html><body/></html> would be parsed into (html ()
                        > (body ())) (in languages with function calls like
                        > function(arg1, arg2), this looks extremely ugly,
                        > though). Although this might be somewhat specific to
                        > Scheme, you might want to consider if it might be
                        > useful for your language to do something like that
                        > using ordinary syntactic featues. I think you
                        > mentioned something like this, and you said it would
                        > be constructed into chunks of XML with your current
                        > design.

                        I could use a different syntax, but it my case it was quite
                        convinient to use as it saved me having to write code to parse
                        something else...
                        of course there is the limit that the parser can only read plain xml,
                        and can't do any "kewl things" with it (it could be
                        modified/assimilated into the language parser to fix this).
                        xml also looks like xml, and this makes things a little more obvious.

                        > Do you mean that XML is inextricably attached
                        > to your GUI and you are forced to use XML as an
                        > internal datastructure?
                        yes, pretty much. it would require major alterations to construct
                        interfaces some other way.

                        in fact, my current language's parser also internally works by
                        converting everything to xml. this was also because it was
                        convinient, it was a use xml or write something else type situation
                        (the interpreter was built on 'pdnet', which was more specialized in
                        dealing with net protocols and such than anything else).

                        the gui is part of lbxgl (a lib left for handling all things
                        graphical/sound related). lbxgl has (annoyingly enough) a lot of ties
                        into pdlib/pdnet.
                        it is all a big mess in the end anyways, lang/bgb is still tied up in
                        everything as well.

                        here is a partial parse-tree dump from the interpreter:
                        <funcall name="println">
                        <args>
                        <array>
                        <number value="1"/>
                        <number value="2"/>
                        <number value="3"/>
                        </array>
                        </args>
                        </funcall>
                        <funcall name="println">
                        <args>
                        <xml>
                        <?xml version="1.0"?>
                        <xmltest>
                        <aTag/>
                        some text
                        </xmltest>
                        <another/>
                        </xml>
                        </args>
                        </funcall>

                        xml is an xml tag.

                        > Although declaritive GUIs are
                        > convienent, this sort of design would seem to make it
                        > hard to upgrade when a sucessor to XML is invented
                        > (and not everyone will love XML forever).
                        >
                        I am not sure a true "sucessor to xml" will come into existance (or
                        at least not in the short term...).
                        if anything, it may change forms (eg: a binary variant), but I think
                        the core aspects are likely to stay fairly stable for a while.

                        quite likely it will lose some popularity, but remain as one of those
                        common formats/substructures found in a great many file-
                        formats/protocols.

                        but whatever, if something major happens I can trash a lot of code
                        and start over...
                      • Sébastien Pierre
                        ... There is already a (very effective) binary form of XML ( ), which is being standardized
                        Message 11 of 16 , May 4, 2004
                          cr88192 wrote:

                          > I am not sure a true "sucessor to xml" will come into existance (or
                          > at least not in the short term...).
                          > if anything, it may change forms (eg: a binary variant), but I think
                          > the core aspects are likely to stay fairly stable for a while.

                          There is already a (very effective) binary form of XML
                          (<http://www.cubewerx.com/main/cwxml/>), which is being standardized
                          (<http://www.opengis.org/docs/03-002r8.pdf>).

                          > quite likely it will lose some popularity, but remain as one of those
                          > common formats/substructures found in a great many file-
                          > formats/protocols.
                          >
                          > but whatever, if something major happens I can trash a lot of code
                          > and start over...

                          XML has a rather cumbersome syntax, which may render it less useful than
                          DSL when hand-writing code, but when you use a dedicated editor XML
                          becomes a valuable choice, because anyone will be able to parse and
                          process your UI specification. So my guess is that sticking with XML is
                          a rather pertinent choice for UI design, even if it was a little bit
                          overhyped.

                          BTW, I would be curious to see how you declare your UI in your specific
                          XML format (application would be a better term)...

                          Cheers,

                          -- Sébastien
                        • cr88192
                          ... (or ... think ... standardized ... yes, interesting. ... those ... than ... XML is ... bit ... agreed. if needed an alternate syntax could be added,
                          Message 12 of 16 , May 4, 2004
                            --- In langsmiths@yahoogroups.com, Sébastien Pierre <sebastien-
                            lists@t...> wrote:
                            > cr88192 wrote:
                            >
                            > > I am not sure a true "sucessor to xml" will come into existance
                            (or
                            > > at least not in the short term...).
                            > > if anything, it may change forms (eg: a binary variant), but I
                            think
                            > > the core aspects are likely to stay fairly stable for a while.
                            >
                            > There is already a (very effective) binary form of XML
                            > (<http://www.cubewerx.com/main/cwxml/>), which is being
                            standardized
                            > (<http://www.opengis.org/docs/03-002r8.pdf>).
                            >
                            yes, interesting.

                            > > quite likely it will lose some popularity, but remain as one of
                            those
                            > > common formats/substructures found in a great many file-
                            > > formats/protocols.
                            > >
                            > > but whatever, if something major happens I can trash a lot of code
                            > > and start over...
                            >
                            > XML has a rather cumbersome syntax, which may render it less useful
                            than
                            > DSL when hand-writing code, but when you use a dedicated editor XML
                            > becomes a valuable choice, because anyone will be able to parse and
                            > process your UI specification. So my guess is that sticking with
                            XML is
                            > a rather pertinent choice for UI design, even if it was a little
                            bit
                            > overhyped.
                            >
                            agreed. if needed an alternate syntax could be added, however likely
                            it would be internally converted into xml parse trees...

                            > BTW, I would be curious to see how you declare your UI in your
                            specific
                            > XML format (application would be a better term)...
                            >
                            basically it is a rip/mod of web forms.

                            <form style="window">
                            <vbox fgcolor="lime" bgcolor="black">
                            <input type="button" id="btn0" label="Button0"/>
                            <input type="checkbox" id="btn1" label="Button1"/>
                            <input type="text" id="txt0" value="textbox"/>

                            <input type="radio" name="rad0" label="Radio1"/>
                            <input type="radio" name="rad0" label="Radio2"/>
                            <input type="radio" name="rad0" label="Radio3"/>
                            </vbox>
                            </form>

                            more features are being added, but lots of misc stuff is still being
                            done as well.

                            only vbox and hbox currently exist as container widgets (tables are
                            planned). I have no <textarea/>, <text/>, <select/>, ... widgets yet.

                            <img/> will likely be used similarly to html.

                            the approach of putting widgets in lines, spliting things up with
                            linebreaks, using spaces to position widgets, ... is not possible (I
                            don't really feel this is very appropriate for gui's anyways).

                            all for now.
                          • Daniel Ehrenberg
                            ... I don t think you understand, it does look like XML, it s just stored as nested function calls internally. ... So what you re really doing is using your
                            Message 13 of 16 , May 4, 2004
                              > I could use a different syntax, but it my case it
                              > was quite
                              > convinient to use as it saved me having to write
                              > code to parse
                              > something else...
                              > of course there is the limit that the parser can
                              > only read plain xml,
                              > and can't do any "kewl things" with it (it could be
                              > modified/assimilated into the language parser to fix
                              > this).
                              > xml also looks like xml, and this makes things a
                              > little more obvious.
                              >
                              I don't think you understand, it does look like XML,
                              it's just stored as nested function calls internally.

                              > yes, pretty much. it would require major alterations
                              > to construct
                              > interfaces some other way.
                              >
                              > in fact, my current language's parser also
                              > internally works by
                              > converting everything to xml. this was also because
                              > it was
                              > convinient, it was a use xml or write something else
                              > type situation
                              > (the interpreter was built on 'pdnet', which was
                              > more specialized in
                              > dealing with net protocols and such than anything
                              > else).
                              >
                              > the gui is part of lbxgl (a lib left for handling
                              > all things
                              > graphical/sound related). lbxgl has (annoyingly
                              > enough) a lot of ties
                              > into pdlib/pdnet.
                              > it is all a big mess in the end anyways, lang/bgb is
                              > still tied up in
                              > everything as well.

                              So what you're really doing is using your DOM library
                              for datastructures? That sounds like it would be
                              inefficient.

                              > I am not sure a true "sucessor to xml" will come
                              > into existance (or
                              > at least not in the short term...).
                              > if anything, it may change forms (eg: a binary
                              > variant), but I think
                              > the core aspects are likely to stay fairly stable
                              > for a while.
                              >
                              > quite likely it will lose some popularity, but
                              > remain as one of those
                              > common formats/substructures found in a great many
                              > file-
                              > formats/protocols.
                              >
                              > but whatever, if something major happens I can trash
                              > a lot of code
                              > and start over...

                              Well, SGML looked like it was going to be the
                              standard, but then along came XML. YAML is gaining
                              some popularity, and it's much better for many
                              purposes because of its lack of redundancy, builtin
                              datatypes, and ease of typing by humans with features
                              like syntactically significant whitespace. For now, I
                              guess XML is popular enough that this would work,
                              though. It's intersting how the XML is parsed at
                              read-time, though.

                              Daniel Ehrenberg




                              __________________________________
                              Do you Yahoo!?
                              Win a $20,000 Career Makeover at Yahoo! HotJobs
                              http://hotjobs.sweepstakes.yahoo.com/careermakeover
                            • cr88192
                              ... yes. another poster can up with an interesting use of namespaces (of course I altered the idea a little as well). ... largely, yes. ... sgml being defeated
                              Message 14 of 16 , May 4, 2004
                                --- In langsmiths@yahoogroups.com, Daniel Ehrenberg
                                <littledanehren@y...> wrote:
                                > > I could use a different syntax, but it my case it
                                > > was quite
                                > > convinient to use as it saved me having to write
                                > > code to parse
                                > > something else...
                                > > of course there is the limit that the parser can
                                > > only read plain xml,
                                > > and can't do any "kewl things" with it (it could be
                                > > modified/assimilated into the language parser to fix
                                > > this).
                                > > xml also looks like xml, and this makes things a
                                > > little more obvious.
                                > >
                                > I don't think you understand, it does look like XML,
                                > it's just stored as nested function calls internally.
                                >
                                yes.

                                another poster can up with an interesting use of namespaces (of
                                course I altered the idea a little as well).

                                > > yes, pretty much. it would require major alterations
                                > > to construct
                                > > interfaces some other way.
                                > >
                                > > in fact, my current language's parser also
                                > > internally works by
                                > > converting everything to xml. this was also because
                                > > it was
                                > > convinient, it was a use xml or write something else
                                > > type situation
                                > > (the interpreter was built on 'pdnet', which was
                                > > more specialized in
                                > > dealing with net protocols and such than anything
                                > > else).
                                > >
                                > > the gui is part of lbxgl (a lib left for handling
                                > > all things
                                > > graphical/sound related). lbxgl has (annoyingly
                                > > enough) a lot of ties
                                > > into pdlib/pdnet.
                                > > it is all a big mess in the end anyways, lang/bgb is
                                > > still tied up in
                                > > everything as well.
                                >
                                > So what you're really doing is using your DOM library
                                > for datastructures? That sounds like it would be
                                > inefficient.
                                >
                                largely, yes.

                                > > I am not sure a true "sucessor to xml" will come
                                > > into existance (or
                                > > at least not in the short term...).
                                > > if anything, it may change forms (eg: a binary
                                > > variant), but I think
                                > > the core aspects are likely to stay fairly stable
                                > > for a while.
                                > >
                                > > quite likely it will lose some popularity, but
                                > > remain as one of those
                                > > common formats/substructures found in a great many
                                > > file-
                                > > formats/protocols.
                                > >
                                > > but whatever, if something major happens I can trash
                                > > a lot of code
                                > > and start over...
                                >
                                > Well, SGML looked like it was going to be the
                                > standard, but then along came XML. YAML is gaining
                                > some popularity, and it's much better for many
                                > purposes because of its lack of redundancy, builtin
                                > datatypes, and ease of typing by humans with features
                                > like syntactically significant whitespace. For now, I
                                > guess XML is popular enough that this would work,
                                > though. It's intersting how the XML is parsed at
                                > read-time, though.
                                >
                                sgml being defeated by xml, yes, I can understand that one.
                                yaml, however, I believe is less suited to many kinds of data/network
                                protocols and would be a little more complicated to parse.

                                one can wait and see.

                                before I had my pet 'sx' notation, which was really a terser hybrid
                                of xml and s-expressions. it died eventually though, mostly because I
                                had been the only one pushing it, and many other protocols existed
                                for the basic things I was doing (most of which were based on xml).

                                <foo><bar>baz</bar></foo> (foo(bar baz))

                                the exact syntax for attributes was never decided (they were not
                                added), probably would hve been something like:
                                <foo bar="baz"/> (foo[bar=baz])
                                quotes were only needed in cases where tokens contained spaces or
                                other "invalid" characters.
                                the issue was that, sizewise, it was too close to xml to really be
                                worth it (only about 30%-60% reduction).

                                a few tests of mine with "psuedotextual" xml encodings was able to
                                get about an 80% size reduction, but again, the force behind the
                                textual encoding was stronger.

                                all for now.
                              • Daniel Ehrenberg
                                ... That looks a lot better. Not only does it have a 1-to-1 corrospondance to XML and is much easier to type, but it looks like it would be great for the
                                Message 15 of 16 , May 4, 2004
                                  > sgml being defeated by xml, yes, I can understand
                                  > that one.
                                  > yaml, however, I believe is less suited to many
                                  > kinds of data/network
                                  > protocols and would be a little more complicated to
                                  > parse.
                                  >
                                  > one can wait and see.
                                  >
                                  > before I had my pet 'sx' notation, which was really
                                  > a terser hybrid
                                  > of xml and s-expressions. it died eventually though,
                                  > mostly because I
                                  > had been the only one pushing it, and many other
                                  > protocols existed
                                  > for the basic things I was doing (most of which were
                                  > based on xml).
                                  >
                                  > <foo><bar>baz</bar></foo> (foo(bar baz))
                                  >
                                  > the exact syntax for attributes was never decided
                                  > (they were not
                                  > added), probably would hve been something like:
                                  > <foo bar="baz"/> (foo[bar=baz])
                                  > quotes were only needed in cases where tokens
                                  > contained spaces or
                                  > other "invalid" characters.
                                  > the issue was that, sizewise, it was too close to
                                  > xml to really be
                                  > worth it (only about 30%-60% reduction).
                                  >
                                  > a few tests of mine with "psuedotextual" xml
                                  > encodings was able to
                                  > get about an 80% size reduction, but again, the
                                  > force behind the
                                  > textual encoding was stronger.
                                  >
                                  > all for now.

                                  That looks a lot better. Not only does it have a
                                  1-to-1 corrospondance to XML and is much easier to
                                  type, but it looks like it would be great for the
                                  syntax of a programming language too. Just because
                                  "you're the only one pusing it" doesn't mean you
                                  shouldn't use it. You're one of a few people pusing
                                  this language, too, but that doesn't make it
                                  worthless.

                                  Daniel Ehrenberg




                                  __________________________________
                                  Do you Yahoo!?
                                  Win a $20,000 Career Makeover at Yahoo! HotJobs
                                  http://hotjobs.sweepstakes.yahoo.com/careermakeover
                                • cr88192
                                  ... xml is not that bad either once one gets used to it... having an alternate syntax opens up the issue of what syntax to use for what things, and there is
                                  Message 16 of 16 , May 4, 2004
                                    --- In langsmiths@yahoogroups.com, Daniel Ehrenberg
                                    <littledanehren@y...> wrote:
                                    > > sgml being defeated by xml, yes, I can understand
                                    > > that one.
                                    > > yaml, however, I believe is less suited to many
                                    > > kinds of data/network
                                    > > protocols and would be a little more complicated to
                                    > > parse.
                                    > >
                                    > > one can wait and see.
                                    > >
                                    > > before I had my pet 'sx' notation, which was really
                                    > > a terser hybrid
                                    > > of xml and s-expressions. it died eventually though,
                                    > > mostly because I
                                    > > had been the only one pushing it, and many other
                                    > > protocols existed
                                    > > for the basic things I was doing (most of which were
                                    > > based on xml).
                                    > >
                                    > > <foo><bar>baz</bar></foo> (foo(bar baz))
                                    > >
                                    > > the exact syntax for attributes was never decided
                                    > > (they were not
                                    > > added), probably would hve been something like:
                                    > > <foo bar="baz"/> (foo[bar=baz])
                                    > > quotes were only needed in cases where tokens
                                    > > contained spaces or
                                    > > other "invalid" characters.
                                    > > the issue was that, sizewise, it was too close to
                                    > > xml to really be
                                    > > worth it (only about 30%-60% reduction).
                                    > >
                                    > > a few tests of mine with "psuedotextual" xml
                                    > > encodings was able to
                                    > > get about an 80% size reduction, but again, the
                                    > > force behind the
                                    > > textual encoding was stronger.
                                    > >
                                    > > all for now.
                                    >
                                    > That looks a lot better. Not only does it have a
                                    > 1-to-1 corrospondance to XML and is much easier to
                                    > type, but it looks like it would be great for the
                                    > syntax of a programming language too. Just because
                                    > "you're the only one pusing it" doesn't mean you
                                    > shouldn't use it. You're one of a few people pusing
                                    > this language, too, but that doesn't make it
                                    > worthless.
                                    >
                                    xml is not that bad either once one gets used to it...
                                    having an alternate syntax opens up the issue of what syntax to use
                                    for what things, and there is still the problem that "they are too
                                    damn similar".
                                    xml is more common, at least things written in it could be more
                                    easily used by other tools, vs. having to convert the syntax or such.
                                  Your message has been successfully submitted and would be delivered to recipients shortly.