LINUX.ORG.RU

Расширение синтаксиса

 ,


1

3

Сейчас принято расширять синтаксис, в основном, с помощью макросов. Но макросистемы достаточно сложны, и требуют времени на изучение. Между тем, можно же расширять синтаксис путем непосредственного изменения исполнителя. Если дело касается совместной разработки, макросы еще, возможно имеют какой-то смысл. Но в других случаях их применение, как мне кажется, совершенно не обоснованно.

Зачем, например, мне, изучать макросистемы, если я пишу код один? Не проще ли мне писать мини-язык под задачу, и расширять его по мере надобности путем изменения самого исполнителя?

К тому же, синтаксис этот становится куда более сладким и органичным. А язык — несравненно более гибкий и мощный. Любой каприз без каких-либо ограничений.

Ответ на: комментарий от ozkriff

Да какая разница, на чем реализован исполнитель? Это второстепенно, по-моему.

terminator-101 ()

У тебя в голове какаша

Зачем, например, мне, изучать макросистемы, если я пишу код один? Не проще ли мне писать мини-язык под задачу, и расширять его по мере надобности путем изменения самого исполнителя?

А не всё ли равно если первоначальный язык - CL?

ados ★★★★★ ()
Последнее исправление: ados (всего исправлений: 2)

макросы позволяют инкрементально расширять язык

x4DA ★★★★★ ()
Ответ на: комментарий от x4DA

Профит невелик. Мне открыть файл кода исполнителя и подправить его не трудно.

terminator-101 ()

незачем, проще

anonymous ()

Но в других случаях их применение, как мне кажется, совершенно не обоснованно.

Ты уже написал быструю реализацию регэкспов, ничтожество?

Не проще ли мне писать мини-язык под задачу, и расширять его по мере надобности путем изменения самого исполнителя?

Ну напиши эффективный «исполнитель» (что бы это ни было в твоей шизофреничной башке) для регулярных выражений.

anonymous ()

Ты не пишешь код один. Когда будешь смотреть на свой код, написанный 2+ года назад, будешь воспринимать его как написанный кем-то другим.

holuiitipun ()
Ответ на: комментарий от holuiitipun

Ты не пишешь код один.

Ты чо, ты только что оскорбил всю ЛNСП-братию. Для них работа в коллективе — это зашквар и западло.

(Но мы-то с вами знаем, что это просто бугурт от того, что из энтерпрайза/науки/промышленности их погнали ссаными тряпками.)

anonymous ()
Ответ на: комментарий от ados

CL

кстати, схема вот очень хорошо умеет в dsl, а как с этим делом у common lisp?

Deleted ()
Ответ на: комментарий от Deleted

кстати, схема вот очень хорошо умеет в dsl, а как с этим делом у common lisp

Также. Единственная разница между макросами схемы и CL — работа с лексическим окружением, в котором запущен макрос. Для dsl это не важно.

При использовании даже в CL чуть легче: можно менять синтаксис на кусок файла, а не на модуль целиком.

monk ★★★★★ ()

Не проще ли мне писать мини-язык под задачу, и расширять его по мере надобности путем изменения самого исполнителя?

Не проще.

Но макросистемы достаточно сложны, и требуют времени на изучение.

Инструмент надо изучить один единственный раз - и после этого он всегда будет тебе помогать. В результате - огромная эконмия времени и усилий.

anonymous ()
Ответ на: комментарий от terminator-101

Мне открыть файл кода исполнителя и подправить его не трудно.

Но разобраться в макросистеме проще чем в коде исполнителя.

anonymous ()
Ответ на: комментарий от terminator-101

Мне открыть файл кода исполнителя и подправить его не трудно.

ORLY? Если я тебе скажу три своих хотелки в трех разных исполнителях, ты готов взять и быстро решительно их реализовать? Если тебе не трудно, конечно.

А вообще кончай спамить тегами, заебал уже.

staseg ★★★★★ ()

Хватит уже лепить на свои высеры таг lisp. Заипал.

Oxdeadbeef ★★★ ()

А что там изучать-то собственно?

buddhist ★★★★★ ()

А если в разных модулях тебе надо несколько дслей, то что будешь делать? Хранить несколько исполнителей и помнить, где какой использовать? Или с помощью бондажа и дисциплины не писать пересекающиеся дсли, чтобы всё можно было свалить в одну кучу?

