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

Re: [langsmiths] Re: Associating interfaces and types

Expand Messages
  • Marcin 'Qrczak' Kowalczyk
    ... Plain functions would work in this case. ... I don t feel the need of a macro system. Yes, it does mean that the language includes more syntactic sugar
    Message 1 of 32 , Jul 1, 2003
    • 0 Attachment
      Dnia pon 30. czerwca 2003 18:09, cr88192 napisał:

      > it would be pretty simple for me to make a few macros:
      > (defmacro values rest `(list ,@rest))
      > (defmacro call-with-values (from to) (apply ,from (,to)))

      Plain functions would work in this case.

      > ok, I have a macro system a little more flexible than defmacro, but
      > most attempts at hygenic macros are broken.

      I don't feel the need of a macro system. Yes, it does mean that the language
      includes more syntactic sugar than there would be with macros, but it's still
      much simpler than a macro language.

      A macro system is closely tied to the syntax itself. Without macros syntax is
      less rigid - it doesn't have to have an obvious map to a tree, it can use
      other means of grouping as long as it's readable. For example let's take the
      definition of max I showed previously:

      def max x = x
      def max x y
      when x < y = y
      else = x
      def max x y rest... = max (max x y) rest...

      How would it be presented to a macro system? Of course some encoding could
      be designed, but it's not obvious, so it would be yet another thing to learn.
      Macros constrain the syntax too much.

      What I dislike most about Lisp is syntax. It's not easily readable because it
      tries to fit everything into a nested structure of mostly parentheses,
      identifiers and literals. It's similar to why Morse code could not be as
      readable as a normal alphabet: it uses fewer kinds of elements, so expressing
      the same concept requires more "encoding".

      > first dynamically typed then later lexically.

      You mean "scoped"?

      > I had mostly considered something to allow "wrapping" bindings in an
      > environment and then later selectively importing them.
      > the details are seriously unclear.

      In my language there are three basic kinds of syntax elements: expressions,
      patterns and definitions. A package body consists of definitions. Names
      introduced by definitions are known statically and all unqualified names are
      lexically scoped. Only functions and lazy variables can be recursive

      This is similar to statically typed languages like ML and Haskell. I wonder
      why dynamically typed languages often dynamically manage environments.

      __("< Marcin Kowalczyk
      \__/ qrczak@...
      ^^ http://qrnik.knm.org.pl/~qrczak/
    • cr88192
      ... my ... bits in ... garbage ... integers etc. ... the problem is the occurance of (cell
      Message 32 of 32 , Jul 8, 2003
      • 0 Attachment
        --- In langsmiths@yahoogroups.com, Marcin 'Qrczak' Kowalczyk
        <qrczak@k...> wrote:
        > Dnia wto 8. lipca 2003 17:33, cr88192 napisa┬│:
        > > the main cost, however, is that likely my gc will break if I ran
        > > code on a 64bit machine, as it assumes the word size to be 32
        bits in
        > > many places.
        > Fortunately I don't need to assume this. I use pointer-sized ints
        > for vector and string sizes, for object and memory sizes in the
        > collector, for symbol and type serial numbers, inside small
        integers etc.
        the problem is the occurance of (cell<<3) to get the byte offset, I
        would need (cell<<4) for 64 bit systems.
        most values rely on ELEM_SZ, which was used because at one point I
        was using 'long long' for values and sizeof(long long) was reporting
        4 (I think that is fixed now, I think it was a gcc version specific
        (cell*ELEM_SZ*2) seemed a bit more expensive.

        if I wanted I could leave gc cells 8 bytes, but make a cons cell
        require 2 cells. it would probably be better to increase the cell
        size though...

        > > gc cells are aligned on 8 bytes.
        > Most objects consist of an integral number of words (pointers or
        > integers), so this would waste on average half of word per object.
        Maybe it's
        > worth to align only some objects (which would require changes to
        the garbage
        > collector). Maybe not.

        > I already plan to have mutable arrays with the contents allocated
        using malloc
        > (so they aren't moved), so float arrays will be aligned if
        implemented as a
        > separate type at all. This leaves only double. I think I won't
        bother with
        > larger alignment than a word and will conditionally copy doubles to
        > temporary C variable if needed on the given platform.
        my gc has some types it views as "non-movable", though this is
        nothing major as it is not a copy collector.

        > > > which represented void * and char * differently from other
        > > > where this would break.
        > >
        > > this is not so good, I didn't know of this.
        > I think this applies to Crays. char * is represented as a native
        pointer plus
        > byte offset within the word (has a larger sizeof), and all types
        except char
        > use an integral number of words. Their C compiler translates
        > char*/void* representation and the representation of other pointers
        when the
        > pointer is cast directly, but can't of course do this when the
        > storage is reinterpreted under a different type.
        > I don't know if there are any recent or non-exotic architectures
        like that.
        > Perhaps not.
        ok, good.

        my general hope is that it doesn't break on common systems (well,
        assuming I port it to other systems, it is gradually getting more
        tied to windows...).
      Your message has been successfully submitted and would be delivered to recipients shortly.