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

Re: [Frink] unit suggestion

Expand Messages
  • Edward Peschko
    Well, the more I think about it, the more I like the idea of having a sigil (either prefix or postfix) to tell Frink when something is a unit as opposed to a
    Message 1 of 13 , Dec 7, 2005
    View Source
    • 0 Attachment
      Well, the more I think about it, the more I like the
      idea of having a sigil (either prefix or postfix) to
      tell Frink when something is a unit as opposed to a
      variable. Its a bit ugly, but if you said something
      like:

      2 kids. / household.

      to indicate that kids and households are units (and
      hence should be treated as such) then you could parse
      arbitrary data files that had the sigil, and you
      wouldn't have to write frink code at all when you were
      processing them.

      I'm still thinking about what the best sigil would be
      - '.' might be a bit too common and not work due to
      method parsing issues, but maybe putting it in ':', eg
      . :kids:, or <kids> might work.. Or even prefix it
      with '$' as in perl. Or having a special keyword, say
      'unit' to tell frink that it is a unit...

      Ed
      --- Alan Eliasen <eliasen@...> wrote:

      >
      >
      >
      >




      __________________________________________
      Yahoo! DSL – Something to write home about.
      Just $16.99/mo. or less.
      dsl.yahoo.com
    • Alan Eliasen
      ... Yes, at some point, Frink will probably have a strict mode in which you ll have to do one or both of the following: * Declare all variables before using
      Message 2 of 13 , Dec 8, 2005
      View Source
      • 0 Attachment
        Edward Peschko wrote:
        > Well, the more I think about it, the more I like the
        > idea of having a sigil (either prefix or postfix) to
        > tell Frink when something is a unit as opposed to a
        > variable. Its a bit ugly, but if you said something
        > like:
        >
        > 2 kids. / household.

        Yes, at some point, Frink will probably have a "strict" mode in which
        you'll have to do one or both of the following:

        * Declare all variables before using them

        * Note all units that you use as being units (possibly with a sigil
        on use, or by saying something once like "import meter").

        They're separate issues, so you may only be required to do one or the
        other.

        This gets into a bigger issue: should this strict mode be the
        default? The designers of both Perl and Ruby have said that they
        sometimes regret not making strict mode the default. Making things
        strict might involve rewriting all of your programs and libraries.

        Perl gets around this in sort of an ugly way by making all "strict"
        flags only applicable to the file being compiled. You can't force "use
        strict" in Perl to affect all files and libraries. Just the ones that
        you add it to.

        > to indicate that kids and households are units (and
        > hence should be treated as such) then you could parse
        > arbitrary data files that had the sigil, and you
        > wouldn't have to write frink code at all when you were
        > processing them.

        I'm not sure quite what you're saying here... from the statement, it
        sounds like you'd have to add the sigil to these data files, which means
        more or less writing Frink code? Or am I misunderstanding your intent?

        > I'm still thinking about what the best sigil would be
        > - '.' might be a bit too common and not work due to
        > method parsing issues, but maybe putting it in ':', eg
        > . :kids:, or <kids> might work.. Or even prefix it
        > with '$' as in perl. Or having a special keyword, say
        > 'unit' to tell frink that it is a unit...

        $ is still free. A leading _ is still free. A period would cause
        ambiguities. I'm not quite sure what it'll look like.

        You might be interested in looking at the "Fortress" language that
        Sun is developing. It was originally intended to be a high-performance
        Fortran replacement, but it looks more and more like Frink with each
        revision:

        http://lambda-the-ultimate.org/node/view/1121

        They'll have units of measure, and they use a trailing _ to indicate
        these. Like m_ for meters. They have weird rules about how they'll
        hide this underscore on display in Fortress-aware editors, and they'll
        display the *variable* m in italics (the unit m will be displayed in
        roman type). See section 2.2.4 of their spec. I don't think a lot of
        their unit manipulation has been fully thought out yet, as my comments
        at lambda-the-ultimate indicate.

        --
        Alan Eliasen | "It's amazing how much mature wisdom
        eliasen@... | resembles being too tired."
        http://futureboy.homeip.net/ | -- Robert Heinlein
      • Edward Peschko
        ... Well, You are assuming that I m writing Frink code to process these files. I can just as easily use perl, ruby, python, etc. to preprocess these files and
        Message 3 of 13 , Dec 8, 2005
        View Source
        • 0 Attachment
          > I'm not sure quite what you're saying here...
          > from the statement, it
          > sounds like you'd have to add the sigil to these
          > data files, which means
          > more or less writing Frink code? Or am I
          > misunderstanding your intent?

          Well, You are assuming that I'm writing Frink code to
          process
          these files. I can just as easily use perl, ruby,
          python, etc.
          to preprocess these files and add the sigil.

          Of course I could use ruby et al to generate the frink
          code, and then eval that frink code, but it seems
          cleaner to just add a leading underscore to every word
          and go from there..

          I'd vote for a trailing underscore...

          Ed

          __________________________________________________
          Do You Yahoo!?
          Tired of spam? Yahoo! Mail has the best spam protection around
          http://mail.yahoo.com
        • Edward Peschko
          ps - I just looked at the fortress spec, and it looks like they are making the mistake of having unicode operators.. perl6 unfortunately is doing that too,
          Message 4 of 13 , Dec 8, 2005
          View Source
          • 0 Attachment
            ps -

            I just looked at the fortress spec, and it looks like
            they are making the mistake of having unicode
            operators.. perl6 unfortunately is doing that too,
            although some people are desperately trying to
            convince larry wall to drop this idea fast..

            I don't know. Maybe its me, but the language syntax,
            etc. just left me cold.. too used to c-like languages
            ;-)

            Ed

            __________________________________________________
            Do You Yahoo!?
            Tired of spam? Yahoo! Mail has the best spam protection around
            http://mail.yahoo.com
          • Alan Eliasen
            ... Okay, I think I see what you re saying. Pick the language right for each part of the job, that s what I say. :) ... I see nothing significantly wrong
            Message 5 of 13 , Dec 9, 2005
            View Source
            • 0 Attachment
              Alan Eliasen wrote:
              >> I'm not sure quite what you're saying here...
              >>from the statement, it
              >>sounds like you'd have to add the sigil to these
              >>data files, which means
              >>more or less writing Frink code? Or am I
              >>misunderstanding your intent?

              Edward Peschko wrote:
              > Well, You are assuming that I'm writing Frink code to
              > process
              > these files. I can just as easily use perl, ruby,
              > python, etc.
              > to preprocess these files and add the sigil.
              >
              > Of course I could use ruby et al to generate the frink
              > code, and then eval that frink code, but it seems
              > cleaner to just add a leading underscore to every word
              > and go from there..

              Okay, I think I see what you're saying. Pick the language right for
              each part of the job, that's what I say. :)

              > I'd vote for a trailing underscore...

              I see nothing significantly wrong with a trailing underscore like
              Fortress. I've considered allowing people to set their own explicit
              prefix/suffix for units, which probably wouldn't be a problem, if it
              falls within a well-defined set of prefixes/suffixes. The lexer still
              has to lex, after all, and can't use any arbitrary pattern without
              ambiguity. Choosing a leading underscore would not affect *any*
              existing programs, (as all Frink identifiers currently have to begin
              with a Unicode "letter" character and then may contain Unicode letters,
              numbers, or underscores.) A trailing underscore may affect *some*
              programs, but it's probably minor.

              Still, for readability, I do want to allow people to write programs
              with normal unit notation, and no sigil, if they so desire.

              --
              Alan Eliasen | "It's amazing how much mature wisdom
              eliasen@... | resembles being too tired."
              http://futureboy.homeip.net/ | -- Robert Heinlein
            • Alan Eliasen
              ... Yes, Fortress is unashamedly and whole-hog on the obscure Unicode operator-and-bracket bandwagon. They ve defined some ASCII alternates for their Unicode
              Message 6 of 13 , Dec 9, 2005
              View Source
              • 0 Attachment
                Edward Peschko wrote:
                > ps -
                >
                > I just looked at the fortress spec, and it looks like
                > they are making the mistake of having unicode
                > operators.. perl6 unfortunately is doing that too,
                > although some people are desperately trying to
                > convince larry wall to drop this idea fast..

                Yes, Fortress is unashamedly and whole-hog on the obscure Unicode
                operator-and-bracket bandwagon. They've defined some ASCII alternates
                for their Unicode operators, but they seem to translate them to Unicode
                on output. It'll take a quantum leap in Unicode ability of most text
                editors/viewers to make this work reliably. Although I know that it's
                easy to run out of brackets, (in ASCII, we have () [] {} <> and maybe
                `') I think the Fortress specification hopes for too much in terms of
                editor capabilities. They've already chosen some wacky, untypeable,
                non-standard brackets for intervals.

                > I don't know. Maybe its me, but the language syntax,
                > etc. just left me cold.. too used to c-like languages

                My hugest fear in Fortress is the disregard for normal mathematical
                precedence; they have weird precedences based on whitespace... operators
                may do entirely different things if they're surrounded by spaces or not.
                Yuck.

                --
                Alan Eliasen | "It's amazing how much mature wisdom
                eliasen@... | resembles being too tired."
                http://futureboy.homeip.net/ | -- Robert Heinlein
              • Alan Eliasen
                ... By the way, you shouldn t have to do *any* modification of many files containing normal mathematical notation to turn it into Frink notation. Frink is
                Message 7 of 13 , Dec 9, 2005
                View Source
                • 0 Attachment
                  Edward Peschko wrote:
                  >> I'm not sure quite what you're saying here...
                  >>from the statement, it
                  >>sounds like you'd have to add the sigil to these
                  >>data files, which means
                  >>more or less writing Frink code? Or am I
                  >>misunderstanding your intent?
                  >
                  >
                  > Well, You are assuming that I'm writing Frink code to
                  > process
                  > these files. I can just as easily use perl, ruby,
                  > python, etc.
                  > to preprocess these files and add the sigil.

                  By the way, you shouldn't have to do *any* modification of many files
                  containing normal mathematical notation to turn it into Frink notation.
                  Frink is designed, more than any other language I know, to parse normal
                  mathematical notation and units correctly without any modification. If
                  you follow, say, the SI (the International System of units, the modern
                  "metric" system) rules and style conventions (
                  http://physics.nist.gov/cuu/Units/rules.html ), Frink will usually parse
                  your equations without ambiguity or error. Except where's there's
                  ambiguity in standard mathematical notation.

                  Most often, the biggest thing you'll need to do is put a ^ symbol in
                  front of exponents, 'cause cutting and pasting, or plain ASCII loses the
                  ability to note that a number's littler and higher up on the line.

                  The differences are in things that are somewhat ambiguous... Frink
                  requires you to write "x y" or "x*y" for something that in mathematical
                  notation might be "xy" because Frink allows variable names of more than
                  one letter. (Which is reasonable.) Other ambiguities include such
                  things as "sin x + y", which must be written with unambiguous brackets
                  "sin[x+y]". There's also an implied human-centric disambiguation in
                  knowing that "sin" doesn't mean "s*i*n". Normal mathematical notation
                  is more ambiguous than it may initially seem.

                  The rules of the SI are still somewhat ambiguous, but they're not too
                  bad. Following them will usually give you an unambiguous Frink expression.

                  For a really interesting look into ambiguities in standard
                  mathematical notation, here's a really interesting talk by Stephen
                  Wolfram, the main person behind Mathematica:

                  http://www.stephenwolfram.com/publications/talks/mathml/index.html

                  Especially read the section called "Computers" to read about
                  precedence, ambiguity in normal mathematical notation, and different
                  attempts to get around it. No, really, read the whole thing. It's a
                  really great article. Mathematica and Frink take different tactics for
                  underlying representation, but the problem of ambiguity in normal
                  mathematical notation is the same. Mathematica breaks normal SI
                  orthography, forcing you to write "Meter" instead of "m" or "meter",
                  etc, so Frink's a bit more natural.

                  --
                  Alan Eliasen | "It's amazing how much mature wisdom
                  eliasen@... | resembles being too tired."
                  http://futureboy.homeip.net/ | -- Robert Heinlein
                Your message has been successfully submitted and would be delivered to recipients shortly.