anonymous ()
Ответ на: комментарий от anonymous

То-то я думаю почему инженера на разработку квантового компьютера нанимают писать код на sbcl.

loz ★★★★★ ()
Последнее исправление: loz (всего исправлений: 1)
Ответ на: комментарий от anonymous

А если язык можно создать без регулярных выражений?

loz ★★★★★ ()

Не проще ли мне писать мини-язык под задачу

Да-да! Чувак начни уже, начни что-нибудь писать. Лучше что-нибудь полезное для себя, ну или хотя-бы примеры из книжки. Напиши «исполнителя» языка со «сладким и органичным» синтаксисом - покажи всем как ты клепаешь «мини-языки под задачи» (кстати, очень интересно, какие-такие сложные задачи ты там решаешь с помощью мини языков?). А макросистемы действительно достаточно сложны, и требуют времени на изучение. Видимо, это так. Ведь, вместо создания пятитысячной говнотемы, ты бы уже разобрался давно? Верно? Ты ведь не такой тупой как тут говорят?

anonymous ()

Чем это отличается от макросов? Ну, кроме того, что свой мини-язык уже сложнее по определению.

turtle_bazon ★★★★ ()
Ответ на: комментарий от turtle_bazon

Чем это отличается от макросов?

Именно простотой и расширяемостью. Ты должен писать макрос внимательно следя за квотированием, правилами скопа, думать о том, когда он раскроется, и прочее, тогда как я просто напишу if(input===«bar»)(handle input whatEver_You_Want_and_All_Rules_Sucks)

terminator-101 ()
Ответ на: комментарий от loz

Нет. Там написано

This script demonstrates how to use the built in parse

functionality of Rebol to create an internal DSL. А я говорю о чистом DSL, то есть, просто язык с нуля под задачу.

terminator-101 ()
Ответ на: комментарий от terminator-101

Ну сделать интерпретатор который будет читать файлы с dsl и выполнять их не проблема вобщем-то. Что значит с нуля под задачу не совсем понятно, ты хочешь с нуля реализовать все от сложения до конкатенации строк?

loz ★★★★★ ()
Ответ на: комментарий от terminator-101

Ты действительно считаешь, что проще свой миниязык? Ну тогда язык будет сильно ограниченным, если его интерпретатор писать проще, чем макрос.

turtle_bazon ★★★★ ()
Ответ на: комментарий от turtle_bazon

Ну тогда язык будет сильно ограниченным, если его интерпретатор писать проще, чем макрос.

Ну почему же? Берём L++ для примера. Получаем скорость C++ (что невозможно на чистом Lisp/Scheme), но при этом возможность доопределять синтаксис так, как нравится.

Если скобки не нравятся, то можно вспомнить Groovy. На базе которого делаются вполне симпатичные DSL, запускаемые из Java. И, опять же, без особых ограничений

monk ★★★★★ ()
Ответ на: комментарий от loz

Конкатенацию строк реализовать несложно, кстати. Арифметику свою не обязательно, если нет какой-то специфичной задачи.

terminator-101 ()
Ответ на: комментарий от turtle_bazon

язык будет сильно ограниченным

На самом деле, это заблуждение. Как правило, чем проще язык, тем он мощней. Обилие фич вместе с усложнением накладывают массу ограничений.

terminator-101 ()
Ответ на: комментарий от turtle_bazon

Кроме того, любая фича source-языка будет работать и в target-языке, если мы этого хотим. Это вообще не вопрос.

terminator-101 ()
Ответ на: комментарий от terminator-101

Кроме того, любая фича source-языка будет работать и в target-языке, если мы этого хотим. Это вообще не вопрос.

Это если у тебя макросы. Если самописный интерпретатор - то не будет.

anonymous ()
Ответ на: комментарий от terminator-101

Твой язык не умеет не то что в векторы, но даже флоаты. Вперед, расширяй минимальную парашу до уровня, на котором аналог BLAS писать не стыдно.

anonymous ()
Ответ на: комментарий от monk

Берём L++ для примера. Получаем скорость C++ (что невозможно на чистом Lisp/Scheme),

Который интерпретируется ракетой... Хм... Что-то тут не так. :) Да и в самом L++ очень даже встречается define-syntax.

