Re: [langsmiths] Re: Associating interfaces and types
- Dnia pon 30. czerwca 2003 18:09, cr88192 napisał:
> it would be pretty simple for me to make a few macros:Plain functions would work in this case.
> (defmacro values rest `(list ,@rest))
> (defmacro call-with-values (from to) (apply ,from (,to)))
> ok, I have a macro system a little more flexible than defmacro, butI don't feel the need of a macro system. Yes, it does mean that the language
> most attempts at hygenic macros are broken.
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 anIn my language there are three basic kinds of syntax elements: expressions,
> environment and then later selectively importing them.
> the details are seriously unclear.
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
- --- In firstname.lastname@example.org, Marcin 'Qrczak' Kowalczyk
> Dnia wto 8. lipca 2003 17:33, cr88192 napisa³:my
> > 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 32bits in
> > many places.much:
> Fortunately I don't need to assume this. I use pointer-sized ints
> for vector and string sizes, for object and memory sizes in thegarbage
> collector, for symbol and type serial numbers, inside smallintegers 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
> > gc cells are aligned on 8 bytes.sometimes
> 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 tothe garbage
> collector). Maybe not.ok.
> I already plan to have mutable arrays with the contents allocatedusing malloc
> (so they aren't moved), so float arrays will be aligned ifimplemented as a
> separate type at all. This leaves only double. I think I won'tbother with
> larger alignment than a word and will conditionally copy doubles toa
> 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 otherpointers
> > > where this would break.pointer plus
> > this is not so good, I didn't know of this.
> I think this applies to Crays. char * is represented as a native
> byte offset within the word (has a larger sizeof), and all typesexcept char
> use an integral number of words. Their C compiler translatesbetween
> char*/void* representation and the representation of other pointerswhen the
> pointer is cast directly, but can't of course do this when thepointer
> storage is reinterpreted under a different type.like that.
> I don't know if there are any recent or non-exotic architectures
> 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...).