kernfach-devel Mailing List for Kernfach
Status: Planning
Brought to you by:
dilmah
You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(2) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
(13) |
Feb
(2) |
Mar
(1) |
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Denis L. <dl...@ra...> - 2005-05-01 16:29:17
|
Found nice link about SUN's new language Fortress: http://www.linux.org.ru/jump-message.jsp?msgid=895098&lastmod=1114963923698 |
From: Denis L. <dl...@ra...> - 2005-04-02 15:41:47
|
=D0=D2=C9=D7=C5=D4, > =F1 =CE=C1=D0=C9=D3=C1=CC =D0=D2=C5=C4=D7=C1=D2=C9=D4=C5=CC=D8=CE=D5=C0= =D3=D0=C5=C3=C9=C6=C9=CB=C1=C3=C9=C0 =D1=DA=D9=CB=C1 FeNiX (=D7=C5=D2=D3= =C9=D1 0.15). =F0=CF=CB=C1 =D7 =CE=C5=CA > =CD=CE=CF=C7=CF =DE=C5=C7=CF =CE=C5 =C8=D7=C1=D4=C1=C5=D4 =C9, =CD=CF=D6= =C5=D4 =C2=D9=D4=D8, =DE=D4=CF-=D4=CF =C5=DD=C5 =CE=C5 =CF=CB=CF=CE=DE=C1= =D4=C5=CC=D8=CE=CF (=CF=D3=CF=C2=C5=CE=CE=CF > =DC=D4=CF =CB=C1=D3=C1=C5=D4=D3=D1 =CD=CE=CF=D6=C5=D3=D4=D7=C5=CE=CE=CF= =C7=CF =CE=C1=D3=CC=C5=C4=CF=D7=C1=CE=C9=D1). =F7-=CF=C2=DD=C5=CD =D1 =D0= =CF=D3=D9=CC=C1=C0 =C5=C5 =D4=C5=C2=C5, =DE=D4=CF=C2=D9 =D0=CF=CB=C1=DA=C1= =D4=D8 > =CB=C1=CB=C9=CD =D0=D2=C9=CD=C5=D2=CE=CF =CD=CE=C5 =C8=CF=D4=C5=CC=CF=D3= =D8 =C2=D9 =D7=C9=C4=C5=D4=D8 =DC=D4=CF=D4 =D1=DA=D9=CB. =D4=C1=CD =D5 =D4=C5=C2=D1 =CE=C5 =CE=C1=D0=C9=D3=C1=CE=CF, =CB=C1=CB =CE= =C1 =DC=D4=C9 =CF=C2=DF=C5=CB=D4=D9 =CD=CF=D6=CE=CF =D3=D3=D9=CC=C1=D4=D8= =D3=D1. =F7=D3=C5=C7=C4=C1 =CC=C9 =CD=CF=D6=CE=CF =D0=CF=C4=D3=D4=C1=D7=CC= =D1=D4=D8 =D7=CD=C5=D3=D4=CF =C2=C1=DA=CF=D7=CF=C7=CF =D0=D2=CF=C9=DA=D7=CF=C4=CE=D9=CA. =ED=CF=D6=C5=DB=D8 =D7=D9=CC=CF=D6=C9=D4=D8 =D3=D0=C5=C3=C9=C6=C9=CB=C1=C3= =C9=C0 =D7 cvs, =D4=CF=CC=D8=CB=CF =D6=C5=CC=C1=D4=C5=CC=D8=CE=CF =D7 =D4= =C5=CB=D3=D4=CF=D7=CF=CD =D7=C9=C4=C5, =C1 =CE=C5 =D7 pdf: =D4=C5=CB=D3=D4=CF=D7=D9=CA =CC=C5=C7=CB=CF =C1=D0=C4=C5=CA=D4=C9=D4=D3=D1= , a =C2=C9=CE=C1=D2=CE=D9=CA pdf =C2=D5=C4=C5=D4 =D0=D2=C9 =CB=C1=D6=C4=CF= =CD =C1=D0=C4=C5=CA=D4=C5 =D7=D9=CB=C1=DE=C9=D7=C1=D4=D8=D3=D1 =C3=C5=CC=C9= =CB=CF=CD. > =EB=D3=D4=C1=D4=C9, =C8=CF=D4=C5=CC =D5 =D4=C5=C2=D1 =D3=D0=D2=CF=D3=C9= =D4=D8: =CB=C1=CB =C4=C5=CC=C1 =D3 kernfach ? =FE=D4=CF-=CE=C9=C2=D5=C4=D8= =C5=D3=D4=D8 =CE=CF=D7=CF=C7=CF ? =CE=D5 kernfach =D7=D3=C5 =C2=CF=CC=D8=DB=C5 =D0=D2=C5=D7=D2=C1=DD=C1=C5=D4= =D3=D1 =C9=DA =CF=D0=C9=D3=C1=CE=C9=D1 =D1=DA=D9=CB=C1 =D7 =CF=D0=C9=D3=C1= =CE=C9=C5 =C1=C2=D3=D4=D2=C1=CB=D4=CE=CF=CA =CD=C1=DB=C9=CE=D9. =FC=D4=C1 =CD=C1=DB=C9=CE=C1 =D5=CD=C5=C5=D4 =CF=D0=C5=D2=C9=D2=CF=D7=C1=D4= =D8 =D0=D2=C9=CD=C5=D2=CE=CF =D4=C5=CD=C9 =D6=C5 core values =DE=D4=CF =C9= =D2=C1=CE=D8=DB=C5. Core values =CD=CF=D6=CE=CF =CF=D2=C7=C1=CE=C9=DA=CF=D7=D9=D7=C1=D4=D8 =D7 =D3= =D0=C9=D3=CB=C9/=C4=C5=CB=C9. =F7 =C1=C2=D3=D4=D2=C1=CB=D4=CE=CF=CA =CD=C1= =DB=C9=CE=C5 =C5=D3=D4=D8 =CD=CE=CF=C7=CF =D0=D2=CF=C3=C5=D3=D3=CF=D7, =D5 =CE=C9=C8 =C5=D3=D4=D8 =D3=CF=D3=D4=CF=D1= =CE=C9=C5. =F3=CF=D3=D4=CF=D1=CE=C9=C5 =DC=D4=CF =D7o =D0=C5=D2=D7=D9=C8= =DE=D4=CF-=D4=CF =D4=C9=D0=C1 =D2=C1=C2=CF=DE=C5=C7=CF =D3=D4=C5=CB=C1 =D7= =E6=CF=D2=D4=C5, =CE=CF =D4=CF=CC=D8=CB=CF =D4=C1=CD =CD=CF=C7=D5=D4 =CC=C0=C2=D9=C5 =CF=C2= =DF=C5=CB=D4=D9 =C8=D2=C1=CE=C9=D4=D8=D3=D1. =EE=D5 =C9 =D7=CF =D7=D4=CF= =D2=D9=C8 =CE=C1=C2=CF=D2 =D3=C9=CD=D7=CF=CC=CF=D7 =CE=C1 =CB=CF=D4=CF=D2= =D9=C5 =DA=C1=C2=C1=CA=CE=C4=C5=CE=D9 =CB=C1=CB=C9=C5-=D4=CF =CF=C2=DF=C5=CB=D4=D9. =D7=D3=C5 =C2=CF=CC=D8=DB=C5 =C9 =C2=CF=CC=D8=DB=C5 =D0=D2=CF=D1=D7=CC=D1= =C5=D4=D3=D1 =C1=CE=C1=CC=CF=C7=C9=D1 =CD=C5=D6=C4=D5 =D2=C1=DA=D2=C1=C2=CF= =D4=CB=CF=CA =D4=C1=CB=CF=CA =C1=C2=D3=D4=D2.=CD=C1=DB=C9=CE=D9 =C9 =D2=C1= =DA=D2=C1=C2=CF=D4=CB=CF=CA =EF=F3. =F7=CF=DA=CE=C9=CB=C1=C5=D4 =D6=C5=CC=C1=CE=C9=C5 =CE=C1=D0=D2=C9=CD=C5=D2= =C4=CF=C2=C1=D7=C9=D4=D8 =D7 kernfach =C1=CE=C1=CC=CF=C7 systrace -- =C7= =D2=D5=C2=CF =C7=CF=D7=CF=D2=D1 =DE=D4=CF=C2=D9 =CD=CF=D6=CE=CF =C2=D9=CC=CF =CF=C7=D2=C1=CE=C9=DE=C9=D4=D8 =CB=D5=D3=CF=CB =CB=CF=C4=C1 = =D7 =D4=CF=CD =DE=D4=CF =CF=CE =CD=CF=D6=C5=D4 =C4=C5=CC=C1=D4=D8. |
From: Denis L. <dl...@ma...> - 2005-03-13 12:17:44
|
8NLJ18XULA0KDQrLwcvP188g1MXL1d3FxSDTz9PUz9HOycUgxMXMLCDQ0s/Fy9Qgxd3FINbJ 1z8/OikNCg0K9Nkg08/CydLBzNPRINDPxMfP1M/XydTYINPXz8og0drZyyDX2dPPy8/HzyDV 0s/XztEsDQrLwcsg0yDOyc0/DQoNCvDPINDP18/E1SBrZXJuZmFjaCwg0SDSxdvJzCDTxMXM wdTYIMXHzyDCz8zFxSDQz8jP1snNDQrOwSDmz9LULiAg/NTPINDP2tfPzMnUIMnawsXWwdTY IMvV3skgycTJz9TTy8nIINPLz8LPyy4NCvUgz8LZ3s7Px88g5s/S1MEg1yDT1MXLxSDNz9bO zyDI0sHOydTYINTPzNjLzyDDxczZxQ0K3snTzMEsINcgwcLT1NLBy9TOz80g09TFy8Uga2Vy bmZhY2ggzc/Wzs8gwtXExdQgyNLBzsnU2A0KzMDC2cUgz8LfxcvU2Swg1yDewdPUzs/T1Mkg xtXOy8PJySDJINfMz9bFzs7ZxSDT1MXLyS/T0MnTy8kuDQr0wcvJzSDPwtLB2s/NIM3P1s7P IMLVxMXUINDF0sXOxdPUySDE0sXXz9fJxM7VwCDT1NLVy9TV0tUNCtMg1dLP187RINPLz8LP yywgzsEg1dLP18XO2CDT1NLVy9TV0iDEwc7O2cguDQoNCvTBy9bFINDSxcTQz8zP1snUxczY zs8g0NLJINDB0tPJzsfFIMnTyM/Ezs/HzyDLz8TBIGtlcm5mYWNoDQrNz9bOzyDC1cTF1CDa wc3FztHU2CDQwdLTxdIgzsEg09fPwCDQ0s/J2tfPzNjO1cAgxtXOy8PJwC4NCg== |
From: Denis L. <dl...@ma...> - 2005-02-03 12:16:04
|
> Нет, не чушь! Статистический контроль типов можно сделать только для > аннотированных списков, в которых будут указываться типы параметров функций > и возвращаемых значений или придумав что-нибудь еще. > > Как, например узнать, что получится в результате (.PK (.RD pos) (1 (2 3)))? > Результат работы этого фрагмента зависит от того какое значение лежит в > переменной pos и это может быть либо список, либо целое число. Какая же > здесь возможна статистическая проверка, если значение pos может меняться как > угодно в результате работы программы, а тогда тип результирующего выражения > на этапе компиляции не определен. Наверное, это можно как-нибудь обойти. это вопрос того что компилятор должен знать что может возвратить (.RD pos) Это решается либо теми же аннотациями, либо в большинстве случаев (например локальные переменные) компилятор это может вывести самостоятельно. Я не вижу как списки мешают этому. Списки и динамическая типизация перпендикулярны. Еще раз -- gcc компилирует в промежуточный язык. Я не называю его лисп-подобным, но он построен на списках: http://olympus.het.brown.edu/cgi-bin/info2www?(gcc-295)RTL > Например, надо сделать, чтобы результатом .PK был всегда список, т.е. > (.PK 1 (1 (2 3))) вернет список (1) > (.PK 2 (1 (2 3))) вернет список ((2 3)) > для списков последнего вида можно ввести операцию .UL так, что > (.UL ((2 3))) вернет (2 3) > Правда, тогда непонятно, что делать с (.PK), который будет возвращен в > результате работы (.PK 1 (.QU(.PR .PR)))? Можно выйти из положения введя > операцию .UP, которая будет для списка (.PR) возвращать .PR и выполнять его. > Тогда надо писать так: > (.UP (.PK 1 (.QU (.PR .PR))) 1), что будет эквивалентно (.PR 1) > > Я думаю, что все это вполне логично. То что приходиться вводить несколько > операций для извлечения из одноэлементного списка объясняется так: > На самом деле мы определяем одну операцию .U*, перегруженную для возвращения > различных результатов. Можно обойти это если мы введем дополнительные > ключевые слова, которые будут обозначать тип возвращаемого значения > (.U EP (.PR)) - извлечет элемент типа EP - примитива выполнения, > (.U IV (1)) - извлечет целое число, > (.U FPV (0.75)) - извлечет вещественное число. > Кстати, упаковку в список можно разрешить выполнять автоматически, т.е. это > будет неявное приведение типа. Данные при этом не теряются. > > >FL все равно нужен чтобы превратить целое в float. > > Зачем он нужен? Множество целых чисел является подмножеством вещественных > поэтому преобразование целых в вещественные должно выполняться > автоматически, если это требуется для вычисления выражения. > > >Я против вещественных литералов. > > Не понятно : почему? > > >Со строковыми сложнее, учитывая действительно необходимость > >поддержки Unicode. > > В чем сложность? Стандартные символы ASCII пусть представляются как > печатаются, а расширенные указываются например так \FEA0, при этом для > русских символов такое преобразование из "привет" в двухбайтовый аналог > преобразовывать автоматически или с указанием кодировки. я потом углубленно это прочту, подумаю. > > чтобы сделать код читаемым нужно будет пользоваться библиотеками > > макроопределений. > > Зачем нужны макроопределения? Если они будут работать только как > подстановки, то это может вызвать трудно отлавливаемые ошибки. Лучше > реализовать все что нужно сразу. > >на Си будет писаться только транслятор kernfach->C. > >Все остальное на kernfach. В процессе написания нужно создать > >библиотеки макроопределений, которые сделают программирование > >на kernfach удобным. > > Вообще не понятен смысл макроопределений. Все равно все это будет > преобразовываться на этапе компиляции, а писать на kernfach без таких > библиотек ты не станешь, зачем тогда все усложнять? в языке есть core сущности, а есть синтаксический сахар. Они должны быть четко отделены. Кстати примеры: С--: http://www.cminusminus.org/ CIL: http://manju.cs.berkeley.edu/cil/ |
From: Nazarov M. <mi...@ra...> - 2005-02-02 05:50:21
|
Hi all! This text is probably useful to read http://cay.hotbox.ru/sl.pdf. It is "The Standart Lisp Report". |
From: Denis L. <dl...@ma...> - 2005-01-27 22:50:56
|
I've encountered following project developing new language, (and new OS btw): http://www.coyotos.org/docs/bitc-spec/bitc-spec.html I have not studied it in detail but this project seems to be quite similar to ours in spirit. |
From: Denis L. <dl...@ma...> - 2005-01-27 16:02:51
|
Just encountered: http://www.coyotos.org/docs/bitc-spec/bitc-spec.html Have not read yet but it seems to be quite similar to kernfach. |
From: Denis L. <dl...@ma...> - 2005-01-20 13:50:05
|
ok, I'll write BNF. Also we need to settle with exec entities. Maybe some entities are redundant and should be eliminated. For example, exec entity MR (metaroll) -- it can be expressed by other entities. I thougt about adding exec entity for matching patterns in lists, but it also seems to be redundant. Some entities still need to be added. In addition to annotation by predicate (every entity may be annotated by some predicate that should hold true for that entity), maybe we should add annotation of factorization. Every entity may be annotated by some equivalence relation. For example priorities -- they are just lists of integers but their actual values does not matter, only ordinal relation between them. Some comments about ML (mangle) and DM (demangle) -- why are they needed. As written in spec all entities in kernfach are either core values, or symbols, or lists. Core values are just values (integer, float, pointers and so on). Lists are just lists of entities. Symbols are symbols, they designate something, for example variables. But we need some way to construct complex symbols -- something like names of templates in C++. For that purpose there are mangle and demangle exec entities. For example we can construct complex symbol (ML (func 3)) -- it is analoguous to func< 3 > in C++. |
From: Nazarov M. <mi...@ra...> - 2005-01-20 07:02:17
|
>ok, I've written some very preliminary specification. >It is very incomplete, it still does not cover functions definitions and many more, only basics. Also it is very scarce >in details, it contains only short definitions. But have a look at it anyway. I think that we should write also syntax definition for kernfach in BNF ( Backus-Naur Form). It will be very useful in all our work. |
From: Nazarov M. <mi...@ra...> - 2005-01-20 07:02:17
|
Hi all ! I started write kernfach to C translator (KF2C) and I've written lexical analyzer for it. You can found this project in CVS repository http://cvs.sourceforge.net/viewcvs.py/kernfach/kf/KF2C/. I think that many parts of this translator are suitable to use in other translators from kernfach. |
From: Denis L. <dl...@sm...> - 2005-01-16 21:16:19
|
> > I think it is time to reach agreement about syntax of kernfach ( maybe > > approximately). > > I\'ll try to prepare preliminary specification for kernfach > in the next few days. ok, I've written some very preliminary specification. It is very incomplete, it still does not cover functions definitions and many more, only basics. Also it is very scarce in details, it contains only short definitions. But have a look at it anyway. I commited it to CVS repository at sourceforge. You can view it here: http://cvs.sourceforge.net/viewcvs.py/kernfach/kf/doc/TRPLKF.txt?view=markup (the text at this reference will change as I will commit new versions of the specification). The specification follows: 0. Design spirit. Design of Kernfach was driven by following intentions: it should provide ways to express as much as possible opportunities for optimization of generated compiled code as far we can stay machine independent. Some of those opportunities can be provided by certain high level abstractions. it should be simple and elegant. Occam's razor to the help. it should serve as a machine independent assembler, universal core programming language. it may sacrifice simplicity for a human if it can help to achieve other goals. If some features can be implemented at a preprocessor level, they should be. In other words: convenience for human is no excuse for bloat and quirks. 1. Source character set, words and kernfach source. Regular characters are: the 26 uppercase characters of Latin alphabet: A B C D E F G H I J K L M N O P Q R S T U V W X Y Z the 26 lowercase characters of Latin alphabet: a b c d e f g h i j k l m n o p q r s t u v w x y z the 10 decimal numbers: 0 1 2 3 4 5 6 7 8 9 the following 28 graphic characters: ! ? # @ $ - _ ; : ' " , . / + = * % ^ & < > { } [ ] \ Control characters are: the parentheses: ( ) the whitespace. Source Character Regular Set (SCRS) is the set of regular characters (and only them). Source Character Control Set (SCCS) is the set of control characters (and only them). Source Character Set (SCS) is the union of SCRS and SCCS. Word is a (finite) sequence of regular characters. Kernfach Source File (KSF) is a finite sequence of SCS characters having equal number of left and right parentheses. 2. Core values, symbols, lists and entities. Core value is one (and only one) of: integer value floating point value (FPV) memory location parallel evaluation slot memory area channel They will be desribed in detail further on. Symbol is a rooted tree having each leaf marked with a core value, and root marked with integer value zero. List is a rooted tree having each leaf marked with a core value or symbol, and root marked with integer value one. Entity is either core value, or symbol, or list. Every kernfach entity may be annotated with predicate that should hold true for that entity. Annotations will be explained in detail further on. Note that symbol can be viewed as a finite sequence of entities (such a process is called demangling). Also note that list can be viewed as a finite sequence of entities. 3. Evaluation. Every kernfach entity may be evaluated (and optionally annotated, but we will not cover annotation in this section). Evaluation is mapping from set of entities to set of entities. Core values and symbols evaluate to themselves. List evaluates following way -- it is viewed as a finite sequence of entities, first entitity in the list is evaluated, it is called exec entity further on. Then some action is executed depending on the exec entity yielding result of evaluation of this list. 4. Basic mappings. There shall be an implementation defined mapping from SCS into integer values. Every word in kernfach source represents a symbol. This symbol can be viewed as a sequence of integer values corresponding to regular characters being constituents of the word. 5. Basic exec entities. QU -- quote. Quote takes one argument and passes it as a result verbatim without any evaluation. It is distinct from all others exec entities in this regard, because it does not evaluates its argument. AN -- annotation. Annotation takes two arguments. It evaluates them independently and yields evaluated first argument annotated with second argument. FM -- frame. Frame takes three arguments. It evaluates them independently. After evaluation first argument shall be a symbol designating that frame, second argument shall be a list, and third argument shall be a list of initial priorities. Then FM evaluates all members of its second argument (list) independently regarding list of initial priorities and results in list of evaluated members. ML -- mangle. Mangle takes one argument. It evaluates it. After evaluation it shall be a list. Then mangle results symbol corresponding to that list. DM -- demangle. Demangle takes one argument. It evaluates it. After evaluation it shall be a symbol. Then demangle views this symbol as a sequence of entities and yields list of those entities as a result. MR -- metaroll. Metaroll takes three arguments. It evaluates them independently. Then it virtually loops using first argument as predicate of loop continuation and second argument as a loop step. For each loop iteration metaroll evaluates it third argument and eventually returns list of all those evaluations. PK -- pick. Pick takes two arguments. It evaluates them independently. After evaluation second argument shall be a list and first argument shall be an integer value pinning down some position in the list. Pick yilds element of list with this position as a return value. SL -- select. Select takes two arguments. It evaluates them independently. After evaluation first argument shall be a list and second argument shall be a predicate. Select returns the list containing elements of its first argument matching predicate in undeterministic order. DF -- define. Define takes three arguments. It evaluates them independently. After evaluation the first argument shall be a symbol, second argument shall be a predicate. Then it evaluates its third argument again with new variable added to the context of evaluation and yields it as a result. WR -- write. Write takes three arguments. It evaluates them independently. After evaluation the first argument shall be a symbol. Then it evaluates its third argument again with variable assigned with a second argument and yields it as a result. RD -- read. Read takes one argument. It evaluates it. After evaluation it shall be a symbol. Then it returns value of that symbol as a result. BR -- branch. Branch takes three arguments. It evaluates them independently. If the first argument after evaluation is an non-zero integer value then second argument get evaluated again and branch returns it as a result. Otherwise branch evaluates third argument again and returns it as a result. |
From: Denis L. <dl...@sm...> - 2005-01-11 07:20:46
|
> > I think we should write this translator in plain C99, even without any > > C++ extensions. > Why in plain C99? I not insist on using OOP but I plan to use C++ as > improved C. It has very useful features such as enums and it is possible to > declare variables anywhere in the code you need. plain C also has enums. Scattering declaration of variables everywhere -- not sure it is such a big merit.. OK, I do not insist on plain C, but suggest using C++ features only if they are really needed. > > If kernfach is syntactically just lists -- do you think we need to use any > > lex/yacc stuff? > I think that thanks to simply syntax of kernfach it is not necessary to use > such utils as lex and yacc. > > Although we may use them. What do you think about them ? Probably we do not need them for kernfach->C translator. Things will get more complicated when we will write C->kernfach and other translators. But I want those translators to be written in kernfach so it will be not much use for lex/yacc because they generate C code. > I think it is time to reach agreement about syntax of kernfach ( maybe > approximately). I\'ll try to prepare preliminary specification for kernfach in the next few days. |
From: Nazarov M. <mi...@ra...> - 2005-01-11 06:38:55
|
Hi all! >. I think we should write this translator in plain C99, even without any >C++ extensions. Why in plain C99? I not insist on using OOP but I plan to use C++ as improved C. It has very useful features such as enums and it is possible to declare variables anywhere in the code you need. >At home I have no Windows, only NetBSD, so it should be compilable with simple make and gcc. Because we decided make platform independent language I think It is proposed that our project should be compilable with make. >> I propose to use Microsoft Visual Studio .Net > Do you have a valid license for Visual Studio?;) There is good alternative to Visual Studio : DevC++. It is free software and there are versions both under Windows and under Linux( and maybe under NetBsd too). >If kernfach is syntactically just lists -- do you think we need to use any lex/yacc stuff? I think that thanks to simply syntax of kernfach it is not necessary to use such utils as lex and yacc. Although we may use them. What do you think about them ? I think it is time to reach agreement about syntax of kernfach ( maybe approximately). |
From: Denis L. <dl...@sm...> - 2005-01-09 16:00:50
|
> I think that first thing to be implemented should be translator > from kernfach to C. > Of course without any optimizations, just to see how it works. After implementing this translator, next things to do are: Stage 2 written in kernfach translator from C99 to kernfach. And optionally written in kernfach translators from couple of other languages (like C++, Fortran etc) to kernfach. By writing those translators we will achieve following goals: We will become confident in using kernfach, we'll be able to see its weaknesses and probably fix something in it. We will have a bulk of kernfach code to test our translators on it. We'll become assured that anything that can be expressed in other languages can be easily expressed in kernfach. Stage 3 written in kernfach optimized compiler from kernfach to i386 assembler. |
From: Denis L. <dl...@sm...> - 2005-01-09 14:47:01
|
Hi, > > I am still undecided about control structures for kernfach. > What about our previous discussion on this theme? There are some suitab= > le control structures. I incline to the solution with parallel evaluation of subexpressions with strict priorities assigned to them. By changing priorities dynamically we can pass control to and from any subexpression. Such a way sequential evaluation, coroutines, gotos and exceptions can be expressed. > I decide to start write code parallel to discussing conceptions. I prop > ose to use Microsoft Visual Studio .Net without > its features specified to Microsoft Windows Platform such as MFC and Wi > n API ( It is my favorite development instrument). > I think that it is time to write lexical analysis and some other > routines. ok, let\'s start it. I think that first thing to be implemented should be translator from kernfach to C. Of course without any optimizations, just to see how it works. OK with Visual Studio as your development platform, but I think we should write this translator in plain C99, even without any C++ extensions. At home I have no Windows, only NetBSD, so it should be compilable with simple make and gcc. Do you have a valid license for Visual Studio?;) If kernfach is syntactically just lists -- do you think we need to use any lex/yacc stuff? It seems that kernfach code will be very easy to parse. |
From: Nazarov M. <MI...@ya...> - 2005-01-09 13:04:50
|
Hi all! =20 >>=E1 =D7=CF=CF=C2=DD=C5, =CE=C1=D3=CB=CF=CC=D8=CB=CF =D1 =D0=CF=CE=D1=CC= =D7 >>kernfach (=CB=D3=D4=C1=D4=C9, =CF=C2=DF=D1=D3=CE=C9, =D0=CF=D6=C1=CC=D5= =CA=D3=D4=C1, =DC=D4=CF =CE=C1=DA=D7=C1=CE=C9=C5) =D0=D2=C5=C4=D0=CF=CC= =C1=C7=C1=C5=D4=D3=D1 >>=D7=D3=D4=D2=CF=C5=CE=CE=C1=D1=20 >>=D0=CF=C4=C4=C5=D2=D6=CB=C1 =D3=D0=C9=D3=CB=CF=D7=D9=C8 =D4=C9=D0=CF=D7= =C4=C1=CE=CE=D9=C8. =F4=C1=CB =D0=CF=DE=C5=CD=D5 =CE=C5 =D3=C4=C5=CC=C1= =D4=D8 =D7=D3=D4=D2=CF=C5=CE=CE=D5=C0 >>=D0=CF=C4=C4=C5=D2=D6=CB=D5 =C4=D2=D5=C7=C9=C8 >>=C4=C9=CE=C1=CD=C9=DE=C5=D3=CB=C9=C8 =D4=C9=D0=CF=D7 =C4=C1=CE=CE=D9=C8= =C9 =CF=D4=CB=C1=DA=C1=D4=D8=D3=D1 =CF=D4 =D5=CB=C1=DA=C1=D4=C5=CC=C5=CA= ? =2E.. >Spirit of kernfach as I see it is to stuff this language with >constructs enabling maximal optimization of code (either for speed, >or size, or power, or what else?). Do you see it is possible without = pointers?? =20 I think that all pointers=92 duties can be done by links and by introdu= cing built-in dynamic types such as vectors (dynamic arrays), lists, trees. Moreover I think that with or without pointers it is pos= sible to do maximal optimization of code (because vectors, lists and trees will be realized through pointers). =20 >I am still undecided about control structures for kernfach. =20 What about our previous discussion on this theme? There are some suitab= le control structures. =20 I decide to start write code parallel to discussing conceptions. I prop= ose to use Microsoft Visual Studio .Net without=20 its features specified to Microsoft Windows Platform such as MFC and Wi= n API ( It is my favorite development instrument).=20 I think that it is time to write lexical analysis and some other routin= es. =20 |
From: Denis L. <dl...@sm...> - 2005-01-09 10:40:32
|
one more idea for kernfach: I plan all evalutations will be parallel in the first place. But we will have priorities (lists of integers). Priorities are strict in the sense that no evaluation with lesser priority will be advanced if there is evaluation with higher priority in progress. Priorities can be changed in runtime. So with those priorities we can model sequential evaluation and some form of goto. I strive for having one construction able to express many different things. |
From: Denis L. <dl...@sm...> - 2005-01-06 18:25:30
|
Hi, ok I've had a lot of time to think about kernfach and a lot of cigarettes to smoke over it. Following is my current view of kernfach. All objects in kernfach are atoms or lists. There are two most "magic" words in kernfach: QU -- quote AE -- annotated eval QU just passes its argument without evaluating it. AE evaluates its first argument and annotates it with second argument. Annotation is some predicate that should be true about first argument. In order to be top-efficient kernfach should have some sort of static typization. I propose to have typization via predication. For example we will have some predicate true iff object has some particular type. I am still undecided about control structures for kernfach. -- Denis Lagno, PGP key fingerprint: F94F F38F 1895 E673 4374 9D63 2B9E FAB3 8E83 584C |
From: Denis L. <dl...@ma...> - 2004-12-07 13:03:51
|
Hi all, there is text probably useful to read: Towards improved optimization opportunities in C++0x http://www2.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1664.pdf |
From: Denis L. <dl...@ma...> - 2004-12-05 01:14:52
|
Hi, sorry for delay, I was on vacation and then switched to new job. Now I have not so much free time as before. > > насчет типов данных -- ты ничего не сказал про указатели > > Да, про них я как-то не подумал. А вообще, насколько я понял в > kernfach (кстати, объясни, пожалуйста, это название) предполагается встроенная > поддержка списковых типов данных. Так почему не сделать встроенную поддержку других > динамических типов данных и отказаться от указателей? Name "kernfach" was a product of no more than 20 minutes of thinking, so feel free to blame it. Fach is german (and also ukranian) word standing for "specialization" or "skill". "Kern" means just "core". I did not plan kernfach to have list as only basic data structure. Moreover having list as a basic data structure and abandoning pointers goes against spirit of kernfach. If we'd go that way we'll just reinvent Lisp. Spirit of kernfach as I see it is to stuff this language with constructs enabling maximal optimization of code (either for speed, or size, or power, or what else?). Do you see it is possible without pointers?? I plan that syntactic representation of a kernfach program should be organized as list(s) It does not mean that all datatypes will be lists. Those lists should exists at compile time preferrably. > > насчет clever if -- мне более симпатичен подход, когда > > можно некоторые места в коде пометить как события -- > > например, какая из ветвей if'а сработала, или в какую-то > > переменную произведена запись, и т.п. А отдельно можно > > задать (быть может, совместное) распределение вероятностей > > на событиях. > > Я не против, скорее я просто не знал как это реализовать и предложил > свой вариант. Напиши, пожалуйста, как ты предлагаешь эти ветки помечать? I propose to have expression like: (mark name_of_the_mark values) this sort of expression evaluates to nothing at compile time. If present it marks the list where it is encountered with name_of_the_mark=values. Also this mark is propagated to all lists enclosing given list provided that this mark is not overrided by a more high-level mark. For example, (mark event some_name optional_params) can be used to mark some event. Complementary (mark prob ((event1 event2 ...) 0.xxx) can be used to state that probability of combination of events is equal to some floating point constant. It may look in code like this: (if condition (1 (mark event x) (mark prob (x) 0.9) (2) ) Or you construct more complicated probability distributions envolving several events. Note that subexpressions of "sel" also can have different probabilities |
From: Denis L. <dl...@sm...> - 2004-11-08 23:14:23
|
Hi all, In this list we'll try to design programming language, and, I hope, eventually to implement compilers for it. In this first message to this list I post discussion at one russian-speaking forum, that incited creation of this project and this mailing list. It is in Russian, but I hope we'll try to use English further on. Разработка языка программирования. На страницу 1, 2 След. Начать новую тему Ответить на тему Список форумов Форумы ЦИТФорума -> Программирование Предыдущая тема :: Следующая тема Автор Сообщение Михаил Н. Зарегистрирован: 30.10.2004 Сообщения: 12 Откуда: Ростов-на-Дону Сообщение Добавлено: Сб Окт 30 2004 19:20 Разработка языка программирования. Ответить с цитатой _____________________________________________________________________________________ Здравствуйте! Я решил разработать новый язык программирования и ищу единомышлеников. Для начала хотелось бы разработать концепцию языка. А потом реализовать компилятор, IDE и другие нужные программы. Прошу откликнуться желающих этим заняться. Вернуться к началу Посмотреть профиль Отправить личное сообщение Отправить e-mail droopy Зарегистрирован: 28.07.2004 Сообщения: 93 Сообщение Добавлено: Вс Окт 31 2004 15:38 Ответить с цитатой _____________________________________________________________________________________ На каком уровне ты находишься? Какие книжки прочел? И что хочешь от нового языка программирования. Я знаю одного чела который всерьез считает что миру нужен новый язык программирования. Могу дать его почту. Но он ленивый. Вернуться к началу Посмотреть профиль Отправить личное сообщение Посетить сайт автора Гость Сообщение Добавлено: Вс Окт 31 2004 17:47 Ответить с цитатой _____________________________________________________________________________________ Цитата: На каком уровне ты находишься? Какие книжки прочел? И что хочешь от нового языка программирования. Я знаю одного чела который всерьез считает что миру нужен новый язык программирования. Могу дать его почту. Но он ленивый. Хорошо знаю C++, немного Assembler. Изучал книжки по разработке компиляторов : Костельцев "Построение интерпретаторов и компиляторов"; А.Ахо, Р. Сети, Дж. Ульман "Компиляторы: принципы, технологии, инструменты", P.D. Terry "COMPILERS AND COMPILER GENERATORS an introduction with C++", Д. Грис "Конструирование компиляторов для цифровых вычислительных машин" и другую литературу. Писал калькулятор на yacc и bison. В книге Костельцева расказывается про их аналог под Windows, который прилагался на диске к книжке. Чего я хочу от нового языка? Я хочу чтобы он был 1) Бесплатным. 2) Хотелось бы чтобы синтаксис был си- подобным. Правда я еще рассматривал возможность создания языка с русскими ключевыми словами (и может быть имеющего синтаксис приближенный к синтаксису русского языка), однако я не совсем уверен, что это хорошая идея. 3) Этот язык должен быть компилируемым. Лично мне не нравиться тенденция перехода к интерпретируемым языкам ( типа C#, Java, ...). 4) Объектно- ориентированный. 5) Встроенная поддержка различных полезных алгоритмов. 6) Более менее безопасным. В частности я думаю, что указатели, которые являются причиной многих ошибок будут совсем ненужны если сделать встроенный тип данных - динамический массив. Кстати, я хочу реализовать в нем поддержку строк с помощью встроенного типа данных. 7) И, может быть, много другого, чего я еще пока не придумал. А насчет того чела, ты лучше ему напиши (или скажи), чтобы он зашел в этот форум. Вернуться к началу Михаил Н. Зарегистрирован: 30.10.2004 Сообщения: 12 Откуда: Ростов-на-Дону Сообщение Добавлено: Вс Окт 31 2004 17:52 Ответить с цитатой _____________________________________________________________________________________ Забыл в предыдущем письме указать своё имя. Вернуться к началу Посмотреть профиль Отправить личное сообщение Отправить e-mail dilmah Зарегистрирован: 31.10.2004 Сообщения: 10 Сообщение Добавлено: Вс Окт 31 2004 21:52 Ответить с цитатой _____________________________________________________________________________________ я хочу 2 языка. Первый язык это domain specific язык. Он должен быть портабельным ассемблером. Тo есть машинно-независимым, остальные его фичи должны позволять компилятору генерировать эффективный код. Фичам которые могут быть реализованы на уровне макропроцессора в этом языке не место. В частности, никакого OO в нем не должно быть, только extension структур. Синтаксис у него предпочтительно лисп подобный. Второй язык это надстройка над первым, которая генерирует код на первом. (или как довесок, может генерировать код и на других языках, например TeX или VHDL). > 3) этот язык должен быть компилируемым. Лично мне не нравиться тенденция перехода к > интерпретируемым языкам ( типа C#, Java, ...). ну вообще-то, и байт-код джавы, и Intermediate Language компилируются.. > 6) Более менее безопасным. В частности я думаю, что указатели, которые являются причиной > многих ошибок будут совсем ненужны если сделать встроенный тип данных - динамический > массив. никакой безопасности в первом нижнем языке я, естественно, не планирую. Безопасность должна реализовываться соответствующей политикой программирования. Можно только думать о средствах, позволяющих посредством включения каких-то макроопределений в текст программы на втором языке, обеспечить enforcement этой политики. Вернуться к началу Посмотреть профиль Отправить личное сообщение Посетить сайт автора Михаил Н. Зарегистрирован: 30.10.2004 Сообщения: 12 Откуда: Ростов-на-Дону Сообщение Добавлено: Пн Ноя 01 2004 10:00 Ответить с цитатой _____________________________________________________________________________________ Цитата: я хочу 2 языка. Первый язык это domain specific язык. Он должен быть портабельным ассемблером. Тo есть машинно-независимым, остальные его фичи должны позволять компилятору генерировать эффективный код. Фичам которые могут быть реализованы на уровне макропроцессора в этом языке не место. В частности, никакого OO в нем не должно быть, только extension структур. Синтаксис у него предпочтительно лисп подобный. Логично, наверное. Только почему синтаксис лисп- подобный ? Какие в этом плюсы ? Приведи, пожалуйста, пример таких конструкций. ( Я с языком lisp не знаком. Только что-то слышал про него. Не уверен, что объективное). Цитата: Второй язык это надстройка над первым, которая генерирует код на первом. (или как довесок, может генерировать код и на других языках, например TeX или VHDL). С надстройкой над первым языком все понятно. А вот насчет TeX и VHDL не очень. TeX , насколько я знаю, это язык для простого создания книг, статей и.т.п. со всевозможными специальными символами ( Я, например, пишу на нем курсовые работы по математике). А вот про VHDL я ничего не слышал. Какого рода программы можно транслировать в эти языки ? Цитата: > 3) этот язык должен быть компилируемым. Лично мне не нравиться тенденция перехода к > интерпретируемым языкам ( типа C#, Java, ...). ну вообще-то, и байт-код джавы, и Intermediate Language компилируются.. Да, вроде бы это так. Только они, по-моему компилируются на этапе запуска приложения. ( Кстати, над этим можно еще подумать. Вроде-бы на основе такого подхода можно создавать оптимизированный платформо- независимый код. Правда, в случае с двумя языками , это ,наверно, не имеет значения.) Вернуться к началу Посмотреть профиль Отправить личное сообщение Отправить e-mail dilmah Зарегистрирован: 31.10.2004 Сообщения: 10 Сообщение Добавлено: Пн Ноя 01 2004 15:19 Ответить с цитатой _____________________________________________________________________________________ > Логично, наверное. Только почему синтаксис лисп- подобный ? > Какие в этом плюсы ? > Приведи, пожалуйста, пример таких конструкций. ( Я с языком lisp > не знаком. Только что-то слышал > про него. Не уверен, что объективное). просто мне хочется видеть первый язык неизбыточным. Так как все равно реально люди будут писать на втором языке-надстройке, то в нем нужно все делать настолько простым, единообразным и неизбыточным насколько возможно. И лисп-нотация типа (* 2 2) она как раз подходит для первого языка. И это уже задача второго языка-надстройки преобразовать 2*2 в (* 2 2). Примеры, почему так лучше. Например возьмем Си. В нем есть инструкция if. И отдельно, так как возникает желание элегантно включать условные вычисления в выражения, есть конструкция ?:. Это избыточно, ведь достаточно иметь одну конструкцию типа (if x y z). Пример второй. Иногда возникает потребность/желание инструментировать код. Например у нас на работе люди исследовали как будет работать их код на процессорах с разными характеристиками кэшей. Для этого они его инструментировали, но Си/Си++ код они не отважились инструментировать, поэтому инструментировали прямо ассемблерный листинг. Чтобы инструментировать Си/Си++ код нужен нехилый парсер. Или интструментировать код для получения данных о покрытии кода. И прочие манипуляции с кодом, меняющие его, собирающие какую-то статистику. Мне хочется чтобы подобные операции было легко проводить с кодом на первом языке. > С надстройкой над первым языком все понятно. А вот насчет TeX и > VHDL не очень. TeX , насколько я знаю, это > язык для простого создания книг, статей и.т.п. со всевозможными > специальными символами ( Я, например, пишу на > нем курсовые работы по математике). А вот про VHDL я ничего не > слышал. Какого рода программы можно транслировать > в эти языки ? VHDL я сам не знаю, но на нем как-то описывают устройство микросхем. Собственно, Кнут же когда-то делал cweb -- и писал на нем -- это аналог второго языка-надстройки, который как раз и генерировал одновременно код на Си (или Паскале) и документацию на TeX'e. Вернуться к началу Посмотреть профиль Отправить личное сообщение Посетить сайт автора Михаил Н. Зарегистрирован: 30.10.2004 Сообщения: 12 Откуда: Ростов-на-Дону Сообщение Добавлено: Пн Ноя 01 2004 20:05 Ответить с цитатой _____________________________________________________________________________________ В общем, насчет первого языка программирования я согласен: хорошая идея. Можно даже попробовать сделать lisp-подобный синтаксис. А вообще у меня возникла идея сделать его мультисинтаксическим, чтобы те же выражения можно было бы записать и в виде lisp-выражений и в виде asm-выражений , например. А что ты думаешь насчет языка высокого уровня (второго)? Вернуться к началу Посмотреть профиль Отправить личное сообщение Отправить e-mail dilmah Зарегистрирован: 31.10.2004 Сообщения: 10 Сообщение Добавлено: Вт Ноя 02 2004 00:59 Ответить с цитатой _____________________________________________________________________________________ Михаил Н. писал(а): А что ты думаешь насчет языка высокого уровня (второго)? о нем у меня еще менее четкое представление чем о первом.. Ну то есть с одной стороны это должно быть что-то типа мощного макропроцессора. С другой стороны нужно избежать кошмара с обычной текстовой заменой -- то есть как-то типизировать его.. Одной из основных задач языков программирования должно быть описание интерфейсов. С первым языком тут все понятно, интерфейс на нем будет Си-подобным. Второй язык же должен экспортировать и макроопределения, и тут пока туман в голове. У меня в планах было сперва реализовать первый язык, оставляя как раз все вопросы которые можно решить во втором языке на потом. Вернуться к началу Посмотреть профиль Отправить личное сообщение Посетить сайт автора Михаил Н. Зарегистрирован: 30.10.2004 Сообщения: 12 Откуда: Ростов-на-Дону Сообщение Добавлено: Вт Ноя 02 2004 10:29 Ответить с цитатой _____________________________________________________________________________________ dilmah писал(а): Первый язык это domain specific язык. Все хотел спросить: А что ты понимаешь под domain specific языком? dilmah писал(а): Ну то есть с одной стороны это должно быть что-то типа мощного макропроцессора. С другой стороны нужно избежать кошмара с обычной текстовой заменой -- то есть как-то типизировать его.. А почему именно макропроцессор? Мне бы хотелось сделать второй язык самостоятельным языком. В частности, чтобы он мог не только транслироваться в первый язык, но и напрямую в exe-модуль. dilmah писал(а): Одной из основных задач языков программирования должно быть описание интерфейсов. С первым языком тут все понятно, интерфейс на нем будет Си-подобным. Можно чуть подробнее про интерфейсы. Что означает "Си-подобный интерфейс"? dilmah писал(а): У меня в планах было сперва реализовать первый язык, оставляя как раз все вопросы которые можно решить во втором языке на потом. Я не уверен, что понимаю тебя правильно, поэтому мне кажется, что лучше разобрать все вопросы про первый язык сразу, а со вторым хотя бы разобраться с его назначением и особенностями реализации. Вооще, если не сложно, напиши пожалуйста все свои соображения по поводу первого языка более подробно. Вернуться к началу Посмотреть профиль Отправить личное сообщение Отправить e-mail Гость Сообщение Добавлено: Вт Ноя 02 2004 17:34 Ответить с цитатой _____________________________________________________________________________________ > Все хотел спросить: А что ты понимаешь под domain specific языком? это язык, основная задача которого описывать дела в конкретной области. Например Си это язык для описания кода который будет выполняться на процессоре. TeX/troff языки для описания документов. VHDL для описания интегральных схем. Недавно натыкался на текст по теме http://arxiv.org/abs/cs.PL/0409016 > А почему именно макропроцессор? Мне бы хотелось сделать второй > язык самостоятельным языком. В частности, чтобы он мог не только > транслироваться в первый язык, но и напрямую в exe-модуль. а что даст прямая трансляция?? Выигрыш времени компиляции вряд ли. Зато даст запутанность. Никакого выигрыша в эффективности кода при прямой трансляции быть не может по определению -- потому что в первый язык нужно включить все что может помочь генерировать эффективный код. А второму языку останется только задача повысить удобность программирования для человека. Все сегодняшние компиляторы Си++ сперва транслируют во что-то промежуточное, и только потом это промежуточное оптимизируют. > Можно чуть подробнее про интерфейсы. Что означает "Си-подобный > интерфейс"? ну, такой интерфейс может предоставлять некий элементарный набор типов, плюс структуры, массивы и юнионы из них. Может экспортировать переменные этих типов. И предоставлять entry points функций.. > Вооще, если не сложно, напиши пожалуйста все свои соображения > по поводу первого языка более подробно. Есть две основных конструкции выражений: (seq x y z) и (ind x y z) они вычисляют подвыражения x y z.. соответственно последовательно или независимо. Результат -- это список из вычисленных подвыражений. Есть (pick list i j k). Он выдает список состоящий из элементов i, j, k списка list. В такой нотации, например оператор запятая в Си (a, b) запишется как: (pick (seq a b) 2) Есть конструкция для цикла. В принципе последовательный цикл избыточен при наличии goto. Есть последовательный цикл: Сишный цикл for ( i = 0, j = 0; i < 100; ++i ) j *= i; будет выглядеть как-то типа: (seqfor (ind (= i 0) (= j 0) (< i 100) (++ i) (*= j i)) Есть параллельный цикл. Сишный цикл for ( i = 0; i < 100; ++i ) a[i] *= 2; будет выглядеть как-то типа: (indfor (ind (= i 0) (= j 0) (< i 100) (++ i) (*= ([] a i) 2)) Есть if: (if (== i 2) a b) Еще есть (sel list N). sel берет список list и возвращает список из только N из них (любых) которые завершились и вернули не nil. Если все вернули nil, то и sel возвращает nil. Таким образом можно описать switch. Например: switch ( i ) { case 0: a; break; case 1: b; break; case 2: c; break; } выглядит как: (sel (ind (if (== i 0) a nil) (if (== i 1) b nil) (if (== i 2) c nil)) 1) В то же время switch ( i ) { case 0: a; break; case 1: b; break; case 2: c; break; default: d; break; } выглядит как: (sel (seq (sel (ind (if (== i 0) a nil) (if (== i 1) b nil) (if (== i 2) c nil)) 1) d) 1) Я конечно понимаю, что синтаксис получается страшноватый.. Все это не окончательно решено. Отдельный вопрос это структуры управления. Они должны при желании дать возможность реализовать исключения и т.д. Возможно это будут какие-то goto с аргументами, я еще не разобрался, тут желательно заимствовать опыт лиспоподобных языков. Вернуться к началу dilmah Зарегистрирован: 31.10.2004 Сообщения: 10 Сообщение Добавлено: Вт Ноя 02 2004 17:46 Ответить с цитатой _____________________________________________________________________________________ гостем запостил, и теперь редактировать не могу.. > Все хотел спросить: А что ты понимаешь под domain specific языком? я понимаю это язык, основная задача которого описывать дела в конкретной области. Например Си это язык для описания кода который будет выполняться на процессоре. TeX/troff языки для описания документов. VHDL для описания интегральных схем. Недавно натыкался на текст по теме http://arxiv.org/abs/cs.PL/0409016 > А почему именно макропроцессор? Мне бы хотелось сделать второй > язык самостоятельным языком. В частности, чтобы он мог не только > транслироваться в первый язык, но и напрямую в exe-модуль. а что даст прямая трансляция?? Выигрыш времени компиляции вряд ли. Зато даст запутанность. Никакого выигрыша в эффективности кода при прямой трансляции быть не может по определению -- потому что в первый язык нужно включить все что может помочь генерировать эффективный код. А второму языку останется только задача повысить удобность программирования для человека. Все сегодняшние компиляторы Си++ сперва транслируют во что-то промежуточное, и только потом это промежуточное оптимизируют. > Можно чуть подробнее про интерфейсы. Что означает "Си-подобный > интерфейс"? ну, такой интерфейс может предоставлять некий элементарный набор типов, плюс структуры, массивы и юнионы из них. Может экспортировать переменные этих типов. И предоставлять entry points функций.. > Вооще, если не сложно, напиши пожалуйста все свои соображения > по поводу первого языка более подробно. Есть две основных конструкции выражений: (seq x y z) и (ind x y z) они вычисляют подвыражения x y z.. соответственно последовательно или независимо. Результат -- это список из вычисленных подвыражений. Есть (pick list i j k). Он выдает список состоящий из элементов i, j, k списка list. В такой нотации, например оператор запятая в Си (a, b) запишется как: (pick (seq a b) 2) Есть конструкция для цикла. В принципе последовательный цикл избыточен при наличии goto. Есть последовательный цикл: Сишный цикл for ( i = 0, j = 0; i < 100; ++i ) j *= i; будет выглядеть как-то типа: (seqfor (ind (= i 0) (= j 0)) (< i 100) (++ i) (*= j i)) Есть параллельный цикл. Сишный цикл for ( i = 0; i < 100; ++i ) a[i] *= 2; будет выглядеть как-то типа: (indfor (= i 0) (< i 100) (++ i) (*= ([] a i) 2)) Есть if: (if (== i 2) a b) Еще есть (sel list N). sel берет список list и возвращает список из только N из них (любых) которые завершились и вернули не nil. Если все вернули nil, то и sel возвращает nil. Таким образом можно описать switch. Например: switch ( i ) { case 0: a; break; case 1: b; break; case 2: c; break; } выглядит как: (sel (ind (if (== i 0) a nil) (if (== i 1) b nil) (if (== i 2) c nil)) 1) В то же время switch ( i ) { case 0: a; break; case 1: b; break; case 2: c; break; default: d; break; } выглядит как: (sel (seq (sel (ind (if (== i 0) a nil) (if (== i 1) b nil) (if (== i 2) c nil)) 1) d) 1) Я конечно понимаю, что синтаксис получается страшноватый.. Все это не окончательно решено. Отдельный вопрос это структуры управления. Они должны при желании дать возможность реализовать исключения и т.д. Возможно это будут какие-то goto с аргументами, я еще не разобрался, тут желательно заимствовать опыт лиспоподобных языков. Последний раз редактировалось: dilmah (Вт Ноя 02 2004 18:03), всего редактировалось 1 раз Вернуться к началу Посмотреть профиль Отправить личное сообщение Посетить сайт автора dilmah Зарегистрирован: 31.10.2004 Сообщения: 10 Сообщение Добавлено: Вт Ноя 02 2004 18:00 Ответить с цитатой _____________________________________________________________________________________ еще в первом языке планируется возможность пометки отдельных вещей в коде, как событий, и можно будет задавать вероятностные распределения на этих событиях. Просто вероятности могут учитываться при оптимизации, а явные нули/единицы могут рассматриваться как ассерты. Вернуться к началу Посмотреть профиль Отправить личное сообщение Посетить сайт автора Михаил Н. Зарегистрирован: 30.10.2004 Сообщения: 12 Откуда: Ростов-на-Дону Сообщение Добавлено: Вт Ноя 02 2004 19:40 Ответить с цитатой _____________________________________________________________________________________ dilmah писал(а): я понимаю это язык, основная задача которого описывать дела в конкретной области. Например Си это язык для описания кода который будет выполняться на процессоре. TeX/troff языки для описания документов. VHDL для описания интегральных схем. И в какой же именно области должен описывать дела первый язык? Я бы хотел сделать язык как минимум для "описания кода, который будет выполняться на процессоре". Или ты хочешь сделать универсальный язык для описания всего ( типа как XML)? dilmah писал(а): Я конечно понимаю, что синтаксис получается страшноватый.. Все это не окончательно решено. .... тут желательно заимствовать опыт лиспоподобных языков Да, синтаксис действительно страшноватый и, кроме того, трудно читабельный. Зачем вообще делать синтаксис lisp-подобным? Мне кажется лучше придумать что-нибудь не слишком сложное для разбора ( как я понимаю, из-за этого и зашел разговор о lisp-подобном языке. Хотя я не понимаю: какие трудности могут быть с разбором, например, сишного синтаксиса? Я так думаю, что при использовании подходящего инструментария (lex,bison, zubr, Cocol/R, ...) это не принципиально.) и в тоже время более приятное глазам. Мне как-то ближе даже ассемблерный синтаксис. Со своей стороны хочу предложить реализовать стековую реализацию этого первого языка. Суть такова: в стек кладутся операнды для операций, а затем вызывается операция, которая берет параметры в стеке, производит с ними какую-то манипуляцию, а затем помещает в стек результат. Тогда выражение вида x=(a+b)*c можно записать, например, так: push a push b add push c mul set x или так #a #b + #c * = x (Здесь # означает: поместить в стек, +,*,= - соответствующие операции.) Ну или что-то в этом духе. dilmah писал(а): еще в первом языке планируется возможность пометки отдельных вещей в коде, как событий, и можно будет задавать вероятностные распределения на этих событиях. Просто вероятности могут учитываться при оптимизации, а явные нули/единицы могут рассматриваться как ассерты. Что-то не очень понятно, что означает фраза "вероятностные распределения на событиях". Для чего это может пригодиться? Вернуться к началу Посмотреть профиль Отправить личное сообщение Отправить e-mail dilmah Зарегистрирован: 31.10.2004 Сообщения: 10 Сообщение Добавлено: Вт Ноя 02 2004 21:32 Ответить с цитатой _____________________________________________________________________________________ Дополнение к моему предыдущему постингу: seqfor и indfor стоит заменить на просто for который должен как бы генерировать формальный список. Этот список потом можно вычислить с помощью seq или ind. У sel стоит убрать аргумент N.. > И в какой же именно области должен описывать дела первый язык? Я бы хотел сделать язык как > минимум для "описания кода, который будет выполняться на процессоре". Или ты хочешь > сделать универсальный язык для описания всего ( типа как XML)? первый язык -- да, для "описания кода, который будет выполняться на процессоре". второй язык желательно должен быть способен генерировать текст на любом другом языке. У меня есть подозрение что если отойти от лисповского синтаксиса, то будут получаться те же дублирования управляющих конструкций -- отдельно в виде инструкций, отдельно в виде операторов. (как оператор запятая и оператор ?: в Си). Также у меня есть подозрение что с помощью комбинации ind, for и sel можно замутить более мощные конструкции чем с помощью только стековой машины. Кроме того мне не понятно чем этот ассемблер стековой машины будет лучше тех что уже есть. > Что-то не очень понятно, что означает фраза "вероятностные распределения на событиях". Для > чего это может пригодиться? Ну.. Как классический пример, по разному компилировать if в зависимости от вероятностей ветвей. Опять таки, нули/единицы использовать как ассерты. Чем умнее компилятор тем из большего кол-ва ассертов он сможет извлечь пользу.. Вернуться к началу Посмотреть профиль Отправить личное сообщение Посетить сайт автора Показать сообщения: [все сообщения.........] [Начиная со старых] Перейти Начать новую тему Ответить на тему Список форумов Форумы ЦИТФорума -> Программирование Часовой пояс: GMT + 4 На страницу 1, 2 След. Страница 1 из 2 Copyright © 1997-2000 CIT, © 2001-2004 CIT Forum Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Разработка языка программирования. На страницу Пред. 1, 2 Начать новую тему Ответить на тему Список форумов Форумы ЦИТФорума -> Программирование Предыдущая тема :: Следующая тема Автор Сообщение Михаил Н. Зарегистрирован: 30.10.2004 Сообщения: 12 Откуда: Ростов-на-Дону Сообщение Добавлено: Ср Ноя 03 2004 19:25 Ответить с цитатой _____________________________________________________________________________________ dilmah писал(а): У меня есть подозрение что если отойти от лисповского синтаксиса, то будут получаться те же дублирования управляющих конструкций -- отдельно в виде инструкций, отдельно в виде операторов. (как оператор запятая и оператор ?: в Си). .... Также у меня есть подозрение что с помощью комбинации ind, for и sel можно замутить более мощные конструкции чем с помощью только стековой машины. Может быть. Но суть моего предложения была не в этом. Меня интересует упрощение синтаксиса. А насчет так называемого дублирования: не вижу ни чего страшного в операции запятой и ?: в си. (хотя, если честно, я не совсем понимаю что имеется в виду под "дублированием"). dilmah писал(а): Ну.. Как классический пример, по разному компилировать if в зависимости от вероятностей ветвей. А как по-разному можно компилировать if ( разве, что если вероятность ветви равна 0, то исключить ее)? dilmah писал(а): Кроме того мне не понятно чем этот ассемблер стековой машины будет лучше тех что уже есть. А зачем вообще создавать компилятор lisp-а? Ведь предложенный синтаксис, кажется, не сильно отличается от его синтаксиса. Вернуться к началу Посмотреть профиль Отправить личное сообщение Отправить e-mail dilmah Зарегистрирован: 31.10.2004 Сообщения: 10 Сообщение Добавлено: Ср Ноя 03 2004 21:46 Ответить с цитатой _____________________________________________________________________________________ > Может быть. Но суть моего предложения была не в этом. Меня интересует упрощение > синтаксиса. А насчет так называемого дублирования: не вижу ни чего страшного > в операции запятой и ?: в си. (хотя, если честно, я не совсем понимаю что имеется > в виду под "дублированием"). Есть инструкция if. Кроме этого, для возможности вставлять if в выражения есть оператор ?:. Это дублирование. Есть последовательное вычисление выражений expr1; expr2; Кроме этого для возможности включать последовательное вычисление в выражения есть запятая. expr1, expr2; Это дублирование. Лисп-синтаксис и так предельно прост. Делать синтаксис простым для человека задача второго языка.. > А как по-разному можно компилировать if ( разве, что если вероятность ветви равна 0, > то исключить ее)? во первых в некоторых процессорах условный бранч можно снабдить хинтом какой исход более вероятен. вo вторых, если известно что одна ветвь маловероятна то ее можно вынести подальше, повышая локальность более вероятного кода.. Ну по разному можно if скомпилировать, это факт. > А зачем вообще создавать компилятор lisp-а? Ведь предложенный синтаксис, кажется, > не сильно отличается от его синтаксиса. Синтаксис не отличается. Но мне пока казалось что это не совсем лисп.. Язык который получается, по меньшей мере, не может быть менее эффективен чем Си. Вернуться к началу Посмотреть профиль Отправить личное сообщение Посетить сайт автора dilmah Зарегистрирован: 31.10.2004 Сообщения: 10 Сообщение Добавлено: Чт Ноя 04 2004 00:11 Ответить с цитатой _____________________________________________________________________________________ Любой язык задает описание выполнения на какой-то виртуальной машине. Вирт. машина первого языка желательно должна хорошо ложиться на возможные процессоры. Кроме того вирт. машина должна иметь много степеней свободы, предоставляя компилятору больше возможности положить ее на реальную. Кроме того вирт. машина языка должна содержать какие-то более высокоуровневые абстракции (в каком-то смысле это тоже степени свободы). Но абстракции конечно такие которые могут помочь генерировать более оптимальный код. Те же объекты это не та абстракция которая может помочь генерировать оптимальный код -- они не дают ничего что не могут дать структуры. Виртуальная машина ассемблера стековой машины это стековая машина. Это слишком жесткое задание вирт. машины. Вирт. машина лиспа это все-таки машина оперирующая списками. В той модели первого языка которую я вижу списки существуют только на этапе компиляции, вирт. машина самого языка больше похожа на Сишную. Это были так, общефилософские соображения.. Вернуться к началу Посмотреть профиль Отправить личное сообщение Посетить сайт автора Михаил Н. Зарегистрирован: 30.10.2004 Сообщения: 12 Откуда: Ростов-на-Дону Сообщение Добавлено: Чт Ноя 04 2004 12:09 Ответить с цитатой _____________________________________________________________________________________ dilmah писал(а): Есть инструкция if. Кроме этого, для возможности вставлять if в выражения есть оператор ?:. Это дублирование. Есть последовательное вычисление выражений expr1; expr2; Кроме этого для возможности включать последовательное вычисление в выражения есть запятая. expr1, expr2; Это дублирование. А чем плохо такое дублирование? Могу предположить, что только идейными соображениями. dilmah писал(а): Лисп-синтаксис и так предельно прост. Делать синтаксис простым для человека задача второго языка.. А вообще зачем нужен первый язык? Почему вместо него не использовать существующий, например ассемблер, для которого и так есть оптимальные компиляторы, или не генерить для второго языка сразу код на ВМ? Только не надо говорить, что для первого языка можно сделать эффективную кодогенерацию: для любого языка можно это сделать. Вообще я задаю этот вопрос, потому что из твоих слов выходит, что человек писать на первом языке не будет, т.е. он будет промежуточным шагом между вторым языком и ВМ ( или кодом на конкретном процессоре). Вернуться к началу Посмотреть профиль Отправить личное сообщение Отправить e-mail dilmah Зарегистрирован: 31.10.2004 Сообщения: 10 Сообщение Добавлено: Чт Ноя 04 2004 18:11 Ответить с цитатой _____________________________________________________________________________________ > А чем плохо такое дублирование? Могу предположить, что только идейными соображениями. скорее соображениями вкуса. Не мне судить хорошего ли, но моего. И мои вкусовые ощущения для меня очень важны. > А вообще зачем нужен первый язык? Почему вместо него не использовать существующий, > например ассемблер, для которого и так есть оптимальные компиляторы, или не генерить для > второго языка сразу код на ВМ? Только не надо говорить, что для первого языка можно > сделать эффективную кодогенерацию: для любого языка можно это сделать. Вообще я задаю этот > вопрос, потому что из твоих слов выходит, что человек писать на первом языке не будет, > т.е. он будет промежуточным шагом между вторым языком и ВМ ( или кодом на конкретном > процессоре). ну то есть для тебя нормально ассемблер одного процессора скомпилировать в другой? не понял что значит для любого языка можно сделать эффективную кодогенерацию? Если степеней свободы много то можно. Если же есть куча жестких ограничений, то чтобы гарантировать такое же поведение кода на отличающемся процессоре придется эмулировать эти ограничения. Кстати, скоро у всех 20-ядерные девайсы в компах будут стоять.. имхо, то что ты планируешь хорошо для курсового проекта, или чтобы приобрести опыт написания компиляторов и облегчить нахождение работы. Ничего больше. Вернуться к началу Посмотреть профиль Отправить личное сообщение Посетить сайт автора Гость Сообщение Добавлено: Чт Ноя 04 2004 21:55 Ответить с цитатой _____________________________________________________________________________________ dilmah писал(а): скорее соображениями вкуса. Не мне судить хорошего ли, но моего. И мои вкусовые ощущения для меня очень важны. Да... Как говорится: на вкус и цвет товарищей нет. Мне, например, сишный синтаксис нравится намного больше и кажется, что он очень понятный. dilmah писал(а): ну то есть для тебя нормально ассемблер одного процессора скомпилировать в другой? Я не это имел в виду. Про ассемблер я писал, имея в виду случай когда надо разработать компилятор для конкретной машины, а на случай многоплатформенности я думаю подойдет ВМ. Мне же вот что непонятно: если код с первого языка будет транслироваться в код на виртуальной машине, а второго языка в первый, то зачем нужен промежуточный шаг - первый язык. dilmah писал(а): не понял что значит для любого языка можно сделать эффективную кодогенерацию? Если степеней свободы много то можно. Если же есть куча жестких ограничений, то чтобы гарантировать такое же поведение кода на отличающемся процессоре придется эмулировать эти ограничения. Ну хотя бы кодогенерацию на виртуальную машину. ( может я чего-то недопонимаю в этом деле, т.к. разработкой програм для множества различных процессоров я не занимался). dilmah писал(а): Кстати, скоро у всех 20-ядерные девайсы в компах будут стоять.. А что это такое? dilmah писал(а): имхо, то что ты планируешь хорошо для курсового проекта, или чтобы приобрести опыт написания компиляторов и облегчить нахождение работы. Ничего больше. Ну для курсового проекта мне это не надо ( к компъютерам мой курсовой проект не имеет никакого отношения), а насчет опыта : было бы неплохо. А вообще-то я хотел просто написать какой нибудь серьезный и интересный язык программирования ( наверное, его можно было бы потом использовать в дальнейшем), реализовать какие нибудь новые свежие идеи. Цитата: Ничего больше. Кстати, а для чего еще может быть хороша разработка нового языка программирования? И какие у тебя планы на создаваемый язык? dilmah писал(а): Есть инструкция if. Кроме этого, для возможности вставлять if в выражения есть оператор ?:. Это дублирование. Есть последовательное вычисление выражений expr1; expr2; Кроме этого для возможности включать последовательное вычисление в выражения есть запятая. expr1, expr2; Это дублирование. И еще, насчет дублирования: мне кажется, что в языке СИ эти операции, в принципе, являются дополнительными возможностями, такими же как и оператор switch, предоставляемыми именно для удобства, но если в твоем вкусе отсутсвие такого дублирования, то почему нельзя взять за основу сишный синтаксис и урезать ненужную функциональность? Кстати я хочу не обязательно сишный синтаксис. В принципе в синтаксисе каждого языка программирования есть что-то полезное или удобное. Почему бы не выбрать самые "хорошие вещи" из каждого? Да, а для каких процессоров, например ты предполагаешь переносимость? Вернуться к началу dilmah Зарегистрирован: 31.10.2004 Сообщения: 10 Сообщение Добавлено: Пт Ноя 05 2004 02:20 Ответить с цитатой _____________________________________________________________________________________ > Я не это имел в виду. Про ассемблер я писал, имея в виду случай когда надо разработать > компилятор для конкретной машины, а на случай многоплатформенности я думаю подойдет ВМ. > Мне же вот что непонятно: если код с первого языка будет транслироваться в код на > виртуальной машине, а второго языка в первый, то зачем нужен промежуточный шаг - первый язык. a.. наверно я непонятно про ВМ написал. конечно, первый язык уже напрямую нужно в код конкретных процессоров транслировать. Я имел в виду что любой язык неявно определяет ВМ и является ее кодом. В стандарте Си++ прямо записано: # 1.8 Program execution [intro.execution] # # 1 The semantic descriptions in this International Standard define a # parameterized nondeterministic abstract machine. This International # Standard places no requirement on the structure of conforming imple- # mentations. In particular, they need not copy or emulate the struc- # ture of the abstract machine. Rather, conforming implementations are # required to emulate (only) the observable behavior of the abstract # machine as explained below..... Единственно, что код этой ВМ (сишный код) содержит в себе более высокоуровневые вещи, чем просто ассемблерный код. Ну то есть например можно определить структуру, а конкретная ее раскладка в памяти остается на усмотрение компилятора. Но все равно какие-то ограничения эта ВМ накладывает -- память состоит из char'ов, объект это непрерывный регион памяти из целого числа char'ов. разные объекты имеют разные адреса и т.п. > т.к. разработкой програм для множества различных процессоров я не занимался). я тоже.. > > Кстати, скоро у всех 20-ядерные девайсы в компах будут стоять.. > А что это такое? ну вроде все ведущие производители процессоров уперлись в предел увеличения последовательной скорости и планируют многоядерные процессоры. Может быть даже пару мощных ядер + много менее мощных (и менее энергопотребляющих) > Ну для курсового проекта мне это не надо ( к компъютерам мой курсовой проект не имеет > никакого отношения), а насчет опыта : было бы неплохо. А вообще-то я хотел просто написать > какой нибудь серьезный и интересный язык программирования ( наверное, его можно было бы > потом использовать в дальнейшем), реализовать какие нибудь новые свежие идеи. > Кстати, а для чего еще может быть хороша разработка нового языка программирования? И какие > у тебя планы на создаваемый язык? эстетическое удовольствие Smile ну и опыт. курсовые у меня в прошлом (и тоже не имели отношения к программированию). язык может быть первым шагом к написанию своей ОС. И тогда первый язык может играть роль платформообразующего, машинно-независимым ассемблером этой ОС.. > И еще, насчет дублирования: мне кажется, что в языке СИ эти операции, в принципе, являются > дополнительными возможностями, такими же как и оператор switch, предоставляемыми именно > для удобства, но если в твоем вкусе отсутсвие такого дублирования, то почему нельзя взять > за основу сишный синтаксис и урезать ненужную функциональность? Кстати я хочу не > обязательно сишный синтаксис. В принципе в синтаксисе каждого языка программирования есть > что-то полезное или удобное. Почему бы не выбрать самые "хорошие вещи" из каждого? Семантически хорошие вещи конечно заимствовать нужно -- тот же sel(ect) -- наверняка его аналог есть в Оккаме. Но синтаксис.. Если хотеть уметь вставлять в выражения произвольные управляющие конструкции языка, то лисповый синтаксис лучше. И он наиболее прост и естественен. > Да, а для каких процессоров, например ты предполагаешь переносимость? я пользователь NetBSD. И мне очень нравится ее портируемость на много архитектур (хотя я использую только x86). Закладка на максимальную портабельность потенциально означает более чистый и продуманный дизайн. Конечно, первый компилятор первого языка нужно делать для i386, а потом видно будет. Вернуться к началу Посмотреть профиль Отправить личное сообщение Посетить сайт автора async Зарегистрирован: 05.11.2004 Сообщения: 1 Сообщение Добавлено: Пт Ноя 05 2004 08:47 Насчет разработки языка Ответить с цитатой _____________________________________________________________________________________ Михаил Н. Идея конечно хорошая, но спешу тебя огорчить знание C++ и асемблера маловатою Поскольку если ты хочешь разработать толковый язык внести новый синтаксис и сделать из него конфетку то тут нужно знание ПК и мнемоники. слышал о таком? так вот в чем вся загвоздка а так бы мы уже все писали свои языки и компиляторы Wink Вернуться к началу Посмотреть профиль Отправить личное сообщение ICQ Number Гость Сообщение Добавлено: Пт Ноя 05 2004 12:43 Re: Насчет разработки языка Ответить с цитатой _____________________________________________________________________________________ > тут нужно знание ПК и мнемоники. это наверно пипец как круто.. Вернуться к началу Михаил Н. Зарегистрирован: 30.10.2004 Сообщения: 12 Откуда: Ростов-на-Дону Сообщение Добавлено: Пт Ноя 05 2004 16:46 Re: Насчет разработки языка Ответить с цитатой _____________________________________________________________________________________ async писал(а): Михаил Н. Идея конечно хорошая, но спешу тебя огорчить знание C++ и асемблера маловатою Поскольку если ты хочешь разработать толковый язык внести новый синтаксис и сделать из него конфетку то тут нужно знание ПК и мнемоники. слышал о таком? так вот в чем вся загвоздка а так бы мы уже все писали свои языки и компиляторы Wink А что, такое мнемоника? Это так называемые opcodes? Ну я их не то чтобы знаю, но представление имею, а также нашел intel'овский help по этому делу. Ну а вообще все что нужно я думаю можно при необходимости узнать. Вернуться к началу Посмотреть профиль Отправить личное сообщение Отправить e-mail Михаил Н. Зарегистрирован: 30.10.2004 Сообщения: 12 Откуда: Ростов-на-Дону Сообщение Добавлено: Пт Ноя 05 2004 17:00 Ответить с цитатой _____________________________________________________________________________________ dilmah писал(а): я пользователь NetBSD. И мне очень нравится ее портируемость на много архитектур (хотя я использую только x86). А я пользовался ОС QNX. Мне она очень понравилась. Она кстати тоже мультиплатформенная( правда я тоже пользуюсь только x86). dilmah писал(а): Закладка на максимальную портабельность потенциально означает более чистый и продуманный дизайн. Это наверно правильно, только как можно разрабатывать многоплатформенный язык, работая при этом только с одной платформой? dilmah писал(а): Конечно, первый компилятор первого языка нужно делать для i386, а потом видно будет. Согласен. Ну может будем уже делать что-нибудь конкретное? (Хотя бы оформим основные положения). Я кстати открыл свой e-mail. Так что пиши. Вернуться к началу Посмотреть профиль Отправить личное сообщение Отправить e-mail Показать сообщения: [все сообщения.........] [Начиная со старых] Перейти Copyright © 1997-2000 CIT, © 2001-2004 CIT Forum Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. ------- Forwarded Message Subject: programming language design From: dl...@sm... Date: Sat, 6 Nov 2004 15:08:09 +0300 Tогда нужно определиться с дизайном языка(ов). Давай кидать идеи, какие конструкции, опять же какой синтаксис можно иметь в языке. Я все-таки на самом деле хочу 2 языка. В первый кидать те конструкции которые можно назвать примитивами. А то что легко реализуется преобразованием текста -- как в макропроцессоре -- кидать во второй язык. Как пример приведу 2 конструкции. Первая -- иметь специальный примитив для задания конечного автомата. Я считаю что это не должно быть в первом языке -- потому что конечный автомат straigtforward задается свитчем -- а свитч нормально записывается sel'ом. Вообще sel я считаю хорошим примитивом для первого языка -- потому что sel говорит "дайте мне результат ЛЮБОГО подвыражения выдавшего не nil. это дает компилятору какую-то свободу -- и простор для оптимизации. Вторая конструкция -- поиск регулярных выражений. Эта конструкция по моему может быть в какой-то форме включена в первый язык. Вообще давай идеи любых конструкций -- в каком-то из двух языков она место обязательно найдет. Мне самому нравится стиль программирования на шелле с пайпами -- пайпы в каком-то виде нужно включить как базовый тип в первый язык. А сам стиль поддерживать во втором языке, может быть в виде макроопределений. Как минимум, стандартную библиотеку языков нужно писать под BSD-like лицензией, компиляторы желательно тоже. Первый компилятор по моему нужно писать на Си -- который будет компилировать первый язык в Си -- без особых оптимизаций, просто чтобы работало. А остальные компиляторы писать уже на новых языках -- заодно станет ясно, что в них нужно изменить. -- Denis Lagno, PGP key fingerprint: F94F F38F 1895 E673 4374 9D63 2B9E FAB3 8E83 584C ... [truncated message content] |