Groovy. На базе которого делаются вполне симпатичные DSL

Ну и где эти DSL? Точнее, сколько разных DSL на груви можно сделать и насколько сильно расширять?

turtle_bazon ★★★★ ()
Ответ на: комментарий от turtle_bazon

Насчет форта — хз, но, конкретно, CL и Racket — это не простые языки. Могут с плюсами запросто потягаться в уродстве и неконсистентности дизайна. Простые — это, например, смоллток, селф (особенно), в какой-то степени (в плане синтаксиса) scheme R<6RS. Попсовые же лиспы спроектированы так, чтобы быть понятными быдлу, но не концептуально простыми.

anonymous ()
Ответ на: комментарий от anonymous

Только странное - быдло их не понимает. То ли IT совсем скатилась, то ли ошибочка вышла, не для быдла делали.

lovesan ★★ ()
Ответ на: комментарий от anonymous

Твой язык не умеет не то что в векторы, но даже флоаты.

Ошибка. Запомните: «Не уметь в Гугл», но «Не уметь во векторы»!

anonymous ()
Ответ на: комментарий от lovesan

Не понимает, потому что в массе не стремится. Отталкивает синтаксис, в основном, а от практического освоения толку мало, потому и не идет в массы. С точки зрения семантики, они максимально приближены к алгол-стайл-языкам. Сравни, например с lisp-3, или даже Interlisp. Это день и ночь. Лисп изначально был экстремально динамичным языком. Очень медленным и очень выразительным.

anonymous ()
Ответ на: комментарий от turtle_bazon

Нет, я, в данном случае, про метациклический интерпретатор, если рассматривать простой случай.

terminator-101 ()
Ответ на: комментарий от turtle_bazon

Который интерпретируется ракетой

Зачем интерпретируется? Компилируется g++ и запускается.

Да и в самом L++ очень даже встречается define-syntax.

Так я же говорю, DSL. Расширяемый. Но раскрывается не в ракетку, а в C++.

Ну и где эти DSL? Точнее, сколько разных DSL на груви можно сделать и насколько сильно расширять?

http://www.slideshare.net/glaforge/going-to-mars-with-groovy-domainspecific-l...

monk ★★★★★ ()
Ответ на: комментарий от anonymous

Розенталь устарел, в Лурку не умеешь?

anonymous ()

Если макросистемы для тебя сложны, то забей обо всём этом думать. Если о лиспе, то запомнить 3 простых правила сложнее чем мифически «менять исполнитель»? В любом случае самое простое что можно сделать с языком это eDsl, остальное на порядок сложнее.

pseudo-cat ★★★ ()
Ответ на: комментарий от pseudo-cat

Если о лиспе, то запомнить 3 простых правила сложнее чем мифически «менять исполнитель»?

Макросистема более ограничена в синтаксисе. Например, в Racket «меняя исполнитель» я могу сделать такие синтаксисы:

Honu:

#lang honu
// A for loop that iterates between two bounds. 
for x = 1 + 5 to 10 do 
  printf("x is ~a\n" x) 
  
// Similar to above but shows a block of expressions in the body 
for x = 1 to 10 do { 
 var y = x + 1; 
 printf("x ~a y ~a\n", x, y) 
} 
  
// A for loop that iterates over a list of numbers 
for x in [1, 2, 3] do { 
 printf("x ~a\n", x); 
} 

Datalog:

#lang datalog
parent(john, douglas).
parent(bob, john).
parent(ebbon, bob).
ancestor(A, B) :- parent(A, B).
ancestor(A, B) :- 
    parent(A, C), 
    ancestor(C, B).
ancestor(A, B)?

Python:

#lang python
from "racket" import time

def sieve(n):
  primes = [True] * (n+1)
  counter = 0
  for i in range(2,n):
    if primes[i]:
      counter = counter + 1
      for j in range(i*i, n, i):
        primes[j] = False
  return counter

print time(sieve(10000000))

Макросами такое никак.

monk ★★★★★ ()
Ответ на: комментарий от monk

Ну на самом деле если без переписывания лексера - то вполне ок делается на макросах. А если новый лексер нужен - то да, беда. Кстати у меня попытка написать #lang python сразу закрывает др.Ракет. Не встерчал такой проблемы?

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.